AI এজেন্ট সনাক্তকরণ

API-এর জন্য AI এজেন্ট সনাক্তকরণ

আপনার API ইতিমধ্যেই জানে কোন key একটি request করেছে। Proof of Actor আপনাকে বলে, তার পেছনে কী ধরনের actor ছিল, সেই ফলাফলের ভিত্তি কী, এবং আপনার code-কে পরবর্তী পদক্ষেপ নির্ধারণ করতে দেয়.

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

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

আপনার API key জানে। actor জানে না.

প্রতিটি API request-এর সঙ্গে কে এর জন্য অর্থ দিচ্ছে তার কিছু প্রমাণ আসে: একটি API key, একটি OAuth token, একটি session। সেই প্রমাণ একটি প্রশ্ন ভালোভাবে উত্তর দেয়। এটি বলে দেয় কোন account call-এর জন্য দায়ী। কিন্তু এটি বলে না, এই মুহূর্তে আসলে callটি কে বা কী করছে।

একটি API key একদিকে terminal-এ পরীক্ষা করা একজন developer, scheduled job চালানো একটি backend কাজ, AI assistant-এর মাধ্যমে কাজ করা একজন মানুষ, এবং key হাতে পেয়ে কাজ শেষ করতে বলা একটি autonomous agent - সবাই ব্যবহার করতে পারে। এরা খুবই আলাদা actor। তাদের rhythm, failure mode এবং risk profile আলাদা। তাদের সবাইকে একইভাবে扱লে হয় আপনি আপনার customer নির্ভরশীল বৈধ automation অযথা সীমাবদ্ধ করবেন, নয়তো unattended agent দ্বারা চালিত হওয়া উচিত নয় এমন আপনার API-এর অংশগুলো যথেষ্ট সুরক্ষিত থাকবে না।

API-এর জন্য AI agent identification এই ফাঁকটি পূরণ করে। key থেকে সবকিছু infer করার বদলে, আপনি প্রতিটি request-এর পেছনের actor-এর একটি classification পান, সঙ্গে সেই classification সমর্থনকারী evidence। এটিই Proof of Actor দেওয়ার জন্য তৈরি, এবং APIs use case দেখায় API team-গুলো কীভাবে route অনুযায়ী এটি ব্যবহার করে।

এখন API team-গুলোর actor context কেন দরকার

API-তে automated traffic নতুন কিছু নয়। script, integration এবং crawler সবসময়ই এর অংশ ছিল। যেটা বদলেছে, তা হলো automation-এর ধরন। AI agent documentation পড়তে পারে, call chain তৈরি করতে পারে, creativeভাবে retry করতে পারে, এবং এমন মানুষের হয়ে কাজ করতে পারে যারা প্রতিটি ধাপ দেখছে না। তাদের অনেকেই উপকারী এবং স্বাগত। কিছু poorly built। কয়েকটি hostile।

actor context ছাড়া API team-গুলো সাধারণত blunt tool-এ ফিরে যায়:

প্রতি key অনুযায়ী rate limit, যা good agent এবং bad agent-কে একইভাবে ধীর করে।
user-agent rule, যা client header বদলালেই ভেঙে যায়।
সর্বজনীন block, যা বৈধ automation-কে আপনার web app scrape করতে ঠেলে দেয়।

actor context আপনাকে নির্ভুলভাবে প্রতিক্রিয়া জানাতে সাহায্য করে। আপনি যাকে চেনেন এমন operator-এর signed agent read route-এ বেশি limit পেতে পারে। write route-এ unknown caller-কে আরও শক্তিশালী credential দিতে হতে পারে। AI assistant ব্যবহার করা একজন human স্বাভাবিক অভিজ্ঞতা বজায় রাখতে পারে। উদ্দেশ্য agent-কে থামানো নয়। উদ্দেশ্য হলো প্রতিটি ধরনের caller-কে সঠিক path দেওয়া। signed request কী বলতে পারে আর কী পারে না, তা জানতে signed AI agent request কী প্রমাণ করে পড়ুন।

Proof of Actor-এ AI agent identification কীভাবে কাজ করে

