অর্পিত অধিকাৰৰ অৰ্থ কি
অর্পিত অধিকাৰ হৈছে এজন ব্যক্তি (বা এটা সংগঠন) এ AI agent-ক তেওঁৰ হৈ কাৰ্য কৰিবলৈ দিয়া অনুমতি। যেতিয়া কোনো assistant এ আপোনাৰ calendar-ত এটা meeting book কৰে, আপোনাৰ নামত এটা support ticket দাখিল কৰে বা supplier-ৰ portal-ৰ পৰা invoice উদ্ধাৰ কৰে, তেতিয়া ই আপোনাৰ পৰা উৎপন্ন হোৱা অধিকাৰ ব্যৱহাৰ কৰি থাকে।
ভাল delegation-ৰ তিনিটা বৈশিষ্ট্য থাকে: ই সীমাবদ্ধ পৰিসৰৰ (agent এ কিছুমান কাম কৰিব পাৰে, সকলো নহয়), সময়সীমাবদ্ধ (ই মেয়াদ শেষ হয় বা বাতিল কৰিব পাৰি) আৰু কাৰ্য-নির্দেশ্য (গ্ৰহণ কৰা application-এ কাকৰ অধিকাৰ ব্যৱহৃত হৈছে সেয়া বুজিব পাৰে)।
application-ৰ বাবে ইয়াৰ গুৰুত্ব কিয়
এটা application-ৰ দৃষ্টিকোণৰ পৰা, এটা agent request-এ সৰ্বাধিক তিনিটা পৃথক প্ৰশ্ন উত্থাপন কৰে:
- এইটো কোন client-এ পঠিয়ালে? সেইটো হৈছে agent identity, যাক signed requests-এ স্থাপন কৰিব পাৰে (HTTP Message Signatures চাওক)।
- ই কাকৰ অধিকাৰৰ অধীনত কাম কৰি আছে? সেইটো হৈছে delegation।
- এই action-ৰ বাবে সেই অধিকাৰ যথেষ্ট নেকি? সেইটো হৈছে authorization, application-ৰ নিজস্ব policy-এ সিদ্ধান্ত কৰে।
এজন সুপৰিচিত assistant operator-ৰ পৰা অহা signed request-এ প্ৰথম প্ৰশ্নটোৰ ভাল উত্তৰ দিয়ে। কিন্তু ই নিজে নিজেই দ্বিতীয় প্ৰশ্নটোৰ বিষয়ে একো নকয়। assistant-এ আপোনাৰ কোনো user-ৰ হৈ, আপোনাৰ user নহয় এনে কোনো ব্যক্তিৰ হৈ, বা সম্পূৰ্ণ নিজৰ উদ্যোগত কাম কৰি থাকিব পাৰে। client identity-ক এজন ব্যক্তিৰ সম্মতিৰ প্ৰমাণ হিচাপে ধৰা agent-facing design-ৰ আটাইতকৈ সাধাৰণ ভুলসমূহৰ এটা। signed AI agent requests-এ কি প্ৰমাণ কৰে, আৰু কি নকৰে চাওক।
delegation সাধাৰণতে কেনেকৈ প্ৰকাশ কৰা হয়
- OAuth-style grant. ব্যক্তিয়ে আপোনাৰ application-ত sign in কৰে আৰু OAuth 2.0 (RFC 6749)-ত সংজ্ঞায়িত সীমিত scope-ৰ সৈতে এটা token এটা agent-ক দিয়ে। তাৰ পাছত আপোনাৰ application-এ স্পষ্টকৈ জানে token-টোৱে কাকৰ অধিকাৰ বহন কৰিছে, আৰু grant-টো বাতিল কৰিব পাৰি (RFC 7009).
- Account-scoped API keys যি এজন user-এ এটা নিৰ্দিষ্ট integration-ৰ বাবে সৃষ্টি কৰে, আদৰ্শতে সংকীৰ্ণ অনুমতিৰ সৈতে।
- In-app confirmation উচ্চ প্ৰভাৱৰ action-সমূহৰ বাবে, য'ত ব্যক্তিয়ে agent-এ সাজু কৰা এটা নিৰ্দিষ্ট action অনুমোদন কৰে।
- Token-level delegation claim. OAuth 2.0 Token Exchange (RFC 8693)-এ এটা
act(actor) claim সংজ্ঞায়িত কৰে, যি এটা পক্ষই আন এটা পক্ষৰ হৈ কাম কৰা তথ্য ৰাখে। request-ত agent delegation প্ৰকাশ কৰাৰ নতুন কাম এতিয়াও বিকাশধীন, আৰু application-সমূহে যিকোনো delegation claim নিজৰ records-ৰ সৈতে যাচাই কৰিব লাগে, কেৱল তাৰ মুখ্য অৰ্থত গ্ৰহণ নকৰিব লাগে।
সাধাৰণ ভুল ধাৰণা
- "যদি agent verified হয়, তেন্তে user-এ ইয়াক অনুমোদন কৰিছে." Verification-এ client-ৰ পৰিচয় কৰে। অনুমোদন ব্যক্তিৰ পৰা আহিব লাগিব, আপোনাৰ application-এ বিশ্বাস কৰা এটা channel-ৰ জৰিয়তে।
- "মোৰ user-ৰ session ব্যৱহাৰ কৰা এটা agent ঠিক আছে." হ’বও পাৰে, কিন্তু সেই session interactive human use-ৰ বাবে জাৰি কৰা হৈছিল। বহুতো application-এ automation-ৰ বাবে এটা dedicated, scoped grant পছন্দ কৰে, যাতে action-সমূহ কাৰ্য-নির্দেশ্য আৰু বাতিলযোগ্য হয়।
- "Delegation সম্পূৰ্ণ বা একোৱেই নহয়." আটাইতকৈ সুৰক্ষিত delegation-সমূহ সংকীৰ্ণ: broadly read access, কেৱল নিৰ্দিষ্ট action-ৰ বাবে write access, আৰু irreversibly action-ৰ বাবে confirmation।
Proof of Actor-ৰ সৈতে ইয়াৰ সম্পৰ্ক
Proof of Actor-এ আপোনাক দেখুৱাবলৈ সহায় কৰে যে এটা interaction agent-driven নে AI-assisted, আৰু কোন ভিত্তিত: verified, declared, inferred বা unknown। সেই context-এ আপোনাক delegation-ৰ প্ৰশ্ন ক'ত উঠিছে সেয়া বুজায়, উদাহৰণস্বৰূপে এটা autonomous agent এ human account session-ৰ ভিতৰত কাম কৰি থাকিলে। Proof of Actor-এ delegation credential issue বা validate নকৰে, আৰু এটা Agent result-এ কেতিয়াও এইটো সূচোৱা নাই যে কোনো ব্যক্তিয়ে action-টো অনুমোদন কৰিছে। আপোনাৰ application-ৰ নিজস্ব grants, scopes আৰু confirmations-এ সেইটো সিদ্ধান্ত কৰে, আৰু Route-এ আপোনাক real traffic পর্যবেক্ষণ কৰাৰ পাছত প্ৰতিটো route-ৰ বাবে উপযুক্ত policy প্ৰয়োগ কৰিবলৈ দিয়ে। policy pattern-সমূহৰ বাবে মানৱ আৰু AI agent-ৰ বাবে app-level policy design কৰা চাওক।
যিটো evidence স্থাপন কৰিব পাৰে আৰু যিটো কৰিব নোৱাৰে পঢ়ক, বা early access-ৰ বাবে আবেদন কৰক.
উৎস
- RFC 6749: The OAuth 2.0 Authorization Framework: resource owner-ৰ পৰা client-লৈ scoped grant
- RFC 7009: OAuth 2.0 Token Revocation: এটা delegated token revoke কৰা
- RFC 8693: OAuth 2.0 Token Exchange: delegation-ৰ বাবে
act(actor) claim