AI agents have graduated from chat windows. They now book meetings, update customer records, query internal databases, a

AI முகவர்கள் இப்போது வெறும் சாட் விண்டோக்களோடு நின்றுவிடவில்லை. அவை இப்போது கூட்டங்களை முன்பதிவு செய்கின்றன, வாடிக்கையாளர் பதிவுகளைப் புதுப்பிக்கின்றன, உள் தரவுத்தளங்களை (internal databases) ஆய்வு செய்கின்றன மற்றும் நிதிப் பரிவர்த்தனைகளைத் தூண்டுகின்றன. ஆலோசகராக இருந்து செயல்பாட்டாளராக (operator) மாறும் இந்த மாற்றம், அபாயத்தைப் பற்றிய அனைத்தையும் மாற்றுகிறது. மென்பொருள் பரிந்துரைப்பதைக் நிறுத்திவிட்டுச் செய்யத் தொடங்கும் போது, ஒவ்வொரு API endpoint-உம் ஒரு சாத்தியமான நுழைவு வாயிலாக மாறுகிறது. பாரம்பரிய பாதுகாப்பு மாதிரிகள் கணிக்கக்கூடிய மனித நடத்தையைச் சுற்றியே கட்டமைக்கப்பட்டன: ஒரு நபர் உள்நுழைகிறார் (log in), தெரிந்த பாதைகளில் கிளிக் செய்கிறார் மற்றும் வெளியேறுகிறார் (log out). தன்னாட்சி முகவர்கள் (Autonomous agents) அந்த முறைகளைப் பின்பற்றுவதில்லை. அவை வினாடிகளில் நூற்றுக்கணக்கான அழைப்புகளை (calls) லூப் செய்கின்றன, மீண்டும் முயற்சிக்கின்றன மற்றும் கிளைகளாகப் பிரிகின்றன. மனிதர்களால் தொடங்கப்படும் கோரிக்கைகளுக்காகத் தொடக்கத்தில் வடிவமைக்கப்பட்ட API அடுக்கு, இப்போது தொடர்ச்சியான தானியங்கி அழுத்தத்தை எதிர்கொள்கிறது. உங்கள் பாதுகாப்பு முறைகள் இன்னும் கடந்த காலாண்டில் எழுதப்பட்ட நிலையான விதிகளையே நம்பியிருந்தால், தரவு கசிவு மற்றும் அங்கீகரிக்கப்படாத அணுகலுக்கு நீங்கள் கதவைத் திறந்து வைத்திருக்கிறீர்கள் என்று அர்த்தம். ஒவ்வொரு அழைப்பும் நடக்கும்போதே அதை மதிப்பீடு செய்யும் நிகழ்நேரத் தடுப்பு (real-time defense) உங்களுக்குத் தேவை.

முகவர் அதிகாரங்களை மட்டுப்படுத்துங்கள் (Limit Agent Privileges)

முகவர் பயன்பாட்டில் (agent deployment) செய்யப்படும் ஒற்றை மற்றும் மிகவும் ஆபத்தான குறுக்குவழி என்பது, ஒரு சக்திவாய்ந்த API சாவியை (API key) ஒப்படைப்பதாகும். ஒரு சாவி அனைத்து அமைப்புகளுக்கும் அனைத்து அணுகல்களையும் வழங்குகிறது. ஒரு தாக்குதல் நடத்துபவர், விஷத்தன்மை கொண்ட ப்ராம்ப்ட் (poisoned prompt) அல்லது கடத்தப்பட்ட ஒருங்கிணைப்பு (hijacked integration) மூலம் முகவரைத் தாக்கினால், அவர்கள் முழு அமைப்பின் கட்டுப்பாட்டையும் பெற்றுவிடுவார்கள். மீட்புப் பணி ஒரு கனவு nightmares ஆகிவிடும், ஏனெனில் அதன் பாதிப்பு விளிம்பு (blast radius) உங்கள் மின்னஞ்சல் சேவை முதல் உங்கள் உற்பத்தித் தரவுத்தளம் (production database) வரை அனைத்தையும் உள்ளடக்கும்.

