এজেন্ট অ্যাক্সেস নীতি

আপনার নিয়ন্ত্রণে থাকা policy দিয়ে AI agent route করুন

আপনার application মানুষ, AI-assisted user এবং autonomous agent-দের route by route কীভাবে扱বে তা নির্ধারণ করুন। Proof of Actor evidence দেয়; সিদ্ধান্ত নেয় আপনার policy.

প্রাথমিক access পান কীভাবে কাজ করে তা অন্বেষণ করুন

দ্বারা Toshendra SharmaFounder & CEO, AgentCredia · Updated November 13, 2026

সবাইকে নিয়ে একটাই policy এখন আর যথেষ্ট নয়

বেশিরভাগ application এক ধরনের user ধরে তৈরি হয়েছিল: account-এ signed in হয়ে interface-এর মাধ্যমে click করে চলা একজন মানুষ। Access control সেই ধারণা অনুসরণ করত। Session valid হলে request এগিয়ে যেত। Automated মনে হলে CAPTCHA বা block দেখাত।

সেই model ভেঙে যাচ্ছে। আজ একই application মানুষ, AI assistant-এর সাথে কাজ করা মানুষ, এবং কারও পক্ষে কাজ করা autonomous agent-দের সেবা দেয়। কিছু agent customer-এর নিজস্ব integration। কিছু agent documentation আনতে থাকা AI assistant। কিছু crawler। আর কয়েকটি আপনার product abuse করার চেষ্টা করছে। একক yes-or-no rule এদের সবার জন্য ভালো কাজ করতে পারে না।

AI agent routing এবং access policy সেই একক rule-এর জায়গায় deliberate decision-এর একটি set আনে: কোন actor কোন experience পাবে, কোন route-এ, কোন condition-এ। Proof of Actor আপনার application-কে এই decision নেওয়ার evidence দেয়, আর decision-টি আপনার হাতে রাখে। এই approach-এর design principle জানতে পড়ুন মানুষ ও AI agent-এর জন্য app policy ডিজাইন করা, এবং SaaS app use case দেখুন যেখানে policy বাস্তব product workflow-তে কীভাবে মানচিত্রিত হয়।

একটি ভাল agent policy কেমন দেখায়

একটি কার্যকর policy নির্দিষ্ট হয়। এতে একটি route বা workflow, actor class, প্রয়োজনীয় 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 accept করুন এবং routing-এর জন্য label করুন।
Signup: existing check বজায় রাখুন; শুধু inferred actor result থেকে কখনো সিদ্ধান্ত নেবেন না।

প্রতিটি case agent-কে abuse ধরে না নিয়ে এবং প্রতিটি agent-কে অন্ধভাবে বিশ্বাস না করে actor-এর প্রতি সাড়া দেয়। এই ভারসাম্যই agent-aware access-এর মূল কথা, আর মানুষ ও AI agent-এর জন্য app policy ডিজাইন করা ব্লগ পোস্টে route by route আরও উদাহরণ রয়েছে।

পাঁচটি response

Proof of Actor-এর Route capability পাঁচটি response ঘিরে তৈরি, যেগুলোর মধ্যে আপনার policy বেছে নিতে পারে।

Allow

Request-টি স্বাভাবিকভাবে এগোতে দিন। বেশিরভাগ traffic, public বা low-risk route-এ বেশিরভাগ agent traffic-সহ, সহজেই allow করা উচিত।

Adapt

Actor-এর উপযোগী করে experience বদলান। human-shaped interface-এর বদলে verified agent-কে structured API response বা page-এর Markdown version দিন। AI agent-দের structured content পরিবেশন করা guide-এ এই pattern ব্যাখ্যা করা হয়েছে।

Challenge

আরও শক্তিশালী কিছু চাইুন: fresh login, অতিরিক্ত credential, account owner-এর কাছ থেকে confirmation। যেখানে ভুল decision-এর খরচ বেশি, সেই route-এ challenge ব্যবহার করুন।

Review

Action-টি সরাসরি completion-এ না পাঠিয়ে queue-তে যেতে দিন, বা human review-এর জন্য flag করুন। যেখানে block করলে legitimate user ক্ষতিগ্রস্ত হবে কিন্তু unattended completion খুব ঝুঁকিপূর্ণ, সেখানে review উপকারী।

Limit

Actor এবং route অনুযায়ী tuned একটি rate বা volume limit প্রয়োগ করুন, যাতে automated caller মানুষের জন্য তৈরি workflow-কে overwhelm করতে না পারে।

robots.txt কেন access policy নয়