Proof of Actor প্রতিটি request-এর জন্য একই evidence-first flow অনুসরণ করে। সম্পূর্ণ walkthrough আপনি How It Works-এ পড়তে পারেন; এখানে API team-গুলোর জন্য সংক্ষিপ্ত সংস্করণ।

1. আপনার integration থেকে signals

আপনার integration সেই context-এ উপলব্ধ signal-গুলো Proof of Actor-কে দেয়। একটি API-এর জন্য সাধারণত এর মানে request context যেমন header এবং protocol details, client যে কোনো cryptographic request signature দেয়, এবং client নিজের সম্পর্কে যে declaration করে। প্রতিটি signal-এর সঙ্গে এটি কোথা থেকে এসেছে তা চিহ্নিত থাকে।

2. ভিত্তিসহ classification

signal-গুলো পরীক্ষা করে একত্রে চারটি public class-এর একটিতে রাখা হয়:

Human: পর্যবেক্ষণযোগ্য signal-গুলো human-directed interaction নির্দেশ করে।
Human + AI: AI assistance ঘোষণা করা হয়েছে বা এমন একটি integration দ্বারা শনাক্ত হয়েছে যা তা পর্যবেক্ষণ করতে পারে।
Agent: স্বয়ংক্রিয় বা agent-origin traffic, যা verifiable identity বা carefully qualified inference দ্বারা সমর্থিত।
Unknown: evidence নির্ভরযোগ্য সিদ্ধান্তকে সমর্থন করে না।

প্রতিটি ফলাফলের সঙ্গে তার basis-ও থাকে: verified, declared, inferred বা unknown। API team-গুলোর কাছে এটিই সবচেয়ে মূল্যবান অংশ। একটি request যার HTTP message signature, RFC 9421-এ সংজ্ঞায়িত, published key-এর সঙ্গে validate হয়, তাকে verified বলা হয়। যে client কেবল নিজেকে agent বলে, তাকে declared বলা হয়। যে pattern automated বলে মনে হয়, সেটিকে inferred বলা হয়। কোনো ফলাফল cryptography-এর ওপর নাকি heuristic-এর ওপর নির্ভর করছে, তা নিয়ে আপনাকে কখনও দ্বিধায় পড়তে হবে না। evidence basis উত্তরেরই অংশ।

3. একটি ফলাফল যেটির ওপর আপনার code কাজ করতে পারে

ফলাফল class, basis এবং একটি readable evidence summary সহ আপনার application-এ ফিরে আসে। আপনার code ঠিক করে এতে কী করবে। observation mode-এ, আপনি কেবল এটি record করেন। প্রস্তুত হলে, আপনি এর ওপর route করেন।

আপনার team কী পায়: Detect, Understand, Route

Proof of Actor একটি product, যার তিনটি capability আছে।

Detect

আপনার API যে actor signal দেখতে পারে তা সংগ্রহ করুন এবং verified assertion-কে behavioral inference থেকে আলাদা করুন। signed agent request, declared client, automation signal এবং Unknown result সবই আলাদা রাখা হয়, যাতে কিছুই নীরবে একক score-এ মিশে না যায়।

Understand

কোন actor কোন route-এ call করে, সময়ের সঙ্গে তা কীভাবে বদলায়, এবং প্রতিটি classification-এর পেছনে কী evidence আছে তা দেখুন। unknown rate দৃশ্যমান থাকে, যা আপনাকে স্পষ্টভাবে জানায় আপনার coverage কোথায় শেষ হয় এবং কোথায় আরও শক্ত signal কাজে আসবে।

Route

প্রতি route এবং প্রতি risk tier অনুযায়ী policy লিখুন: allow, adapt, challenge, review বা rate-limit। read-only endpoint-এ verified agent-দের জন্য structured, generous path রাখুন। high-impact operation-এ আরও শক্তিশালী credential চাইুন। Unknown এবং timeout-এর জন্য একটি স্পষ্ট fallback নির্ধারণ করুন, যাতে আপনার API যাই ঘটুক পূর্বানুমেয়ভাবে আচরণ করে। প্রতিটি policy open নাকি closedভাবে fail করবে, তা আপনি সেই route-এ ভুলের খরচের ভিত্তিতে নির্ধারণ করেন।

