एजेंट प्राधिकरण

एजेंट प्राधिकरण का अर्थ क्या है

एजेंट प्राधिकरण यह निर्णय है कि कोई AI agent क्या करने के लिए अधिकृत है: वह किन routes को call कर सकता है, कौन-सा data read कर सकता है, कौन-सी actions ले सकता है, और किस volume पर। यह agent identity से अलग है, जो यह स्थापित करने के बारे में है कि request कौन-सा agent, या किस operator का agent, कर रहा है।

ये दोनों अक्सर साथ आते हैं, इसलिए इनमें भ्रम होना आसान है। एक signed request आपको बताता है कि उसे किसने भेजा। यह नहीं बताता कि क्या उस sender को account बदलने, order place करने या data export करने की अनुमति होनी चाहिए। Identity evidence है; authorization policy है। हमारी पोस्ट signed AI agent requests क्या साबित करते हैं, और क्या नहीं इस अंतर को स्पष्ट करती है।

यह अंतर क्यों महत्वपूर्ण है

Applications पहले से ही human users के लिए authentication और authorization को अलग करती हैं: login यह साबित करता है कि आप कौन हैं, और roles तथा permissions तय करते हैं कि आप क्या कर सकते हैं। Agents के लिए भी यही separation चाहिए, लेकिन अतिरिक्त सावधानी के साथ:

• Identity मजबूत हो सकती है, लेकिन permission नहीं हो सकती। एक crawler जिसके पास पूरी तरह valid HTTP message signature है, उसे write endpoint call करने का स्वाभाविक अधिकार नहीं होता।
• Permission मजबूत identity के बिना भी हो सकती है। किसी customer की API key का उपयोग करने वाला agent उस key के जरिए authorized है, भले ही कोई यह न बताए कि कौन-सा agent software उसे hold कर रहा है।
• Agent के पीछे मौजूद व्यक्ति महत्वपूर्ण है। जब कोई agent किसी और की ओर से काम करता है, तो सवाल यह होता है कि क्या उस व्यक्ति ने उसे authority दी थी (देखें delegated authority).

इन दोनों को एक ही check में मिला देने से दो तरह की विफलताएं होती हैं: वैध automation को block करना क्योंकि उसके पास human login नहीं है, या एक well-identified agent पर ऐसे actions के लिए भरोसा करना जिन्हें वह कभी करने के लिए बनाया ही नहीं गया था।

Authorization आमतौर पर कैसे व्यक्त की जाती है

अधिकांश applications उन mechanisms से 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. Read-only routes ज्ञात agents के लिए खुले; write routes किसी account से जुड़ी credential की मांग करें।
• Risk tiers. कम-प्रभाव वाली actions व्यापक रूप से अनुमति दी जाएं, जबकि अधिक-प्रभाव वाली actions के लिए मजबूत credentials, confirmation या review आवश्यक हो।
• Rate limits और quotas प्रति operator, प्रति credential या प्रति route।

Agent identity evidence इन निर्णयों में एक input के रूप में काम करता है। एक व्यावहारिक approach के लिए देखें humans और AI agents के लिए app-level policies design करना. इससे आप एक verified operator को एक anonymous client से अलग तरीके से treat कर सकते हैं, लेकिन permission फिर भी आपकी policy से ही आती है।

सामान्य गलत धारणाएं

• "Verified agent means allowed." Verification request को attribute करती है। आपकी policy फिर भी तय करती है कि उस attributed party को क्या करने की अनुमति है।
• "Agents को तब तक block करना चाहिए जब तक वे human साबित न हों." कई agents वैध participants होते हैं। बेहतर सवाल यह है कि हर प्रकार के actor को route by route क्या करने की अनुमति होनी चाहिए।
• "Authorization behavior से infer की जा सकती है." Behavior इस बारे में confidence बढ़ा या घटा सकता है कि मौजूद actor किस प्रकार का है। यह अपने-आप permission नहीं देनी चाहिए।

Proof of Actor इसे कैसे treat करता है

Proof of Actor evidence के प्रश्न का उत्तर देता है: कौन-सा actor मौजूद है, किस basis पर (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 जांच सकें।

जानें कि decisions आपके app में कैसे fit होती हैं, 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 क्या स्थापित करता है