যাচাইকৃত অটোমেশন

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

যখন কোনো স্বয়ংক্রিয় ক্লায়েন্ট তার অনুরোধে সিগনেচার দেয়, তখন আপনার অ্যাপ্লিকেশন সেই সিগনেচার পরীক্ষা করে কলারকে সেই অনুযায়ী扱তে পারে। Proof of Actor সেই পরীক্ষাকে একটি স্পষ্ট, রাউটযোগ্য ফলাফলে রূপ দেয়।

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

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

সব স্বয়ংক্রিয় ট্র্যাফিক এক নয়

স্বয়ংক্রিয় ক্লায়েন্টরা প্রতি মিনিটে আপনার অ্যাপ্লিকেশনে পৌঁছে যায়: সার্চ ক্রলার, মনিটরিং টুল, পার্টনার ইন্টিগ্রেশন, ব্যবহারকারীর জন্য পৃষ্ঠা আনা AI সহকারী, এবং কাজ শেষ করা স্বায়ত্তশাসিত এজেন্ট। বছরের পর বছর ধরে, বেশিরভাগ অ্যাপ্লিকেশন তাদের আলাদা করতে পারত কেবল user-agent header দেখে, যা যে কোনো ক্লায়েন্ট যেকোনো মানে সেট করতে পারে।

এটি অ্যাপ্লিকেশন টিমকে এক কঠিন অবস্থায় ফেলে। সব অটোমেশনকে সন্দেহের চোখে দেখলে, আপনার গ্রাহকের নির্ভরশীল বৈধ এজেন্টগুলোর অভিজ্ঞতা খারাপ হয়। header-এর ওপর ভরসা করলে, যে কেউ নিজেকে পরিচিত কোনো ক্রলার বলে দাবি করতে পারে।

যাচাইকৃত স্বয়ংক্রিয় অনুরোধ এই সমীকরণ বদলে দেয়। যখন কোনো স্বয়ংক্রিয় ক্লায়েন্ট তার প্রকাশিত কী দিয়ে অনুরোধে সিগনেচার দেয়, তখন আপনার অ্যাপ্লিকেশন সেই সিগনেচার পরীক্ষা করে ক্রিপ্টোগ্রাফিকভাবে জানতে পারে কোন ক্লায়েন্ট অনুরোধটি সই করেছে। Proof of Actor সেই পরীক্ষাকে একটি একক, সামঞ্জস্যপূর্ণ actor ফলাফলের অংশে পরিণত করে, যার ওপর আপনার কোড রাউট করতে পারে। এই পরীক্ষা কী করে আর কী করে না, তা আরও কাছ থেকে দেখতে signed AI agent requests কী প্রমাণ করে পড়ুন।

অনুরোধ সাইনিং কীভাবে কাজ করে

স্বয়ংক্রিয় ট্র্যাফিকের জন্য উদীয়মান পদ্ধতিতে HTTP message signatures ব্যবহার করা হয়, যা RFC 9421-এ মানসম্মত। এতে HTTP message-এর উপাদানগুলোর ওপর সিগনেচার তৈরি, এনকোড এবং যাচাই করার পদ্ধতি নির্ধারিত আছে। ক্লায়েন্ট প্রতিটি অনুরোধের নির্বাচিত অংশ একটি private key দিয়ে সাইন করে এবং headers-এ সিগনেচার ও তার প্যারামিটারগুলো অন্তর্ভুক্ত করে। এরপর এটি যে শনাক্তকারীর ওপর তার নিয়ন্ত্রণ আছে, সাধারণত তার domain, তার সঙ্গে যুক্ত স্থানে সংশ্লিষ্ট public key প্রকাশ করে।

অনুরোধ এলে, receiver প্রকাশিত কী আনে বা খুঁজে দেখে, সই করা কনটেন্ট পুনর্গঠন করে, এবং সিগনেচার পরীক্ষা করে। যদি এটি যাচাই হয়, তবে অনুরোধটি ওই কী-এর ধারকের দ্বারা সই করা হয়েছে। স্বয়ংক্রিয় ট্র্যাফিক সাইন করার কাজ IETF Web Bot Auth working group-এ চলমান, যার charter-এ crawlers এবং শেষ ব্যবহারকারীদের পক্ষে কাজ করা AI agent-এর মতো স্বয়ংক্রিয় ক্লায়েন্টদের ক্রিপ্টোগ্রাফিকভাবে প্রমাণীকরণ অন্তর্ভুক্ত। Web Bot Auth glossary entry এটি সংক্ষেপে ব্যাখ্যা করে। signed AI agent requests কী প্রমাণ করে ব্লগ পোস্টে একটি যাচাইকৃত অনুরোধ শুরু থেকে শেষ পর্যন্ত দেখানো হয়েছে, আর APIs use case দেখায় কোথায় যাচাইকরণ সবচেয়ে আগে উপকার দেয়।

