AI ഏജന്റുകൾ ഇപ്പോൾ വെറും ചാറ്റ് വിൻഡോകൾക്ക് അപ്പുറത്തേക്ക് വളർന്നിരിക്കുന്നു. അവ മീറ്റിംഗുകൾ ബുക്ക് ചെയ്യുകയും, കസ്റ്റമർ റെക്കോർഡുകൾ അപ്ഡേറ്റ് ചെയ്യുകയും, ഇന്റേണൽ ഡാറ്റാബേസുകൾ ക്വറി ചെയ്യുകയും, സാമ്പത്തിക ഇടപാടുകൾ നടത്തുകയും ചെയ്യുന്നു. ഒരു ഉപദേശകനിൽ (advisor) നിന്ന് ഒരു പ്രവർത്തികനിലേക്കുള്ള (operator) ഈ മാറ്റം റിസ്ക് സംബന്ധിച്ച എല്ലാ കാര്യങ്ങളെയും മാറ്റിമറിക്കുന്നു. സോഫ്റ്റ്വെയർ നിർദ്ദേശങ്ങൾ നൽകുന്നതിന് പകരം പ്രവർത്തിക്കാൻ തുടങ്ങുമ്പോൾ, ഓരോ API എൻഡ്പോയിന്റും ഒരു സാധ്യമായ പ്രവേശന കവാടമായി മാറുന്നു. പരമ്പരാഗത സുരക്ഷാ മാതൃകകൾ നിർമ്മിച്ചിരിക്കുന്നത് പ്രവചിക്കാവുന്ന മനുഷ്യ സ്വഭാവങ്ങളെ അടിസ്ഥാനമാക്കിയാണ്: ഒരാൾ ലോഗിൻ ചെയ്യുന്നു, പരിചിതമായ പാതകളിലൂടെ ക്ലിക്ക് ചെയ്യുന്നു, തുടർന്ന് ലോഗ് ഔട്ട് ചെയ്യുന്നു. എന്നാൽ സ്വയം പ്രവർത്തിക്കുന്ന ഏജന്റുകൾ (Autonomous agents) ഈ രീതി പിന്തുടരുന്നില്ല. അവ സെക്കൻഡുകൾക്കുള്ളിൽ നൂറുകണക്കിന് കോളുകളിലൂടെയും റീട്രൈകളിലൂടെയും ബ്രാഞ്ചുകളിലൂടെയും സഞ്ചരിക്കുന്നു. മനുഷ്യർ തുടങ്ങുന്ന റിക്വസ്റ്റുകൾക്കായി രൂപകൽപ്പന ചെയ്ത API ലെയർ ഇപ്പോൾ നിരന്തരമായ ഓട്ടോമേറ്റഡ് സമ്മർദ്ദത്തെ നേരിടുന്നു. നിങ്ങളുടെ പ്രതിരോധ സംവിധാനങ്ങൾ ഇപ്പോഴും കഴിഞ്ഞ പാദത്തിൽ എഴുതിയ സ്റ്റാറ്റിക് നിയമങ്ങളെയാണ് ആശ്രയിക്കുന്നതെങ്കിൽ, ഡാറ്റാ ചോർച്ചയ്ക്കും അനധികൃത പ്രവേശനത്തിനും നിങ്ങൾ വാതിലുകൾ തുറന്നു കൊടുക്കുകയാണ്. ഓരോ കോളും നടക്കുമ്പോൾ തന്നെ അത് വിലയിരുത്തുന്ന തത്സമയ പ്രതിരോധം (real-time defense) നിങ്ങൾക്ക് ആവശ്യമാണ്.
ഏജന്റുകളുടെ അധികാരപരിധി പരിമിതപ്പെടുത്തുക (Limit Agent Privileges)
ഏജന്റ് വിന്യാസത്തിലെ (deployment) ഏറ്റവും അപകടകരമായ കുറുക്കുവഴി എന്നത് ഒരു ശക്തമായ API കീ കൈമാറുന്നതാണ്. ഒരു കീ എല്ലാ സിസ്റ്റങ്ങളിലുമുള്ള എല്ലാ ആക്സസ്സും നൽകുന്നു. ഒരു 'പോയിസൺഡ് പ്രോംപ്റ്റ്' (poisoned prompt) വഴിയോ അല്ലെങ്കിൽ ഹൈജാക്ക് ചെയ്ത ഇന്റഗ്രേഷൻ വഴിയോ ഒരു ആക്രമണകാരി ഏജന്റിനെ കീഴടക്കിയാൽ, അവർക്ക് ആ സിസ്റ്റത്തിന്റെ മുഴുവൻ നിയന്ത്രണവും ലഭിക്കുന്നു. ഇതിന്റെ പ്രത്യാഘാതങ്ങൾ (blast radius) നിങ്ങളുടെ ഇമെയിൽ സർവീസ് മുതൽ പ്രൊഡക്ഷൻ ഡാറ്റാബേസ് വരെ എല്ലാം ഉൾക്കൊള്ളുന്നതിനാൽ, വീണ്ടെടുക്കൽ ഒരു ദുസ്വപ്നമായി മാറും.
ഈ ശീലം ഉടൻ തന്നെ മാറ്റുക. ഡെലിഗേറ്റഡ് ഓതറൈസേഷനായി (delegated authorization) OAuth 2.0 ഉപയോഗിച്ച് തുടങ്ങുക. ഏജന്റ് ഒരു സ്വതന്ത്ര സൂപ്പർ യൂസറായി (superuser) ഓതന്റിക്കേറ്റ് ചെയ്യരുത്. പകരം, ഏജന്റിനെയും അത് സേവിക്കുന്ന എൻഡ് യൂസറെയും പ്രതിനിധീകരിക്കുന്ന ഒരു ടോക്കൺ അത് കൈവശം വെക്കണം. മനുഷ്യന്റെ സെഷൻ അവസാനിക്കുമ്പോൾ, ഏജന്റിന്റെ ആക്സസ്സും അതോടൊപ്പം അവസാനിക്കണം.
Token Exchange ഇത് പ്രായോഗികമാക്കുന്നു. ഏജന്റിന് ഇപ്പോൾ കൃത്യമായി എന്താണോ ആവശ്യമുള്ളത് അതിന് മാത്രം പരിമിതപ്പെടുത്തിക്കൊണ്ട് കുറഞ്ഞ കാലയളവിലേക്ക് മാത്രം നിലനിൽക്കുന്ന (short-lived) ടോക്കണുകൾ നൽകുക. ഒരു ഷെഡ്യൂളിംഗ് ഏജന്റിന് കലണ്ടർ വായിക്കാനും ഇൻവൈറ്റുകൾ അയക്കാനും അനുമതി ലഭിച്ചേക്കാം, എന്നാൽ കലണ്ടർ ഇൻഫ്രാസ്ട്രക്ചർ ഡിലീറ്റ് ചെയ്യാനോ പേറോൾ API-കൾ ആക്സസ് ചെയ്യാനോ അനുമതി നൽകരുത്. ഒരു ആക്രമണകാരി ടോക്കൺ തട്ടിയെടുക്കുകയാണെങ്കിൽ പോലും, ദുരുപയോഗം ചെയ്യാൻ കഴിയുന്ന സമയം വളരെ കുറവായിരിക്കും.
Context-Bound Scopes മറ്റൊരു പാളി കൂടി ചേർക്കുന്നു. എല്ലാ ടോക്കണുകളും ഡിഫോൾട്ട് ആയി 'റീഡ്-ഒൺലി' (read-only) ആക്കുക. ഏജന്റ് ഡാറ്റ എഴുതേണ്ടതുണ്ടെങ്കിൽ (ഉദാഹരണത്തിന് ഒരു റീഫണ്ട് പ്രോസസ്സ് ചെയ്യുകയോ അല്ലെങ്കിൽ ഒരു കരാർ അപ്ഡേറ്റ് ചെയ്യുകയോ ചെയ്യുമ്പോൾ), ഒരു മനുഷ്യന്റെ അംഗീകാര കവാടം (human approval gate) നിർബന്ധമാക്കുക. പണം കൈമാറുന്നതിനോ, അക്കൗണ്ടുകൾ മാറ്റുന്നതിനോ, റെക്കോർഡുകൾ ഇല്ലാതാക്കുന്നതിനോ എപ്പോഴാണ് തീരുമാനമെടുക്കേണ്ടതെന്ന് മോഡലിനെ മാത്രം വിടരുത്. അനുമതി എന്നത് ആ നിമിഷത്തിന് അനുയോജ്യമായതായിരിക്കണം, പരമാവധി അധികാരമായിരിക്കരുത്.
Ephemeral Windows ഈ പ്രക്രിയയെ പൂർണ്ണമായും സുരക്ഷിതമാക്കുന്നു. ടോക്കൺ കാലാവധി ദിവസങ്ങളിലല്ല, മിനിറ്റുകളിൽ കണക്കാക്കുക. ഒരു ചെറിയ സുരക്ഷാ വീഴ്ചയിലൂടെ ടോക്കൺ ലഭിച്ചാലും, ഒരു ആക്രമണകാരി അത് വീണ്ടും ഉപയോഗിക്കാൻ ശ്രമിക്കുമ്പോഴേക്കും അത് ഉപയോഗശൂന്യമായിരിക്കണം. ഇതിനെ നിരന്തരം മാറിക്കൊണ്ടിരിക്കുന്ന ഒരു ലോക്ക് പോലെ കരുതുക.
നിങ്ങളുടെ CRM-ൽ നിന്ന് ലീഡ് ഡാറ്റ വായിക്കുകയും മെയിൽ API വഴി ഫോളോ-അപ്പ് ഇമെയിലുകൾ അയക്കുകയും ചെയ്യുന്ന ഒരു സെയിൽസ് ഓട്ടോമേഷൻ ഏജന്റിനെ പരിഗണിക്കുക. ഒരു ശാശ്വത അഡ്മിൻ കീക്ക് പകരം, ഏജന്റിന് നിങ്ങളുടെ ഐഡന്റിറ്റി പ്രൊവൈഡറിൽ നിന്ന് 15 മിനിറ്റ് മാത്രം നിലനിൽക്കുന്ന ഒരു ടോക്കൺ ലഭിക്കുന്നു. ഈ ടോക്കൺ CRM റീഡുകൾക്കും മെയിൽ അയക്കുന്നതിനും അനുവദിക്കുന്നു, എന്നാൽ കോൺടാക്റ്റ് ഡിലീഷനും ബില്ലിംഗ് ആക്സസ്സും തടയുന്നു. മുഴുവൻ ഡാറ്റാബേസും എക്സ്പോർട്ട് ചെയ്യാൻ ഏജന്റിന് സംശയാസ്പദമായ ഒരു നിർദ്ദേശം ലഭിച്ചാൽ, ഈ സ്കോപ്പ് ആ ശ്രമത്തെ തടയും.
ഇൻഡയറക്റ്റ് പ്രോംപ്റ്റ് ഇൻജക്ഷൻ തടയുക (Stop Indirect Prompt Injection)
പ്രോംപ്റ്റ് ഇൻജക്ഷൻ (Prompt injection) എന്നത് ഇപ്പോൾ ചാറ്റ്ബോട്ടുകൾക്കായുള്ള വെറുമൊരു വിനോദമല്ല. ഏജന്റുകളുടെ യുഗത്തിൽ, ഇത് ഇമെയിൽ വഴി ലഭിക്കുന്ന റിമോട്ട് കോഡ് എക്സിക്യൂഷൻ (remote code execution) പോലെ പ്രവർത്തിക്കുന്നു.
ഇതാ ഒരു യഥാർത്ഥ സാഹചര്യം. മീറ്റിംഗുകൾ ഷെഡ്യൂൾ ചെയ്യുന്നതിനായി ഒരു ഏജന്റ് ഉപയോക്താവിന്റെ ഇൻബോക്സ് നിരീക്ഷിക്കുന്നു. ഒരു സന്ദേശത്തിനുള്ളിൽ, ഒരുപക്ഷേ അദൃശ്യമായ ടെക്സ്റ്റ് രൂപത്തിലോ അല്ലെങ്കിൽ ഒരു അറ്റാച്ച്മെന്റിലെ മെറ്റാഡേറ്റിലോ, എല്ലാ ഇൻവോയ്സുകളും ഒരു ബാഹ്യ വിലാസത്തിലേക്ക് ഫോർവേഡ് ചെയ്യാനും ഒറിജിനലുകൾ ഡിലീറ്റ് ചെയ്യാനുമുള്ള ഒരു കമാൻഡ് ഒളിഞ്ഞിരിക്കുന്നു. ഏജന്റ് ഇമെയിൽ വായിക്കുന്നു, ആ വിഷലിഷ്ടമായ ടെക്സ്റ്റിനെ ഒരു നിയമപരമായ സിസ്റ്റം നിർദ്ദേശമായി തെറ്റിദ്ധരിക്കുന്നു, തുടർന്ന് API-കൾ വിളിക്കാൻ തുടങ്ങുന്നു. ഏജന്റിന് തന്നെ ഇതിനുള്ള അനുമതി ഉള്ളതിനാൽ, ഈ ദുരുദ്ദേശ്യപരമായ അഭ്യർത്ഥനകൾ സാധാരണ ചാനലുകളിലൂടെ ഒഴുകുന്നു. ഇതിന്റെ ഫലമായി, സാധാരണ രീതിയിലുള്ള പ്രവർത്തനമായി തോന്നുന്ന അനധികൃത ഡാറ്റാ ചോർച്ച (data exfiltration) സംഭവിക്കുന്നു.
നിങ്ങളുടെ ആദ്യ പ്രതിരോധം കർശനമായ ഇൻപുട്ട് വാലിഡേഷൻ (input validation) ആണ്. AI നിർമ്മിക്കുന്ന ഓരോ പാരാമീറ്ററും തെളിവ് ലഭിക്കുന്നത് വരെ വിശ്വസിക്കാൻ കൊള്ളാത്തതായി കണക്കാക്കുക. നിങ്ങളുടെ API ഗേറ്റ്വേയിൽ JSON-schema validation നടത്തുക. ഏജന്റ് ഒരു കസ്റ്റമർ റെക്കോർഡ് ആവശ്യപ്പെട്ടാൽ, പേലോഡിൽ (payload) പ്രതീക്ഷിച്ച ഒരൊറ്റ ഐഡന്റിഫയർ മാത്രമേ ഉള്ളൂ എന്ന് ഗേറ്റ്വേ പരിശോധിക്കണം; ഒരു വൈൽഡ്കാർഡോ അസാധാരണമായ വലിയ ബാച്ച് റിക്വസ്റ്റോ ആകരുത്. തെറ്റായതോ, അമിത വലുപ്പമുള്ളതോ, അസ്വാഭാവികമായതോ ആയ എന്തിനെയും ബാക്കെൻഡിൽ എത്തുന്നതിന് മുമ്പ് നിരസിക്കുക.
രണ്ടാമതായി, റെസ്പോൺസ് പാത്തിൽ ഡാറ്റ എക്സ്ഫിൽട്രേഷൻ (data exfiltration) ഫിൽട്ടറുകൾ ഉപയോഗിക്കുക. API റെസ്പോൺസുകൾ AI-യിൽ എത്തുന്നതിന് മുമ്പ് അവ പരിശോധനയ്ക്ക് വിധേയമാക്കണം. രഹസ്യ വിവരങ്ങൾ (secrets), അതന്റിക്കേഷൻ ടോക്കണുകൾ, അല്ലെങ്കിൽ വൻതോതിലുള്ള വ്യക്തിഗത വിവരങ്ങൾ എന്നിവയുമായി പൊരുത്തപ്പെടുന്ന പാറ്റേണുകൾക്കായി സ്കാൻ ചെയ്യുക. ഒരു CRM ക്വറി ഒരു റെക്കോർഡിന് പകരം പതിനായിരം റെക്കോർഡുകൾ നൽകുന്നുണ്ടെങ്കിൽ, അത് തടയുക. പേലോഡിൽ ഒരു ഇന്റേണൽ API കീ ഉണ്ടെങ്കിൽ, അത് റെഡാക്ട് (redact) ചെയ്യുക. ഏജന്റിന് അതിന്റെ ജോലി ചെയ്യാൻ രഹസ്യ വിവരങ്ങളുടെ (raw secrets) ആവശ്യമില്ല, കൂടാതെ ഔട്ട്ബൗണ്ട് ചാനലുകൾ മോഷ്ടിച്ച ഡാറ്റ കടത്താനുള്ള പാതകളായി മാറാൻ പാടില്ല.
മൂന്നാമതായി, ഡൊമെയ്ൻ വൈറ്റ്ലിസ്റ്റിംഗ് (domain whitelisting) നടപ്പിലാക്കുക. ഏജന്റിന് നിങ്ങളുടെ കലണ്ടർ സർവീസ്, പേയ്മെന്റ് പ്രോസസ്സർ, ഇന്റേണൽ ഇൻവെന്ററി സിസ്റ്റം എന്നിവയുമായി ആശയവിനിമയം നടത്തേണ്ടതുണ്ട്. എന്നാൽ ഏതെങ്കിലും ഫയൽ ഷെയറിംഗ് സൈറ്റുകളുമായോ, പേസ്റ്റ്ബോർഡ് സർവീസുകളുമായോ, വിദേശ ക്ലൗഡ് സ്റ്റോറേജ് എൻഡ്പോയിന്റുകളുമായോ ആശയവിനിമയം നടത്തേണ്ടതില്ല. ഔട്ട്ബൗണ്ട് DNS റെസല്യൂഷനും HTTP റിക്വസ്റ്റുകളും ഒരു വ്യക്തമായ അലൗ-ലിസ്റ്റിലേക്ക് (allow-list) മാത്രമായി പരിമിതപ്പെടുത്തുക. ഒരു അറ്റാക്കർ ഏജന്റിനെ കബളിപ്പിച്ച് ഡാറ്റ മറ്റൊരിടത്തേക്ക് അയക്കാൻ ശ്രമിച്ചാൽ പോലും, നെറ്റ്വർക്ക് ലെയർ ആ കണക്ഷൻ നിരസിക്കും.
സീറോ-ട്രസ്റ്റ് ആർക്കിടെക്ചറുകൾ നിർമ്മിക്കുക
സീറോ-ട്രസ്റ്റ് എന്നത് നിങ്ങൾ ഇൻസ്റ്റാൾ ചെയ്യേണ്ട ഒരു ഉൽപ്പന്നമല്ല. അത് ഒരു ഡിസൈൻ ഫിലോസഫിയാണ്, അത് ഒരു അനുമാനത്തിൽ അധിഷ്ഠിതമാണ്: ഏജന്റ് ഇതിനകം തന്നെ കോംപ്രമൈസ് ചെയ്യപ്പെട്ടിരിക്കുന്നു (compromised). അതനുസരിച്ച് പ്രവർത്തിക്കുക.
അതിനർത്ഥം ഐഡന്റിറ്റി കൃത്യമായി വേർതിരിക്കുക എന്നാണ്. ഏജന്റ് ഉപയോക്താവിന് വേണ്ടി പ്രവർത്തിക്കുമ്പോൾ പോലും, മനുഷ്യ ഉപയോക്താവും ഏജന്റും ഒരേ എന്റിറ്റിയല്ല. മനുഷ്യന്റെ SSO സെഷനിൽ നിന്ന് വ്യത്യസ്തമായി, ഏജന്റിന് തന്നെ പ്രത്യേക സർവീസ് ഐഡന്റിറ്റികൾ നിലനിർത്തുക. നിങ്ങളുടെ ഓഡിറ്റ് ലോഗുകൾ രണ്ട് ഐഡന്റിറ്റികളെയും ഒരുമിച്ച് രേഖപ്പെടുത്തണം. എന്തെങ്കിലും പിഴവ് സംഭവിക്കുമ്പോൾ, നിങ്ങൾ