ଏଜେଣ୍ଟ ଅଧିକାରୀକରଣ

ଏଜେଣ୍ଟ ଅଧିକାରୀକରଣର ଅର୍ଥ କ'ଣ

ଏଜେଣ୍ଟ ଅଧିକାରୀକରଣ ହେଉଛି ଏହି ନିଷ୍ପତ୍ତି ଯେ ଏକ AI agent କ'ଣ କରିବାକୁ allowed ଅଛି: କେଉଁ routes ସେ call କରିପାରିବ, କେଉଁ data ସେ read କରିପାରିବ, କେଉଁ actions ସେ ନେଇପାରିବ ଏବଂ କେଉଁ volumeରେ। ଏହା agent identity ଠାରୁ ଅଲଗା, ଯାହାର କଥା ହେଉଛି କେଉଁ agent, କିମ୍ବା କେଉଁ operatorର agent, request କରୁଛି ତାହା ସ୍ଥାପନ କରିବା।

ଏହି ଦୁଇଟିକୁ ଅଲଗା କରିବା ସହଜ ନୁହେଁ କାରଣ ସେମାନେ ପ୍ରାୟ ସହିତେ ଆସନ୍ତି। ଏକ signed request ଆପଣଙ୍କୁ କହେ କିଏ ପଠାଇଛି। କିନ୍ତୁ ସେହି senderଙ୍କୁ account change କରିବା, order place କରିବା କିମ୍ବା data export କରିବାକୁ allowed ହେବା ଉଚିତ କି ନୁହେଁ, ତାହା କହେ ନାହିଁ। Identity ହେଉଛି evidence; authorization ହେଉଛି policy. ଆମର signed AI agent requests କ'ଣ ପ୍ରମାଣ କରେ, ଏବଂ କ'ଣ କରେ ନାହିଁ ବିଷୟକ ଲେଖା ଏହି ପାର୍ଥକ୍ୟକୁ ଖୋଲିଦିଏ।

ଏହି ପାର୍ଥକ୍ୟ କାହିଁକି ଗୁରୁତ୍ୱପୂର୍ଣ୍ଣ

Applications ପୂର୍ବରୁ human users ପାଇଁ authentication ଠାରୁ authorizationକୁ ଅଲଗା କରେ: log in କରିବା ଆପଣ କିଏ ତାହା ପ୍ରମାଣ କରେ, ଏବଂ roles ଓ permissions ଆପଣ କ'ଣ କରିପାରିବେ ତାହା ନିର୍ଣ୍ଣୟ କରେ। Agentsଙ୍କୁ ସେହି separation ଆବଶ୍ୟକ, ଏକ ଅତିରିକ୍ତ ସାବଧାନତା ସହିତ:

• Identity ଶକ୍ତିଶାଳୀ ହୋଇପାରେ, କିନ୍ତୁ permission ନଥାଇପାରେ। ଏକ crawler ଯାହା ପାଖରେ ସଠିକ HTTP message signature ଅଛି, write endpoint call କରିବାର ଜନ୍ମସିଦ୍ଧ ଅଧିକାର ରଖେ ନାହିଁ।
• Permission strong identity ଛଡ଼ା ମଧ୍ୟ ରହିପାରେ। ଏକ customerଙ୍କ API key ବ୍ୟବହାର କରୁଥିବା agent ସେ key ଦ୍ୱାରା authorized, ଯଦିଓ କେଉଁ agent software ଏହାକୁ ଧାରଣ କରିଛି ତାହା କିଛି ଚିହ୍ନଟ କରେ ନାହିଁ।
• Agent ପଛରେ ଥିବା person ଗୁରୁତ୍ୱପୂର୍ଣ୍ଣ। ଯେତେବେଳେ ଏକ agent କାହାରୋ ପକ୍ଷରେ କାମ କରେ, ପ୍ରଶ୍ନ ହେଉଛି ସେ person ଏହାକୁ authority ଦେଇଥିଲେ କି ନାହିଁ (ଦେଖନ୍ତୁ delegated authority).

ଏଗୁଡ଼ିକୁ ଗୋଟିଏ ଯାଞ୍ଚରେ ମିଶାଇଦେଲେ ଦୁଇଟି failure mode ହୁଏ: human log in ନଥିବାରୁ legitimate automationକୁ block କରିଦେବା, କିମ୍ବା ଭଲଭାବରେ identified ହୋଇଥିବା agentକୁ ସେ କଦାଚିତ ନେବାକୁ ଥିବା ନଥିବା actions ପାଇଁ trust କରିଦେବା।