அந்தப் பழக்கத்தை உடனடியாகத் தவிருங்கள். ஒப்படைக்கப்பட்ட அங்கீகாரத்திற்காக (delegated authorization) OAuth 2.0 மூலம் தொடங்குங்கள். முகவர் ஒரு தனிப்பட்ட சூப்பர் யூசராக (superuser) அங்கீகரிக்கப்படக் கூடாது. அதற்குப் பதிலாக, முகவர் மற்றும் அது சேவை செய்யும் இறுதிப் பயனரை (end user) பிரதிநிதித்துவப்படுத்தும் ஒரு டோக்கனை (token) அது வைத்திருக்க வேண்டும். மனித அமர்வு (human session) முடிந்துவிட்டால், முகவரின் அணுகலும் அதனுடன் முடிந்துவிட வேண்டும்.

Token Exchange இதை நடைமுறைக்குக் கொண்டுவருகிறது. முகவருக்கு இப்போது சரியாக என்ன தேவையோ அதற்கு மட்டும் வரையறுக்கப்பட்ட குறுகிய கால டோக்கன்களை வழங்கவும். ஒரு கால அட்டவணை முகவர் (scheduling agent), காலண்டரை வாசிக்கவும் அழைப்புகளை அனுப்பவும் அனுமதியைப் பெறலாம், ஆனால் காலண்டர் கட்டமைப்பை நீக்கவோ அல்லது ஊதிய API-களை (payroll APIs) அணுகவோ கூடாது. ஒரு தாக்குதல் நடத்துபவர் டோக்கனை இடைமறித்தால், அதன் துஷ்பிரயோகத்திற்கான கால அவகாசம் மிகக் குறைவாகவே இருக்கும்.

Context-Bound Scopes மற்றொரு அடுக்கைச் சேர்க்கிறது. ஒவ்வொரு டோக்கனையும் 'read-only' (வாசிப்பு மட்டும்) நிலைக்கு மாற்றவும். முகவர் தரவை எழுத வேண்டியிருந்தால் (உதாரணமாக, ரீஃபண்ட் செய்தல் அல்லது ஒப்பந்தத்தைப் புதுப்பித்தல்), ஒரு மனித அங்கீகாரக் கதவை (human approval gate) அமல்படுத்தவும். பணம் நகரும்போது, கணக்குகள் மாறும்போதோ அல்லது பதிவுகள் மறையும்போதோ, மாடலே அதைத் தீர்மானிக்க அனுமதிக்காதீர்கள். அனுமதி என்பது அந்தத் தருணத்திற்குப் பொருந்த வேண்டும், அதிகபட்ச அனுமதியாக இருக்கக்கூடாது.

Ephemeral Windows இந்தச் சுழற்சியை முழுமையாக முடிக்கிறது. டோக்கன் ஆயுட்காலத்தை நாட்களாக அல்லாமல் நிமிடங்களாக வைத்திருக்கவும். ஒரு சிறிய ஊடுருவலின் போது பெறப்பட்ட டோக்கன், ஒரு தாக்குதல் நடத்துபவர் அதை மீண்டும் பயன்படுத்த முயற்சிக்கும் போது பயனற்றதாகிவிட வேண்டும். இதைத் தொடர்ந்து சுழலும் ஒரு பூட்டு போலக் கருதவும்.

