Authentication എന്നത് നിങ്ങൾ ആരാണെന്ന് പരിശോധിക്കുന്നു; authorization എന്നത് നിങ്ങൾക്ക് എന്ത് ചെയ്യാൻ അനുവാദമുണ്ടെന്ന് തീരുമാനിക്കുന്നു. വർദ്ധിച്ചുവരുന്ന എണ്ണം AI അധിഷ്ഠിത ആപ്ലിക്കേഷനുകൾ, ലോഗിൻ സമയത്ത് ഒരു തവണ മാത്രം ഉപയോക്താവിന്റെ ഐഡന്റിറ്റി പരിശോധിക്കുകയും, ബാക്കി സെഷൻ മുഴുവൻ ആ ഏജന്റിന് ഏത് റിസോഴ്സിനും പ്രവർത്തിക്കാൻ അനുമതി നൽകുകയും ചെയ്യുന്നു. ഇത് യഥാർത്ഥത്തിൽ ഏജന്റിന് ഒരു "ബ്ലാങ്ക് ചെക്ക്" നൽകുന്നതിന് തുല്യമാണ്. ഈ രീതി അബദ്ധവശാൽ ഡാറ്റാ ചോർച്ചകൾക്കും, അനാവശ്യ ഇമെയിലുകൾക്കും, അല്ലെങ്കിൽ ഡാറ്റാബേസ് അപ്‌ഡേറ്റുകൾക്ക് പോലും കാരണമായേക്കാവുന്ന അപകടസാധ്യതകൾ തുറന്നുവിടുന്നു. ഒരു AI അസിസ്റ്റന്റിന് മില്ലിസെക്കൻഡ് ലേറ്റൻസിയിൽ ഒന്നിലധികം ടൂളുകൾ ഉപയോഗിക്കാൻ കഴിയുമ്പോഴേക്കും ഈ റിസ്ക് വർദ്ധിക്കുന്നു.

എന്തുകൊണ്ടാണ് ഈ തെറ്റ് ആവർത്തിക്കുന്നത്

മിക്ക AI ഡെവലപ്പർമാരും ലോഗിൻ സ്ക്രീനെ മാത്രമാണ് ഏക സുരക്ഷാ കവാടമായി കാണുന്നത്. കോഡ് ഒരു പാസ്‌വേഡോ ടോക്കണോ ആവശ്യപ്പെടുന്നു, സെഷനെ “authenticated” എന്ന് അടയാളപ്പെടുത്തുന്നു, തുടർന്ന് തുടർന്നുവരുന്ന എല്ലാ അഭ്യർത്ഥനകളും സുരക്ഷിതമാണെന്ന് കരുതുന്നു. ഒരു പരമ്പരാഗത വെബ് ആപ്പിൽ, മനുഷ്യന്റെ സാവധാനത്തിലുള്ള ക്ലിക്കുകൾ സ്വാഭാവികമായ ഒരു നിയന്ത്രണമായി (throttling point) പ്രവർത്തിക്കുന്നു; ഒരു മനുഷ്യൻ “delete” അമർത്തുന്നതിന് മുമ്പ് ഒന്ന് ആലോചിക്കും. എന്നാൽ, ഒരു AI ഏജന്റിന് സെക്കൻഡുകൾക്കുള്ളിൽ ഡസൻ കണക്കിന് ടൂൾ കോളുകൾ നടത്താൻ കഴിയും. പ്ലാറ്റ്‌ഫോം “ഉപയോക്താവ് ലോഗിൻ ചെയ്തിട്ടുണ്ടോ?” എന്ന് മാത്രം ചോദിക്കുകയാണെങ്കിൽ, ഓരോ കോളും ഒരേ നിയന്ത്രണമില്ലാത്ത അധികാരങ്ങൾ കൈപ്പറ്റുന്നു.

