মুখ্য সামগ্ৰীৰ পৰা এৰাই চাওক
সত্যায়িত স্বয়ংক্ৰিয়তা

সত্যায়িত স্বয়ংক্রিয় অনুৰোধ চিনাক্ত কৰক

যেতিয়া কোনো স্বয়ংক্ৰিয় ক্লায়েণ্টে নিজৰ অনুৰোধসমূহ স্বাক্ষৰ কৰে, আপোনাৰ application-এ সেই স্বাক্ষৰ যাচাই কৰি কলাৰক সেই অনুসৰি আচৰণ কৰিব পাৰে। Proof of Actor-এ সেই যাচাইক এটা স্পষ্ট, ৰুট কৰিব পৰা ফলাফললৈ ৰূপান্তৰ কৰে।

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

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

সকলো স্বয়ংক্ৰিয় traffic একে নহয়

স্বয়ংক্ৰিয় ক্লায়েণ্টে প্ৰতিটো মিনিটতে আপোনাৰ application-ত আহে: search crawler, monitoring tool, partner integration, user-ৰ বাবে page fetch কৰা AI সহায়ক, আৰু task সম্পন্ন কৰা autonomous agent। বছৰ বছৰ ধৰি, বেছিভাগ application-এ সিহঁতক পৃথক কৰাৰ একমাত্ৰ উপায় আছিল user-agent header, এটা string যি যিকোনো ক্লায়েণ্টে যিকোনো মানেৰে set কৰিব পাৰে।

ইয়াৰ ফলত application দলসমূহ অসুবিধাত পৰে। সকলো automation-ক সন্দেহৰ দৃষ্টিৰে চালে legitimate agent-ৰ অভিজ্ঞতা ক্ষতিগ্ৰস্ত হয়, যিবোৰৰ ওপৰত আপোনাৰ customer-সকলে নিৰ্ভৰ কৰে। Header-টোক বিশ্বাস কৰিলে যিকোনো লোকে নিজকে কোনো well-known crawler বুলি দাবী কৰিব পাৰে।

সত্যায়িত স্বয়ংক্রিয় অনুৰোধে এই সমীকৰণ সলনি কৰে। যেতিয়া কোনো স্বয়ংক্ৰিয় ক্লায়েণ্টে নিজৰ প্ৰকাশিত key-ৰে অনুৰোধসমূহ স্বাক্ষৰ কৰে, আপোনাৰ application-এ স্বাক্ষৰটো যাচাই কৰি ক্ৰিপ্টোগ্ৰাফিকভাৱে জানিব পাৰে কোন ক্লায়েণ্টে অনুৰোধটো স্বাক্ষৰ কৰিছে। Proof of Actor-এ সেই যাচাইক আপোনাৰ code ৰুট কৰিব পৰা এটা একক, সামঞ্জস্যপূৰ্ণ actor ফলাফলৰ অংশ কৰি তোলে। সেই যাচাইয়ে ঠিক কি প্ৰতিষ্ঠা কৰে আৰু কি নকৰে, সেই বিষয়ে অধিক জানিবলৈ signed AI agent requests কি প্ৰমাণ কৰে পঢ়ক।

অনুৰোধ স্বাক্ষৰণ কেনেকৈ কাম কৰে

স্বয়ংক্ৰিয় traffic-ৰ বাবে উদীয়মান approach-টোৱে HTTP message signatures ব্যৱহাৰ কৰে, যাক RFC 9421-ত standardize কৰা হৈছে, যিয়ে এটা HTTP message-ৰ components-ৰ ওপৰত signature সৃষ্টি, encode আৰু verify কৰাৰ নিয়ম সংজ্ঞায়িত কৰে। ক্লায়েণ্টে প্ৰতিটো অনুৰোধৰ নিৰ্বাচিত অংশ এটা private key-ৰে স্বাক্ষৰ কৰে আৰু header-সমূহত signature আৰু তাৰ parameter অন্তৰ্ভুক্ত কৰে। ই এটা control কৰা identifier-ৰ সৈতে সংযুক্ত স্থানত, সাধাৰণতে তাৰ domain-ত, সংশ্লিষ্ট public key প্ৰকাশ কৰে।