ସାଧାରଣତଃ 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. Known agents ପାଇଁ read-only routes ଖୋଲା; write routes account ସହିତ ଯୋଡ଼ାଯାଇଥିବା credential ଆବଶ୍ୟକ କରେ।
• Risk tiers. କମ ପ୍ରଭାବ ଥିବା actions ବ୍ୟାପକ ଭାବରେ allowed; ଉଚ୍ଚ ପ୍ରଭାବ ଥିବା actions ପାଇଁ ଅଧିକ ସକ୍ତିଶାଳୀ credentials, confirmation କିମ୍ବା review ଆବଶ୍ୟକ।
• Rate limits ଏବଂ quotas ପ୍ରତି operator, ପ୍ରତି credential କିମ୍ବା ପ୍ରତି route ଅନୁଯାୟୀ।

Agent identity evidence ଏହି ନିଷ୍ପତ୍ତିଗୁଡ଼ିକୁ ଗୋଟିଏ input ଭାବେ ସହାୟତା କରେ। ଏକ worked approach ପାଇଁ, human ଏବଂ AI agents ପାଇଁ app-level policies କିପରି design କରିବେ ଦେଖନ୍ତୁ। ଏହା ଆପଣଙ୍କୁ ଏକ verified operatorକୁ ଏକ anonymous client ଠାରୁ ଭିନ୍ନ ଭାବେ treat କରିବାକୁ ଦେଇଥାଏ, କିନ୍ତୁ permission ନିଜେ ତଥାପି ଆପଣଙ୍କ policyରୁ ଆସେ।

ସାଧାରଣ ଭ୍ରାନ୍ତିଧାରଣା

• "Verified agent ମାନେ allowed." Verification requestକୁ attribute କରେ। ଆପଣଙ୍କ policy ତଥାପି ସେ attributed party କ'ଣ କରିପାରିବ ତାହା ନିର୍ଣ୍ଣୟ କରେ।
• "ପ୍ରମାଣିତ human ନ ଥିଲେ agentsକୁ block କରିଦେବା ଉଚିତ." ଅନେକ agents legitimate participants। ଭଲ ପ୍ରଶ୍ନ ହେଉଛି ପ୍ରତ୍ୟେକ actor ପ୍ରକାରକୁ route by route କ'ଣ କରିବାକୁ allowed ହେବା ଉଚିତ।
• "Authorizationକୁ behaviorରୁ infer କରାଯାଇପାରେ." Behavior କେଉଁ ପ୍ରକାରର actor ଅଛି ତାହା ସମ୍ପର୍କରେ confidence ବଢ଼ାଇବା କିମ୍ବା କମାଇପାରେ। ଏହା ନିଜେ permission ଦେବା ଉଚିତ ନୁହେଁ।

Proof of Actor ଏହାକୁ କିପରି ହାତଲ କରେ

Proof of Actor evidence ପ୍ରଶ୍ନର ଉତ୍ତର ଦେଇଥାଏ: କେଉଁ ପ୍ରକାରର actor ଉପସ୍ଥିତ, କେଉଁ basisରେ (verified, declared, inferred କିମ୍ବା unknown), ଏବଂ କ'ଣ known ଏବଂ କ'ଣ not known। ଏହା intentionally permission ନିର୍ଣ୍ଣୟ କରେ ନାହିଁ। ଏକ Agent result, verified ହେଲେ ମଧ୍ୟ, କେବେ ମଧ୍ୟ authorization ସୂଚିତ କରେ ନାହିଁ। Routeରେ, ଆପଣଙ୍କ application actor resultକୁ ତାହାର own credentials, scopes ଏବଂ risk tiers ସହିତ combine କରେ, ଯାହା ଦ୍ୱାରା ପ୍ରତ୍ୟେକ interactionକୁ allow, adapt, challenge, review କିମ୍ବା limit କରିପାରିବ, ଆରମ୍ଭରେ observation modeରେ, ଯାହାଦ୍ୱାରା କିଛି enforce କରିବା ପୂର୍ବରୁ outcomes ଯାଞ୍ଚ କରିପାରିବେ।

ଆପଣଙ୍କ appରେ decisions କିପରି fit କରେ ବିଷୟରେ ଅଧିକ ଜାଣନ୍ତୁ, APIs ଏବଂ MCP servers use cases ଦେଖନ୍ତୁ, କିମ୍ବା early access ପାଇଁ apply କରନ୍ତୁ.

ସ୍ରୋତ

• 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 କ'ଣ ସ୍ଥାପନ କରେ