Agent অনুমোদন মানে কী
Agent অনুমোদন হলো সিদ্ধান্ত যে একটি AI agent কী করতে পারবে: কোন routes সে call করতে পারবে, কোন data সে read করতে পারবে, কোন actions সে নিতে পারবে, এবং কোন পরিমাণে। এটি agent identity থেকে আলাদা, যা নিয়ে কাজ করে কোন agent, বা কোন operator-এর agent, request করছে তা প্রতিষ্ঠা করা।
এই দুটিকে আলাদা করা সহজ নয়, কারণ অনেক সময় তারা একসঙ্গে আসে। একটি 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 যদি perfectly valid HTTP message signature-সহও আসে, তাতে তার write endpoint call করার স্বাভাবিক অধিকার নেই।
- Permission থাকতে পারে, কিন্তু strong identity নাও থাকতে পারে। একটি customer-এর API key ব্যবহার করা agent সেই key-এর মাধ্যমে authorized, এমনকি কোন agent software সেটি ধরে আছে তা কিছুই শনাক্ত না করলেও।
- Agent-এর পেছনের person গুরুত্বপূর্ণ। যখন একটি agent কারও হয়ে কাজ করে, তখন প্রশ্ন হয় সেই person কি তাকে authority দিয়েছিল কি না (দেখুন delegated authority)।
এই সবকিছুকে একটিমাত্র check-এ মিশিয়ে দিলে দুটি failure mode তৈরি হয়: human login না থাকায় legitimate automation ব্লক হয়ে যায়, অথবা যে agent-কে কখনও সেই কাজের জন্য intended করা হয়নি তাকে ভালোভাবে শনাক্ত করা হয়েছে ভেবে বিশ্বাস করা হয়।
সাধারণত authorization কীভাবে প্রকাশ করা হয়
বেশিরভাগ application আগে থেকেই থাকা mechanisms দিয়ে agents-কে authorize করে:
- Credentials এবং scopes। API keys বা OAuth 2.0 tokens, য deren scopes integration-এর প্রয়োজনীয় কাজের মধ্যেই সীমাবদ্ধ। MCP servers একই model ব্যবহার করে: MCP authorization specification একটি protected server-কে OAuth 2.1 resource server হিসেবে ধরে।
- Route-level policy। known agents-এর জন্য read-only routes খোলা; write routes-এর জন্য account-এর সাথে যুক্ত একটি credential প্রয়োজন।
- Risk tiers। কম-impact action broadly allowed, বেশি-impact action-এর জন্য stronger credentials, confirmation বা review দরকার।
- প্রতি operator, প্রতি credential বা প্রতি route অনুযায়ী rate limits এবং quotas।
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 কী করতে পারবে।
- "Agents-কে block করা উচিত যতক্ষণ না তারা human বলে প্রমাণিত হয়." অনেক agent-ই legitimate participant। আরও ভালো প্রশ্ন হলো প্রতিটি ধরনের actor-কে route by route কী করতে দেওয়া উচিত।
- "Authorization behavior থেকে infer করা যেতে পারে." Behavior কী ধরনের actor আছে সে বিষয়ে confidence বাড়াতে বা কমাতে পারে। কিন্তু এটি নিজে থেকে permission দেয় না।
Proof of Actor এটি কীভাবে দেখে
Proof of Actor evidence প্রশ্নের উত্তর দেয়: কী ধরনের actor উপস্থিত, কোন ভিত্তিতে (verified, declared, inferred or unknown), এবং কী জানা আছে আর কী জানা নেই। এটি ইচ্ছাকৃতভাবে permission নির্ধারণ করে না। একটি Agent result, এমনকি verified হলেও, কখনও authorization imply করে না। Route-এ, আপনার application actor result-কে তার নিজস্ব credentials, scopes এবং risk tiers-এর সঙ্গে মিশিয়ে প্রতিটি interaction-কে allow, adapt, challenge, review বা limit করে, observation mode-এ শুরু করে যাতে কিছু enforce করার আগে আপনি outcomes যাচাই করতে পারেন।
আরও জানুন আপনার app-এ decisions কীভাবে fit করে, APIs এবং MCP servers use case দেখুন, অথবা early access-এর জন্য apply করুন।
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 কী প্রতিষ্ঠা করে