অনেক team robots.txt দিয়ে শুরু করে, এবং crawler-এর জন্য এটি একটি যুক্তিসঙ্গত first signal। কিন্তু এটি agent-এর জন্য access policy নয়। Crawler operator-রা ভিন্ন user agent-এর জন্য ভিন্ন আচরণ নথিভুক্ত করে: Anthropic বলছে তাদের bot robots.txt directive মেনে চলে (Anthropic crawler documentation), আর OpenAI উল্লেখ করেছে যে ChatGPT-User-এর ক্ষেত্রে, যা ব্যবহারকারী ChatGPT-কে প্রশ্ন করলে কাজ করে, robots.txt rule প্রযোজ্য নাও হতে পারে কারণ action শুরু করেন ব্যবহারকারী (OpenAI crawler documentation). Robots.txt API, MCP tool বা signed-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 evaluate করে, তা চারটি অংশসহ একটি 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 description, logging এবং review-এর জন্য useful।
Context: কোন integration এবং কোন route এটি তৈরি করেছে।

Basis explicit হওয়ায় আপনার policy precise হতে পারে। "Allow agents" হয়ে যায় "read route-এ verified agent allow করুন, declared agent-কে rate-limit করুন, বাকি সবকিছুর জন্য Unknown fallback প্রয়োগ করুন।" Request থেকে decision পর্যন্ত পুরো flow How It Works-এ বর্ণিত।

Fallback policy-র অংশ

Evidence না থাকলে policy কীভাবে behavior করবে, সেটাই policy-র আসল মান। Proof of Actor সেই case-গুলোকে লুকিয়ে না রেখে explicit করে।

Unknown: evidence কোনো নির্ধারণকে সমর্থন করেনি। আপনার policy বলে দেয় প্রতিটি route-এ Unknown কী বোঝাবে। এটি কখনো Human-এ রূপান্তরিত হয় না এবং 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 হয়। Sensitive action-এ সাধারণত fail closed হয়। আপনি এটি risk tier অনুযায়ী সেট করেন, globally নয়।

Identity, credential এবং authorization আলাদা রাখুন

Agent access policy তিনটি আলাদা স্তরের উপর বসে, আর সেগুলোকে আলাদা রাখা সবচেয়ে ক্ষতিকর ভুলগুলো প্রতিরোধ করে।

Identity evidence উত্তর দেয় কোন ধরনের actor কল করছে এবং কী সেটি প্রমাণ করে। Proof of Actor এটি দেয়।
Credentials উত্তর দেয় কোন account দায়ী। আপনার session, token বা API key এটি দেয়।
Authorization উত্তর দেয় এই caller এই action করতে পারবে কি না। আপনার permission model এটি নির্ধারণ করে।

একটি verified agent identity মানে এই নয় যে agent authorized, কোনো মানুষ সেটিকে authority দিয়েছে, বা এর action safe। Routing এবং context-এর জন্য actor result ব্যবহার করুন। Permission দেওয়ার জন্য আপনার authorization model ব্যবহার করুন। Detection & Limitations পৃষ্ঠা ব্যাখ্যা করে প্রতিটি evidence কী প্রতিষ্ঠা করতে পারে।

কিছু ভাঙা ছাড়া rollout করুন

Agent access policy চালু করার সবচেয়ে নিরাপদ উপায় হলো ধাপে ধাপে এগোনো।

Observe. observation mode-এ Proof of Actor install করুন। ব্যবহারকারীদের জন্য কিছুই বদলাবে না; result record হবে।
Understand. কোন actor কোন route ব্যবহার করছে, প্রতিটিতে unknown rate কত, এবং আপনার জানা তথ্যের সঙ্গে না মেলা কোনো result আছে কি না, তা পর্যালোচনা করুন।
Preview. Policy-টি preview-তে চালান, enforce না করে এটি কী করত তা log করুন।
Enforce narrowly. একটি route-এ policy enable করুন যেখানে evidence স্পষ্টভাবে এটি সমর্থন করে। Outcome দেখুন।
Expand. Confidence বাড়ার সঙ্গে সঙ্গে আরও route-এ প্রসারিত করুন।

নিরাপদে actor-aware policy rollout করা guide প্রতিটি stage-এ পথ দেখায়, আর agent block না করে sensitive action সুরক্ষিত করা high-stakes route-গুলো কভার করে।

আপনার team কী পায়

Proof of Actor দিয়ে আপনার team এক integration-এ তিনটি capability পায়। Detect actor signal সংগ্রহ করে এবং verified assertion-কে inference থেকে আলাদা করে। Understand actor analytics, trend এবং প্রতিটি result-এর পেছনের evidence দেখায়, Unknown-কে দৃশ্যমান রেখেই। Route আপনাকে এই page-এ বর্ণিত policy লিখতে এবং যেখানে চান সেখানে প্রয়োগ করতে দেয়। Private beta চলাকালীন, routing policy প্রতিটি founding team-এর সঙ্গে নকশা করা হয় এবং আপনার নিজের application code-এ চলে, তাই আপনি পূর্ণ নিয়ন্ত্রণ রাখেন।

এড়িয়ে চলার সাধারণ policy ভুল