যেতিয়া অনুৰোধটো আহে, receiver-এ প্ৰকাশিত key আনিব বা lookup কৰিব, স্বাক্ষৰিত content পুনৰ গঠন কৰিব, আৰু স্বাক্ষৰটো যাচাই কৰিব। যদি ই validate কৰে, তেন্তে অনুৰোধটো সেই key-ৰ holder-এ স্বাক্ষৰ কৰিছিল। স্বয়ংক্ৰিয় traffic স্বাক্ষৰকৰণৰ ওপৰত কাম IETF Web Bot Auth working group-ত চলি আছে, যাৰ charter-এ crawler আৰু end user-ৰ হৈ কাম কৰা AI agent-ৰ দৰে স্বয়ংক্ৰিয় ক্লায়েণ্টক ক্ৰিপ্টোগ্ৰাফিকভাৱে authenticate কৰাক অন্তৰ্ভুক্ত কৰে; Web Bot Auth glossary entry-এ ইয়াৰ সংক্ষিপ্ত বিৱৰণ দিয়ে। signed AI agent requests কি প্ৰমাণ কৰে blog post-এ এটা verified অনুৰোধ end to end দেখুৱায়, আৰু APIs use case-এ verification ক’ত প্ৰথমে লাভজনক হয় সেয়া দেখুৱায়।

signed agent requests যাচাই কৰাৰ guide-এ mechanics বিশদভাৱে সামৰি লয়, timestamp, replay window আৰু key caching অন্তৰ্ভুক্ত কৰি।

সত্যায়িত স্বাক্ষৰে কি প্ৰমাণ কৰে, আৰু কি নকৰে

সত্যায়িত স্বয়ংক্রিয় অনুৰোধৰ সঠিক handling-ৰ আটাইতকৈ গুৰুত্বপূৰ্ণ অংশ এয়াই।

এটা বৈধ স্বাক্ষৰে প্ৰমাণ কৰে যে অনুৰোধটো প্ৰকাশিত identifier-ৰ সৈতে সংযুক্ত এটা key-ৰে স্বাক্ষৰ কৰা হৈছিল। যদি key-টো কোনো operator-ৰ domain-ৰ হয়, তেন্তে অনুৰোধটো সেই operator-ৰ key ধৰি থকা ক্লায়েণ্টৰ পৰা আহিছিল।

এটা বৈধ স্বাক্ষৰে প্ৰমাণ নকৰে:

  • কাক agent-টোক নিৰ্দেশ দিয়া হৈছিল, বা কোনো ব্যক্তিয়ে এই action-টো বিচাৰিছিল নে নাই;
  • কোনো ব্যক্তিয়ে agent-টোক authority delegate কৰিছিল নে নাই;
  • operator-ৰ পিছে থকা বাস্তৱ জগতৰ আইনী পৰিচয়;
  • অনুৰোধ কৰা action-টো আপোনাৰ application-ত নিৰাপদ বা অনুমোদিত নেকি।

এইবোৰ পৃথক প্ৰশ্ন। আপোনাৰ application-এ নিজৰ credentials, authorization model আৰু policy-ৰে এইবোৰৰ উত্তৰ দিয়ে। Proof of Actor-এ ইচ্ছাকৃতভাৱে এইবোৰ পৃথক ৰাখে, আৰু Detection & Limitations পৃষ্ঠাই প্ৰতিটো evidence-ৰ ধৰণে ঠিক কি প্ৰতিষ্ঠা কৰিব পাৰে সেয়া স্পষ্টকৈ বৰ্ণনা কৰে।

Proof of Actor-এ সত্যায়িত স্বয়ংক্রিয় অনুৰোধ কেনেকৈ হেণ্ডল কৰে

Detect

আপোনাৰ integration-এ অনুৰোধ context, signature header-সহ, Proof of Actor-লৈ পঠিয়ায়। Signature-সমূহ প্ৰকাশিত key-ৰ বিপৰীতে যাচাই কৰা হয়। যিবোৰ অনুৰোধ validate কৰে সেয়া verified basis-ৰে record কৰা হয়। কেৱল নিজৰ নাম দিয়া client-সকল declared হিচাপে record কৰা হয়। আচৰণগত pattern-সমূহ inferred হিচাপে record কৰা হয়। যথেষ্ট তথ্য নাথাকিলে ফলাফল Unknown হয়। ক্ৰিপ্টোগ্ৰাফিক যাচাই পাৰ হ’লে বাদে একোকে verified-লৈ উন্নীত কৰা নহয়।

