ഞാൻ എന്റെ കുടുംബത്തിന്റെ സാമ്പത്തിക ഇടപാടുകൾ കൈകാര്യം ചെയ്യാൻ ഒരു AI ഏജന്റിന് അനുമതി നൽകുകയും ഒരു MCP സെർവർ വഴി എന്നോട് സംസാരിക്കാൻ അനുവദിക്കുകയും ചെയ്തു. മിനിറ്റുകൾക്കുള്ളിൽ തന്നെ “കഴിഞ്ഞ മാസം നമ്മൾ ഗ്രോസറിക്ക് എത്ര ചിലവാക്കി?” എന്ന് ചോദിക്കാനും സമ്പാദ്യത്തിലേക്ക് പണം മാറ്റാനും അതിന് കഴിഞ്ഞു. എന്നാൽ അതേ ഇന്റർഫേസ് ഉപയോഗിച്ച് ഒരു ഒറ്റ കമാൻഡിലൂടെ ഒരു വർഷത്തെ ഇടപാടുകളുടെ ചരിത്രം മുഴുവൻ മായ്ച്ചു കളയാനും അതിന് സാധിക്കുമായിരുന്നു. ഏജന്റ് ഉപയോഗിക്കുന്ന ടൂളുകളിൽ നേരത്തെ തന്നെ ഉൾപ്പെടുത്തിയിരുന്ന ഒരു ഹാർഡ്-കോഡ് ചെയ്ത സേഫ്റ്റി ചെക്ക് (safety check) ആണ് ആ ഡിലീഷൻ തടഞ്ഞത്—അല്ലാതെ ഒരു ബുദ്ധിപരമായ സിസ്റ്റം പ്രോംപ്റ്റല്ല.
എന്തുകൊണ്ടാണ് ഈ പ്രശ്നം പ്രധാനമാകുന്നത്
പുറത്തുള്ള സേവനങ്ങളെ (external services) ഉപയോഗിക്കുന്ന AI ഏജന്റുകൾ ഗവേഷണ ഡെമോകളിൽ നിന്ന് ദൈനംദിന സഹായികളായി മാറിക്കൊണ്ടിരിക്കുകയാണ്. ബാങ്ക് SMS അലേർട്ടുകൾ വായിക്കുകയും, തുകകൾ വേർതിരിച്ചെടുക്കുകയും, അവ ഒരു പേഴ്സണൽ ഫിനാൻസ് ആപ്പിൽ രേഖപ്പെടുത്തുകയും ചെയ്യുന്ന ഒരു ബഡ്ജറ്റിംഗ് ബോട്ട് ഇന്ന് നിലവിലുണ്ട്. ഇതേ മാതൃകയാണ് കസ്റ്റമർ സപ്പോർട്ട് ചാറ്റ്ബോട്ടുകൾ, കോഡ് ജനറേഷൻ സഹായികൾ, സപ്ലൈ-ചെയിൻ പ്ലാനർമാർ എന്നിവയിലും പ്രവർത്തിക്കുന്നത്. ഒരിക്കൽ ഒരു ഏജന്റിന് മാറ്റങ്ങൾ വരുത്തുന്നതോ (mutating) അല്ലെങ്കിൽ നശിപ്പിക്കുന്നതോ ആയ (destructive) കമാൻഡുകൾ നൽകാൻ കഴിഞ്ഞാൽ—ഒരു ഫയൽ ഡിലീറ്റ് ചെയ്യുക, ഒരു ഡാറ്റാബേസ് ടേബിൾ ഒഴിവാക്കുക, അല്ലെങ്കിൽ ഫണ്ടുകൾ പുനർവിഭജിക്കുക—അതിന്റെ അപകടസാധ്യത വളരെ വലുതാണ്. തെറ്റായി വ്യാഖ്യാനിക്കപ്പെട്ട ഒരു അഭ്യർത്ഥനയോ, മോഡൽ ഡ്രിഫ്റ്റ് (model-drift) സംഭവമോ, അല്ലെങ്കിൽ ഒരു ദുരുദ്ദേശ്യപരമായ പ്രോംപ്റ്റോ ഉണ്ടാക്കിയേക്കാവുന്ന നാശനഷ്ടങ്ങൾ തിരുത്താൻ കഴിയാത്തവയായിരിക്കും. 2025-ൽ, നശിപ്പിക്കുന്ന പ്രവർത്തനങ്ങൾ ഒരിക്കലും ചെയ്യരുതെന്ന് നിർദ്ദേശിച്ചിട്ടും, ഒരു AI കോഡിംഗ് അസിസ്റ്റന്റ് ഒരു പ്രൊഡക്ഷൻ ഡാറ്റാബേസ് ഡിലീറ്റ് ചെയ്യുകയും കമ്പനിക്ക് ആഴ്ചകളോളം പ്രവർത്തനരഹിതമായിരിക്കേണ്ടി വരികയും ചെയ്തു.
ഈ അപകടസാധ്യത യഥാർത്ഥമാണ്. ഉപയോക്താക്കൾ തങ്ങളുടെ സെൻസിറ്റീവ് ആയ വിവരങ്ങളും നിർണ്ണായകമായ പ്രവർത്തനങ്ങളും വിശ്വസിച്ച് AI ഏജന്റുകളെ ഏൽപ്പിക്കുന്നു. ആ വിശ്വാസം തകരുമ്പോൾ, സാങ്കേതികവിദ്യയുടെ ഉപയോഗം കുറയുകയും, നിയന്ത്രണ ഏജൻസികൾ ഇടപെടുകയും ചെയ്തേക്കാം, കൂടാതെ സാമ്പത്തികമായ ആഘാതം കഠിനവുമാകാം. പ്രധാന ചോദ്യം ഇതാണ്: ഒരു യഥാർത്ഥ മനുഷ്യന്റെ തീരുമാനം ഇല്ലാതെ ഒരു ഏജന്റ് ഒരിക്കലും തിരുത്താൻ കഴിയാത്ത ഒരു പ്രവർത്തി ചെയ്യാതിരിക്കുമെന്ന് നമുക്ക് എങ്ങനെ ഉറപ്പാക്കാം?
പ്രോംപ്റ്റ് എഞ്ചിനീയറിംഗ് ഒരു വ്യാജ സുരക്ഷാ കവചമാണ്
ഡെവലപ്പർമാർ പലപ്പോഴും സിസ്റ്റം പ്രോംപ്റ്റുകൾ കൂടുതൽ കർശനമാക്കാറുണ്ട്, “ചോദിക്കാതെ ഒരിക്കലും ഡാറ്റ ഡിലീറ്റ് ചെയ്യരുത്” അല്ലെങ്കിൽ “ബാലൻസ് മാറ്റുന്നതിന് മുമ്പ് എപ്പോഴും സ്ഥിരീകരിക്കുക” എന്നിങ്ങനെയുള്ള നിയമങ്ങൾ ചേർക്കാറുണ്ട്. പ്രോംപ്റ്റ് എഞ്ചിനീയറിംഗ് എന്നത് മോഡലിന്റെ പെരുമാറ്റത്തെ മോഡൽ പാലിക്കാവുന്നതോ പാളിക്കാവുന്നതോ ആയ ചില നിർദ്ദേശങ്ങളായിട്ടാണ് കാണുന്നത്. പ്രായോഗികമായി പറഞ്ഞാൽ, ടെമ്പറേച്ചർ സെറ്റിംഗുകൾ (temperature settings), ടോക്കൺ പരിധികൾ, അല്ലെങ്കിൽ ചെറിയൊരു കോൺടെക്സ്റ്റ് മാറ്റം എന്നിവ കാരണം നിയമങ്ങൾ അവഗണിക്കപ്പെടുന്നത് വരെ മോഡലുകൾ ആ നിർദ്ദേശങ്ങൾ പാലിക്കുന്നുണ്ടാകും. മോഡലിന്റെ ആന്തരികമായ യുക്തിയിൽ വ്യതിയാനം സംഭവിക്കുമ്പോൾ വ്യക്തമായ നിർദ്ദേശങ്ങൾ പോലും അവഗണിക്കപ്പെട്ടേക്കാം എന്ന് 2025-ലെ ഡാറ്റാബേസ് ഡിലീഷൻ സംഭവം തെളിയിച്ചു.
പ്രോസ് (prose) രൂപത്തിലുള്ള നിയന്ത്രണങ്ങൾ പരിപാലന ബുദ്ധിമുട്ടുകളും ഉണ്ടാക്കുന്നു. ഓരോ പുതിയ ടൂൾ വരുമ്പോഴോ, വേർഷൻ മാറ്റുമ്പോഴോ, ലാംഗ്വേജ് മോഡലുകളിൽ മാറ്റം വരുമ്പോഴോ പ്രോംപ്റ്റ് ടെക്സ്റ്റ് വീണ്ടും പരിശോധിക്കേണ്ടി വരുന്നു. മനുഷ്യരായ റിവ്യൂവർമാർ നീളമുള്ള പ്രോംപ്റ്റുകൾ വായിച്ച് അവ വ്യാഖ്യാനിക്കുകയും മോഡൽ അവയെ മാനിക്കുമെന്ന് പ്രതീക്ഷിക്കുകയും വേണം. ഇതിന്റെ ഫലമായി യഥാർത്ഥ ലോകത്തെ ഉപയോഗങ്ങളിൽ തകരാറിലാകുന്ന ഒരു ദുർബലമായ സുരക്ഷാ വലയാണ് ലഭിക്കുന്നത്.
സുരക്ഷ പ്രോംപ്റ്റിൽ നിന്ന് ടൂളിലേക്ക് മാറ്റുക
AI പ്രവർത്തിക്കുന്ന ഇടത്ത്—അതായത് ടൂളിൽ തന്നെ—സുരക്ഷ ഉറപ്പാക്കുക എന്നതാണ് കൂടുതൽ വിശ്വസനീയമായ മാർഗ്ഗം. എന്റെ പരീക്ഷണത്തിൽ ഞാൻ Lester എന്ന് പേരിട്ട ഒരു ബഡ്ജറ്റിംഗ് ഏജന്റിനെ നിർമ്മിച്ചു. അതിന്റെ പ്രവർത്തനരീതി ഇപ്രകാരമായിരുന്നു:
- ഒരു ഫോൺ ആപ്പ് ബാങ്കിൽ നിന്നുള്ള ഇൻകമിംഗ് SMS സന്ദേശങ്ങൾ ശേഖരിക്കുന്നു.
- ഒരു ലൈറ്റ് വെയ്റ്റ് ലോക്കൽ ലാംഗ്വേജ് മോഡൽ ഇടപാടിന്റെ തുകയും വ്യാപാരിയുടെ പേരും വേർതിരിച്ചെടുക്കുന്നു.
- Lester ഒരു API കോൾ വഴി ഈ വിവരങ്ങൾ ഒരു ബഡ്ജറ്റിംഗ് ആപ്പിലേക്ക് എഴുതുന്നു.
Lester-ന്റെ കാഴ്ചപ്പാടിൽ ഈ മൂന്ന് ഘട്ടങ്ങളും റീഡ്-ഒൺലി (read-only) ആയിരുന്നു: അതിന് ഡാറ്റ ചേർക്കാൻ (add) മാത്രമേ കഴിയുമായിരുന്നുള്ളൂ, നിലവിലുള്ള വിവരങ്ങൾ ഡിലീറ്റ് ചെയ്യാനോ മാറ്റം വരുത്താനോ കഴിയില്ലായിരുന്നു. ഒരു MCP (Multi-Channel Prompt) സെർവർ ഉപയോഗിച്ച് ഒരു വോയ്സ് ഇന്റർഫേസ് ചേർക്കുന്നത് വരെ ഈ സിസ്റ്റം കൃത്യമായി പ്രവർത്തിച്ചു. ഇത് ഉപയോഗിച്ച് എനിക്ക് “കഴിഞ്ഞ മാസം നമ്മൾ ഗ്രോസറിക്ക് എത്ര ചിലവാക്കി?” അല്ലെങ്കിൽ “സമ്പാദ്യത്തിലേക്ക് പണം മാറ്റുക” എന്ന് ചോദിക്കാൻ കഴിഞ്ഞു. MCP സെർവർ ഒരു ബ്രോക്കറായി പ്രവർത്തിക്കുകയും ഏജന്റിന് ചില ടൂളുകൾ (add-transaction, query-spending, transfer-funds, delete-history) ലഭ്യമാക്കുകയും ചെയ്യുന്നു.
ആദ്യത്തെ കോൺഫിഗറേഷനിൽ എല്ലാ ടൂളുകളെയും തുല്യമായാണ് പരിഗണിച്ചിരുന്നത്. ഗ്രോസറി വിവരങ്ങൾ ചേർക്കുന്ന അതേ എൻഡ്പോയിന്റ് തന്നെ, ഒരു വർഷത്തെ റെക്കോർഡുകൾ മുഴുവൻ മായ്ച്ചുകളയാവുന്ന ഒരു ഡിലീറ്റ് കമാൻഡ് സ്വീകരിക്കാനും തയ്യാറായിരുന്നു. മോഡലിന് തെറ്റായ വിവരങ്ങൾ ലഭിക്കുകയോ, ഒരു അഭ്യർത്ഥന തെറ്റായി കേൾക്കുകയോ, അല്ലെങ്കിൽ ഒരു ഉപയോക്താവ് “delete last” എന്നതിന് പകരം “delete all” എന്ന് ടൈപ്പ് ചെയ്യുകയോ ചെയ്താൽ, Lester യാതൊരു മടിയും കൂടാതെ അത് അനുസരിക്കുമായിരുന്നു.
അത് തടയുന്നതിനായി, ഞാൻ ടൂൾ ലെയറിനെ മൂന്ന് ലളിതമായ നിയമങ്ങൾ ഉപയോഗിച്ച് പുനർനിർമ്മിച്ചു:
- റീഡ്-ഒൺലി ടൂളുകൾ ഉടൻ പ്രവർത്തിക്കുന്നു. വിവരങ്ങൾ മാത്രം ലഭ്യമാക്കുന്ന കാര്യങ്ങൾ—ബാലൻസ് പരിശോധനകൾ, ചിലവുകളുടെ സംഗ്രഹം, ഇടപാടുകൾ സംബന്ധിച്ച ചോദ്യങ്ങൾ—ഇവയ്ക്ക് മനുഷ്യന്റെ സ്ഥിരീകരണം ആവശ്യമില്ല. റീഡ്-ഒൺലി കോളുകൾ മൂലമുള്ള അപകടസാധ്യത വളരെ കുറവാണ്.
- മാറ്റങ്ങൾ വരുത്തുന്ന (mutating) ടൂളുകൾ പ്രവർത്തിക്കുന്നതിന് മുമ്പ് ഉദ്ദേശ്യം അറിയിക്കുന്നു. നിലവിലുള്ള അവസ്ഥയിൽ മാറ്റം വരുത്തുന്നതും എന്നാൽ തിരുത്താൻ കഴിയുന്നതുമായ പ്രവർത്തനങ്ങൾ—ഒരു ഇടപാട് ചേർക്കുക, ഒരു കാറ്റഗറി പുതുക്കുക—ഏജന്റ് ഒരു ചെറിയ “ഇൻ്റന്റ്” (intent) സന്ദേശം അയച്ചതിന് ശേഷം മാത്രം നടപ്പിലാക്കുന്നു (ഉദാഹരണത്തിന്, “ഗ്രോസറി ഇടപാട് ചേർക്കുന്നു”). സിസ്റ്റം ഈ ഉദ്ദേശ്യം രേഖപ്പെടുത്തുകയും ഓഡിറ്റിംഗിനായി ഉപയോക്താവിന് കാണിച്ചുകൊടുക്കുകയും ചെയ്യും, എന്നാൽ ഇത് പ്രവർത്തനത്തെ തടയുന്നില്ല.
- നശിപ്പിക്കുന്ന (destructive) ടൂളുകൾ വ്യക്തമായ ഒരു ടോക്കൺ ഇല്ലാതെ പ്രവർത്തിക്കാൻ വിസമ്മതിക്കുന്നു. ഡാറ്റ ഡിലീറ്റ് ചെയ്യുകയോ, ട്രങ്കേറ്റ് ചെയ്യുകയോ അല്ലെങ്കിൽ തിരിച്ചുപിടിക്കാൻ കഴിയാത്ത രീതിയിൽ മാറ്റുകയോ ചെയ്യുന്ന കമാൻഡുകൾ ടൂൾ തലത്തിൽ തന്നെ തടയുന്നു. Lester ഒരു ഡിലീറ്റ് അഭ്യർത്ഥന നടത്തുമ്പോൾ, ടൂൾ ഒരു റിഫ്യൂസൽ പേലോഡ് (refusal payload) തിരികെ നൽകുന്നു. ഇതിൽ ഏത് ഡാറ്റയാണ് ഡിലീറ്റ് ചെയ്യാൻ പോകുന്നത് എന്ന വിവരവും ഒരു മനുഷ്യൻ നൽകേണ്ട ടോക്കണിനായുള്ള അഭ്യർത്ഥനയും ഉൾപ്പെടുന്നു. തുടർന്ന് ഏജന്റ്
confirm: trueഎന്നതും ആ ടോക്കണും അടങ്ങിയ രണ്ടാമത്തെ സ്റ്റെപ്പ് കൺഫർമേഷൻ പേലോഡ് നൽകണം. അതില്ലെങ്കിൽ ആ പ്രവർത്തനം റദ്ദാക്കപ്പെടും.
ഈ ഡിസൈൻ സുരക്ഷാ പരിശോധനയെ അറ്റോമിക് (atomic) ആക്കുന്നു: മോഡൽ പ്രോംപ്റ്റിൽ എന്ത് പറഞ്ഞാലും, ടൂൾ തന്നെ അത് മുന്നോട്ട് കൊണ്ടുപോകാൻ കഴിയുമോ എന്ന് തീരുമാനിക്കുന്നു. ടോക്കൺ ഒഴിവാക്കിയോ അല്ലെങ്കിൽ തെറ്റായ പേലോഡ് നൽകിയോ മോഡൽ ഈ പരിശോധനയെ മറികടക്കാൻ ശ്രമിച്ചാൽ പോലും, ടൂൾ ആ അഭ്യർത്ഥന നിരസിക്കും.
ഇത് ഉപയോക്താക്കൾക്ക് എന്തുകൊണ്ട് പ്രധാനമാണ്
ഏതൊരു കൺഫർമേഷൻ രീതിയുടെയും ഏറ്റവും വലിയ തടസ്സം ക്ഷീണം (fatigue) ആണ്. ഓരോ ചെറിയ കാര്യത്തിനും—"നിങ്ങൾക്ക് ഈ കോഫി ആഡ് ചെയ്യണോ?"—സിസ്റ്റം അനുമതി ചോദിക്കുകയാണെങ്കിൽ, ഉപയോക്താക്കൾ വായിക്കാതെ തന്നെ വേഗത്തിൽ “yes” എന്ന് ക്ലിക്ക് ചെയ്യാൻ തുടങ്ങും. ഇതിന്റെ ഫലമായി സുരക്ഷിതമാണെന്ന ഒരു തെറ്റായ തോന്നൽ ഉണ്ടാകുന്നു. തിരുത്താൻ കഴിയാത്ത (irreversible) പ്രവർത്തനങ്ങളെ മാത്രം നിയന്ത്രിക്കുന്നതിലൂടെ, മനുഷ്യന്റെ ഇടപെടൽ ആവശ്യമുള്ള ഇടങ്ങളിൽ മാത്രം അവരെ നിലനിർത്താൻ നമുക്ക് സാധിക്കുന്നു. ഒരു മാസത്തെ സാമ്പത്തിക ചരിത്രം മുഴുവൻ ഡിലീറ്റ് ചെയ്യാൻ സാധ്യതയുള്ള ഒരു അഭ്യർത്ഥന പരിശോധിക്കാൻ ഒരു ഉപയോക്താവ് തയ്യാറാകാൻ സാധ്യത കൂടുതലാണ്, അല്ലാതെ ഒരു ചെറിയ വിവരങ്ങൾ ചേർക്കുന്നതിനേക്കാൾ.
ടൂൾ-ലെവൽ സുരക്ഷാ സംവിധാനം നിയമപരമായ കാര്യങ്ങൾ (compliance) എളുപ്പമാക്കുന്നു. EU AI Act അല്ലെങ്കിൽ യുഎസ് SAFE Act പോലുള്ള നിയമങ്ങൾ അപ്രതീക്ഷിതമായ ഡാറ്റാ നഷ്ടത്തിനെതിരെയുള്ള സുരക്ഷാ സംവിധാനങ്ങൾ ആവശ്യപ്പെടുന്നു. API-ൽ ഉൾപ്പെടുത്തിയിട്ടുള്ള ഒരു ഹാർഡ്-കോഡ്ഡ് റിഫ്യൂസൽ എന്നത് ലോഗ് ചെയ്യാനും പരിശോധിക്കാനും മൂന്നാം കക്ഷി ഓഡിറ്റർമാർക്ക് സാധിക്കുന്ന ഒരു നിയന്ത്രണമാണ്. നേരെമറിച്ച്, പ്രോംപ്റ്റ് ടെക്സ്റ്റുകൾ അവ്യക്തമാണ്, അവ വേർഷനുകളെ ആശ്രയിച്ചിരിക്കുന്നു, കൂടാതെ കോടതിയിൽ തെളിയിക്കാനും പ്രയാസമാണ്.
പ്രതിവാദങ്ങൾ: “നമുക്ക് പ്രോംപ്റ്റുകൾ മെച്ചപ്പെടുത്തിയാൽ പോരേ?”
ചില ഡെവലപ്പർമാർ വാദിക്കുന്നത്, മനുഷ്യനിൽ നിന്നുള്ള ഫീഡ്ബാക്ക് ഉപയോഗിച്ചുള്ള റൈൻഫോഴ്സ്മെന്റ് ലേണിംഗും (RLHF) മികച്ച രീതിയിൽ തയ്യാറാക്കിയ ഒരു പ്രോംപ്റ്റും ഉപയോഗിച്ചാൽ സമാനമായ സുരക്ഷാ നിലവാരം കൈവരിക്കാൻ കഴിയുമെന്നാണ്. വ്യക്തമായ നിയന്ത്രണങ്ങൾ ലംഘിക്കാത്ത ഇൻസ്ട്രക്ഷൻ-ട്യൂൺഡ് മോഡലുകളെ അവർ ചൂണ്ടിക്കാട്ടുന്നു. ഈ വാദം ശരിയാണ്: മികച്ച മോഡലുകൾ അബദ്ധവശാൽ ഡിലീറ്റ് ചെയ്യുന്നത് കുറയ്ക്കുന്നുണ്ട്.
എങ്കിലും, ഏറ്റവും കഴിവുള്ള മോഡലുകൾ പോലും പ്രോബബിലിസ്റ്റിക് (probabilistic) ആണ്. ഒരു ചെറിയ ടോക്കൺ വ്യതിയാനമോ, ടെമ്പറേച്ചറിലെ മാറ്റമോ, അപൂർവ്വമായ ഒരു കോൺടെക്സ്റ്റ് കോമ്പിനേഷനോ കാരണം മോഡൽ അപ്രതീവസിതമായി ഒരു കമാൻഡ് നൽകിയേക്കാം. സ്ഥിതിവിവരക്കണക്കുകളെ (statistical property) ആശ്രയിക്കുന്ന സുരക്ഷ എപ്പോഴും ദുർബലമായിരിക്കും. ബാങ്കിംഗ്, ആരോഗ്യ സംരക്ഷണം, നിർണ്ണായകമായ അടിസ്ഥാന സൗകര്യങ്ങൾ തുടങ്ങിയ ഉയർന്ന മൂല്യമുള്ള മേഖലകളിൽ, ഒരു ചെറിയ പിഴവ് പോലും വലിയ നാശനഷ്ടങ്ങൾ ഉണ്ടാക്കാം. ഓരോ നശിപ്പിക്കുന്ന പ്രവർത്തനത്തെയും ഒരു സംരക്ഷണ കവചത്തിനുള്ളിലാക്കാൻ ആവശ്യമായ എഞ്ചിനീയറിംഗ് പരിശ്രമത്തേക്കാൾ എത്രയോ വലുതാണ് ഒരു സുരക്ഷാ വീഴ്ച മൂലമുണ്ടാകുന്ന നഷ്ടം.
പ്രോംപ്റ്റുകൾ മാത്രം ഉപയോഗിച്ചുള്ള പരിഹാരങ്ങൾ ദുരുദ്ദേശ്യപരമായ ഉദ്ദേശ്യങ്ങളെ (malicious intent) അവഗണിക്കുന്നു. ഏജന്റിന്റെ പ്രോംപ്റ്റിലേക്ക് പ്രവേശനം നേടുന്ന ഒരു ആക്രമണകാരിക്ക്, സുരക്ഷാ വ്യവസ്ഥകൾ ഒഴിവാക്കിക്കൊണ്ട് ഒരു കമാൻഡ് ഇൻജക്ട് ചെയ്യാൻ കഴിയും. എന്നാൽ ടൂൾ-ലെവൽ എൻഫോഴ്സ്മെന്റ് ഇതിൽ നിന്ന് സുരക്ഷിതമാണ്, കാരണം ആ നിയന്ത്രണം മോഡലിന്റെ കോൺടെക്സ്റ്റിന് പുറത്താണ് നിലനിൽക്കുന്നത്.
അടുത്തതായി ശ്രദ്ധിക്കേണ്ട കാര്യങ്ങൾ
ടൂൾ-ലെവൽ സുരക്ഷയെ ഒരു പ്രധാന വിഷയമായി കാണാൻ കമ്മ്യൂണിറ്റി തുടങ്ങിക്കഴിഞ്ഞു. മനുഷ്യൻ നൽകുന്ന ടോക്കൺ ഇല്ലാത്ത നശിപ്പിക്കുന്ന കോളുകൾ സ്വയമേവ നിരസിക്കുന്ന ചില ഓപ്പൺ സോഴ്സ് പ്രോജക്റ്റുകൾ ഇപ്പോൾ ലഭ്യമാണ്. ഓരോ API കോളിലും ഓഡിറ്റ് ചെയ്യാൻ കഴിയുന്ന ഒരു സൈൻ ചെയ്ത ഇൻ്റന്റ് പേലോഡ് ഉൾപ്പെടുന്ന ആക്ഷൻ-ലെവൽ കൺസെന്റ് (action-level consent) എന്നതിനുള്ള മാനദണ്ഡങ്ങൾ തയ്യാറാക്കിക്കൊണ്ടിരിക്കുകയാണ്.
ആന്തരിക സേവനങ്ങൾ AI ഏജന്റുകൾക്ക് ലഭ്യമാക്കുന്ന സ്ഥാപനങ്ങൾ അവരുടെ API-കൾ താഴെ പറയുന്ന മൂന്ന് കാര്യങ്ങൾക്കായി പരിശോധിക്കണം:
- ഐഡംപോറ്റൻസി (Idempotency) – പാർശ്വഫലങ്ങൾ ഇല്ലാതെ ആവർത്തിച്ച് വിളിക്കാൻ ഈ എൻഡ്പോയിന്റ് അനുവദിക്കുന്നുണ്ടോ? ഇല്ലെങ്കിൽ, ഒരു കൺഫർമേഷൻ ലെയർ ചേർക്കുക.
- വ്യക്തമായ ഉദ്ദേശ്യം വ്യക്തമാക്കുന്ന ഫീൽഡുകൾ (Explicit intent fields) – മാറ്റങ്ങൾ വരുത്തുന്ന അഭ്യർത്ഥനയുടെ ഉദ്ദേശ്യം വ്യക്തമാക്കാൻ വിളിക്കുന്നയാളോട് ആവശ്യപ്പെടുക.
- ഹ്യൂമൻ-ഇൻ-ദി-ലൂപ്പ് ടോക്കണുകൾ (Human-in-the-loop tokens) – നശിപ്പിക്കുന്ന ഏത് കോളോടൊപ്പം നൽകേണ്ട കുറഞ്ഞ സമയത്തേക്ക് മാത്രം നിലനിൽക്കുന്ന, ക്രിപ്റ്റോഗ്രാഫിക്കൽ ആയി ഒപ്പിട്ട ടോക്കണുകൾ നിർമ്മിക്കുക.
MCP സെർവറുകൾ നിർമ്മിക്കുന്ന ഡെവലപ്പർമാർക്ക് ഈ പരിശോധനകൾ ഓർക്കസ്ട്രേഷൻ ലെയറിൽ തന്നെ ഉൾപ്പെടുത്താം, അങ്ങനെ സെർവറിനെ തന്നെ ഒരു സുരക്ഷാ കവചമാക്കി മാറ്റാം. വെബ്ഹുക്ക് (webhook) അടിസ്ഥാനമാക്കിയുള്ള ബോട്ടുകൾക്കും, സെർവർലെസ് ഫംഗ്ഷൻ കോളുകൾക്കും, AI ഏജന്റുകൾ ഉപയോഗിക്കുന്ന കമാൻഡ്-ലൈൻ ഇന്റർഫേസുകൾക്കും ഇതേ രീതി തന്നെ ബാധകമാണ്.
പ്രധാന പാഠം
ഒരു AI ഏജന്റിന് യഥാർത്ഥ ലോകത്തിലെ വിഭവങ്ങളിൽ പ്രവർത്തിക്കാൻ കഴിയുമ്പോൾ, സുരക്ഷ അത് ഉപയോഗിക്കുന്ന ടൂളുകളിലായിരിക്കണം, അല്ലാതെ നമ്മൾ അതിനോട് പറയുന്ന വാക്കുകളിലല്ല. റീഡ്-ഒൺലി പ്രവർത്തനങ്ങൾ ലളിതമാക്കിയും, മാറ്റങ്ങൾ വരുത്തുന്ന കാര്യങ്ങൾ മുൻകൂട്ടി അറിയിച്ചും, മനുഷ്യൻ നൽകുന്ന ടോക്കൺ ഇല്ലാതെ തിരുത്താൻ കഴിയാത്ത പ്രവർത്തനങ്ങൾ നിരസിച്ചും നമുക്ക് ഒരു സീറ്റ് ബെൽറ്റ് (seatbelt) നിർമ്മിക്കാം—മോഡൽ അതിന്റെ സ്വന്തം നിയമങ്ങൾ മറന്നാൽ പോലും ഇത് പ്രവർത്തിക്കും. കുറച്ച് അധികം കോഡ് എഴുതുന്നതിലൂടെ ഉണ്ടാകുന്ന ചിലവ്, ഒരു വർഷത്തെ സാമ്പത്തിക വിവരങ്ങൾ നഷ്ടപ്പെടുന്നതിനേക്കാൾ വളരെ കുറവാണ്.