ഒരു AI നിർമ്മിത cron job പത്ത് സെക്കൻഡിൽ താഴെ സമയം കൊണ്ട് ഒരു സ്റ്റാർട്ടപ്പിലെ എല്ലാ സജീവമായ Stripe സബ്സ്ക്രിപ്ഷനുകളും ഡിലീറ്റ് ചെയ്തു, ഇത് കമ്പനിയുടെ പ്രതിമാസ വരുമാനം (MRR) 38 ഡോളറായി കുറച്ചു. കോഡ് എഴുതിയ ലാംഗ്വേജ് മോഡലിലല്ല, മറിച്ച് ഡെപ്ലോയ്മെന്റ് പൈപ്പ്ലൈനിലാണ് അപകടം ഒളിഞ്ഞിരിക്കുന്നതെന്ന് ഈ സംഭവം കാണിച്ചുതരുന്നു.
എന്താണ് സംഭവിച്ചത്
കഴിഞ്ഞ ആഴ്ച BridgeMindAI-യുടെ ടീം ഉണർന്നപ്പോൾ ഡാഷ്ബോർഡിൽ പ്രതിമാസ വരുമാനം (MRR) വെറും 38 ഡോളർ മാത്രമാണ് കാണിച്ചിരുന്നത്. ഒരു AI മോഡൽ നിർമ്മിച്ച ഒരു വരി കോഡ് ഷെഡ്യൂളർ സ്വയമേവ പ്രവർത്തിപ്പിച്ചു. ഓരോ കസ്റ്റമർ റെക്കോർഡിനും വേണ്ടി Stripe-ന്റെ subscription-cancellation endpoint ഈ കോഡ് വിളിച്ചു. വെറും ഏഴ് സെക്കൻഡുകൾക്കുള്ളിൽ ഈ പ്രക്രിയ പൂർത്തിയായി കസ്റ്റമർ ബേസ് മുഴുവൻ ഇല്ലാതായി.
ഡിലീഷൻ ക്യൂ (deletion queue) കാലിയാണെന്നതിനെ എല്ലാം ഡിലീറ്റ് ചെയ്യാനുള്ള സിഗ്നലായി സ്ക്രിപ്റ്റ് തെറ്റായി വ്യാഖ്യാനിച്ചു. ജനറേറ്റീവ് AI വരുന്നതിനും എത്രയോ മുമ്പ്, അതായത് 1980-കൾ മുതൽ പ്രൊഡക്ഷൻ കോഡുകളിൽ ഈ “empty = all” പാറ്റേൺ നിലവിലുണ്ട്.
എന്തുകൊണ്ട് മോഡൽ കുറ്റക്കാരനല്ല
AI മോഡൽ വിശ്വസനീയമല്ലെന്ന് പറഞ്ഞ് ആളുകൾ പെട്ടെന്ന് അതിനെ കുറ്റപ്പെടുത്തി. എന്നാൽ മോഡൽ മാറ്റിയതുകൊണ്ട് മാത്രം ഈ പ്രശ്നം ഒഴിവാകില്ലായിരുന്നു, കാരണം ഇത് ഒരു ഹാലൂസിനേഷൻ (hallucination) അല്ലെങ്കിൽ പക്ഷപാതം (bias) മൂലമല്ല, മറിച്ച് മനുഷ്യൻ എഴുതിയ ലോജിക് (logic) മൂലമുണ്ടായ പിഴവാണ്.
യഥാർത്ഥ പരാജയങ്ങൾ ആർക്കിടെക്ചറൽ (architectural) ആയിരുന്നു:
- സബ്സ്ക്രിപ്ഷനുകൾ റദ്ദാക്കാൻ കഴിയുന്ന ഒരു ലൈവ് പ്രൊഡക്ഷൻ Stripe API കീ സ്ക്രിപ്റ്റിൽ സൂക്ഷിച്ചിരുന്നു.
- റൺടൈം മേൽനോട്ടം (runtime supervision) ഇല്ലാതെയാണ് ഇത് പ്രവർത്തിച്ചത്.
- കോഡ് ജനറേഷനും എക്സിക്യൂഷനും (execution) ഇടയിൽ ഒരു ഹ്യൂമൻ ചെക്ക്പോയിന്റും ഉണ്ടായിരുന്നില്ല.
ഈ പോരായ്മകൾ കാരണം ഒരു ചെറിയ ബഗ് സെക്കൻഡുകൾക്കുള്ളിൽ വരുമാന സ്രോതസ്സിനെ തകർത്തു കളഞ്ഞു.
ഏതൊരു ഓട്ടോണമസ് പൈപ്പ്ലൈനും പരിശോധിക്കേണ്ട മൂന്ന് സുരക്ഷാ ചോദ്യങ്ങൾ
തിരിച്ചുപിടിക്കാൻ കഴിയാത്ത (irreversible) പ്രവർത്തനങ്ങൾ ഏതെല്ലാം? സബ്സ്ക്രിപ്ഷൻ റദ്ദാക്കുകയോ, ഒരു റെക്കോർഡ് ഡിലീറ്റ് ചെയ്യുകയോ, റീഫണ്ട് നൽകുകയോ ചെയ്യുന്നത് മാറ്റാൻ കഴിയില്ല. അതിനാൽ ഇവയ്ക്ക് റീഡ്-ഓൺലി (read-only) ക്വറികളേക്കാൾ കൂടുതൽ സംരക്ഷണം ആവശ്യമാണ്.
ഏതൊക്കെ ക്രെഡൻഷ്യലുകളാണ് (credentials) ഏജന്റിന് കൈവശമുള്ളത്? ഒരു ഓട്ടോണമസ് പ്രക്രിയയ്ക്ക് മാസ്റ്റർ Stripe കീ നൽകുന്നത് നിയന്ത്രണമില്ലാത്ത അധികാരം നൽകുന്നതിന് തുല്യമാണ്. 'ലീസ്റ്റ്-പ്രിവിലേജ്' (least-privilege) തത്വം പ്രയോഗിക്കുക: ആവശ്യമായ ജോലി മാത്രം ചെയ്യാൻ കഴിയുന്ന സ്കോപ്പ് ചെയ്ത (scoped) കീകൾ ഉപയോഗിക്കുക.
ഹ്യൂമൻ ചെക്ക്പോയിന്റ് എവിടെയാണ്? കോഡ് റിവ്യൂ മാത്രം മതിയാകില്ല. കോഡ് ജനറേഷന് ശേഷം ഉം ഏതെങ്കിലും വിനാശകരമായ (destructive) നടപടികൾക്ക് മുൻപും ഒരു ഗേറ്റ് (gate) ഏർപ്പെടുത്തുക.
പ്രായോഗികമായ സുരക്ഷാ മാർഗങ്ങൾ
- Dry-run gate – ഏതെങ്കിലും ഡിലീറ്റ് അല്ലെങ്കിൽ ക്യാൻസൽ കോൾ ചെയ്യുന്നതിന് മുമ്പ്, ലക്ഷ്യമിടുന്നവയുടെ ലിസ്റ്റ് (log) തയ്യാറാക്കുക. ലിസ്റ്റ് കാലിയാണെങ്കിലോ അസാധാരണമാംവിധം വലുതാണെങ്കിലോ, പ്രക്രിയ നിർത്തിവെച്ച് ഒരു മനുഷ്യനെ അറിയിക്കുക.
- Scoped credentials – ഡിഫോൾട്ട് ആയി റീഡ്-ഓൺലി കീകൾ ഉപയോഗിക്കുക. ഒരു സബ്സ്ക്രിപ്ഷൻ റദ്ദാക്കേണ്ടി വരുമ്പോൾ, ഒരേസമയം ഒരു കസ്റ്റമർ ഐഡിയിൽ മാത്രം പ്രവർത്തിക്കാൻ കഴിയുന്ന നിയന്ത്രിത കീ (restricted key) ഉപയോഗിക്കുക.
- Human-in-the-loop prompt – "ഞാൻ 47 സബ്സ്ക്രിപ്ഷനുകൾ റദ്ദാക്കാൻ പോകുകയാണ്. സ്ഥിരീകരിക്കുക?" എന്നതുപോലെയുള്ള ഒരു ചെറിയ സന്ദേശം ഒരു ചാനലിലേക്ക് (ഉദാഹരണത്തിന് Slack) അയക്കുക. ഇതിനുള്ള ചിലവ് വളരെ കുറവാണ്, എന്നാൽ സുരക്ഷാ ഗുണം വളരെ വലുതാണ്.
കോഡ് എഴുതുന്നത് ഏത് മോഡലാണെങ്കിലും ഈ നടപടികൾ ഫലപ്രദമാണ്, കാരണം ഇവ കോഡ് നിർമ്മിക്കുന്നതിനെയല്ല, മറിച്ച് അത് പ്രവർത്തിക്കുന്ന എൻവയോൺമെന്റിനെയാണ് സംരക്ഷിക്കുന്നത്.
ഓട്ടോണമസ് ഏജന്റുകൾക്കായുള്ള ഒരു പ്രൊഡക്ഷൻ ചെക്ക്ലിസ്റ്റ്
- എല്ലാ പ്രവർത്തനങ്ങളെയും read, reversible, അല്ലെങ്കിൽ irreversible എന്നിങ്ങനെ തരംതിരിക്കുക.
- എല്ലാ irreversible പ്രവർത്തനങ്ങൾക്കും മനുഷ്യന്റെ വ്യക്തമായ അനുമതി ആവശ്യമാണ്.
- ഒരു ജോലിക്ക് ആവശ്യമായ ഏറ്റവും കുറഞ്ഞ പെർമിഷനുകൾ മാത്രം ക്രെഡൻഷ്യലുകൾക്ക് നൽകുക.
- റെക്കോർഡുകൾ ഡിലീറ്റ് ചെയ്യുകയോ മാറ്റം വരുത്തുകയോ ചെയ്യുന്ന ലൂപ്പുകൾക്ക് (loops) പരിധി നിശ്ചയിക്കുക.
- ഏജന്റുകളെ ആദ്യം പ്രൊഡക്ഷൻ ഡാറ്റയ്ക്ക് സമാനമായ ഒരു സാൻഡ്ബോക്സിൽ (sandbox) പ്രവർത്തിപ്പിക്കുക; ലൈവ് ഡാറ്റയിൽ മാറ്റം വരുത്തുന്നതിന് മുമ്പ് ഫലം ഉറപ്പുവരുത്തുക.
- എക്സിക്യൂഷന് മുമ്പ് ഏജന്റിന്റെ പ്ലാൻ ലളിതമായ ഭാഷയിൽ രേഖപ്പെടുത്തുക (log), അങ്ങനെ ഒരു റിവ്യൂവർക്ക് പെട്ടെന്ന് കാര്യം മനസ്സിലാക്കാൻ സാധിക്കും.
ഈ ചെക്ക്ലിസ്റ്റ് പിന്തുടരുന്നതിലൂടെ, "ഒരിക്കൽ പ്രവർത്തിപ്പിച്ച് മറന്നുപോകുന്ന" ഒരു സ്ക്രിറ്റിനെ, എന്തെങ്കിലും തെറ്റാണെന്ന് തോന്നിയാൽ പരിശോധിക്കാനും നിർത്താനും കഴിയുന്ന നിയന്ത്രിതമായ ഒരു വർക്ക്ഫ്ലോ (workflow) ആക്കി മാറ്റാം.
പാഠം വ്യക്തമാണ്: പ്രക്രിയയെ വിശ്വസിക്കുക, മോഡലിനെയല്ല.