உங்கள் CRM-லிருந்து லீட் தரவை (lead data) படித்து, உங்கள் mail API மூலம் தொடர் மின்னஞ்சல்களை அனுப்பும் ஒரு விற்பனைத் தானியங்கி முகவரை (sales automation agent) எடுத்துக்கொள்வோம். ஒரு நிலையான அட்மின் சாவியைப் பயன்படுத்துவதற்குப் பதிலாக, முகவர் உங்கள் அடையாள வழங்குநரிடமிருந்து (identity provider) 15 நிமிட டோக்கனைப் பெறுகிறது. அந்த டோக்கன் CRM வாசிப்பு மற்றும் மின்னஞ்சல் அனுப்புவதற்கு அனுமதிக்கிறது, ஆனால் தொடர்புகளை நீக்குவதையும் பில்லிங் அணுகலையும் தடுக்கிறது. முகவர் முழு தரவுத்தளத்தையும் ஏற்றுமதி செய்யச் சொல்லும் சந்தேகத்திற்குரிய கட்டளையை எதிர்கொண்டால், அந்த எல்லை (scope) அந்த முயற்சியைத் தடுத்துவிடும்.

மறைமுக ப்ராம்ப்ட் இன்ஜெக்ஷனைத் தடுத்தல் (Stop Indirect Prompt Injection)

Prompt injection என்பது இப்போது சாட்பாட்களுக்கான ஒரு சாதாரண விளையாட்டு அல்ல. முகவர் யுகத்தில் (agentic era), இது மின்னஞ்சல் மூலம் அனுப்பப்படும் தொலைதூரக் குறியீடு இயக்கம் (remote code execution) போலச் செயல்படுகிறது.

இதோ ஒரு தெளிவான சூழல். ஒரு முகவர் கூட்டங்களை ஏற்பாடு செய்ய பயனரின் இன்பாக்ஸைக் கண்காணிக்கிறது. ஒரு செய்தியின் உள்ளே, ஒருவேளை கண்ணுக்குத் தெரியாத உரை அல்லது இணைப்பில் உள்ள மெட்டாடேட்டாவில் (metadata), அனைத்து இன்வாய்ஸ்களையும் ஒரு வெளி முகவரிக்கு அனுப்பவும் அசல் இன்வாய்ஸ்களை நீக்கவும் போன்ற ஒரு கட்டளை மறைந்திருக்கலாம். முகவர் அந்த மின்னஞ்சலைப் படிக்கிறது, அந்த விஷத்தன்மை கொண்ட உரையை ஒரு முறையான கணினி கட்டளையாகத் தவறாகப் புரிந்துகொள்கிறது, மேலும் API-களை அழைக்கத் தொடங்குகிறது. முகவரே அங்கீகரிக்கப்பட்டிருப்பதால், அந்தத் தீய கோரிக்கைகள் சாதாரண வழிகள் வழியாகச் செல்கின்றன. இதன் விளைவாக, சாதாரண நடத்தை போலத் தோன்றும் அங்கீகரிக்கப்படாத தரவு வெளியேற்றம் (data exfiltration) நிகழ்கிறது.

உங்கள் முதல் பாதுகாப்பு முறையானது கடுமையான உள்ளீட்டு சரிபார்ப்பு (input validation) ஆகும். AI உருவாக்கும் ஒவ்வொரு அளவுருவையும் (parameter) அது நிரூபிக்கப்படும் வரை நம்பகமற்றதாகக் கருதவும். உங்கள் API கேட்வேயில் JSON-schema சரிபார்ப்பைச் செயல்படுத்தவும். முகவர் ஒரு வாடிக்கையாளர் பதிவைக் கோரினால், அந்தத் தரவு (payload) ஒரு எதிர்பார்க்கப்படும் அடையாள எண்ணைக் (identifier) கொண்டிருப்பதை கேட்வே சரிபார்க்க வேண்டும்; அது ஒரு வைல்ட்கார்டு (wildcard) அல்லது வழக்கத்திற்கு மாறாகப் பெரிய அளவிலான கோரிக்கையாக இருக்கக்கூடாது. உங்கள் பேக்எண்டிற்கு (backend) சென்றே அடையாமல், தவறான அல்லது வழக்கத்திற்கு மாறான கோரிக்கைகளை நிராகரிக்கவும்.

