प्रतिनिधीकृत अधिकाराचा अर्थ काय आहे
प्रतिनिधीकृत अधिकार म्हणजे एखादी व्यक्ती (किंवा एखादी organization) AI agent ला तिच्या वतीने कृती करण्यासाठी दिलेली परवानगी. जेव्हा एखादा assistant तुमच्या calendar मध्ये meeting book करतो, तुमच्या नावाने support ticket दाखल करतो किंवा supplier च्या portal मधून invoice मिळवतो, तेव्हा तो तुमच्याकडून आलेला अधिकार वापरत असतो.
चांगल्या delegation मध्ये तीन गुणधर्म असतात: ती scoped असते (agent काही गोष्टी करू शकतो, सर्व काही नाही), bounded in time असते (ती संपते किंवा revoke करता येते) आणि attributable असते (स्वीकारणाऱ्या application ला कोणाचा अधिकार वापरला जात आहे हे सांगता येते).
applications साठी ते का महत्त्वाचे आहे
एका application च्या दृष्टीने, agent request तीन स्वतंत्र प्रश्न उपस्थित करते:
- हा कोणता client पाठवत आहे? हे agent identity आहे, जे signed requests सिद्ध करू शकतात (पहा HTTP Message Signatures).
- तो कोणाच्या अधिकाराखाली कृती करत आहे? हे delegation आहे.
- या action साठी तो अधिकार पुरेसा आहे का? हे authorization आहे, जे application's own policy ठरवते.
एखाद्या प्रसिद्ध assistant operator कडून आलेला signed request पहिल्या प्रश्नाचे चांगले उत्तर देतो. पण दुसऱ्या प्रश्नाबद्दल तो स्वतःहून काहीही सांगत नाही. assistant कदाचित तुमच्या एका user साठी, तुमचा user नसलेल्या एखाद्यासाठी, किंवा पूर्णपणे स्वतःच्या initiative वर कृती करत असेल. client identity ला व्यक्तीच्या consent चा पुरावा मानणे ही agent-facing design मधील सर्वात सामान्य चुकांपैकी एक आहे. signed AI agent requests काय सिद्ध करतात, आणि काय नाही हे पहा.
delegation सामान्यतः कसे व्यक्त केले जाते
- OAuth-style grants. व्यक्ती तुमच्या application मध्ये sign in करते आणि मर्यादित scopes असलेला token agent ला देते, OAuth 2.0 (RFC 6749) मध्ये परिभाषित केल्याप्रमाणे. त्यानंतर तुमच्या application ला token कोणाचा अधिकार घेऊन आला आहे हे नेमके माहीत होते, आणि तो grant revoke करता येतो (RFC 7009).
- Account-scoped API keys ज्या user एखाद्या विशिष्ट integration साठी तयार करतो, आदर्शतः अरुंद permissions सह.
- In-app confirmations उच्च परिणाम असलेल्या actions साठी, जिथे व्यक्ती agent ने तयार केलेली विशिष्ट action approve करते.
- Token-level delegation claims. OAuth 2.0 Token Exchange (RFC 8693) मध्ये
act(actor) claim परिभाषित आहे, जो एक party दुसऱ्यासाठी कृती करत असल्याची नोंद करतो. requests मध्ये agent delegation व्यक्त करण्यावरील नवीन काम अजून विकसित होत आहे, आणि applications ने कोणताही delegation claim तोंडावरच्या किंमतीवर स्वीकारण्याऐवजी तो त्यांच्या own records विरुद्ध verify करावा.
सामान्य गैरसमज
- "जर agent verified असेल, तर user ने ते approve केले आहे." Verification client ओळखते. Approval व्यक्तीकडून, तुमच्या application ला trusted असलेल्या channel मधून यायला हवे.
- "माझ्या user's session वापरणारा agent ठीक आहे." कदाचित असेल, पण session interactive human use साठी issued केलेला होता. अनेक applications automation साठी dedicated, scoped grant पसंत करतात, जेणेकरून actions attributable आणि revocable राहतील.
- "Delegation म्हणजे सर्व किंवा काहीच नाही." सर्वात सुरक्षित delegations अरुंद असतात: read access व्यापक, write access फक्त विशिष्ट actions साठी, आणि अपरिवर्तनीय काहीही करण्यापूर्वी confirmation.
Proof of Actor याच्याशी कसा संबंधित आहे
Proof of Actor तुम्हाला interaction agent-driven आहे की AI-assisted आहे, आणि कोणत्या basis वर ते दिसण्यात मदत करते: verified, declared, inferred किंवा unknown. तो context delegation प्रश्न कुठे उद्भवतात हे सांगतो, उदाहरणार्थ human account session मध्ये काम करणारा autonomous agent. Proof of Actor delegation credentials जारी करत नाही किंवा validate करत नाही, आणि Agent result कधीही एखाद्या व्यक्तीने action authorize केली आहे असे सूचित करत नाही. तुमची application's own grants, scopes आणि confirmations ते ठरवतात, आणि Route तुम्हाला प्रत्यक्ष traffic निरीक्षण केल्यानंतर route नुसार योग्य policy लागू करू देते. policy patterns साठी humans आणि AI agents साठी app-level policies design करणे पहा.
पुरावा काय सिद्ध करू शकतो आणि काय नाही वाचा, किंवा early access साठी apply करा.
स्रोत
- 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