ഇതിന്റെ മൂലകാരണം സൗകര്യമാണ്. കോഡിന് ഒന്നിലധികം ടോക്കണുകളോ സ്കോപ്പുകളോ കൈകാര്യം ചെയ്യേണ്ടി വരാതിരിക്കാൻ, ടീമുകൾ പലപ്പോഴും ആപ്ലിക്കേഷന് മുഴുവനായി ഒരു ലോങ്ങ്-ലിവിഡ് (long-lived) സർവീസ് അക്കൗണ്ട് നൽകുന്നു. ഈ അക്കൗണ്ടിന് സാധാരണയായി എല്ലാ പ്രോജക്റ്റുകളിലും റീഡ്, റൈറ്റ്, ഡിലീറ്റ് എന്നിങ്ങനെ വിപുലമായ അനുമതികളുണ്ടാകും. ഒരു AI അസിസ്റ്റന്റ് ആ സെഷനിൽ പ്രവർത്തിക്കുമ്പോൾ, നിലവിലെ ടാസ്ക് അതിന് ആവശ്യമുണ്ടോ എന്നത് പരിഗണിക്കാതെ തന്നെ ആ അധികാരങ്ങൾ അത് സ്വയമേവ കൈപ്പറ്റുന്നു.

എന്തൊക്കെയാണ് നഷ്ടപ്പെടാൻ സാധ്യതയുള്ളത്

  • ഡാറ്റാ എക്സ്പോഷർ (Data exposure) – ഉപയോക്താവ് ലോഗിൻ ചെയ്ത ശേഷം ഏത് ഫയലും വായിക്കാൻ കഴിയുന്ന ഒരു ഏജന്റ്, അറിയാതെ തന്നെ രഹസ്യരേഖകൾ ഒരു മറുപടിയിൽ ഉൾപ്പെടുത്തുകയും അത് പിന്നീട് സ്ഥാപനത്തിന് പുറത്തേക്ക് പങ്കുവെക്കപ്പെടുകയും ചെയ്തേക്കാം.
  • അപ്രതീക്ഷിത നടപടികൾ (Unintended actions) – ഒരു സപ്പോർട്ട് എഞ്ചിനീയറുടെ AI ഹെൽപ്പറിന്, എഞ്ചിനീയറുടെ സെഷൻ സജീവമായതുകൊണ്ട് മാത്രം പ്രൊഡക്ഷൻ ഡാറ്റാബേസുകൾക്കെതിരെ ഒരു SQL ക്വറി പ്രവർത്തിപ്പിക്കാൻ കഴിഞ്ഞേക്കാം, ആ ക്വറി കൈകാര്യം ചെയ്യുന്ന ടിക്കറ്റുമായി ബന്ധമില്ലെങ്കിൽ പോലും.
  • റെഗുലേറ്ററി കംപ്ലയൻസ് (Regulatory compliance) – ഡാറ്റാ സംരക്ഷണ നിയമങ്ങൾ പലതും അനുമതികൾ ആവശ്യമായ പരിധിയിൽ മാത്രം പരിമിതപ്പെടുത്തണമെന്ന് ആവശ്യപ്പെടുന്നു. ഒരു ബ്ലാങ്കറ്റ് പെർമിഷൻ മോഡൽ ഈ തത്വങ്ങൾ ലംഘിക്കുകയും ഓഡിറ്റുകൾക്കോ പിഴകൾക്കോ കാരണമാവുകയും ചെയ്യാം.
  • പ്രവർത്തന ചെലവ് (Operational cost) – റെക്കോർഡുകൾ ഡിലീറ്റ് ചെയ്യുകയോ മാറ്റം വരുത്തുകയോ ചെയ്യുന്ന തെറ്റുകൾ ടീമുകളെ മാറ്റങ്ങൾ റോളബാക്ക് ചെയ്യാനും, കാരണങ്ങൾ അന്വേഷിക്കാനും, ഉപയോക്താക്കളുമായുള്ള വിശ്വാസം വീണ്ടെടുക്കാനും നിർബന്ധിക്കുന്നു—ഇതെല്ലാം സമയം ലാഭിക്കാനും പണം നഷ്ടപ്പെടുത്താനും കാരണമാകുന്നു.

വിട്ടുപോയ ഘട്ടം: ഓരോ പ്രവൃത്തിക്കും പ്രത്യേകമായുള്ള ഓതറൈസേഷൻ (per-action authorization)