Identity evidence, credential এবং authorization - তিনটি আলাদা জিনিস

agent-aware API design-এ সবচেয়ে সাধারণ ভুল হলো তিনটি আলাদা প্রশ্নকে একটিতে মিশিয়ে ফেলা। Proof of Actor এগুলোকে আলাদা রাখে, এবং আপনার design-ও রাখা উচিত।

Identity evidence: কোন ধরনের actor call করছে, এবং কী তা প্রমাণ করে? AI agent identification এটিই দেয়। একটি verified signature request-কে একটি key এবং তার published operator identifier-এর সঙ্গে যুক্ত করে। IETF-এর Web Bot Auth working group এই ধরনের automated client-এর জন্য cryptographic authentication standardize করতে chartered, এবং এর scope end user নয়, agent-কে authenticate করা।
Credential: এই call-এর জন্য কোন account দায়ী? এটি আপনার API key, token বা session, যা আপনি ইস্যু এবং পরিচালনা করেন।
Authorization: এই caller কি এই নির্দিষ্ট কাজটি করতে পারে? এটি আপনার permission model।

একটি verified agent স্বয়ংক্রিয়ভাবে authorized agent নয়। একটি valid signature প্রমাণ করে না যে কোনো মানুষ agent-কে authority অর্পণ করেছে, এবং এটি requested action-কে নিরাপদও করে না। Proof of Actor প্রথম প্রশ্নের জন্য আপনাকে বিশ্বাসযোগ্য context দেয় এবং দ্বিতীয় ও তৃতীয় প্রশ্নকে ঠিক যেখানে তাদের থাকা উচিত সেখানেই রাখে: আপনার application-এ। agent authorization-এ আরও পড়ুন এবং Detection & Limitations-এ evidence কী প্রমাণ করতে পারে আর পারে না, তা দেখুন।

Unknown একটি feature, failure নয়

request signing optional, এবং unsigned client নিজের পরিচয় নিজের মতো করে দিতে পারে। যে system প্রতিটি request-কে Human বা Agent-এ বাধ্য করে ফেলবে, সেটি কিছু সময়ে আত্মবিশ্বাসের সঙ্গে ভুল হবে, এবং আপনি কখন তা হবে তা জানবেন না।

প্রমাণ নির্ধারণকে সমর্থন না করলে Proof of Actor Unknown রিপোর্ট করে। Unknown কখনও Human-এ রূপান্তরিত হয় না এবং defaultভাবে কখনও malicious হিসেবে ধরা হয় না। আপনার policy route অনুযায়ী Unknown-এর অর্থ কী হবে তা নির্ধারণ করে: public read-এ allow করুন, account change-এ আপনার existing check রাখুন, stakes বেশি হলে review-এর জন্য queue করুন। Unknown-কে দৃশ্যমান রাখা-ই আপনার অন্য classification-গুলোকে বিশ্বাসযোগ্য করে। unknown traffic handling-এর guide দেখায় এটি কীভাবে design করতে হয়।

আপনার stack-এ AI agent identification কোথায় বসে

Proof of Actor আপনার existing gateway, authentication এবং rate limiting-এর পাশে বসে। এটি এদের কোনোটিকেই প্রতিস্থাপন করে না। সাধারণ placement-এর মধ্যে রয়েছে:

Server-side middleware আপনার route handler-এর সামনে, যাতে আপনার business logic চলার আগে প্রতিটি request মূল্যায়িত হয়।
edge-এ, যাতে request origin-এ পৌঁছানোর আগে signal মূল্যায়িত হয়।
একটি generic HTTP integration, যাতে যেকোনো stack request context পাঠাতে পারে এবং basis-সহ একটি result পেতে পারে।

Onboarding-এর সময় প্রতিটি founding team-এর সঙ্গে হাতে-কলমে integration দেওয়া হয়, যাতে পথটি আপনার architecture-এর সঙ্গে মানানসই হয়, উল্টোটা নয়। developer hub আজকের উপলব্ধ integration path দেখায়। আপনি যদি agent-এর জন্য tool চালান, তাহলে MCP Servers use case tool call-এর নির্দিষ্ট pattern কভার করে।

