মুখ্য সামগ্ৰীৰ পৰা এৰাই চাওক
AI এজেণ্ট চিনাক্তকৰণ

API ৰ বাবে AI এজেণ্ট চিনাক্তকৰণ

আপোনাৰ API-এ ইতিমধ্যে জানে কোন key এ request কৰিছে। Proof of Actor এ আপোনাক কয় তাৰ পিছত কোন ধৰণৰ actor আছিল, সেই ফলক সমৰ্থন কৰা প্ৰমাণ কি, আৰু কি হ'ব সেয়া আপোনাৰ code-এ নিৰ্ধাৰণ কৰিবলৈ দিয়ে।

Early Access লওকই কেনেকৈ কাম কৰে অন্বেষণ কৰক
Toshendra Sharma

দ্বাৰা 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, সময়সূচী অনুসৰি চলা backend job, AI assistant ৰ সৈতে কাম কৰা ব্যক্তি, আৰু এটা autonomous agent যাক key দি এটা task শেষ কৰিবলৈ কোৱা হৈছে, এই সকলোৰে দ্বাৰা ব্যৱহাৰ হ'ব পাৰে। এইবোৰ বহুত পৃথক actor। সিহঁতৰ rhythm, failure mode আৰু risk profile বেলেগ। সিহঁতক একে ধৰণে treat কৰিলে হয় আপুনি আপোনাৰ customer এ ভৰসা কৰা legitimate automation অতিমাত্ৰা সীমিত কৰে, নহয় আপোনাৰ API ৰ সেই অংশবোৰ যথেষ্ট সুৰক্ষিত নকৰে যিবোৰ কেতিয়াও unattended agent দ্বাৰা চালিত হোৱা উচিত নহয়।

API ৰ বাবে AI agent identification এ সেই gap বন্ধ কৰে। key ৰ পৰা সকলো infer কৰাৰ পৰিৱৰ্তে, আপুনি প্ৰতিটো request ৰ পিছৰ actor ৰ এটা classification পায়, লগতে সেই classification ক সমৰ্থন কৰা প্ৰমাণো পায়। সেইটোৱেই Proof of Actor ডেলিভাৰ কৰিবলৈ নিৰ্মিত, আৰু APIs use case এ দেখুৱায় API teams এ route by route কেনেকৈ ইয়াক apply কৰে।

API teams ক এতিয়া actor context কিয় লাগে

API লৈ automated traffic নতুন নহয়। script, integration আৰু crawler সদায়েই এই ছবিাৰ অংশ আছিল। যি সলনি হৈছে সেয়া automation ৰ ধৰণ। AI agent এ documentation পঢ়িব পাৰে, call একেলগে chain কৰিব পাৰে, creatively retry কৰিব পাৰে আৰু তেওঁলোকক নাচাই থকা মানুহৰ হৈ act কৰিব পাৰে। সিহঁতৰ বহুতেই উপযোগী আৰু স্বাগতম। কিছুমান দুর্বলকৈ নিৰ্মিত। কেইটামান hostile।

Actor context নাথাকিলে API teams সাধাৰণতে blunt tools লৈ উভতি যায়:

  • প্ৰতি key ত rate limit, যিয়ে ভাল agent আৰু বেয়া agent দুয়োটাক সমানে ধীৰ কৰে।
  • User-agent rules, যিবোৰ client এ header সলনি কৰাৰ লগে লগে ভাঙি যায়।
  • সৰ্বজনীন block, যিয়ে legitimate automation ক আপোনাৰ web app scrape কৰিবলৈ ঠেলি দিয়ে।

Actor context এ আপোনাক সূক্ষ্মভাৱে respond কৰিবলৈ দিয়ে। আপুনি চিনা operator ৰ পৰা অহা signed agent ক read route ত অধিক limit দিব পাৰে। write route ত unknown caller ক অধিক শক্তিশালী credential বিচৰা হ'ব পাৰে। AI assistant ব্যৱহাৰ কৰা মানুহে স্বাভাৱিক অভিজ্ঞতা পাই থাকিব পাৰে। উদ্দেশ্য agent ৰোধ কৰা নহয়। উদ্দেশ্য প্ৰতিটো caller ক উপযুক্ত পথ দিয়া। signed request এ কি ক'ব পাৰে আৰু কি নোৱাৰে, সেই বিষয়ে signed AI agent requests প্ৰমাণ কৰে কি পঢ়ক।

Proof of Actor ত AI agent identification কেনেকৈ কাম কৰে