இரண்டாவதாக, பதில் பாதையில் (response path) தரவு கசிவுத் தடுப்பு வடிகட்டிகளை (data exfiltration filters) செயல்படுத்தவும். API பதில்கள் AI-ஐ சென்றடைவதற்கு முன் ஆய்வுக்கு உட்படுத்தப்பட வேண்டும். ரகசியங்கள், அங்கீகார டோக்கன்கள் (authentication tokens) அல்லது அதிகப்படியான தனிப்பட்ட தகவல்களுடன் பொருந்தக்கூடிய வடிவங்களை ஸ்கேன் செய்யவும். ஒரு CRM வினவல் ஒரு பதிவிற்குப் பதிலாக பத்தாயிரம் பதிவுகளைத் திருப்பிக் கொடுத்தால், அதைத் தடுத்து நிறுத்துங்கள். payload-இல் ஒரு உள் API சாவி இருந்தால், அதை மறைக்கவும் (redact). ஏஜென்ட் தனது வேலையைச் செய்ய மூல ரகசியங்கள் தேவையில்லை, மேலும் வெளியேறும் சேனல்கள் திருடப்பட்ட தரவைக் கடத்துவதற்கான வழிகளாக மாறக்கூடாது.

மூன்றாவதாக, டொமைன் ஒயிட்லிஸ்டிங்கை (domain whitelisting) அமல்படுத்தவும். ஏஜென்ட் உங்கள் காலண்டர் சேவை, உங்கள் பேமெண்ட் ப்ராசஸர் மற்றும் உங்கள் உள் சரக்கு மேலாண்மை அமைப்புடன் தொடர்பு கொள்ள வேண்டியிருக்கும். அது ஏதேனும் ஒரு கோப்புப் பகிர்வு தளங்கள், pasteboard சேவைகள் அல்லது வெளிநாட்டு கிளவுட் ஸ்டோரேஜ் முனையங்களுடன் (endpoints) தொடர்பு கொள்ள வேண்டிய அவசியமில்லை. வெளியேறும் DNS தீர்வு (DNS resolution) மற்றும் HTTP கோரிக்கைகளை ஒரு தெளிவான அனுமதிப் பட்டியலுக்கு (allow-list) மட்டும் கட்டுப்படுத்தவும். ஒரு தாக்குதல் நடத்துபவர் ஏஜென்ட்டை ஏமாற்றி தரவை வேறு எங்கோ அனுப்ப முயன்றாலும், நெட்வொர்க் அடுக்கு (network layer) அந்த இணைப்பை எளிதாக மறுத்துவிடும்.

ஜீரோ-ட்ரஸ்ட் கட்டமைப்புகளை உருவாக்குங்கள்

ஜீரோ-ட்ரஸ்ட் என்பது நீங்கள் நிறுவும் ஒரு தயாரிப்பு அல்ல. இது ஒரு வடிவமைப்புத் தத்துவமாகும், இது ஒரு கருதுகோளின் அடிப்படையில் கட்டமைக்கப்பட்டுள்ளது: ஏஜென்ட் ஏற்கனவே ஊடுருவப்பட்டுவிட்டது (compromised). அதற்கேற்ப செயல்படுங்கள்.

அதாவது அடையாளத்தை (identity) தெளிவாகப் பிரிப்பதாகும். ஏஜென்ட் பயனரின் சார்பாகச் செயல்படும்போது கூட, மனிதப் பயனரும் ஏஜென்ட்டும் ஒரே அமைப்பல்ல. மனிதனின் SSO அமர்விலிருந்து வேறுபட்ட, ஏஜென்ட்டிற்கெனத் தனித்த சேவை அடையாளங்களைப் பராமரிக்கவும். உங்கள் தணிக்கை பதிவுகள் (audit logs) இரண்டு அடையாளங்களையும் அருகருகே பதிவு செய்ய வேண்டும். ஏதேனும் தவறு நடக்கும்போது, நீங்கள்