Agent અધિકૃતકરણનો અર્થ શું છે
Agent અધિકૃતકરણ એ નિર્ણય છે કે AI agentને શું કરવાની મંજૂરી છે: તે કયા routes call કરી શકે, કયો data read કરી શકે, કયા actions લઈ શકે અને કયા volume પર. આ agent identityથી અલગ છે, જે એ નક્કી કરવા વિશે છે કે કયો agent, અથવા કયા operatorનો agent, request કરી રહ્યો છે.
આ બે બાબતોને અલગ પાડવું સરળ નથી, કારણ કે ઘણી વાર તે સાથે આવે છે. એક signed request તમને જણાવે છે કે તે કોને મોકલી. પરંતુ તે તમને આ નથી જણાવતું કે મોકલનારને account બદલવાની, order મૂકવાની અથવા data export કરવાની મંજૂરી હોવી જોઈએ કે નહીં. Identity evidence છે; authorization policy છે. what signed AI agent requests prove, and what they don't પરનો અમારો લેખ આ ફરક સ્પષ્ટ કરે છે.
આ તફાવત કેમ મહત્વનો છે
Applications human users માટે પહેલેથી જ authentication અને authorizationને અલગ રાખે છે: login થવાથી તમે કોણ છો તે સાબિત થાય છે, અને roles અને permissions નક્કી કરે છે કે તમે શું કરી શકો. Agents માટે પણ એ જ અલગાવ જરૂરી છે, સાથે થોડી વધારે કાળજી સાથે:
- Identity મજબૂત હોઈ શકે છે, પણ permission ન હોય. એક crawler પાસે સંપૂર્ણ માન્ય HTTP message signature હોવા છતાં write endpoint call કરવાનો સ્વાભાવિક અધિકાર નથી.
- Permission strong identity વગર પણ હોઈ શકે છે. કોઈ customerનું API key વાપરતો agent તે key દ્વારા authorized હોય છે, ભલે કયો agent software તેને પકડી રાખે છે તે કંઈ ઓળખાતું ન હોય.
- Agent પાછળનો person મહત્વનો છે. જ્યારે agent કોઈની behalf પર કાર્ય કરે છે, ત્યારે પ્રશ્ન એ બને છે કે શું તે વ્યક્તિએ તેને authority આપી હતી કે નહીં (જુઓ delegated authority).
આ બધાને એક જ checkમાં ભેળવી દેવું બે પ્રકારની ભૂલ લાવે છે: માનવીય login ન હોવાથી legitimate automationને અવરોધવું, અથવા એવા actions માટે સારી રીતે ઓળખાયેલા agent પર ભરોસો કરવો જે કરવા માટે તે બનાવાયો જ નહોતો.
સામાન્ય રીતે authorization કેવી રીતે વ્યક્ત થાય છે
મોટાભાગના applications agentને તેઓ પાસે પહેલેથી જ રહેલા mechanismsથી authorize કરે છે:
- Credentials અને scopes. API keys અથવા OAuth 2.0 tokens, જેમાં scopes integrationને જેટલું જરૂરી હોય એટલા સુધી મર્યાદિત હોય. MCP servers એ જ model વાપરે છે: MCP authorization specification protected serverને OAuth 2.1 resource server તરીકે ગણે છે.
- Route-level policy. જાણીતા agents માટે read-only routes ખુલ્લા; લખવાના routes માટે account સાથે જોડાયેલ credential જરૂરી.
- Risk tiers. ઓછા અસરવાળા actions વ્યાપક રીતે મંજૂર, વધુ અસરવાળા actions માટે વધુ મજબૂત credentials, confirmation અથવા review જરૂરી.
- Rate limits અને quotas operator દીઠ, credential દીઠ અથવા route દીઠ.
Agent identity evidence આ નિર્ણયોમાં એક input તરીકે જાય છે. એક વ્યવહારુ approach માટે જુઓ designing app-level policies for humans and AI agents. તે તમને verified operatorને anonymous clientથી અલગ રીતે વર્તવા દે છે, પરંતુ permission પોતે હજી પણ તમારી policyમાંથી આવે છે.
સામાન્ય ગેરસમજો
- "Verified agent એટલે મંજૂર." Verification requestને attribute કરે છે. તમારી policy હજી પણ નક્કી કરે છે કે આ attributed party શું કરી શકે.
- "Agentsને human સાબિત ન થાય ત્યાં સુધી block કરવું જોઈએ." ઘણા agents legitimate participants છે. વધુ સારું પ્રશ્ન એ છે કે દરેક પ્રકારનો actor route by route શું કરી શકે.
- "Authorization behavior પરથી infer કરી શકાય." Behavior present actor કયા પ્રકારનો છે તેની confidence વધારી કે ઘટાડી શકે છે. પરંતુ તે પોતે permission આપવી ન જોઈએ.
Proof of Actor તેને કેવી રીતે જુએ છે
Proof of Actor evidenceનો પ્રશ્ન જવાબ આપે છે: કયો actor present છે, કયા basis પર (verified, declared, inferred અથવા unknown), અને શું જાણીતું છે અને શું નથી. તે જાણબૂઝીને permission નક્કી કરતું નથી. એક Agent result, ભલે verified હોય, authorization સૂચવે જ એવું નથી. Routeમાં, તમારી application પોતાના credentials, scopes અને risk tiers સાથે actor resultને જોડીને દરેક interactionને allow, adapt, challenge, review અથવા limit કરે છે, અને શરૂઆત observation modeમાં કરે છે જેથી તમે કંઈ enforce કરતા પહેલાં outcomes ચકાસી શકો.
વધુ જાણો how decisions fit into your app વિશે, APIs અને MCP servers use cases જુઓ, અથવા apply for 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 શું સ્થાપિત કરે છે તે