Proof of Actor এ প্ৰতিটো request ৰ বাবে একে evidence-first flow অনুসৰণ কৰে। How It Works ত সম্পূৰ্ণ walkthrough পঢ়িব পাৰে; API teams ৰ বাবে ইয়াত চুটি সংস্কৰণ দিয়া হৈছে।

1. আপোনাৰ integration ৰ পৰা signals

আপোনাৰ integration এ সেই context ত উপলব্ধ Proof of Actor ৰ signals pass কৰে। এটা API ৰ বাবে সাধাৰণতে ইয়াত request context যেনে headers আৰু protocol details, client এ দিয়া যিকোনো cryptographic request signature, আৰু client এ নিজৰ বিষয়ে কৰা যিকোনো declaration অন্তৰ্ভুক্ত থাকে। প্ৰতিটো signal ক সেয়া ক'ৰ পৰা আহিছে সেই অনুসৰি label কৰা হয়।

2. এটা basis ৰ সৈতে classification

signals পৰীক্ষা কৰি একেলগে মিলাই public class চাৰিটাৰ এটালৈ লৈ যোৱা হয়:

  • Human: দৃশ্যমান signals এ human-directed interaction সূচায়।
  • Human + AI: AI assistance declare কৰা হৈছে বা ইয়াক observe কৰিব পৰা integration এ detect কৰিছে।
  • Agent: automate কৰা বা agent-origin traffic, verifiable identity বা সতর্কভাৱে qualified inference ৰ দ্বাৰা সমৰ্থিত।
  • Unknown: প্ৰমাণে নিৰ্ভৰযোগ্য সিদ্ধান্ত সমৰ্থন নকৰে।

প্ৰতিটো ফলৰ সৈতে তাৰ basis থাকে: verified, declared, inferred বা unknown। এয়াই সেই অংশ যাক API teams এ আটাইতকৈ মূল্য দিয়ে। HTTP message signature যি RFC 9421 ত সংজ্ঞায়িত, published key ৰ সৈতে validate হ'লে verified হিচাপে report হয়। এটা client এ নিজকে কেৱল agent বুলি নাম দিলে declared হিচাপে report হয়। automated যেন লাগা pattern inferred হিচাপে report হয়। ফলটো cryptography ত নে heuristic ত ভিত্তি কৰিছে সেয়া ভাবি থাকিব নালাগে। evidence basis উত্তৰৰ অংশ।

3. আপোনাৰ code এ ব্যৱহাৰ কৰিব পৰা ফল

ফলটো class, basis আৰু এটা readable evidence summary সহ আপোনাৰ application লৈ উভতি আহে। আপোনাৰ code এ ইয়াৰ সৈতে কি কৰিব সেয়া নিৰ্ধাৰণ কৰে। observation mode ত, আপুনি ইয়াক কেৱল record কৰে। আপুনি ready হ'লে, ইয়াৰ ওপৰত route কৰে।

আপোনাৰ team এ কি পায়: Detect, Understand, Route

Proof of Actor এটা product, তিনিটা capability ৰ সৈতে।

Detect

আপোনাৰ API এ দেখা actor signals সংগ্ৰহ কৰক আৰু verified assertions ক behavioural inferences ৰ পৰা পৃথক কৰক। signed agent request, declared client, automation signals আৰু Unknown ফল সকলো পৃথককৈ ৰখা হয়, যাতে একোৱেই নীৰৱে একেটা score ত মিলি নাযায়।

Understand

কোন actor এ কোন route কল কৰে, সেইটো সময়ৰ সৈতে কেনেকৈ সলনি হয়, আৰু প্ৰতিটো classification ৰ পিছত কোন প্ৰমাণ থাকে সেয়া দেখক। unknown rate দৃশ্যমান থাকে, যিয়ে আপোনাক স্পষ্টকৈ কয় coverage ক'ত শেষ হয় আৰু ক'ত অধিক শক্তিশালী signal সহায় কৰিব।

Route

প্ৰতিটো route আৰু প্ৰতিটো risk tier ৰ বাবে policies লিখক: allow, adapt, challenge, review বা rate-limit। read-only endpoint ত verified agent ৰ বাবে structured, generous path ৰাখক। উচ্চ-impact operation ত অধিক শক্তিশালী credential বিচাৰক। Unknown আৰু timeout ৰ বাবে এটা explicit fallback সংজ্ঞায়িত কৰক, যাতে যি-কি নহওক আপোনাৰ API predictable থাকে। আপুনি প্ৰতিটো policy open নে closed কেনেকৈ fail কৰিব সেয়া নিৰ্ধাৰণ কৰে, সেই route ত ভুলৰ খৰচৰ ওপৰত ভিত্তি কৰি।