observation mode-এ শুরু করুন

Proof of Actor ইনস্টল করলে আপনার API কীভাবে respond করে তা বদলে যায় না। ফলাফল record করা হয়, যাতে আপনার team সেগুলোর সঙ্গে ইতিমধ্যেই জানা outcome তুলনা করতে পারে, agent-রা আসলে কোথায় যায় তা দেখতে পারে, প্রতিটি route-এ unknown rate মাপতে পারে, এবং ভুল মনে হওয়া যেকোনো classification পর্যালোচনা করতে পারে। এর পরে তবেই আপনি route অনুযায়ী policy সক্রিয় করেন, যেখানে evidence তা সমর্থন করে।

এইভাবেই আপনি customer-দের অবাক না করে বা তারা যে integration-এর ওপর নির্ভর করে তা ভেঙে না দিয়ে AI agent identification roll out করেন। actor-aware policy নিরাপদে roll out করা-এর guide ধাপে ধাপে sequence দেখায়।

founding developer program-এ যোগ দিন

Proof of Actor private beta-তে আছে, একটি ছোট founding development team-এর সঙ্গে। নির্বাচিত team-গুলো onboarding-এর সময় agreed usage limit-এর মধ্যে up to 12 months of free access পেতে পারে, সঙ্গে আমাদের engineer-দের সরাসরি integration support এবং আমরা পরবর্তীতে কী তৈরি করব সে বিষয়ে বাস্তব প্রভাব।

আপনি যদি একটি API পরিচালনা করেন এবং জানতে চান আসলে কে এটি call করছে, early access-এর জন্য apply করুন। আপনার API, সবচেয়ে গুরুত্বপূর্ণ route-গুলো, এবং actor context থাকলে আপনি কোন সিদ্ধান্তগুলো ভিন্নভাবে নিতেন তা আমাদের জানান। আমরা আপনাকে বলব Proof of Actor কীভাবে মানায়।

Source

RFC 9421: HTTP Message Signatures, IETF, February 2024.
Web Bot Auth (webbotauth) working group charter, IETF.

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

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 এজেন্ট সনাক্তকরণ API key authentication থেকে কীভাবে আলাদা?

একটি API key আপনাকে বলে কোন account request পাঠিয়েছে। AI agent identification আপনাকে বলে request-এর পেছনে কী ধরনের actor আছে এবং সেই সিদ্ধান্তের ভিত্তি কী। দুটোই দরকার, এবং তারা ভিন্ন প্রশ্নের উত্তর দেয়।

Proof of Actor কি আমার API-তে কল করা প্রতিটি AI এজেন্ট শনাক্ত করতে পারে?

Proof of Actor যে প্রতিটি request দেখে, সেটিকে Human, Human + AI, Agent বা Unknown হিসেবে শ্রেণিবদ্ধ করে, এবং প্রতিটি ফলাফলের ভিত্তি জানায়। প্রমাণ যথেষ্ট শক্তিশালী না হলে, ফলাফল অনুমানের বদলে Unknown হয়।

কোনো agent-কে শনাক্ত করা মানে কি সেটি কাজ করার অনুমতি পেয়েছে?

না। সনাক্তকরণ এবং authorization আলাদা। Proof of Actor আপনার application-কে কলার সম্পর্কে context দেয়, এবং আপনার নিজের authorization rule নির্ধারণ করে সেই কলার কী করতে পারে।

Proof of Actor কি আমার API-তে request block করবে?

আপনি তা চাইলে তবেই। প্রতিটি integration observation mode-এ শুরু হয়, এবং enforcement কেবল তখনই হয় যখন আপনার team policy লিখে সক্রিয় করে।

আমি কীভাবে access পাব?

Proof of Actor private beta-তে আছে। early access-এর জন্য apply করুন, এবং নির্বাচিত founding developer team-গুলো agreed usage limit-এর মধ্যে up to 12 months free পেতে পারে।

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

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

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

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