verifying signed agent requests গাইডে timestamps, replay windows এবং key caching-সহ mechanics বিস্তারিতভাবে ব্যাখ্যা করা হয়েছে।

একটি যাচাইকৃত সিগনেচার কী প্রমাণ করে, আর কী প্রমাণ করে না

যাচাইকৃত স্বয়ংক্রিয় অনুরোধ সঠিকভাবে সামলানোর সবচেয়ে গুরুত্বপূর্ণ অংশ এটি।

একটি বৈধ সিগনেচার প্রমাণ করে যে অনুরোধটি প্রকাশিত শনাক্তকারীর সঙ্গে যুক্ত একটি কী দিয়ে সই করা হয়েছে। যদি কীটি কোনো operator-এর domain-এর হয়, তবে অনুরোধটি ওই operator-এর কী ধারণকারী ক্লায়েন্ট থেকে এসেছে।

একটি বৈধ সিগনেচার প্রমাণ করে না:

কে agent-কে নির্দেশ দিয়েছিল, বা কোনো মানুষ এই কাজটি চেয়েছিল কি না;
কোনো মানুষ agent-কে কর্তৃত্ব অর্পণ করেছে কি না;
operator-এর পেছনের বাস্তব জগতের আইনগত পরিচয়;
অনুরোধ করা কাজটি আপনার অ্যাপ্লিকেশনে নিরাপদ বা অনুমোদিত কি না।

এগুলো আলাদা প্রশ্ন। আপনার অ্যাপ্লিকেশন সেগুলোর উত্তর দেয় তার নিজস্ব credentials, authorization model এবং policy দিয়ে। Proof of Actor ইচ্ছে করেই এগুলোকে আলাদা রাখে, আর Detection & Limitations পৃষ্ঠায় প্রতিটি ধরনের evidence কী প্রতিষ্ঠা করতে পারে তা স্পষ্টভাবে বলা আছে।

যাচাইকৃত স্বয়ংক্রিয় অনুরোধ Proof of Actor কীভাবে সামলায়

Detect

আপনার integration অনুরোধের context, যার মধ্যে যে কোনো signature header অন্তর্ভুক্ত, Proof of Actor-এ পাঠায়। সিগনেচারগুলো প্রকাশিত key-এর সঙ্গে মিলিয়ে পরীক্ষা করা হয়। যে অনুরোধগুলো যাচাই হয়, সেগুলো যাচাইকৃত ভিত্তিতে রেকর্ড হয়। যেসব ক্লায়েন্ট কেবল নিজেদের পরিচয় দেয়, সেগুলো ঘোষিত হিসেবে রেকর্ড হয়। আচরণগত প্যাটার্ন অনুমিত হিসেবে রেকর্ড হয়। পর্যাপ্ত তথ্য না থাকলে ফলাফল হয় Unknown। কোনো cryptographic check পাস না করা পর্যন্ত কিছুই যাচাইকৃত হিসেবে উন্নীত হয় না।

Understand

দেখুন কোন যাচাইকৃত operator আপনার অ্যাপ্লিকেশনকে কল করছে, কোন route ব্যবহার করছে, কতবার করছে, এবং তা ঘোষিত ও Unknown অটোমেশনের সঙ্গে কীভাবে তুলনা করে। প্রতিটি ফলাফলের evidence summary জানায় কোন key এবং শনাক্তকারী involved ছিল, যাতে আপনার দল দ্রুত যে কোনো অনুরোধ তদন্ত করতে পারে।

Route

আপনার policy-তে ভিত্তিটি ব্যবহার করুন। সাধারণ pattern-এর মধ্যে রয়েছে:

verified agent-দের read-only route-এ একটি structured response দিন, যেমন একটি API বা পৃষ্ঠার Markdown version।
যেসব verified operator-কে আপনি চিনতে পারেন তাদের জন্য rate limit বাড়ান, আর ঘোষিত ক্লায়েন্টদের জন্য standard limit বজায় রাখুন।
সিগনেচার যা-ই বলুক, প্রতিটি write route-এ আপনার বিদ্যমান authorization বজায় রাখুন।
প্রতিটি route-এ unsigned এবং Unknown কলারের জন্য একটি স্পষ্ট fallback নির্ধারণ করুন।

আপনার policy সিদ্ধান্ত নেয়; Proof of Actor evidence সরবরাহ করে।

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