Understand

কোন verified operator-সকলে আপোনাৰ application কল কৰে, সিহঁতে কোন route ব্যৱহাৰ কৰে, কিমান সঘনাই কৰে, আৰু সেয়া declared আৰু unknown automation-ৰ সৈতে কেনে তুলনীয় সেয়া দেখক। প্ৰতিটো ফলাফলত থকা evidence summary-এ আপোনাক কোন key আৰু identifier জড়িত আছিল সেয়া কয়, যাতে আপোনাৰ দলৰ বাবে যিকোনো অনুৰোধ দ্ৰুত অনুসন্ধান কৰিব পৰা যায়।

Route

আপোনাৰ policy-ত ভিত্তি ব্যৱহাৰ কৰক। সাধাৰণ pattern-সমূহত অন্তৰ্ভুক্ত:

  • read-only route, যেনে API বা page-ৰ Markdown সংস্কৰণ, ত verified agent-লৈ এটা গঠিত response দিয়ক।
  • চিনাক্ত কৰা verified operator-সকলৰ বাবে rate limit বৃদ্ধি কৰক, কিন্তু declared client-ৰ বাবে standard limit ৰাখক।
  • স্বাক্ষৰ যিয়েই কওক, প্ৰতিটো write route-ত আপোনাৰ বিদ্যমান authorization অক্ষুণ্ণ ৰাখক।
  • প্ৰতিটো route-ত unsigned আৰু Unknown caller-ৰ বাবে এটা স্পষ্ট fallback সংজ্ঞায়িত কৰক।

আপোনাৰ policy-সমূহেই সিদ্ধান্ত লয়; Proof of Actor-এ evidence যোগান ধৰে।

user-agent header কিয় যথেষ্ট নহয়

user-agent string-সমূহ declaration। যিকোনো client-এ যিকোনো value পঠিয়াব পাৰে, আৰু user-agent spoofing-ৰ বাবে কোনো দক্ষতাৰ প্ৰয়োজন নাই। সেইবাবে crawler operator-সকলে নিজৰ নিজস্ব check প্ৰকাশ কৰে: Google-এ verifying Googlebot-ৰ বাবে reverse আৰু forward DNS lookup আৰু প্ৰকাশিত IP range নথিভুক্ত কৰিছে, Bing-এ verifying Bingbot-ৰ বাবে DNS check নথিভুক্ত কৰিছে, আৰু OpenAI-এ নিজৰ crawlers and user agents-ৰ বাবে IP range file প্ৰকাশ কৰিছে। Proof of Actor-এ user-agent দাবীক declared evidence হিচাপে গণ্য কৰে, কেতিয়াও verification হিচাপে নহয়। ইয়াৰ অৰ্থ হৈছে যে কোনো বৈধ স্বাক্ষৰ নথকা কোনো well-known crawler বুলি দাবী কৰা client-এ declared বা inferred basis-ৰে report কৰা হয়, আৰু আপোনাৰ policy-এ ইয়াক নিজৰ পৰিচয় প্ৰমাণ কৰা client-ৰ পৰা পৃথকে গণ্য কৰিব পাৰে।

এইটোৱে সত্যায়িত স্বয়ংক্রিয় অনুৰোধক মূল্যৱান কৰি তোলে: ইয়াৰ দ্বাৰা যিসকলে বিশ্বাস উপাৰ্জন কৰে, সেই client-সকললৈ বিশ্বাস বিস্তাৰ কৰাৰ এটা নিৰ্ভৰযোগ্য উপায় পোৱা যায়, header copy কৰা সকলোৰে মাজত সেই বিশ্বাস বিস্তাৰ নকৰাকৈ।

পৰিচয় evidence, credentials আৰু authorization

