সকলোৰে বাবে একেটা policy এতিয়া যথেষ্ট নহয়
বেছিভাগ application একেটা ধৰণৰ ব্যৱহাৰকাৰীক ধৰি ডিজাইন কৰা হৈছিল: account-ত sign in কৰা আৰু interface-ৰ মাজেৰে click কৰা এজন ব্যক্তি। Access control-এ সেই অনুমান অনুসৰণ কৰিছিল। যদি session valid হয়, request আগবঢ়ে। যদি সেয়া automated যেন লাগে, CAPTCHA বা block দেখা দিয়ে।
সেই model এতিয়া ভাঙি পৰিছে। আজিকালি একেটা application-এ মানুহ, AI assistant-সহ কাম কৰা মানুহ, আৰু কোনোবাৰ হৈ autonomous agent-ও serve কৰে। কিছুমান agent হৈছে customer-ৰ নিজৰ integration। কিছুমান AI assistant যিয়ে documentation fetch কৰে। কিছুমান crawler। কেইটামানে আপোনাৰ product abuse কৰিবলৈ চেষ্টা কৰে। একেটা yes-or-no rule-এ তেওঁলোক সকলোৰে বাবে ভাল কাম কৰিব নোৱাৰে।
AI agent routing আৰু access policy-এ সেই একক rule-টো deliberate decision-ৰ এটা set-এৰে সলনি কৰে: কোন actor-এ কোন experience পাব, কোন route-ত, কোন condition-ৰ অধীনত। Proof of Actor-এ আপোনাৰ application-লৈ সেই সিদ্ধান্ত ল’বলৈ evidence দিয়ে, আৰু সিদ্ধান্ত নিজে আপোনাৰ হাতত এৰি দিয়ে। এই approach-ৰ design principle-সমূহৰ বাবে মানুহ আৰু AI agent-ৰ বাবে app policy ডিজাইন কৰা পঢ়ক, আৰু বাস্তৱ product workflow-ৰ সৈতে policy কেনেকৈ মিলে তাৰ বাবে SaaS apps use case চাওক।
এটা ভাল agent policy কেনেকুৱা
উপযোগী policy এটা নির্দিষ্ট হয়। ই এটা route বা workflow, এটা class of actor, প্ৰয়োজনীয় evidence-ৰ শক্তি, আৰু response-ৰ নাম দিয়ে। উদাহৰণস্বৰূপে:
- Read-only catalog route-সমূহ: verified agent-সমূহক allow কৰক আৰু structured response দিয়ক; declared agent-সমূহক standard rate limit-সহ allow কৰক।
- Account-changing action-সমূহ: সকলোৰে বাবে আপোনাৰ existing re-authentication বজাই ৰাখক; actor Unknown হ’লে আৰু action high impact হ’লে review যোগ কৰক।
- Support submission: disclosed AI-assisted content গ্ৰহণ কৰক আৰু routing-ৰ বাবে label কৰক।
- Signup: existing check বজাই ৰাখক; inferred actor result-ৰ ওপৰত এককভাৱে সিদ্ধান্ত নল’ব।
এই সকলোয়ে প্ৰতিটো agent-কে abuse হিচাপে গণ্য নকৰাকৈ actor-ৰ প্ৰতি সঁহাৰি দিয়ে, আৰু প্ৰতিটো agent-ক অন্ধভাৱে বিশ্বাসো নকৰে। এই balance-ই হৈছে agent-aware access-ৰ মূল কথা, আৰু মানুহ আৰু AI agent-ৰ বাবে app policy ডিজাইন কৰা বিষয়ে blog post-এ route by route অধিক উদাহৰণ দেখুৱায়।
পাঁচটা response
Proof of Actor-ৰ Route capability-টা আপোনাৰ policy-এ বাছি ল’ব পৰা পাঁচটা response-ৰ ওপৰত নিৰ্মিত।
Allow
Request-টো স্বাভাৱিকভাৱে আগবঢ়িবলৈ দিয়ক। Public বা low-risk route-ত থকা বেছিভাগ traffic-সহ বেছিভাগ agent traffic সাধাৰণতে allow কৰিব লাগে।
Adapt
Actor-ৰ উপযোগী কৰি experience সলনি কৰক। মানুহৰ interface-ৰ সলনি verified agent-লৈ structured API response বা page-ৰ Markdown version দিয়ক। AI agent-লৈ structured content serve কৰা guide-এ এই pattern cover কৰে।
Challenge
এটা অধিক শক্তিশালী বস্তু বিচাৰক: fresh login, এটা অতিৰিক্ত credential, account owner-ৰ পৰা confirmation। ভুল সিদ্ধান্তৰ খৰচ বেছি হোৱা route-সমূহত challenge ব্যৱহাৰ কৰক।
Review
Action-টো সোজাকৈ সম্পূৰ্ণ কৰাৰ সলনি queue-লৈ যাওক, বা human-এ পৰীক্ষা কৰিবলৈ flag কৰক। Blocking-এ legitimate user-ৰ ক্ষতি কৰিব পাৰে, কিন্তু unattended completion অতি বিপজ্জনক হ’লে review উপযোগী।
Limit
Actor আৰু route-অনুসৰি সজোৱা rate বা volume limit প্ৰয়োগ কৰক, যাতে মানুহৰ বাবে ডিজাইন কৰা workflow-টো automated caller-এ অতিৰিক্তভাৱে ব্যস্ত কৰি তুলিব নোৱাৰে।
robots.txt এটা access policy নহয় কিয়
বহু team-এ robots.txt-ৰে আৰম্ভ কৰে, আৰু crawler-ৰ বাবে সেয়া এটা যুক্তিসংগত প্ৰথম signal। কিন্তু সেয়া agent-ৰ বাবে access policy নহয়। Crawler operator-এ ভিন্ন user agent-ৰ বাবে ভিন্ন আচৰণ নথিভুক্ত কৰে: Anthropic-এ কয় যে তাৰ bot-সমূহে robots.txt directive মানে (Anthropic crawler documentation), আনহাতে OpenAI-এ লক্ষ্য কৰে যে ChatGPT-User-ৰ ক্ষেত্ৰত, যি user-এ ChatGPT-লৈ question সোধা সময়ত কাম কৰে, robots.txt rule-সমূহ প্ৰযোজ্য নহ’বও পাৰে কাৰণ action-টো user-initiated (OpenAI crawler documentation). Robots.txt-এ API, MCP tool বা sign-in কৰা workflow-ৰ বিষয়ে একো নকয়।
Access policy-টো request য’ত handle হয় তাতেই চলিব লাগে, RFC 9421-ৰ অধীনত যাচাই কৰা signature-ৰ দৰে evidence পঢ়িব লাগে, আৰু route-অনুসৰি response বাছি ল’ব লাগে। MCP server-ৰ বাবে, MCP authorization specification-এ client-এ HTTP-ৰ জৰিয়তে access token কেনেকৈ পায় সেয়া নিৰ্ধাৰণ কৰে; actor policy-য়ে তাৰ ওপৰত context যোগ কৰে, সেয়া প্রতিস্থাপন নকৰে।
Proof of Actor-এ আপোনাৰ policy-লৈ কেনেকৈ feed কৰে
আপোনাৰ integration-এ মূল্যায়ন কৰা প্ৰতিটো request-এ এটা actor result সৃষ্টি কৰে, যাৰ চাৰিটা অংশ আপোনাৰ policy-এ পঢ়িব পাৰে:
- Class: Human, Human + AI, Agent বা Unknown.
- Basis: verified, declared, inferred বা unknown, যাতে আপোনাৰ policy-এ validated signature-ক self-declared client name-ৰ পৰা পৃথকভাৱে বিবেচনা কৰিব পাৰে।
- Evidence summary: result-টো কিহৰ ওপৰত ভিত্তি কৰি আছে তাৰ readable বৰ্ণনা, logging আৰু review-ৰ বাবে উপযোগী।
- Context: কোন integration আৰু কোন route-এ সেয়া সৃষ্টি কৰিলে।
Basis স্পষ্ট হোৱাৰ বাবে আপোনাৰ policy-সমূহ নিখুঁত হ’ব পাৰে। "Agents allow কৰক"-ৰ সলনি হ’ব "read route-ত verified agent allow কৰক, declared agent-এ rate-limit কৰক, বাকী সকলোতে Unknown fallback প্ৰয়োগ কৰক।" Request-ৰ পৰা decision-লৈ সম্পূৰ্ণ flow How It Works-ত বৰ্ণনা কৰা হৈছে।
Fallback-ও policy-ৰ অংশ
Evidence অনুপস্থিত থাকিলে policy কেনেকৈ আচৰণ কৰে সেয়াই তাৰ মান নিৰ্ধাৰণ কৰে। Proof of Actor-এ সেই ক্ষেত্ৰসমূহ লুকুৱাই নাৰাখি স্পষ্ট কৰে।
- Unknown: evidence-এ কোনো determination সমৰ্থন কৰা নাছিল। আপোনাৰ policy-এ প্ৰতিটো route-ত Unknown-ৰ অৰ্থ কি সেয়া কয়। সেয়া কেতিয়াও Human-লৈ convert নহয় আৰু default হিচাপে malicious বুলি গণ্য কৰা নহয়।
- Timeout: result সময়মতে নাহিল। আপোনাৰ integration-এ সেই route-ৰ বাবে বাছি লোৱা fallback প্ৰয়োগ কৰে।
- Missing signals: কোনো collector চলা নাছিল বা header নাছিল। Result-এ সেইটো প্ৰতিফলিত কৰে, আৰু আপোনাৰ policy-এ সেয়া অনুসাৰে ব্যৱহাৰ কৰে।
প্ৰতিটো route-ৰ বাবে আপুনি fail open বা fail closed বাছি ল’ব। Fail open মানে request-টো Proof of Actor নথকাৰ দৰে আগবাঢ়ে; fail closed মানে আপোনাৰ existing stronger check প্ৰয়োগ হয়। Low-risk route-সমূহ সাধাৰণতে fail open হয়। সংবেদনশীল action-সমূহ সাধাৰণতে fail closed হয়। আপুনি এইটো global নহয়, risk tier-অনুসৰি স্থাপন কৰে।
Identity, credential আৰু authorization পৃথক ৰাখক
Agent access policy-সমূহ তিনিটা পৃথক স্তৰৰ ওপৰত থাকে, আৰু সিহঁত পৃথককৈ ৰাখিলে আটাইতকৈ ক্ষতিকাৰক ভুলসমূহ ৰোধ হয়।
- Identity evidence-এ কোন ধৰণৰ actor কল কৰিছে আৰু কিহে তাক প্ৰমাণ কৰে সেয়া কয়। Proof of Actor-এ এইটো দিয়ে।
- Credential-এ কোন account দায়ী সেয়া কয়। আপোনাৰ session, token বা API key-এ এইটো দিয়ে।
- Authorization-এ এই caller-এ এই action কৰিব পাৰিব নেকি সেয়া কয়। আপোনাৰ permission model-এ এইটো দিয়ে।
এটা verified agent identity-ৰ অৰ্থ এইটো নহয় যে agent-টো authorized, কোনো ব্যক্তিয়ে তাক authority delegate কৰিছিল, বা তাৰ action safe। Routing আৰু context-ৰ বাবে actor result ব্যৱহাৰ কৰক। Permission দিবলৈ আপোনাৰ authorization model ব্যৱহাৰ কৰক। Detection & Limitations পৃষ্ঠাই প্ৰতিটো evidence-ৰ ধৰণে ঠিক কি establish কৰিব পাৰে সেয়া স্পষ্টকৈ ব্যাখ্যা কৰে।
একো নাভাঙি roll out কৰক
Agent access policy আনি সংযোজন কৰাৰ আটাইতকৈ সুৰক্ষিত উপায় হৈছে পৰ্যায়ক্রমে কৰা।
- Observe. observation mode-ত Proof of Actor স্থাপন কৰক। আপোনাৰ user-ৰ বাবে একোৱেই সলনি নহয়; result ৰেকৰ্ড হয়।
- Understand. কোন actor-এ কোন route ব্যৱহাৰ কৰে, প্ৰতিটোত unknown rate কিমান, আৰু আপুনি ইতিমধ্যে জানি থকা বিষয়ৰ সৈতে অসংগত result আছে নে নাই চাওক।
- Preview. Policy-টো preview-ত চলাওক, enforce নকৰাকৈ সেয়া কি কৰিলেহেঁতেন সেয়া log কৰক।
- Enforce narrowly. Evidence-এ স্পষ্টভাৱে সমৰ্থন কৰা এটা route-ত policy enable কৰক। Outcome-সমূহ চাওক।
- Expand. Confidence বৃদ্ধি পোৱাৰ লগে লগে অধিক route-লৈ বিস্তাৰ কৰক।
actor-aware policy সুৰক্ষিতভাৱে roll out কৰা guide-এ প্ৰতিটো stage-ৰ মাজেৰে লৈ যায়, আৰু agent-সমূহ block নকৰাকৈ sensitive action সুৰক্ষিত কৰা-এ high-stakes route-সমূহ cover কৰে।
আপোনাৰ team-এ কি পায়
Proof of Actor-ৰে আপোনাৰ team-এ তিনিটা capability-সহ এটা integration পায়। Detect-এ actor signal সংগ্ৰহ কৰে আৰু verified assertion-সমূহ inference-ৰ পৰা পৃথক কৰে। Understand-এ actor analytics, trend আৰু প্ৰতিটো result-ৰ পিচৰ evidence দেখুৱায়, Unknown visible ৰাখি। Route-এ এই পৃষ্ঠাত বৰ্ণনা কৰা policy লিখিবলৈ আৰু আপোনাৰ পছন্দমতে সিহঁত প্ৰয়োগ কৰিবলৈ দিয়ে। Private beta চলাকালীন routing policy প্ৰতিটো founding team-ৰ সৈতে ডিজাইন কৰা হয় আৰু আপোনাৰ নিজা application code-ত চলোৱা হয়, যাতে আপুনি সম্পূৰ্ণ নিয়ন্ত্ৰণ ৰাখে।
এৰাই চলিবলগীয়া সাধাৰণ policy ভুল
প্ৰথমবাৰৰ বাবে agent access ডিজাইন কৰা team-এ কিছুমান ভুল পুনৰাবৃত্তি কৰে। সিহঁত এৰাই চলিলে সপ্তাহৰ rework ৰক্ষা হয়।
- Default হিচাপে প্ৰতিটো agent block কৰা। Legitimate agent-এ তাৰ পিছত আপোনাৰ পৰা ঘূৰি যাব, প্ৰায়ে মানুহৰ বাবে বান্ধি দিয়া interface scrape কৰি, যিটো structured path-তকৈ সুৰক্ষিত কৰা কঠিন।
- Declared name-ৰ ওপৰত বিশ্বাস কৰা। কেৱল নিজৰ নাম কোৱা client-এ এটা claim কৰিছে, proof দিয়া নাই। অযাচিত caller-লৈ আপুনি যি treatment দিব সেইটোৱে এই ক্ষেত্ৰতো দিয়ক।
- সকলো ঠাইতে একেটা fallback ব্যৱহাৰ কৰা। Public pricing page-ত Unknown আৰু password change-ত Unknown একে পৰিস্থিতি নহয়। প্ৰতিটো route-এ নিজৰ উত্তৰ লাগে।
- Inference-ৰ পৰা মানুহৰ বিষয়ে সিদ্ধান্ত লোৱা। Actor result routing-ৰ বাবে context, ব্যক্তিৰ verdict নহয়। Consequential decision আপোনাৰ own control আৰু review-তে ৰাখক।
- Observation এৰি দিয়া। Day one-তেই enforce কৰিলে আপুনি customer complaint-ৰ জৰিয়তে false positive বিচাৰি পায়। প্ৰথমে observe কৰক, তাৰ পিছত evidence স্পষ্ট হোৱা ঠাইত enforce কৰক।
প্ৰতিটো enforcement step-ৰ আগতে আপোনাৰ security, product আৰু support lead-ৰ সৈতে এটা চুটি policy review কৰিলে এইবোৰৰ বেছিভাগ আগতেই ধৰা পৰে।
Founding developer program-ৰ সৈতে আৰম্ভ কৰক
Proof of Actor private beta-ত আছে। নিৰ্বাচিত founding development team-এ agreed usage limit-ৰ ভিতৰত 12 months পৰ্যন্ত free access, আৰু আপোনাৰ প্ৰথম policy ডিজাইন কৰোঁতে আমাৰ engineer-ৰ পৰা direct support পেতে পাৰে।
আপোনাৰ application-এ AI agent-সমূহক কেনেকৈ ব্যৱহাৰ কৰা উচিত সেইটো সিদ্ধান্ত ল’বলৈ গৈ থাকিলে, early access-ৰ বাবে আবেদন কৰক. কোন route আটাইতকৈ গুৰুত্বপূৰ্ণ আৰু কোন decision আপুনি ল’ব বিচাৰে সেয়া আমাক জনাওক, আমি আপোনাক উপযুক্ত policy গঢ়িবলৈ সহায় কৰিম। আপুনি এইটো APIs আৰু MCP servers-ত কেনেকৈ প্ৰযোজ্য হয় সেয়াও চাব পাৰে।
Sources
- Does Anthropic crawl data from the web, and how can site owners block the crawler?, Anthropic.
- Overview of OpenAI crawlers, OpenAI.
- RFC 9421: HTTP Message Signatures, IETF, February 2024.
- MCP authorization, modelcontextprotocol.io.