User-agent string হলো ঘোষণা। যে কোনো ক্লায়েন্ট যে কোনো মান পাঠাতে পারে, এবং user-agent spoofing করতে বিশেষ দক্ষতার দরকার হয় না। সে কারণেই crawler operator-রা নিজেদের যাচাই প্রক্রিয়া প্রকাশ করে: 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 দাবিকে ঘোষিত evidence হিসেবে গণ্য করে, কখনোই যাচাইকরণ হিসেবে নয়। এর মানে, কোনো valid সিগনেচার ছাড়া নিজেকে পরিচিত কোনো ক্রলার বলে দাবি করা ক্লায়েন্টকে ঘোষিত বা অনুমিত ভিত্তিতে রিপোর্ট করা হয়, এবং আপনার policy সেটিকে সেই ক্লায়েন্টের থেকে আলাদা ভাবে বিবেচনা করতে পারে যে নিজের পরিচয় প্রমাণ করেছে।

এটাই যাচাইকৃত স্বয়ংক্রিয় অনুরোধকে মূল্যবান করে তোলে: এগুলো আপনাকে নির্ভরযোগ্য একটি উপায় দেয় সেই ক্লায়েন্টদের কাছে আস্থা বিস্তৃত করার, যারা তা অর্জন করেছে, কিন্তু যারা কেবল তাদের header নকল করেছে তাদের সবার কাছে নয়।

পরিচয় evidence, credentials এবং authorization

যে কোনো অ্যাপ্লিকেশন যা স্বয়ংক্রিয় ক্লায়েন্টদের সেবা দেয়, সেখানে তিনটি স্তর একসঙ্গে কাজ করে:

পরিচয় evidence: কোন ক্লায়েন্ট এই অনুরোধে সই করেছে? একটি যাচাইকৃত সিগনেচার এটির উত্তর দেয়।
Credentials: কোন account দায়ী? আপনার API key, token বা session এটির উত্তর দেয়।
Authorization: এই কলার কি এটা করতে পারে? আপনার permission model এটির উত্তর দেয়।

Proof of Actor প্রথম স্তরকে শক্তিশালী করে এবং দৃশ্যমান করে। এটি পরিচয় বা delegation credentials ইস্যু করে না, এবং আপনার authorization প্রতিস্থাপনও করে না। স্তরগুলো আলাদা রাখা আপনাকে low-risk route-এ verified agent-দের জন্য উদার এবং high-impact ক্ষেত্রে সতর্ক হতে সাহায্য করে।

এটি কোথায় বসে

Proof of Actor আপনার gateway, authentication এবং rate limiting-এর পাশাপাশি বসে। Integration server-side middleware হিসেবে, edge-এ, আপনার MCP server-এ অথবা generic HTTP integration-এর মাধ্যমে চলে, এবং প্রতিটি founding দলের সঙ্গে হাতে ধরে সরবরাহ করা হয়। যদি আপনার ট্র্যাফিকের বেশিরভাগই APIs এবং tool হয়, তাহলে APIs এবং MCP Servers use case সবচেয়ে গুরুত্বপূর্ণ patternগুলো দেখায়।

পর্যবেক্ষণ মোডে শুরু করুন

প্রতিটি integration পর্যবেক্ষণ মোডে শুরু হয়। ফলাফল রেকর্ড করা হয়, কিন্তু আপনার অ্যাপ্লিকেশন কীভাবে প্রতিক্রিয়া জানায় তা বদলানো হয় না, যাতে আপনি দেখতে পারেন আপনার স্বয়ংক্রিয় ট্র্যাফিকের কতটা যাচাইকৃত, কোন operator সাইন করছে, এবং কোথায় Unknown হার সবচেয়ে বেশি। প্রমাণ সমর্থন করলে পরে, route-by-route policy আসে। How It Works পুরো flow দেখায়।

যাচাইকরণ নির্ভরযোগ্য করতে যে বাস্তব দিকগুলো দরকার

সিগনেচার যাচাই যতটা ভালো, তার চারপাশের detail ততটাই গুরুত্বপূর্ণ। কয়েকটি practice যাচাইকৃত স্বয়ংক্রিয় অনুরোধকে production-এ নির্ভরযোগ্য করে তোলে।

تازা থাকা পরীক্ষা করুন

RFC 9421 created এবং expires signature parameter নির্ধারণ করে, এবং signed request-এ সাধারণত সেগুলো থাকে। ছোট একটি window-এর বাইরে থাকা সিগনেচার প্রত্যাখ্যান করুন, যাতে captured request পরে replay করা না যায়।

কীগুলো বিচক্ষণভাবে cache করুন