স্বয়ংক্ৰিয় client-সকলক সেৱা দিয়া যিকোনো application-ত তিনিটা স্তৰ একেলগে কাম কৰে:

  1. পৰিচয় evidence: এই অনুৰোধটো কোন client-এ স্বাক্ষৰ কৰিলে? এটা verified স্বাক্ষৰে এই প্ৰশ্নৰ উত্তৰ দিয়ে।
  2. Credentials: কোন account দায়ী? আপোনাৰ API key, token বা session-এ এই প্ৰশ্নৰ উত্তৰ দিয়ে।
  3. Authorization: এই caller-এ এই কাম কৰিব পাৰিবনে? আপোনাৰ permission model-এ এই প্ৰশ্নৰ উত্তৰ দিয়ে।

Proof of Actor-এ প্ৰথম স্তৰ শক্তিশালী কৰে আৰু দৃশ্যমান কৰে। ই পৰিচয় বা delegation credential জাৰি নকৰে, আৰু আপোনাৰ authorization-ৰ স্থানও নলয়। স্তৰসমূহ পৃথক ৰাখাই হৈছে যিয়ে আপোনাক low-risk route-ত verified agent-ৰ সৈতে উদাৰ আৰু high-impact route-ত সাৱধান হ’বলৈ সক্ষম কৰে।

ই ক’ত খাপ খায়

Proof of Actor আপোনাৰ gateway, authentication আৰু rate limiting-ৰ কাষত থাকে। Integration-সমূহ server-side middleware হিচাপে, edge-ত, আপোনাৰ MCP server-ত বা generic HTTP integration-ৰ জৰিয়তে চলে, আৰু প্ৰতিটো founding দলৰ সৈতে হাতে-হাতে প্ৰদান কৰা হয়। যদি আপোনাৰ traffic বেছিভাগে APIs আৰু tools হয়, APIs আৰু MCP Servers use case-সমূহে আটাইতকৈ গুৰুত্বপূৰ্ণ pattern-সমূহ দেখুৱায়।

observation mode-ত আৰম্ভ কৰক

প্ৰতিটো integration observation mode-ত আৰম্ভ হয়। Application-এ কেনেকৈ respond কৰে সেয়া সলনি নকৰাকৈ ফলাফল record কৰা হয়, যাতে আপোনাৰ স্বয়ংক্ৰিয় traffic-ৰ কিমান অংশ verified, কোন operator-সকলে স্বাক্ষৰ কৰি আছে, আৰু unknown rate ক’ত সৰ্বোচ্চ সেয়া আপুনি দেখিব পাৰে। Evidence-এ সমৰ্থন কৰিলে পাছলৈ, route by route, policy আহে। How It Works-এ সম্পূৰ্ণ flow দেখুৱায়।

Verification নিৰ্ভৰযোগ্য কৰা ব্যৱহাৰিক বিৱৰণ

Signature checking-এ ইয়াৰ চাৰিওফালৰ বিৱৰণৰ মানদণ্ডৰ ওপৰত নিৰ্ভৰ কৰে। কেইটামান practice-এ production-ত সত্যায়িত স্বয়ংক্রিয় অনুৰোধ নিৰ্ভৰযোগ্য কৰি তোলে।

Freshness পৰীক্ষা কৰক

RFC 9421-এ created আৰু expires signature parameter সংজ্ঞায়িত কৰে, আৰু স্বাক্ষৰিত অনুৰোধে সাধাৰণতে সেয়া বহন কৰে। এটা সৰু সময়ৰ সীমাৰ বাহিৰৰ স্বাক্ষৰ reject কৰক, যাতে capture কৰা অনুৰোধ পাছত replay কৰিব নোৱাৰি।

Key-সমূহ বুদ্ধিমত্তাৰে cache কৰক

প্ৰতিটো অনুৰোধত operator-ৰ প্ৰকাশিত key আনিলে latency বৃদ্ধি পায়। যুক্তিসংগত সময়ৰ বাবে সিহঁত cache কৰক আৰু unknown key identifier-ৰে signature fail হ’লে refresh কৰক, যাতে key rotation-এ false failure সৃষ্টি নকৰে।

অনুৰোধৰ সঠিক অংশ স্বাক্ষৰ কৰক

কেৱল timestamp-কে সামৰা স্বাক্ষৰে অতি কম প্ৰমাণ কৰে। Signed component-সমূহত method, path আৰু host অন্তৰ্ভুক্ত আছে নে নাই সেয়া পৰীক্ষা কৰক, যাতে signature-এ আপোনাৰ application-এ প্ৰকৃততে পোৱা request-ৰ সৈতে bind হয়।

