agent परवानगीचा अर्थ काय
Agent परवानगी म्हणजे AI agent ला काय करू दिले जाते याबाबतचा निर्णय: तो कोणते routes कॉल करू शकतो, कोणता data वाचू शकतो, कोणत्या actions करू शकतो आणि किती प्रमाणात करू शकतो. हे agent identity पेक्षा वेगळे आहे, ज्याचा संबंध कोणता agent, किंवा कोणत्या operator चा agent, request करत आहे हे ठरवण्याशी असतो.
ही दोन्ही गोष्टी सहज एकत्र गोंधळतात, कारण त्या अनेकदा एकाच वेळी येतात. signed request तुम्हाला तो कोणी पाठवला हे सांगतो. पण त्या sender ला account बदलण्याची, order देण्याची किंवा data export करण्याची परवानगी असावी का हे सांगत नाही. Identity म्हणजे evidence; authorization म्हणजे policy. signed AI agent requests काय सिद्ध करतात, आणि काय सिद्ध करत नाहीत याबद्दलची आमची post हा फरक स्पष्ट करते.
हा फरक का महत्त्वाचा आहे
Applications आधीच human users साठी authentication आणि authorization वेगळे करतात: login केल्याने तुम्ही कोण आहात हे सिद्ध होते, आणि roles आणि permissions ठरवतात की तुम्ही काय करू शकता. Agents साठीही तीच वेगळी मांडणी आवश्यक आहे, पण अधिक काळजीच्या एका अतिरिक्त स्तरासह:
- Identity मजबूत असू शकते, पण permission नसू शकते. पूर्णपणे वैध HTTP message signature असलेल्या crawler ला write endpoint कॉल करण्याचा स्वाभाविक अधिकार नसतो.
- Permission मजबूत identity शिवायही अस्तित्वात असू शकते. customer's API key वापरणारा agent त्या key मुळे authorized असतो, जरी तो key कोणत्या agent software कडे आहे हे काहीही ओळखत नसले तरी.
- agent च्या मागचा व्यक्ती महत्त्वाचा असतो. जेव्हा agent एखाद्यासाठी काम करतो, तेव्हा प्रश्न असा होतो की त्या व्यक्तीने त्याला अधिकार दिला आहे का (पहा delegated authority).
या दोन्ही गोष्टी एका check मध्ये एकत्र केल्याने दोन अपयशाची रूपे निर्माण होतात: human login नसल्यामुळे वैध automation रोखणे, किंवा चांगल्या प्रकारे ओळखलेल्या agent वर कधीही करायला नसावेत अशा actions साठी विश्वास ठेवणे.
परवानगी साधारणपणे कशी मांडली जाते
बहुतेक applications agents ना आधीपासून असलेल्या यंत्रणांद्वारे 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 उघडे ठेवणे; write routes ला account शी जोडलेले credential आवश्यक असणे.
- Risk tiers. कमी परिणाम असलेले actions व्यापकपणे allowed करणे, जास्त परिणाम असलेल्या actions साठी अधिक मजबूत credentials, confirmation किंवा review आवश्यक करणे.
- Rate limits आणि quotas प्रति operator, प्रति credential किंवा प्रति route.
Agent identity evidence या निर्णयांसाठी एक input म्हणून काम करते. अधिक तपशीलवार पद्धतीसाठी humans आणि AI agents साठी app-level policies कशा डिझाइन करायच्या हे पाहा. यामुळे तुम्ही verified operator ला anonymous client पेक्षा वेगळ्या प्रकारे हाताळू शकता, पण permission स्वतः अजूनही तुमच्या policy मधूनच येते.
सामान्य गैरसमज
- "Verified agent म्हणजे allowed." Verification request ला attribute करते. तुमची policy तरीही त्या attributed party ला काय करू द्यायचे हे ठरवते.
- "तो human सिद्ध होईपर्यंत agents रोखले पाहिजेत." अनेक agents वैध participants असतात. अधिक चांगला प्रश्न म्हणजे route by route प्रत्येक actor प्रकाराला काय करू द्यायचे.
- "Authorization वर्तनावरून inferred होऊ शकते." वर्तनामुळे कोणत्या प्रकारचा actor आहे याबद्दल confidence वाढू किंवा कमी होऊ शकते. पण ते स्वतःहून permission देऊ नये.
Proof of Actor हे कसे हाताळते
Proof of Actor evidence चा प्रश्न सोडवते: कोणत्या प्रकारचा actor उपस्थित आहे, कोणत्या आधारावर (verified, declared, inferred किंवा unknown), आणि काय ज्ञात आहे आणि काय अज्ञात आहे. ते जाणीवपूर्वक permission ठरवत नाही. 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 cases पहा, किंवा 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 काय स्थापित करते ते