ഓതറൈസേഷൻ എന്നത് സിസ്റ്റത്തിന്റെ മുൻവാതിലിൽ മാത്രം പോരാ, ഉള്ളിലെ ഓരോ “വാതിലിലും” പരിശോധിക്കേണ്ടതുണ്ട്. ചോദ്യം “ഇത് ആരാണ്?” എന്നതിൽ നിന്ന് “ഈ പ്രത്യേക റിസോഴ്സിന്മേൽ ഈ പ്രത്യേക പ്രവൃത്തി ഇപ്പോൾ ചെയ്യാൻ അനുവാദമുണ്ടോ?” എന്നതിലേക്ക് മാറണം. ഈ പരിശോധന നടപ്പിലാക്കാൻ സിസ്റ്റം പൂർണ്ണമായും പുനർരൂപകൽപ്പന ചെയ്യേണ്ടതില്ല; ഒരു സിംഗിൾ സെഷൻ ഫ്ലാഗിൽ നിന്ന് കുറഞ്ഞ കാലയളവുള്ള, സ്കോപ്പ് ചെയ്ത (scoped) ടോക്കണുകളിലേക്ക് മാറുന്നതだけで മതിയാകും.

ഇത് പ്രായോഗികമായി എങ്ങനെ പ്രവർത്തിക്കുന്നു

  1. നിശ്ചിത സ്കോപ്പുള്ള ഒരു ടോക്കൺ അഭ്യർത്ഥിക്കുക (Request a token with a defined scope) – AI ഏജന്റിന് ഒരു ടൂൾ വിളിക്കേണ്ടതുണ്ട് എന്ന് വരുമ്പോൾ, ആവശ്യമായ കൃത്യമായ അനുമതികൾ (ഉദാഹരണത്തിന്, read:ticket, execute:sql_query) ഉൾക്കൊള്ളുന്ന ഒരു ടോക്കൺ അത് ആദ്യം നേടുന്നു.
  2. ഓരോ കോളിലും ടോക്കൺ പരിശോധിക്കുക (Validate the token for each call) – ടൂൾ പ്രവർത്തിക്കുന്നതിന് മുമ്പ്, ടോക്കണിൽ ആവശ്യമായ സ്കോപ്പ് ഉണ്ടെന്നും ടോക്കൺ കാലാവധി കഴിഞ്ഞിട്ടില്ലെന്നും സർവീസ് പരിശോധിക്കുന്നു.
  3. റിസോഴ്സിനെ സ്കോപ്പുമായി പൊരുത്തപ്പെടുത്തുക (Match resource to scope) – അഭ്യർത്ഥന ഒരു പ്രത്യേക പ്രോജക്റ്റിനെയോ ഡാറ്റാബേസിനെയോ ലക്ഷ്യം വെക്കുന്നതാണെങ്കിൽ, ടോക്കൺ ആ ഐഡന്റിഫിക്കേഷറിലേക്ക് പ്രവേശനം വ്യക്തമായി അനുവദിച്ചിരിക്കണം.
  4. നിരസിക്കുകയോ അനുവദിക്കുകയോ ചെയ്യുക (Reject or allow) – ഏതെങ്കിലും പരിശോധന പരാജയപ്പെട്ടാൽ, ആ കോൾ നിരസിക്കപ്പെടുകയും ഏജന്റിന് ഉപയോക്താവിന് കാണിക്കാൻ കഴിയുന്ന ഒരു എറർ ലഭിക്കുകയും ചെയ്യുന്നു.

കോഡിലെ വ്യത്യാസം ലളിതമാണ്. ഒരു “മോശം” രീതി ഇപ്രകാരമായിരിക്കാം:

if session.is_authenticated():
    tool.run(params)

ഒരു “നല്ല” രീതി പരിശോധന വിപുലീകരിക്കുന്നു:

token = get_scoped_token(user, required_scope)
if token.is_valid() and token.allows(required_scope, resource_id):
    tool.run(params)
else:
    raise PermissionError

രണ്ടാമത്തെ രീതി കുറച്ച് വരികൾ അധികം ചേർക്കുന്നുണ്ടെങ്കിലും, ഓരോ പ്രവർത്തനത്തിനും ശരിയായ ചോദ്യം ചോദിക്കാൻ സിസ്റ്റത്തെ നിർബന്ധിക്കുന്നു.