Identity evidence, credentials আৰু authorization তিনিটা পৃথক কথা

agent-aware API design ত আটাইতকৈ সাধাৰণ ভুল হ'ল তিনিটা পৃথক প্ৰশ্নক এটা কৰি পেলোৱা। Proof of Actor এ সিহঁতক পৃথক কৰি ৰাখে, আৰু আপোনাৰ design এও তেনে কৰা উচিত।

  1. Identity evidence: কোন ধৰণৰ actor কল কৰিছে, আৰু কি তাৰ প্ৰমাণ? এয়াই AI agent identification এ দিয়ে। এটা verified signature এ request ক key আৰু তাৰ published operator identifier ৰ সৈতে associate কৰে। IETF Web Bot Auth working group autonomous client ৰ বাবে এই ধৰণৰ cryptographic authentication standardize কৰিবলৈ charter কৰা হৈছে, আৰু ইয়াৰ scope ত end user নহয়, agent ক authenticate কৰা অন্তৰ্ভুক্ত।
  2. Credentials: এই call ৰ বাবে কোন account দায়ী? এয়াই আপোনাৰ API key, token বা session, যি আপুনি issue আৰু manage কৰে।
  3. Authorization: এই caller ক এই নিৰ্দিষ্ট কাম কৰিবলৈ অনুমতি আছে নে? এয়াই আপোনাৰ permission model।

এটা verified agent স্বয়ংক্ৰিয়ভাৱে authorized agent নহয়। valid signature এ কোনো ব্যক্তি agent ক authority delegate কৰিছিল বুলি প্ৰমাণ নকৰে, আৰু ই requested action সুৰক্ষিত কৰে বুলিও প্ৰমাণ নকৰে। Proof of Actor এ প্ৰথম প্ৰশ্নৰ বাবে বিশ্বাসযোগ্য context দিয়ে আৰু দ্বিতীয় আৰু তৃতীয়ক ঠিক সিহঁতৰ স্থানত এৰি দিয়ে: আপোনাৰ application ত। agent authorization আৰু প্ৰমাণে কি কৰিব পাৰে আৰু কি নোৱাৰে সেই বিষয়ে Detection & Limitations ত অধিক পঢ়ক।

Unknown এটা feature, failure নহয়

Request signing ঐচ্ছিক, আৰু unsigned client এ নিজকে যেনেকৈ ভাল পায় তেনেকৈ বৰ্ণনা কৰিব পাৰে। প্ৰতি request ক Human বা Agent ত বাধ্য কৰোৱা এটা system কিছুমান সময়ত নিশ্চিতভাৱে ভুল হ'ব, আৰু কেতিয়া সেইটো হৈছে আপুনি নাজানিব।

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

AI agent identification আপোনাৰ stack ত ক'ত উপযুক্ত

Proof of Actor আপোনাৰ বৰ্তমান gateway, authentication আৰু rate limiting ৰ কাষত থাকে। ই সিহঁতৰ কোনোটোকেই replace নকৰে। সাধাৰণ placement সমূহৰ ভিতৰত আছে:

  • Server-side middleware আপোনাৰ route handler ৰ আগত, যাতে প্ৰতিটো request আপোনাৰ business logic চলাৰ আগতে evaluate হয়।
  • At the edge, যাতে request আপোনাৰ origin ত পোৱাৰ আগতেই signals evaluate হয়।
  • A generic HTTP integration, যাতে যিকোনো stack এ request context পঠিয়াই basis সহ এটা result receive কৰিব পাৰে।

Onboarding ৰ সময়ত প্ৰতিটো founding team ৰ সৈতে হাতে-কলমে integration দিয়া হয়, যাতে path আপোনাৰ architecture ৰ সৈতে মিলে, উল্টা নহয়। developer hub এ আজিৰ উপলব্ধ integration path দেখুৱায়। যদি আপুনি agent ৰ বাবে tools চলায়, MCP Servers use case ত tool call ৰ বাবে নিৰ্দিষ্ট pattern অন্তৰ্ভুক্ত আছে।

observation mode ত আৰম্ভ কৰক

Proof of Actor install কৰিলেও আপোনাৰ API এ কেনেকৈ respond কৰে সেয়া সলনি নহয়। ফল record কৰা হয় যাতে আপোনাৰ team এ ইতিমধ্যে জনা outcome ৰ সৈতে সিহঁত তুলনা কৰিব পাৰে, actor সঁচাকৈ ক'ত যায় সেয়া দেখিব পাৰে, প্ৰতিটো route ত unknown rate measure কৰিব পাৰে, আৰু ভুল যেন লাগা যিকোনো classification review কৰিব পাৰে। তাৰ পাছতহে আপুনি evidence সমৰ্থন কৰা route by route policy enable কৰে।