প্রতিটি অনুরোধে operator-এর প্রকাশিত key নিয়ে আসলে latency বাড়ে। যুক্তিসংগত সময়ের জন্য এগুলো cache করুন এবং যখন কোনো সিগনেচার unknown key identifier নিয়ে ব্যর্থ হয় তখন refresh করুন, যাতে key rotation false failure সৃষ্টি না করে।

অনুরোধের সঠিক অংশ সাইন করুন

শুধু timestamp-কে ঘিরে থাকা সিগনেচার খুব সামান্যই প্রমাণ করে। যাচাই করুন যে সাইন করা component-এর মধ্যে method, path এবং host আছে, যাতে সিগনেচার আপনার অ্যাপ্লিকেশন যে অনুরোধ সত্যিই পেয়েছে তার সঙ্গেই বাঁধা থাকে।

evidence রেকর্ড করুন

প্রতিটি যাচাইকৃত অনুরোধের সঙ্গে key identifier, প্রকাশিত শনাক্তকারী এবং ফলাফল রাখুন। কিছু অস্বাভাবিক ঘটলে, আপনার দল ঠিক দেখতে পারবে কোন ক্লায়েন্ট কী সই করেছে এবং কখন।

Proof of Actor Detect ধাপের অংশ হিসেবে এসব check সামলায় এবং ফলাফলকে এমন একটি ভিত্তি হিসেবে রিপোর্ট করে, যা আপনার policy পড়তে পারে, তাই আপনার অ্যাপ্লিকেশন কোড সরল থাকে।

founding developer program-এ যোগ দিন

Proof of Actor private beta-তে রয়েছে। নির্বাচিত founding development দলগুলো সম্মত ব্যবহারের সীমার মধ্যে, আমাদের engineer-দের সরাসরি integration support-সহ, সর্বোচ্চ 12 মাস বিনামূল্যে access পেতে পারে।

যদি স্বয়ংক্রিয় ক্লায়েন্টরা আপনার অ্যাপ্লিকেশনে পৌঁছে যায় এবং আপনি যাচাইকৃতগুলোকে আলাদা ভাবে扱তে চান, তাহলে প্রারম্ভিক অ্যাক্সেসের জন্য আবেদন করুন. আপনার অ্যাপ্লিকেশন এবং আপনি যে স্বয়ংক্রিয় কলারগুলো দেখেন সেগুলো সম্পর্কে আমাদের জানান, আমরা দেখাব কীভাবে Proof of Actor মানানসই।

উৎস

RFC 9421: HTTP Message Signatures, IETF, February 2024.
Web Bot Auth (webbotauth) working group charter, IETF.
Verifying Googlebot and other Google crawlers, Google Search Central.
How to verify that Bingbot is Bingbot, Bing Webmaster Blog.
Overview of OpenAI crawlers, OpenAI.

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

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 পড়ুন

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

যাচাইকৃত স্বয়ংক্রিয় অনুরোধ কী?

এটি এমন একটি অনুরোধ, যা কোনো স্বয়ংক্রিয় ক্লায়েন্ট থেকে এসেছে এবং যার ক্রিপ্টোগ্রাফিক সিগনেচার একটি পরিচিত শনাক্তকারীর জন্য প্রকাশিত কী-এর বিরুদ্ধে যাচাই হয়, যেমন অপারেটরের ডোমেইন। এটি দেখায়, কোন ক্লায়েন্ট অনুরোধটি সই করেছে।

যাচাইকৃত সিগনেচার মানে কি এজেন্ট অনুমোদিত?

না। একটি সিগনেচার অনুরোধকে একটি কী এবং তার প্রকাশিত শনাক্তকারীর সঙ্গে যুক্ত করে। ওই ক্লায়েন্ট কোনো কাজ করতে পারবে কি না, তা আপনার অ্যাপ্লিকেশন যে আলাদা অনুমোদন সিদ্ধান্ত নেয় তার বিষয়।

যেসব স্বয়ংক্রিয় ক্লায়েন্ট তাদের অনুরোধে সিগনেচার দেয় না, তাদের কী হবে?

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

একটি user-agent string কি কোনো ক্লায়েন্টকে যাচাই করতে পারে?

না। User-agent string সহজেই নকল করা যায়, তাই এটি একটি ঘোষণা, যাচাইকরণ নয়। ক্রিপ্টোগ্রাফিক সিগনেচারই কোনো অনুরোধকে যাচাইযোগ্য করে।

আমি কীভাবে শুরু করব?

প্রারম্ভিক অ্যাক্সেসের জন্য আবেদন করুন। Founding দলগুলো পর্যবেক্ষণ মোডে শুরু করে, আর নির্বাচিত দলগুলো সম্মত ব্যবহারের সীমার মধ্যে সর্বোচ্চ 12 মাস বিনামূল্যে পেতে পারে।

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

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

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

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