অর্পিত কর্তৃত্বের অর্থ কী
অর্পিত কর্তৃত্ব হলো এমন অনুমতি, যা একজন ব্যক্তি (অথবা একটি সংস্থা) একটি AI agent-কে তাদের হয়ে কাজ করার জন্য দেয়। যখন একটি assistant আপনার calendar-এ একটি meeting বুক করে, আপনার নামে একটি support ticket তৈরি করে বা কোনো supplier-এর portal থেকে একটি invoice আনে, তখন সেটি আপনার দেওয়া কর্তৃত্ব ব্যবহার করছে।
ভালো delegation-এর তিনটি বৈশিষ্ট্য আছে: এটি scoped (agent কিছু কাজ করতে পারে, সব নয়), bounded in time (এটির মেয়াদ শেষ হয় বা revoke করা যায়) এবং attributable (যে application এটি গ্রহণ করছে, সে বুঝতে পারে কার কর্তৃত্ব প্রয়োগ হচ্ছে)।
এটি applications-এর জন্য কেন গুরুত্বপূর্ণ
একটি application's দৃষ্টিকোণ থেকে, একটি agent request সর্বোচ্চ তিনটি আলাদা প্রশ্ন তোলে:
- এই request কোন client পাঠিয়েছে? সেটি agent identity, যা signed requests দিয়ে নির্ধারণ করা যায় (দেখুন HTTP Message Signatures)।
- এটি কার কর্তৃত্বে কাজ করছে? সেটি delegation।
- এই কাজের জন্য সেই কর্তৃত্ব যথেষ্ট কি? সেটি authorization, যা application's নিজস্ব policy দ্বারা নির্ধারিত হয়।
একজন পরিচিত assistant operator থেকে আসা signed request প্রথম প্রশ্নের ভালো উত্তর দেয়। কিন্তু এটি নিজে থেকে দ্বিতীয় প্রশ্নের উত্তর দেয় না। assistant হয়তো আপনার কোনো user-এর পক্ষে, আপনার user নয় এমন কারও পক্ষে, অথবা পুরোপুরি নিজের উদ্যোগে কাজ করছে। client identity-কে একজন ব্যক্তির consent-এর প্রমাণ হিসেবে ধরা agent-facing design-এর সবচেয়ে সাধারণ ভুলগুলোর একটি। দেখুন signed AI agent requests কী প্রমাণ করে, আর কী করে না।
delegation সাধারণত কীভাবে প্রকাশ করা হয়
- OAuth-style grants. ব্যক্তি আপনার application-এ sign in করে এবং একটি agent-কে সীমিত scope-সহ token দেয়, যেমনটি OAuth 2.0 (RFC 6749)-এ নির্ধারিত। এরপর আপনার application ঠিক জানে token কোন authority বহন করছে, এবং grant revoke করা যেতে পারে (RFC 7009)।
- Account-scoped API keys যা একজন user নির্দিষ্ট integration-এর জন্য তৈরি করে, আদর্শভাবে সীমিত permission-সহ।
- In-app confirmations উচ্চ-প্রভাবযুক্ত কাজের জন্য, যেখানে ব্যক্তি agent প্রস্তুত করা নির্দিষ্ট action অনুমোদন করেন।
- Token-level delegation claims. OAuth 2.0 Token Exchange (RFC 8693) একটি
act(actor) claim নির্ধারণ করে, যা একজন পক্ষ অন্যের হয়ে কাজ করছে তা নথিভুক্ত করে। request-এ agent delegation প্রকাশ করার নতুন কাজ এখনো বিকাশমান, এবং application-গুলোর উচিত delegation claim-কে কেবল মুখ্যভাবে মেনে নেওয়ার বদলে নিজেদের record-এর সঙ্গে যাচাই করা।
সাধারণ ভুল ধারণা
- "Agent verified হলে user অনুমোদন করেছে।" Verification client-কে চিহ্নিত করে। অনুমোদন আসতে হবে ব্যক্তির কাছ থেকে, এমন একটি channel-এর মাধ্যমে যা আপনার application বিশ্বাস করে।
- "আমার user-এর session ব্যবহার করা agent-এর জন্য ঠিক আছে।" হতে পারে, কিন্তু সেই session interactive human use-এর জন্য জারি করা হয়েছিল। অনেক application automation-এর জন্য একটি dedicated, scoped grant পছন্দ করে, যাতে কাজগুলো attributable এবং revocable হয়।
- "Delegation হয় সব, নয়তো কিছুই নয়।" সবচেয়ে নিরাপদ delegation হলো সংকীর্ণ: broad read access, নির্দিষ্ট কাজের জন্যই write access, এবং যেকোনো irreversibly কাজের জন্য confirmation।
Proof of Actor-এর সঙ্গে এর সম্পর্ক
Proof of Actor আপনাকে দেখতে সাহায্য করে কখন কোনো interaction agent-driven বা AI-assisted, এবং কোন basis-এ: verified, declared, inferred বা unknown। এই context আপনাকে দেখায় delegation-এর প্রশ্ন কোথায় উঠছে, যেমন একটি autonomous agent human account session-এর মধ্যে কাজ করছে। Proof of Actor delegation credentials issue বা validate করে না, এবং একটি Agent result কখনোই বোঝায় না যে কোনো ব্যক্তি সেই কাজ অনুমোদন করেছেন। আপনার application's নিজস্ব grants, scopes এবং confirmations সেটি নির্ধারণ করে, এবং Route আপনাকে বাস্তব traffic পর্যবেক্ষণের পর প্রতি route-এ সঠিক policy প্রয়োগ করতে দেয়। policy patterns-এর জন্য দেখুন মানুষ এবং AI agent-এর জন্য app-level policy কীভাবে ডিজাইন করবেন।
প্রমাণ কী করতে পারে এবং কী করতে পারে না পড়ুন, অথবা প্রাথমিক access-এর জন্য আবেদন করুন।
উৎস
- 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