കാര്യങ്ങൾ എളുപ്പമാക്കുന്ന മാനദണ്ഡങ്ങൾ (Standards)

OAuth 2.0 സ്കോപ്പുകൾ ഒരു ടോക്കണിന് എന്ത് ചെയ്യാൻ കഴിയുമെന്ന് പരിമിതപ്പെടുത്താൻ നിലവിൽ വ്യാപകമായി ഉപയോഗിക്കുന്ന ഒരു മാർഗ്ഗമാണ്. project:1234:write അല്ലെങ്കിൽ email:send പോലുള്ള സ്കോപ്പുകൾ ഉൾക്കൊള്ളുന്ന കുറഞ്ഞ കാലയളവുള്ള ആക്സസ് ടോക്കണുകൾ നൽകുന്നതിലൂടെ, പരിശോധന ഘട്ടം നിർവ്വഹിക്കാൻ ഡെവലപ്പർമാർക്ക് നിലവിലുള്ള ലൈബ്രറികളെ ആശ്രയിക്കാം.

പുതിയ Rich Authorization Requests (RFC 9396) ഈ ആശയത്തെ വിപുലീകരിക്കുന്നു, ഇത് ഒരു സ്റ്റാറ്റിക് ലിസ്റ്റ് മുൻകൂട്ടി നിശ്ചയിക്കുന്നതിന് പകരം റൺടൈമിൽ (runtime) സൂക്ഷ്മമായ അനുമതികൾ അഭ്യർത്ഥിക്കാൻ ക്ലയന്റിനെ അനുവദിക്കുന്നു. ഉപയോക്താവിന്റെ ഉദ്ദേശ്യത്തിനനുസരിച്ച് ഒരു AI വർക്ക്ഫ്ലോയ്ക്ക് അതിന്റെ കഴിവുകൾ പെട്ടെന്ന് കൂട്ടിച്ചേർക്കാനോ ഒഴിവാക്കാനോ ആവശ്യമായി വരുമ്പോൾ ഈ വഴക്കം (flexibility) വളരെ ഉപകാരപ്രദമാണ്.

എതിർവാദം: ലാളിത്യം വേഴ്സസ് സുരക്ഷ (simplicity versus security)

ഓരോ ആക്ഷനും പ്രത്യേകം പരിശോധിക്കുന്നത് ലേറ്റൻസിയും (latency) കോഡ് സങ്കീർണ്ണതയും വർദ്ധിപ്പിക്കുമെന്ന് ചില ടീമുകൾ വാദിക്കുന്നു, പ്രത്യേകിച്ച് AI അസിസ്റ്റന്റ് വേഗത്തിൽ നിരവധി ടൂളുകൾ ഉപയോഗിക്കേണ്ടി വരുമ്പോൾ. ഓരോ തവണയും പുതിയ ടോക്കൺ എടുക്കുന്നതിനും പരിശോധിക്കുന്നതിനുമുള്ള അധിക ജോലി ഒഴിവാക്കാൻ ഒരു സിംഗിൾ സെഷൻ ടോക്കൺ മതിയാകും എന്ന് അവർ ചൂണ്ടിക്കാട്ടുന്നു. എന്നാൽ, ഇതിന്റെ പകരമായി ലഭിക്കുന്നത് ദുരുപയോഗത്തിനുള്ള സാധ്യത വളരെ കൂടുതലാണ് എന്നതാണ്. ആധുനിക ടോക്കൺ-വാലിഡേഷൻ സേവനങ്ങൾ മൈക്രോസെക്കൻഡുകൾക്കുള്ളിൽ പ്രവർത്തിക്കാൻ രൂപകൽപ്പന ചെയ്തിട്ടുള്ളതാണ്, കൂടാതെ principle of least privilege ലംഘിക്കാതെ തന്നെ അധിക നെറ്റ്‌വർക്ക് റൗണ്ട്-ട്രിപ്പുകൾ ബാച്ച് ചെയ്യാനോ കാഷെ ചെയ്യാനോ സാധിക്കും. ഡാറ്റാ ഇന്റഗ്രിറ്റിയും കംപ്ലയൻസും (compliance) അനിവാര്യമായ സാഹചര്യങ്ങളിൽ, ചെറിയ രീതിയിലുള്ള പെർഫോമൻസ് കുറവിനേക്കാൾ വലിയ നേട്ടം റിസ്ക് കുറയ്ക്കുന്നതിലൂടെ ലഭിക്കുന്നു.

