ഏജന്റ് അനുമതി

ഏജന്റ് അനുമതി എന്നതിന്റെ അർത്ഥം

ഏജന്റ് അനുമതി എന്നത് ഒരു AI ഏജന്റിന് എന്ത് ചെയ്യാൻ അനുവദിച്ചിരിക്കുന്നു എന്നതിനെക്കുറിച്ചുള്ള തീരുമാനമാണ്: ഏത് routeകൾ വിളിക്കാം, ഏത് ഡാറ്റ വായിക്കാം, ഏത് actionകൾ എടുക്കാം, ഏത് തോതിൽ. ഇത് ഏജന്റ് ഐഡന്റിറ്റിയിൽ നിന്ന് വ്യത്യസ്തമാണ്, കാരണം ഏത് ഏജന്റ്, അല്ലെങ്കിൽ ഏത് operator ന്റെ ഏജന്റ്, request നടത്തുന്നു എന്നത് സ്ഥാപിക്കുന്നതിനെക്കുറിച്ചാണ് ഐഡന്റിറ്റി.

ഈ രണ്ടും പലപ്പോഴും ഒരുമിച്ച് വരുന്നതിനാൽ അവയെ കലർത്തിപ്പോവാൻ എളുപ്പമാണ്. ഒപ്പിട്ട request അത് ആരാണ് അയച്ചത് എന്ന് നിങ്ങളെ അറിയിക്കുന്നു. എന്നാൽ ആ sender ന് account മാറ്റാനോ, ഓർഡർ ഇടാനോ, അല്ലെങ്കിൽ data export ചെയ്യാനോ അനുവദിക്കേണ്ടതുണ്ടോ എന്ന് അത് പറയുന്നില്ല. ഐഡന്റിറ്റി തെളിവാണ്; അനുമതി policy ആണ്. signed AI agent requests എന്താണ് തെളിയിക്കുന്നത്, എന്താണ് തെളിയിക്കാത്തത് എന്നതിനെക്കുറിച്ചുള്ള ഞങ്ങളുടെ post ഈ വ്യത്യാസം വിശദീകരിക്കുന്നു.

ഈ വ്യത്യാസം എന്തുകൊണ്ട് പ്രധാനമാണ്

മനുഷ്യ ഉപയോക്താക്കൾക്കായി applications ഇതിനകം തന്നെ authentication നെയും authorization നെയും വേർതിരിക്കുന്നു: log in ചെയ്യുന്നത് നിങ്ങൾ ആരാണെന്ന് തെളിയിക്കുന്നു, roles ഉം permissions ഉം നിങ്ങൾക്ക് എന്ത് ചെയ്യാൻ കഴിയുമെന്ന് തീരുമാനിക്കുന്നു. ഏജന്റുകൾക്കും അതേ വേർതിരിവ് വേണം, കൂടാതെ അധിക ജാഗ്രതയും:

• ഐഡന്റിറ്റി ശക്തമായിരിക്കാം, പക്ഷേ അനുമതി ഇല്ലാതിരിക്കാം. പൂർണ്ണമായും സാധുവായ HTTP message signature ഉള്ള ഒരു crawler ന് write endpoint വിളിക്കാൻ സ്വാഭാവികമായ അവകാശമില്ല.
• ശക്തമായ ഐഡന്റിറ്റി ഇല്ലാതെയും അനുമതി ഉണ്ടാകാം. ഒരു customer's API key ഉപയോഗിക്കുന്ന ഒരു ഏജന്റ് ആ key വഴി authorized ആണ്, ആ ഏജന്റ് software ആരുടെ കൈവശമാണ് എന്ന് ഒന്നും തിരിച്ചറിയുന്നില്ലെങ്കിലും.
• ഏജന്റിന് പിന്നിലെ വ്യക്തി പ്രധാനമാണ്. ഒരു ഏജന്റ് ആരെയെങ്കിലും വേണ്ടി പ്രവർത്തിക്കുമ്പോൾ, ആ വ്യക്തി അതിന് authority നൽകിയോ എന്നതാണ് ചോദ്യം (കാണുക delegated authority).

ഇവയെ ഒരൊറ്റ പരിശോധനയിലേക്കു ചുരുക്കുന്നത് രണ്ട് failure modeകളിലേക്ക് നയിക്കുന്നു: മനുഷ്യ login ഇല്ലാത്തതിനാൽ നിയമപരമായ automation തടയുക, അല്ലെങ്കിൽ നന്നായി തിരിച്ചറിഞ്ഞ ഒരു ഏജന്റിനെ അത് ഒരിക്കലും ചെയ്യേണ്ടതല്ലാത്ത actionകൾക്കായി വിശ്വസിക്കുക.

സാധാരണയായി അനുമതി എങ്ങനെ പ്രകടിപ്പിക്കുന്നു

മിക്ക applications ഉം ഇതിനകം ഉള്ള mechanisms ഉപയോഗിച്ചാണ് ഏജന്റുകളെ authorize ചെയ്യുന്നത്:

• Credentials and scopes. ആവശ്യമായ integration ന് മാത്രം പരിമിതപ്പെടുത്തിയ scopes ഉള്ള API keys അല്ലെങ്കിൽ OAuth 2.0 tokens. MCP servers അതേ model ഉപയോഗിക്കുന്നു: MCP authorization specification ഒരു protected server നെ OAuth 2.1 resource server ആയി കാണുന്നു.
• Route-level policy. അറിയപ്പെടുന്ന ഏജന്റുകൾക്കായി തുറന്നിരിക്കുന്ന read-only routeകൾ; ഒരു account നോട് ബന്ധിപ്പിച്ചിരിക്കുന്ന credential ആവശ്യമായ write routeകൾ.
• Risk tiers. കുറഞ്ഞ സ്വാധീനമുള്ള actionകൾ വ്യാപകമായി അനുവദിക്കുക, ഉയർന്ന സ്വാധീനമുള്ള actionകൾക്ക് ശക്തമായ credentials, സ്ഥിരീകരണം അല്ലെങ്കിൽ review ആവശ്യപ്പെടുത്തുക.
• Rate limits and quotas operator, credential അല്ലെങ്കിൽ route അടിസ്ഥാനത്തിൽ.

ഏജന്റ് ഐഡന്റിറ്റി തെളിവ് ഈ തീരുമാനങ്ങളിലേക്കു ഒരു input ആയി പോകുന്നു. പ്രവർത്തിച്ചുകൊണ്ടിരിക്കുന്ന ഒരു സമീപനത്തിനായി, മനുഷ്യർക്കും AI ഏജന്റുകൾക്കും വേണ്ട app-level policyകൾ രൂപകൽപ്പന ചെയ്യുന്നത് കാണുക. ഇത് സ്ഥിരീകരിച്ച ഒരു operator നെ anonymous client നു നിന്ന് വേർതിരിച്ച് കൈകാര്യം ചെയ്യാൻ അനുവദിക്കുന്നു, പക്ഷേ അനുമതി തന്നെ ഇപ്പോഴും നിങ്ങളുടെ policy യിൽ നിന്നാണ് വരുന്നത്.

സാധാരണ തെറ്റിദ്ധാരണകൾ

• "സ്ഥിരീകരിച്ച ഏജന്റ് എന്നാൽ അനുവദിച്ചിരിക്കുന്നു." Verification ഒരു request നെ ആർക്കാണ് ബന്ധിപ്പിക്കുന്നത് എന്ന് വ്യക്തമാക്കുന്നു. ആ ബന്ധിപ്പിക്കപ്പെട്ട partyയ്ക്ക് എന്ത് ചെയ്യാമെന്ന് നിങ്ങളുടെ policy ഇപ്പോഴും തീരുമാനിക്കുന്നു.
• "മനുഷ്യൻ ആണെന്ന് തെളിയിച്ചില്ലെങ്കിൽ ഏജന്റുകളെ തടയണം." പല ഏജന്റുകളും നിയമപരമായ പങ്കാളികളാണ്. ഓരോ route ലും ഓരോ actor തരം എന്ത് ചെയ്യാൻ അനുവദിക്കണം എന്നതാണ് കൂടുതൽ നല്ല ചോദ്യം.
• "പെരുമാറ്റത്തിൽ നിന്ന് അനുമതി അനുമാനിക്കാം." ഏതു തരത്തിലുള്ള actor ആണ് ഉള്ളത് എന്നതിനെക്കുറിച്ചുള്ള confidence ഉയർത്താനോ കുറയ്ക്കാനോ പെരുമാറ്റത്തിന് കഴിയും. എന്നാൽ അത് സ്വയം അനുമതി നൽകാൻ പാടില്ല.

Proof of Actor ഇതിനെ എങ്ങനെ കൈകാര്യം ചെയ്യുന്നു

Proof of Actor തെളിവിന്റെ ചോദ്യംക്ക് ഉത്തരം നൽകുന്നു: ഏത് തരത്തിലുള്ള actor ഉണ്ട്, ഏത് അടിസ്ഥാനത്തിലാണ് അത് പറയുന്നത് (verified, declared, inferred അല്ലെങ്കിൽ unknown), കൂടാതെ എന്താണ് അറിയുന്നതും അറിയാത്തതും. ഇത് ഉദ്ദേശപൂർവ്വം അനുമതി തീരുമാനിക്കുന്നില്ല. ഒരു Agent result, അതു verified ആണെങ്കിലും, ഒരിക്കലും authorization സൂചിപ്പിക്കുന്നില്ല. Route ൽ, നിങ്ങളുടെ application actor result നെ സ്വന്തം credentials, scopes, risk tiers എന്നിവയുമായി ചേർത്ത് ഓരോ interaction നും allow, adapt, challenge, review അല്ലെങ്കിൽ limit ചെയ്യുന്നു, എല്ലാം observation mode ൽ ആരംഭിച്ച് എന്തെങ്കിലും enforce ചെയ്യുന്നതിന് മുൻപ് outcomes പരിശോധിക്കാനായി.

നിങ്ങളുടെ app ൽ തീരുമാനങ്ങൾ എങ്ങനെ ഘടിപ്പിക്കപ്പെടുന്നു എന്ന് കൂടുതൽ അറിയുക, APIs וגם MCP servers use caseകൾ കാണുക, അല്ലെങ്കിൽ early access ന് അപേക്ഷിക്കുക.

Sources

• RFC 6749: The OAuth 2.0 Authorization Framework: clients നുള്ള scoped tokens
• MCP specification 2026-07-28: Authorization: MCP servers നുള്ള OAuth-based authorization
• RFC 9421: HTTP Message Signatures: ഒരു signed request എന്താണ് സ്ഥാപിക്കുന്നത്