നിങ്ങളുടെ AI അധിഷ്ഠിത അസിസ്റ്റന്റ് 99% സമയവും നിർദ്ദേശങ്ങൾ അനുസരിക്കുന്നുണ്ടാകാം, എന്നാൽ ആ വിട്ടുപോയ 1% ആണ് ആക്രമണകാരികൾ ലക്ഷ്യമിടുന്നത്. കൃത്യമായി തയ്യാറാക്കിയ ഒരു പ്രോംപ്റ്റ് നൽകുന്നതിലൂടെ, ഒരു ദുരുദ്ദേശ്യ ഉപയോക്താവിന് മോഡലിനെ അനുമതിയില്ലാത്ത ഫംഗ്ഷനുകൾ പ്രവർത്തിപ്പിക്കാൻ പ്രേരിപ്പിക്കാനും, ഡാറ്റ മോഷ്ടിക്കാനും അല്ലെങ്കിൽ പ്രത്യേക അധികാരമുള്ള പ്രവർത്തനങ്ങൾ ചെയ്യാനും സാധിക്കും. ഇതിനുള്ള പരിഹാരം കൂടുതൽ മര്യാദയുള്ള വാക്കുകൾ ഉപയോഗിക്കുക എന്നതല്ല—മറിച്ച് ഇതിനെ ഒരു ഓതറൈസേഷൻ (authorization) പ്രശ്നമായി കാണുകയും അപകടകരമായ ടൂളുകളെ മോഡലിന്റെ പരിധിയിൽ നിന്ന് നീക്കം ചെയ്യുകയും ചെയ്യുക എന്നതാണ്.
പ്രോംപ്റ്റ് ഇൻജക്ഷൻ വെറുമൊരു പദപ്രയോഗ പ്രശ്നം മാത്രമല്ല
ഡെവലപ്പർമാർ പലപ്പോഴും വലിയ അക്ഷരത്തിലുള്ള മുന്നറിയിപ്പുകൾ, നമ്പറുകൾ നൽകിയ നിയമങ്ങൾ, അല്ലെങ്കിൽ “അഡ്മിൻ ഫംഗ്ഷനുകൾ വിളിക്കരുത്” എന്നതുപോലെയുള്ള നിബന്ധനകൾ ഉപയോഗിച്ച് ഏജന്റുകളെ സുരക്ഷിതമാക്കാൻ ശ്രമിക്കാറുണ്ട്. ഇത്തരം പ്രതിരോധങ്ങൾ “X ചെയ്യരുത്” എന്ന് പറയുന്ന ഒരു വാചകം മോഡൽ അനുസരിക്കുമെന്ന ധാരണയിലാണ് പ്രവർത്തിക്കുന്നത്. എന്നാൽ പ്രായോഗികമായി, അഭ്യർത്ഥനയുടെ രീതി മാറ്റുന്നതിലൂടെയോ, മറ്റൊരു വ്യക്തിയായി അഭിനയിക്കുന്നതിലൂടെയോ (role-playing), അല്ലെങ്കിൽ അധിക വിവരങ്ങൾ ചേർക്കുന്നതിലൂടെയോ നിർദ്ദേശങ്ങൾ അവഗണിക്കാൻ മോഡലിനെ പ്രേരിപ്പിക്കാൻ സാധിക്കും. ഇംഗ്ലീഷ് ഭാഷയിലെ അതിർവരമ്പുകൾ മാറ്റം വരുത്താവുന്നതാണ്; എന്നാൽ ആക്രമണകാരിയുടെ പ്രോംപ്റ്റുകൾക്ക് പരിധികളില്ല, കൂടാതെ അവ പരീക്ഷിച്ചു നോക്കാൻ പണവും ചിലവാകുന്നില്ല.
യഥാർത്ഥ പ്രശ്നം ഏജന്റിന് ലഭിക്കുന്ന ടൂൾ ലിസ്റ്റിലാണ് (tool list). പ്രോംപ്റ്റ് സ്കീമയിൽ അഡ്മിൻ അവകാശങ്ങൾ നൽകുന്ന ഒരു ഫംഗ്ഷൻ അടങ്ങിയിട്ടുണ്ടെങ്കിൽ, ആ അധികാരത്തിലേക്ക് എത്താനുള്ള ഒരു വഴി മോഡലിന് ലഭിക്കുന്നു. “ഉപഭോക്താക്കൾക്കായി ഇത് ഉപയോഗിക്കരുത്” എന്ന് പ്രോംപ്റ്റിൽ പറഞ്ഞിട്ടുണ്ടെങ്കിൽ പോലും, ആ ഫംഗ്ഷൻ അതിന്റെ എക്സിക്യൂഷൻ എൻവയോൺമെന്റിൽ (execution environment) ഉള്ളതുകൊണ്ട് അത് പ്രവർത്തിപ്പിക്കാൻ മോഡലിനെ പ്രേരിപ്പിക്കാൻ സാധിക്കും. അതിനാൽ ഇത് ഒരു ഓതറൈസേഷൻ വിടവാണ് (authorization gap): അധികാരമില്ലാത്ത ഒരു ഉപയോക്താവിന് സിസ്റ്റം ഉയർന്ന അധികാരമുള്ള കഴിവുകൾ തുറന്നുനൽകുന്നു എന്നതാണ് പ്രശ്നം.
എക്സ്പോഷർ പരിമിതപ്പെടുത്തി ഏജന്റുകളെ സുരക്ഷിതമാക്കുക
ഈ വിടവ് അടയ്ക്കാനുള്ള ഏറ്റവും ലളിതമായ മാർഗ്ഗം, ഉപയോഗിക്കാൻ അനുമതിയില്ലാത്ത ടൂളുകളിലേക്ക് മോഡലിന് പ്രവേശനം നൽകുന്നത് നിർത്തുക എന്നതാണ്. ടൂൾ ലിസ്റ്റിനെ ഒരു API കീ പോലെ കരുതുക: കീ ഇല്ലെങ്കിൽ ആ കോൾ നടക്കില്ല. നിലവിലുള്ള കോൺടെക്സ്റ്റിൽ (context) ഇല്ലാത്ത ഒരു ഫംഗ്ഷനെ എത്ര മികച്ച പദപ്രയോഗങ്ങൾ ഉപയോഗിച്ചാലും വിളിക്കാൻ കഴിയില്ല.
തെറ്റായ രീതി
Prompt: “You are an assistant. Do not use the adminDeleteUser function for regular customers.”
മോഡലിന്റെ ടൂൾബോക്സിൽ adminDeleteUser ഇപ്പോഴും കാണുന്നതിനാൽ, അതിനെ ഉപയോഗിക്കാൻ പ്രേരിപ്പിക്കാൻ സാധിക്കും.
ശരിയായ രീതി
Prompt schema for a regular customer: { “functions”: [ “searchCatalog”, “placeOrder” ] }
adminDeleteUser ഇവിടെ കാണുന്നില്ല, അതിനാൽ അത് വിളിക്കാൻ മോഡലിന് കഴിയില്ല.
ഡെവലപ്പർമാർക്കായി മൂന്ന് പ്രായോഗിക നിയമങ്ങൾ
- ഓരോ അഭ്യർത്ഥനയ്ക്കും അനുസൃതമായി ടൂൾ ലിസ്റ്റുകൾ നിർമ്മിക്കുക (Build tool lists per request) – ഓതന്റിക്കേറ്റ് ചെയ്ത ഉപയോക്താവിന്റെ അനുമതികൾ (permissions) അടിസ്ഥാനമാക്കി ഫംഗ്ഷൻ കാറ്റലോഗ് ഡൈനാമിക് ആയി നിർമ്മിക്കുക. ഒരു ഉപഭോക്താവിന് അവർക്ക് ആവശ്യമുള്ള ഫംഗ്ഷനുകൾ മാത്രമേ കാണാൻ കഴിയൂ; എന്നാൽ ഒരു അഡ്മിന് മുഴുവൻ സെറ്റും കാണാം.
- Fail closed – ഉപയോക്താവിന്റെ ഐഡന്റിറ്റി പരിശോധിക്കാൻ കഴിയില്ലെങ്കിൽ, “എല്ലാ ടൂളുകളും ലഭ്യമാണ്” എന്ന പൊതുവായ മറുപടിക്ക് പകരം ഒരു ശൂന്യമായ ലിസ്റ്റ് (empty list) നൽകുക. ഇത് ഓതന്റിക്കേഷൻ ഇല്ലാത്ത ഒരു അഭ്യർത്ഥനയ്ക്ക് അപ്രതീക്ഷിതമായി അധികാരം ലഭിക്കില്ലെന്ന് ഉറപ്പാക്കുന്നു.
- Shared state ഒഴിവാക്കുക (Avoid shared state) – ടൂൾ ഡെഫനിഷനുകൾ കാഷെ (cache) ചെയ്യുമ്പോൾ, ഉപയോക്താവിന്റേതായ ഡാറ്റ ഒരു ഷെയർഡ് ഒബ്ജക്റ്റിൽ (shared object) ഒരിക്കലും എഴുതരുത്. ഒരു ഉപയോക്താവിന്റെ അനുമതികൾ മറ്റൊരാളുടെ അഭ്യർത്ഥനയെ ബാധിക്കാതിരിക്കാൻ copy-on-write അല്ലെങ്കിൽ per-session കോപ്പികൾ ഉപയോഗിക്കുക.
ഒരു സാധാരണ ഉപയോക്താവിന് കാണാൻ കഴിയുന്ന സ്കീമ അഡ്മിന് കാണാൻ കഴിയുന്നതിന് സമാനമാണെങ്കിൽ, സുരക്ഷാ അതിർവരമ്പ് ഇപ്പോഴും പ്രോംപ്റ്റ് ടെക്സ്റ്റിൽ മാത്രമാണ്, പ്രോംപ്റ്റുകൾ ഒരു വിശ്വസനീയമായ സുരക്ഷാ സംവിധാനമല്ല.
നമ്മൾ ഇതിലേക്ക് എങ്ങനെ എത്തിച്ചേർന്നു
എക്സ്റ്റേണൽ API-കൾ വിളിക്കാനോ, കോഡ് പ്രവർത്തിപ്പിക്കാനോ, ഡാറ്റാബേസുകൾ മാറ്റം വരുത്താനോ ആവശ്യമായ വർക്ക്ഫ്ലോകളിൽ ഡെവലപ്പർമാർ ലാർജ് ലാംഗ്വേജ് മോഡലുകൾ (LLMs) ഉപയോഗിക്കാൻ തുടങ്ങിയപ്പോഴാണ് പ്രോംപ്റ്റ് ഇൻജക്ഷൻ എന്ന പ്രശ്നം ഉയർന്നുവന്നത്. മോഡലിന്റെ “റീസണിംഗ്” (reasoning) എന്നത് ലഭ്യമായ ടൂളുകളുടെ പട്ടിക ഉൾപ്പെടെയുള്ള ഒരു പ്രോംപ്റ്റ് വഴിയാണ് നിയന്ത്രിക്കപ്പെടുന്നത്. “അഡ്മിൻ അല്ലാത്തവരുടെ റെക്കോർഡുകൾ ഡിലീറ്റ് ചെയ്യരുത്” എന്നതുപോലെയുള്ള സ്വാഭാവിക ഭാഷയിലുള്ള നിയമങ്ങൾ മോഡൽ അനുസിക്കുമെന്ന് ആദ്യകാല പ്രോട്ടോടൈപ്പുകൾ കരുതിയിരുന്നു. എന്നാൽ ഏതാനും അധിക വാചകങ്ങൾ ഉപയോഗിച്ച് ആ നിയമങ്ങൾ മറികടന്ന് ഡിലീറ്റ് ഫംഗ്ഷൻ പ്രവർത്തിപ്പിക്കാൻ സാധിക്കുമെന്ന് ആക്രമണകാരികൾ വേഗത്തിൽ തെളിയിച്ചു.
പ്രോംപ്റ്റ് ഭാഷ കൂടുതൽ കർശനമാക്കുകയോ, “ഒരിക്കലും X ചെയ്യരുത്” എന്നതുപോലെയുള്ള നിബന്ധനകൾ ചേർക്കുകയോ, സംശയാസ്പദമായ ടോക്കണുകൾ നീക്കം ചെയ്യാൻ regex ഫിൽട്ടറുകൾ ഉപയോഗിക്കുകയോ ആയിരുന്നു കമ്മ്യൂണിറ്റിയുടെ ആദ്യ പ്രതികരണം. ഈ നടപടികൾ അബദ്ധവശാൽ സംഭവിക്കുന്ന തെറ്റായ ഉപയോഗങ്ങൾ കുറച്ചെങ്കിലും, അഭ്യർത്ഥനയുടെ രീതി മാറ്റാൻ കഴിവുള്ള ഒരു ആക്രമണകാരിയെ തടയാൻ സാധിച്ചില്ല. ഇതിന്റെ അടിസ്ഥാന കാരണം—അധികാരമില്ലാത്ത ഒരാൾക്ക് ഉയർന്ന അധികാരമുള്ള ഫംഗ്ഷനുകൾ തുറന്നുനൽകുന്നു എന്നത്—മാറ്റമില്ലാതെ തുടർന്നു.
ആര് ജയിക്കുന്നു, ആര് തോൽക്കുന്നു
ഓരോ അഭ്യർത്ഥനയ്ക്കും അനുസൃതമായി ടൂൾ സ്കോപ്പിംഗ് (per-request tool scoping) നടപ്പിലാക്കുന്ന സംരംഭങ്ങൾ (Enterprises) വ്യക്തവും നടപ്പിലാക്കാൻ കഴിയുന്നതുമായ ഒരു സുരക്ഷാ അതിർവരമ്പ് നേടുന്നു. ഒരു തെറ്റായ പ്രോംപ്റ്റ് വഴി അഡ്മിൻ അധികാരങ്ങൾ ലഭിക്കുമെന്ന ഭയമില്ലാതെ ഇവരുടെ ഏജന്റുകളെ വലിയ തോതിൽ ഉപയോഗിക്കാൻ സാധിക്കും. ഓഡിറ്റ് ട്രയലുകൾ (audit trail) കമ്പനികൾക്ക് ഗുണകരമാണ്: മോഡലിന് അയച്ച ഫംഗ്ഷനുകളുടെ പട്ടിക ലോഗ് ചെയ്യാനും പരിശോധിക്കാനും കഴിയുന്ന ഒരു കൃത്യമായ രേഖയായിരിക്കും.
പ്രോംപ്റ്റുകളെ മാത്രം ആശ്രയിക്കുന്ന ഡെവലപ്പർമാർ നിരന്തരം വെല്ലുവിളികൾ നേരിടേണ്ടി വരും. അവരുടെ ഏജന്റുകൾ ടെസ്റ്റിംഗിൽ കൃത്യമായി പ്രവർത്തിക്കുന്നതായി തോന്നാമെങ്കിലും, യഥാർത്ഥ ഉപയോഗത്തിൽ അവ ഹാക്ക് ചെയ്യപ്പെടാൻ സാധ്യതയുണ്ട്. ഇത് ഡാറ്റാ ചോർച്ചയ്ക്കും, അനധികൃത ഇടപാടുകൾക്കും, നിയമലംഘനങ്ങൾക്കും കാരണമായേക്കാം. ഒരു ഡൈനാമിക് ടൂൾ ലിസ്റ്റ് നിർമ്മിക്കുന്നതിനേക്കാൾ വലിയ നഷ്ടമാണ് ഒരു ഡാറ്റാ ബ്രീച്ച് (data breach) ഉണ്ടാക്കിയേക്കാവുന്ന പ്രത്യാഘാതങ്ങൾ.
എതിർവാദം: “മികച്ച പ്രോംപ്റ്റുകൾ മാത്രം മതി”
മതിയായ ഇൻസ്ട്രക്ഷൻ എഞ്ചിനീയറിംഗിലൂടെ—layered prompts, system messages, and reinforcement learning from human feedback—മോഡലിനെ “ചെയ്യരുത്” (do not) എന്ന നിബന്ധനകൾ പാലിക്കാൻ പ്രേരിപ്പിക്കാൻ കഴിയുമെന്ന് ചിലർ വാദിക്കുന്നു. എന്നാൽ ലാംഗ്വേജ് മോഡലുകൾ പ്രോബബിലിസ്റ്റിക് ജനറേറ്ററുകൾ (probabilistic generators) ആണെന്നതാണ് യാഥാർത്ഥ്യം; അവ ഏറ്റവും സാധ്യതയുള്ള തുടർച്ചയെയാണ് പരിഗണിക്കുന്നത്, അല്ലാതെ കർശനമായ ഒരു സുരക്ഷാ നിയമത്തെയല്ല. കൃത്യമായി ക്രമീകരിച്ച ഗാർഡ്റൈലുകൾ (guardrails) ഉണ്ടെങ്കിൽ പോലും, പുതിയ രീതിയിലുള്ള വാചകഘടനകൾ സുരക്ഷാ വലയങ്ങൾ മറികടക്കാൻ സാധ്യതയുണ്ട്, പ്രത്യേകിച്ച് ആക്രമണകാരിക്ക് യാതൊരു ചിലവുമില്ലാതെ നിരന്തരം പരീക്ഷണങ്ങൾ നടത്താൻ കഴിയുമ്പോൾ. ഗാർഡ്റൈലുകൾ അനാവശ്യമായ വിവരങ്ങൾ (noise) കുറയ്ക്കാൻ ഉപകരിക്കുമെങ്കിലും, അവയെ മാത്രം സുരക്ഷാ കവചമായി കാണരുത്.
അടുത്തതായി ശ്രദ്ധിക്കേണ്ടവ
- ടൂൾ സ്കോപ്പിംഗിനെ (tool scoping) ഒരു ഫസ്റ്റ് ക്ലാസ് API ആയി അവതരിപ്പിക്കുന്ന ഫ്രെയിംവർക്കുകൾ – ഓരോ ഉപയോക്താവിനും അനുമതിയിട്ടുള്ള കാര്യങ്ങൾ (per-user capabilities) പ്രഖ്യാപിക്കാനും, പ്രോംപ്റ്റ് തയ്യാറാക്കുന്നതിന് മുമ്പ് ഫംഗ്ഷൻ ലിസ്റ്റിൽ നിന്ന് അനാവശ്യമായവ ഒഴിവാക്കാനും സഹായിക്കുന്ന പുതിയ ലൈബ്രറികൾ പ്രതീക്ഷിക്കാം.
- സ്റ്റാൻഡേർഡൈസ്ഡ് “ഫംഗ്ഷൻ മാനഫെസ്റ്റുകൾ” (function manifests) – പബ്ലിക് ഫംഗ്ഷനുകളെയും പ്രൈവിലേജഡ് ഫംഗ്ഷനുകളെയും വേർതിരിക്കുന്ന ഒരു JSON സ്കീമ ഇൻഡസ്ട്രി ഗ്രൂപ്പുകൾ നിർവചിച്ചേക്കാം, ഇത് ഓരോ റിക്വസ്റ്റിനും അനുയോജ്യമായ മാനഫെസ്റ്റുകൾ നിർമ്മിക്കുന്നത് എളുപ്പമാക്കും.
- റൺടൈം എൻഫോഴ്സ്മെന്റ് (Runtime enforcement) – ചില പ്ലാറ്റ്ഫോമുകൾ സാൻഡ്ബോക്സ്ഡ് എക്സിക്യൂഷൻ (sandboxed execution) പരീക്ഷിച്ചുവരികയാണ്; ഇത് വിളിക്കപ്പെടുന്ന ഫംഗ്ഷനുമായി താരതമ്യം ചെയ്ത് വിളിക്കുന്നയാളുടെ ടോക്കൺ പരിശോധിക്കുകയും, പ്രോംപ്റ്റ് സ്കോപ്പിംഗിന് പുറമെ രണ്ടാമതൊരു സുരക്ഷാ പാളി കൂടി നൽകുകയും ചെയ്യുന്നു.
ഇതിൽ നിന്നുള്ള പാഠം വ്യക്തമാണ്: പ്രോംപ്റ്റ് ഇൻജക്ഷനെ (prompt injection) ഒരു ഓതറൈസേഷൻ പിഴവായി (authorization flaw) കണക്കാക്കുക. മോഡലിന്റെ ടൂൾബോക്സിൽ നിന്ന് അനുമതിയില്ലാത്ത ടൂളുകൾ നീക്കം ചെയ്യുന്നതിലൂടെ, ബുദ്ധിപരമായ വാചകങ്ങളിലൂടെ ചൂഷണം ചെയ്യാൻ ശ്രമിക്കുന്ന ആ അറ്റാക്ക് സർഫസ് (attack surface) ഇല്ലാതാക്കാൻ സാധിക്കും. പ്രോംപ്റ്റുകൾക്ക് പെരുമാറ്റത്തെ നിയന്ത്രിക്കാൻ കഴിയും; എന്നാൽ അവയ്ക്ക് ശരിയായ ആക്സസ് കൺട്രോളിന് (access control) പകരമാവില്ല.