അടുത്തതായി ശ്രദ്ധിക്കേണ്ട കാര്യങ്ങൾ

  • AI SDK-കളിൽ സ്കോപ്പ് ചെയ്ത ടോക്കണുകളുടെ ഉപയോഗം – പ്രധാനപ്പെട്ട AI പ്ലാറ്റ്‌ഫോം ടൂൾകിറ്റുകളിലെ അപ്‌ഡേറ്റുകൾ ശ്രദ്ധിക്കുക; പലതും OAuth അധിഷ്ഠിത സ്കോപ്പുകൾക്കായി ഹെൽപ്പർ ഫംഗ്ഷനുകൾ അവതരിപ്പിച്ചു തുടങ്ങിയിട്ടുണ്ട്.
  • Policy-as-code ഫ്രെയിംവർക്കുകൾ – പുതിയ പരിഹാരങ്ങൾ വഴി ടീമുകൾക്ക് ഓതറൈസേഷൻ നിയമങ്ങൾ ഒരു ഡെക്ലറേറ്റീവ് ഫയലിൽ രേഖപ്പെടുത്താനും അവ റൺടൈമിൽ സ്വയമേവ നടപ്പിലാക്കാനും സാധിക്കും.
  • ഓരോ ആക്ഷനും സംബന്ധിച്ച തീരുമാനങ്ങൾ വ്യക്തമാക്കുന്ന ഓഡിറ്റ് ലോഗുകൾ – കൂടുതൽ പ്ലാറ്റ്‌ഫോമുകൾ ഓരോ ഓതറൈസേഷൻ പരിശോധനയും രേഖപ്പെടുത്തുന്നതോടെ, ഏതൊക്കെ AI ആക്ഷനുകളാണ് അനുവദിക്കുന്നതോ തടയുന്നതോ എന്ന് മനസ്സിലാക്കാൻ സ്ഥാപനങ്ങൾക്ക് സാധിക്കും, ഇത് ഭാവിയിലെ പോളിസി മാറ്റങ്ങൾക്ക് സഹായിക്കും.

ചുരുക്കം

ലോഗിൻ ചെയ്ത ഒരു സെഷനെ എന്തുമാകാൻ അനുമതിയായി കാണുന്നത് അപ്രതീക്ഷിത പ്രത്യാഘാതങ്ങൾക്ക് കാരണമാകും. ലോഗിൻ ചെയ്യുന്ന സമയത്തുനിന്നും ഓതറൈസേഷൻ തീരുമാനം ഓരോ ടൂൾ കോളിനും മാറ്റുന്നതിലൂടെയും, കുറഞ്ഞ കാലയളവിലേക്ക് മാത്രം നിലനിൽക്കുന്ന സ്കോപ്പ് ചെയ്ത ടോക്കണുകൾ ഉപയോഗിക്കുന്നതിലൂടെയും, ഡാറ്റ സംരക്ഷിച്ചും നിയമങ്ങൾ പാലിച്ചും വലിയ പിഴവുകൾ ഒഴിവാക്കാനും AI ആപ്ലിക്കേഷനുകൾക്ക് ഓട്ടോണമസ് ഏജന്റുകളുടെ സൗകര്യം നിലനിർത്താൻ സാധിക്കും. ഓരോ തവണ ഒരു ആക്ഷൻ പരീക്ഷിക്കുമ്പോഴും ശരിയായ ചോദ്യം ചോദിക്കുന്ന ഒരു സിസ്റ്റത്തിന് വേണ്ടി അധികമായി എഴുതുന്ന കോഡ് വളരെ ചെറിയൊരു വില മാത്രമാണ്.