প্রথমবার agent access design করা team-রা কিছু নির্দিষ্ট ভুল বারবার করে। সেগুলো এড়ালে সপ্তাহের rework বাঁচে।

Default হিসেবে সব agent block করা। Legitimate agent তখন আপনার পাশ কাটিয়ে যায়, প্রায়ই আপনি মানুষের জন্য যে interface তৈরি করেছেন সেটি scraping করে, যা structured path-এর তুলনায় সুরক্ষিত করা কঠিন।
Declared name-কে বিশ্বাস করা। যে client শুধু নিজের নাম বলেছে, সে একটি claim করেছে, proof দেয়নি। unverified caller-কে আপনি যে treatment দিতেন, সেটাই দিন।
সর্বত্র এক fallback ব্যবহার করা। Public pricing page-এ Unknown এবং password change-এ Unknown এক বিষয় নয়। প্রতিটি route-এর নিজের উত্তর দরকার।
Inference থেকে মানুষের সম্পর্কে সিদ্ধান্ত নেওয়া। Actor result routing-এর জন্য context, ব্যক্তির উপর verdict নয়। Consequential decision-গুলো আপনার নিজস্ব control এবং review-এ রাখুন।
Observation বাদ দেওয়া। Day one-এ enforce করলে false positive আপনি customer complaint থেকে জানতে পারেন। আগে 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-এর মধ্যে up to 12 months-এর free access পেতে পারে, এবং আপনার প্রথম policy design করার সময় আমাদের engineer-দের সরাসরি support পাবে।

আপনার application AI agent-দের কীভাবে扱বে তা ঠিক করতে চাইলে, early access-এর জন্য apply করুন। কোন 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.

ডেভেলপারদের জন্য

What your code receives

Every interaction resolves to one result record. Your application reads the class and the basis and applies its own policy.

Result record

{
  "route": "GET /api/v1/catalog",
  "class": "agent",
  "basis": "verified",
  "evidence": [
    { "signal": "http_message_signature", "result": "valid", "keyid": "assistant.example" },
    { "signal": "client_declaration", "value": "assistant.example" }
  ],
  "observed_at": "2026-11-13T10:42:07Z"
}

class: Human, Human + AI, Agent বা Unknown।
basis: evidence কতটা শক্তিশালী: verified, declared, inferred বা unknown।
evidence: result-এর পেছনের signals, যাতে আপনার team কারণটি দেখতে পারে।

observation mode-এ শুরু করুন: results আপনার logs-এর পাশে record করুন এবং আপনি কোনো policy বেছে না নেওয়া পর্যন্ত কিছুই পরিবর্তন করবেন না। Node.js integration guide পড়ুন

প্রায়শই জিজ্ঞাসিত প্রশ্ন

AI agent access policy কী?

এটি এমন একটি নিয়ম যা আপনার application request করা actor-এর ধরন অনুযায়ী প্রয়োগ করে, যেমন read-only route-এ verified agent-কে allow করা বা উচ্চ-প্রভাবের action-এ আরও শক্তিশালী credential চাওয়া। Proof of Actor actor result দেয়; আপনার policy response নির্ধারণ করে।

Proof of Actor কি স্বয়ংক্রিয়ভাবে policy enforce করে?

না। প্রতিটি integration observation mode-এ শুরু হয়, এবং আপনার team route by route policy enable করে, যখন আপনি নিশ্চিত হন যে সেগুলো সেই workflow-র জন্য উপযুক্ত।

Actor যদি Unknown হয় বা check timeout হয়, তখন কী হয়?

আপনি প্রতিটি route-এর জন্য একটি explicit fallback নির্ধারণ করেন, উদাহরণস্বরূপ public read allow করা এবং account change-এ existing check বজায় রাখা। Unknown এবং timeout কখনো Human-এ default হয় না।

আমার কি সব AI agent block করা উচিত?

সাধারণত নয়। অনেক agent বৈধ অংশগ্রহণকারী। Policy আপনাকে তাদের জন্য একটি structured path দিতে, প্রয়োজনীয় জায়গায় limit করতে এবং sensitive action-এর জন্য আরও শক্তিশালী check সংরক্ষণ করতে দেয়।

Policy কি মানুষের সম্পর্কে সিদ্ধান্ত নিতে পারে?

Proof of Actor-এর ফলাফল employment, credit বা essential service-এ access-এর মতো ব্যক্তিগত consequential decision-এর একমাত্র ভিত্তি হওয়া উচিত নয়। এগুলো routing এবং context-এর জন্য ব্যবহার করুন, আপনার নিজস্ব control-এর পাশাপাশি।

কে আপনার app ব্যবহার করছে, তা জানুন।

Founding developer-এর একটি ছোট group-এর জন্য private beta।

প্রাথমিক access পান মূল্য দেখুন

আগে কথা বলতে চান? Founders-এর সঙ্গে কথা বলুন