এইটো হ'ল কেনেকৈ আপুনি AI agent identification customer ক আচৰিত নকৰাকৈ বা তেওঁলোকে ভৰসা কৰা integration ভাঙি নেপেলাই rollout কৰে। actor-aware policies safely roll out কৰা guide এ sequence step by step দেখুৱায়।

founding developer program ত যোগ দিয়ক

Proof of Actor private beta ত আছে, founding development teams ৰ এটা সৰু group ৰ সৈতে। বাছনি কৰা teams এ up to 12 months free access পাব পাৰে, onboarding ৰ সময়ত agreed usage limits ৰ ভিতৰত, লগতে আমাৰ engineer ৰ পৰা direct integration support আৰু আমি আগলৈ কি নিৰ্মাণ কৰো তাৰ ওপৰত বাস্তৱ influence।

আপুনি যদি এটা API operate কৰে আৰু সঁচাকৈ কোনে ইয়াক call কৰিছে জানিব বিচাৰে, early access ৰ বাবে apply কৰক. আপোনাৰ API, আপুনি আটাইতকৈ গুৰুত্ব দিয়া route, আৰু actor context থাকিলে আপুনি ভিন্নভাৱে ল'ব পৰা সিদ্ধান্তসমূহৰ বিষয়ে আমাক কওক। আমি Proof of Actor কেনেকৈ fit হয় সেয়া ক'ম।

Sources

ডেভেলপারসকলৰ বাবে

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
প্ৰমাণ কিমান শক্তিশালী: verified, declared, inferred বা unknown।
evidence
ফলাফলৰ পিছৰ signal, যাতে আপোনাৰ দলক কাৰণ দেখা যায়।

observation mode-ত আৰম্ভ কৰক: আপোনাৰ log-ৰ কাষে ফলাফল record কৰক আৰু আপুনি policy বাছি নলৈকে একো সলনি নকৰিব। Node.js integration guide পঢ়ক

সঘনাই সোধা প্ৰশ্নসমূহ

API key authentication ৰ তুলনাত AI agent identification কেনেকৈ পৃথক?

এটা API key এ আপোনাক কোন account এ request পঠাইছে সেয়া কয়। AI agent identification এ আপোনাক কয় request ৰ পিছত কোন ধৰণৰ actor আছে আৰু সেই সিদ্ধান্তক কোন প্ৰমাণে সমৰ্থন কৰে। আপোনাক দুয়োটাই লাগে, আৰু সিহঁতে ভিন্ন প্ৰশ্নৰ উত্তৰ দিয়ে।

Proof of Actor এ মোৰ API কল কৰা প্ৰতিটো AI agent চিনাক্ত কৰিব পাৰিবনে?

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

এটা agent চিনাক্ত কৰাত মানে কি সেয়া কাৰ্য্য কৰিবলৈ অনুমোদিত?

নহয়। চিনাক্তকৰণ আৰু অনুমোদন পৃথক। Proof of Actor এ আপোনাৰ application ক caller ৰ বিষয়ে context দিয়ে, আৰু আপোনাৰ নিজৰ authorization rules এ সেই caller কি কৰিব পাৰে সেয়া নিৰ্ধাৰণ কৰে।

Proof of Actor এ মোৰ API ৰ request ব্লক কৰিবনে?

আপুনি তেনে হ'ব বুলি সিদ্ধান্ত নোলোৱা পৰ্যন্ত নহয়। প্ৰতিটো integration observation mode ত আৰম্ভ হয়, আৰু enforcement কেৱল আপোনাৰ team এ লিখা আৰু enable কৰা policies ৰ জৰিয়তে হয়।

মই access কেনেকৈ পাম?

Proof of Actor private beta ত আছে। early access ৰ বাবে apply কৰক আৰু বাছনি কৰা founding developer teams এ agreed usage limits ৰ ভিতৰত up to 12 months free পাব পাৰে।

আপোনাৰ app ক কোনে ব্যৱহাৰ কৰিছে জানক।

এটা সৰু founding developer দলৰ বাবে private beta।

Early Access লওকমূল্য তালিকা চাওক

আগতে কথা পাতিবলৈ পচন্দ কৰেনে? Founding team-ৰ সৈতে কথা পাতক