Evidence record কৰক

প্ৰতিটো verified request-ৰ সৈতে key identifier, প্ৰকাশিত identifier আৰু result ৰাখক। অস্বাভাৱিক কিবা ঘটিলে, আপোনাৰ দলে ঠিক কোন client-এ কি আৰু কেতিয়া স্বাক্ষৰ কৰিছিল সেয়া দেখিব পাৰে।

Proof of Actor-এ Detect step-ৰ অংশ হিচাপে এই check-সমূহ হেণ্ডল কৰে আৰু আপোনাৰ policy-সমূহে পঢ়িব পৰা basis হিচাপে outcome প্ৰতিবেদন কৰে, যাতে আপোনাৰ application code সৰল থাকে।

founding developer program-ত যোগদান কৰক

Proof of Actor private beta-ত আছে। নিৰ্বাচিত founding development দলসমূহে agreed usage limits-ৰ ভিতৰত, আমাৰ engineer-সকলৰ পৰা প্ৰত্যক্ষ integration support-সহ, 12 months free access পাব পাৰে।

যদি স্বয়ংক্ৰিয় client-এ আপোনাৰ application-ত আহে আৰু আপুনি verified-সমূহক পৃথকে হেণ্ডল কৰিব বিচাৰে, early access-ৰ বাবে আবেদন কৰক। আপোনাৰ application আৰু আপুনি দেখা স্বয়ংক্ৰিয় caller-সমূহৰ বিষয়ে আমাক কওক, আৰু আমি দেখুৱাম Proof of Actor কেনেকৈ খাপ খায়।

উৎস

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

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 পঢ়ক

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

সত্যায়িত স্বয়ংক্রিয় অনুৰোধ কি?

এয়া এনে এটা অনুৰোধ যি কোনো স্বয়ংক্ৰিয় ক্লায়েণ্টৰ পৰা আহে, যাৰ ক্ৰিপ্টোগ্ৰাফিক স্বাক্ষৰ এটা জ্ঞাত চিনাক্তকৰ্তাৰ বাবে প্ৰকাশিত কী-ৰ সৈতে, যেনে অপাৰেটৰৰ domain, মিল খায়। ই দেখুৱায় কোনটো ক্লায়েণ্টে অনুৰোধটো স্বাক্ষৰ কৰিছে।

সত্যায়িত স্বাক্ষৰে মানে এজেণ্টটো authorized নেকি?

নাই। স্বাক্ষৰে এটা অনুৰোধক এটা কী আৰু তাৰ প্ৰকাশিত চিনাক্তকৰ্তাৰ সৈতে সংযুক্ত কৰে। সেই ক্লায়েণ্টে কোনো action কৰিব পাৰিব নে নোৱাৰে, সেয়া আপোনাৰ application-এ কৰা এক পৃথক authorization সিদ্ধান্ত।

যিবোৰ স্বয়ংক্ৰিয় ক্লায়েণ্টে নিজৰ অনুৰোধ স্বাক্ষৰ নকৰে, সেইবোৰৰ কথা কি?

Proof of Actor-এ সিহঁতক এতিয়াও classify কৰে, য'ত available তাত declared আৰু inferred evidence ব্যৱহাৰ কৰে, আৰু evidence যথেষ্ট শক্তিশালী নহ’লে Unknown প্ৰতিবেদন কৰে। প্ৰতিটো ফলাফলে তাৰ ভিত্তি উল্লেখ কৰে।

user-agent string এ এটা ক্লায়েণ্টক সত্যায়িত কৰিব পাৰেনে?

নাই। user-agent string সহজে নকল কৰিব পাৰি, সেয়েহে ই verification নহয়, declaration হিচাপে গণ্য হয়। ক্ৰিপ্টোগ্ৰাফিক স্বাক্ষৰেই এটা অনুৰোধক verifiable কৰে।

মই কেনেকৈ আৰম্ভ কৰিম?

early access-ৰ বাবে আবেদন কৰক। founding দলসমূহে observation mode-ত আৰম্ভ কৰে আৰু নিৰ্বাচিত দলসমূহে agreed usage limits-ৰ ভিতৰত সৰ্বাধিক 12 months free পাব পাৰে।

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

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

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

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