Delegated authority എന്നതിന്റെ അർത്ഥം
Delegated authority എന്നത് ഒരു AI agent തങ്ങളുടെ പേരിൽ പ്രവർത്തിക്കാൻ ഒരു വ്യക്തി (അല്ലെങ്കിൽ ഒരു സംഘടന) നൽകുന്ന അനുമതിയാണ്. ഒരു assistant നിങ്ങളുടെ calendar-ൽ ഒരു meeting book ചെയ്യുമ്പോഴും, നിങ്ങളുടെ പേരിൽ ഒരു support ticket file ചെയ്യുമ്പോഴും, അല്ലെങ്കിൽ supplier-ന്റെ portal-ിൽ നിന്ന് ഒരു invoice retrieve ചെയ്യുമ്പോഴും, അത് നിങ്ങളിൽ നിന്ന് ഉത്ഭവിച്ച authority ഉപയോഗിച്ചാണ് പ്രവർത്തിക്കുന്നത്.
നല്ല delegation-ന് മൂന്ന് ഗുണങ്ങളുണ്ട്: അത് scoped ആണ് (agent-ിനു ചില കാര്യങ്ങൾ ചെയ്യാം, എല്ലാം അല്ല), bounded in time ആണ് (അത് കാലഹരണപ്പെടും അല്ലെങ്കിൽ revoke ചെയ്യാം), കൂടാതെ attributable ആണ് (അത് സ്വീകരിക്കുന്ന application-ിന് ഏത് വ്യക്തിയുടെ authority ആണ് ഉപയോഗിക്കപ്പെടുന്നത് എന്ന് അറിയാൻ കഴിയണം).
Applications-ിന് ഇത് എന്തുകൊണ്ട് പ്രധാനമാണ്
ഒരു application's കാഴ്ചപ്പാടിൽ നിന്ന്, ഒരു agent request മൂന്ന് വേറിട്ട ചോദ്യങ്ങൾ ഉയർത്തുന്നു:
- ഈ request അയച്ചത് ഏത് client ആണ്? അത് agent identity ആണ്, signed requests വഴി അത് സ്ഥാപിക്കാം (HTTP Message Signatures കാണുക).
- ഇത് ഏത് authority-യുടെ കീഴിലാണ് പ്രവർത്തിക്കുന്നത്? അത് delegation ആണ്.
- ഈ action-യ്ക്ക് ആ authority മതിയാകുന്നുണ്ടോ? അത് authorization ആണ്, application's സ്വന്തം policy തീരുമാനിക്കുന്നത്.
ഒരു well-known assistant operator-ിൽ നിന്നുള്ള signed request ആദ്യത്തെ ചോദ്യത്തിന് നല്ല ഉത്തരം നൽകുന്നു. രണ്ടാമത്തേതിനെക്കുറിച്ച് അത് സ്വയം ഒന്നും പറയുന്നില്ല. Assistant നിങ്ങളുടെ ഉപയോക്താക്കളിൽ ഒരാളുടെ വേണ്ടി, നിങ്ങളുടെ ഉപയോക്താവ് അല്ലാത്ത ഒരാളുടെ വേണ്ടി, അല്ലെങ്കിൽ പൂർണ്ണമായും സ്വന്തം initiative-ിൽ പ്രവർത്തിക്കാമെന്നതാണ്. Client identity-നെ ഒരു person's consent-ിന്റെ തെളിവായി കരുതുന്നത് agent-facing design-ിലെ ഏറ്റവും സാധാരണമായ പിശകുകളിൽ ഒന്നാണ്. signed AI agent requests എന്താണ് തെളിയിക്കുന്നത്, എന്തല്ല എന്നത് കാണുക.
Delegation സാധാരണയായി എങ്ങനെ പ്രകടിപ്പിക്കപ്പെടുന്നു
- OAuth-style grants. ഒരു person നിങ്ങളുടെ application-ിൽ sign in ചെയ്ത്, OAuth 2.0 (RFC 6749)-ൽ നിർവചിച്ചതുപോലെ, പരിമിതമായ scopes ഉള്ള ഒരു token ഒരു agent-ിനു grant ചെയ്യുന്നു. അപ്പോൾ ആ token ഏത് വ്യക്തിയുടെ authority കൊണ്ടാണ് വന്നത് എന്ന് നിങ്ങളുടെ application കൃത്യമായി അറിയും, കൂടാതെ ആ grant revoke ചെയ്യാനും കഴിയും (RFC 7009).
- Account-scoped API keys ഒരു user ഒരു പ്രത്യേക integration-ിനായി സൃഷ്ടിക്കുന്നത്, സാധ്യമായാൽ വളരെ കുറുകിയ permissions-ോടെ.
- In-app confirmations ഉയർന്ന സ്വാധീനമുള്ള actions-ിന്, agent തയ്യാറാക്കിയ ഒരു specific action person അംഗീകരിക്കുന്നിടത്ത്.
- Token-level delegation claims. OAuth 2.0 Token Exchange (RFC 8693) ഒരു
act(actor) claim നിർവചിക്കുന്നു, അത് ഒരാൾ മറ്റൊരാളുടെ വേണ്ടി പ്രവർത്തിക്കുന്നതായി രേഖപ്പെടുത്തുന്നു. Requests-ൽ agent delegation പ്രകടിപ്പിക്കുന്നതിനുള്ള പുതിയ work ഇപ്പോഴും വികസിച്ചുകൊണ്ടിരിക്കുകയാണ്, അതിനാൽ applications ഏതെങ്കിലും delegation claim അതിന്റെ സ്വന്തം records-ുമായി താരതമ്യം ചെയ്ത് verify ചെയ്യണം, മുഖവിലയ്ക്ക് അംഗീകരിക്കരുത്.
സാധാരണ തെറ്റിദ്ധാരണകൾ
- "Agent verified ആണെങ്കിൽ, user അത് അംഗീകരിച്ചു." Verification client-നെ തിരിച്ചറിയുന്നു. Approval person-ിൽ നിന്നാണ് വരേണ്ടത്, നിങ്ങളുടെ application വിശ്വസിക്കുന്ന ഒരു channel വഴി.
- "എന്റെ user's session ഉപയോഗിക്കുന്ന ഒരു agent ശരിയാണ്." ശരിയായിരിക്കാം, പക്ഷേ ആ session interactive human use-ിനായി ആണ് issue ചെയ്തത്. പല applications-ും automation-ിനായി dedicated, scoped grant ആണ് മുൻഗണിക്കുന്നത്, അതുവഴി actions attributable ആയും revocable ആയും ഇരിക്കും.
- "Delegation എല്ലാം അല്ലെങ്കിൽ ഒന്നുമില്ല." ഏറ്റവും സുരക്ഷിതമായ delegations narrow ആയിരിക്കും: പൊതുവെ read access, specific actions-ിന് മാത്രം write access, irreversible ആയ ഏതൊന്നിനും confirmation.
Proof of Actor ഇതുമായി എങ്ങനെ ബന്ധപ്പെടുന്നു
ഒരു interaction agent-driven ആണോ AI-assisted ആണോ, അത് ഏത് basis-ൽ ആണോ എന്ന് കാണാൻ Proof of Actor നിങ്ങളെ സഹായിക്കുന്നു: verified, declared, inferred അല്ലെങ്കിൽ unknown. ഉദാഹരണത്തിന്, ഒരു human account session-ിനുള്ളിൽ പ്രവർത്തിക്കുന്ന ഒരു autonomous agent പോലുള്ള സാഹചര്യങ്ങളിൽ delegation ചോദ്യങ്ങൾ എവിടെയാണ് ഉയരുന്നത് എന്ന് ആ context കാണിക്കുന്നു. Proof of Actor delegation credentials issue ചെയ്യുകയോ validate ചെയ്യുകയോ ചെയ്യുന്നില്ല, കൂടാതെ ഒരു Agent result ഒരിക്കലും ഒരു person ആ action authorize ചെയ്തുവെന്ന് imply ചെയ്യുന്നതുമല്ല. നിങ്ങളുടെ application's own grants, scopes, confirmations എന്നിവയാണ് അത് തീരുമാനിക്കുന്നത്, കൂടാതെ യഥാർത്ഥ traffic observe ചെയ്ത ശേഷം ഓരോ route-ിനും ശരിയായ policy apply ചെയ്യാൻ Route നിങ്ങളെ അനുവദിക്കുന്നു. Policy patterns-ിന്, humans-ക്കും AI agents-ക്കും വേണ്ടി app-level policies design ചെയ്യൽ കാണുക.
എന്താണ് evidence സ്ഥാപിക്കാനാകുന്നത്, എന്താണ് സ്ഥാപിക്കാനാകാത്തത് വായിക്കുക, അല്ലെങ്കിൽ early access-ിന് അപേക്ഷിക്കുക.
Sources
- RFC 6749: The OAuth 2.0 Authorization Framework: ഒരു resource owner-ിൽ നിന്ന് ഒരു client-ിലേക്ക് scoped grants
- RFC 7009: OAuth 2.0 Token Revocation: ഒരു delegated token revoke ചെയ്യൽ
- RFC 8693: OAuth 2.0 Token Exchange: delegation-ിനുള്ള
act(actor) claim