মূল বিষয়বস্তুতে যান
ব্যাখ্যামূলক

পণ্য দলের জন্য Web Bot Auth: signed agent request আপনার roadmap-এর জন্য কী অর্থ বহন করে

AI agent এবং crawler-দের increasingly এমন একটি উপায় দরকার যাতে তারা নিজেকে প্রমাণ করতে পারে, এমন User-Agent string-এর ওপর নির্ভর না করে যা যে কেউ copy করতে পারে। IETF-এর Web Bot Auth কাজটি সেটি standardize করার leading effort। এখানে product manager এবং engineering lead-দের জন্য একটি সহজ ব্যাখ্যা দেওয়া হলো: এটি কীভাবে কাজ করে, কী প্রমাণ করে, November 2026 পর্যন্ত এর অবস্থা কী, এবং এর জন্য কীভাবে plan করতে হবে।

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

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

বছরের পর বছর ধরে, কোনো automated client website-কে সে কে তা জানানোর একমাত্র উপায় ছিল User-Agent header-এর একটি name, আর কয়েকজন বড় operator-এর ক্ষেত্রে, প্রকাশিত IP address-এর তালিকা বা reverse DNS check। Name copy করা সহজ। Network list কেবল তাদেরই cover করে যারা সেগুলো maintain করে। AI agent-রা যখন web জুড়ে বাস্তব মানুষের হয়ে কাজ করতে শুরু করেছে, তখন এই gap শুধু security problem নয়, product problem-ও হয়ে উঠেছে।

Web Bot Auth এই gap বন্ধ করার leading effort। এটি automated client-দের এমন একটি উপায় দেয় যাতে তারা তাদের নিয়ন্ত্রণাধীন এবং প্রকাশিত key দিয়ে request sign করতে পারে, যাতে site name-এর ওপর ভরসা না করে signature check করতে পারে। এই explainerটি product manager এবং engineering lead-দের জন্য, যাদের specification end to end পড়া ছাড়াই এটি কী, কী পরিবর্তন আনে, এবং কী আনে না তা বোঝা দরকার।

সংক্ষিপ্ত সংস্করণ

  • এটি কী: একটি IETF working group, webbotauth, এবং automated HTTP client authenticate করার জন্য তারা যে approach standardize করছে।
  • এটি কীভাবে কাজ করে: client HTTP Message Signatures (RFC 9421) ব্যবহার করে প্রতিটি request-এর অংশ sign করে এবং তার public key-এর একটি directory-এর দিকে ইঙ্গিত করে। site key fetch করে এবং signature verify করে।
  • এটি কী প্রমাণ করে: কোন key request sign করেছে, এবং transit-এর সময় signed অংশগুলো পরিবর্তিত হয়নি।
  • এটি কী প্রমাণ করে না: agent যে কাজটি চাইছে তা করার অনুমতি তার আছে কিনা, এটি কোনো নির্দিষ্ট user-এর behalf-এ act করছে কিনা, বা এটি ভালোভাবে behave করবে কিনা।
  • November 2026 পর্যন্ত অবস্থা: RFC 9421 একটি published Proposed Standard। Web Bot Auth protocol document এখনও একটি working group Internet-Draft, RFC নয়।
  • কী করা উচিত: valid signature-কে strong evidence হিসেবে treat করার plan করুন, unsigned traffic handle করতে থাকুন, এবং authorization decision নিজের code-এ রাখুন।

IETF Web Bot Auth কাজটি কী

IETF Web Bot Auth working group charter করেছে যাতে automated client-দের cryptographically authenticate করার method এবং website-কে তাদের পেছনের operator সম্পর্কে আরও তথ্য দেওয়ার উপায় standardize করা যায়। এই charter এমন site-এর ওপর focus করে যেগুলো মূলত মানুষের জন্য service দেয়, এবং এতে scope-এর মধ্যে একটি বিস্তৃত set-এর client নাম আছে: crawler, web archiver, link checker, AI training crawler এবং end user-দের হয়ে act করা AI agent।

Charter-এ দুইটি exclusion product team-দের জন্য লক্ষণীয়। End-user authentication scope-এর বাইরে, তাই এটি কাউকে লগ ইন করানোর উপায় নয়। Bot reputation tracking-ও scope-এর বাইরে, তাই standard আপনাকে বলে request কে sign করেছে, কিন্তু সেই operator trustworthy কিনা তা বলে না।

Charter-এ তিন ধরনের deliverable তালিকাভুক্ত আছে:

  1. People-এর জন্য তৈরি website-এ automated client authenticate করার technique নিয়ে standards track document।
  2. domain name বা URL-এর মতো বিদ্যমান identifier ব্যবহার করে requesting bot সম্পর্কে আরও তথ্য বহন করার standards track document।
  3. key management, lifecycle এবং deployment-এর মতো operational topic-এ best current practice বা informational document।

Document-গুলোর অবস্থা, November 2026 অনুযায়ী

November 2026 পর্যন্ত, working group-এর একটি adopted working group document আছে: draft-ietf-webbotauth-httpsig-protocol, শিরোনাম "HTTP Message Signatures for automated traffic", revision 01, তারিখ October 29, 2026। এটি একটি Internet-Draft, যার মানে এটি চলমান কাজ এবং এখনও পরিবর্তিত হতে পারে। এটি RFC নয়।

Several individual draft-ও group-এর সঙ্গে সম্পর্কিত এবং আলোচনাধীন, যার মধ্যে registry এবং agent card format, anonymous bot authentication, automated client-দের IP range publish করার জন্য একটি JSON format, এবং signed agent metadata-এর জন্য একটি header সম্পর্কিত proposal আছে। Individual draft হলো proposal; এর কোনোটিই এই তারিখ পর্যন্ত group গ্রহণ করেনি।

Charter-এ 2026 জুড়ে milestone নির্ধারণ করা হয়েছিল যাতে specification approval-এর জন্য IESG-এ পাঠানো যায়। November 2026 পর্যন্ত, protocol document এখনও একটি working group draft। আপনি বর্তমান অবস্থা working group-এর জন্য IETF datatracker page এবং protocol draft-এ অনুসরণ করতে পারেন।

HTTP Message Signatures কীভাবে কাজ করে

Web Bot Auth RFC 9421, HTTP Message Signatures-এর ওপর তৈরি, যা February 2024-এ Proposed Standard হিসেবে published হয়েছে। RFC 9421 হলো একটি general mechanism: এটি HTTP message-এর নির্বাচিত অংশ কীভাবে sign করতে হয় এবং কীভাবে signature header-এ বহন করতে হয় তা নির্ধারণ করে। Web Bot Auth এটি automated client-দের জন্য profile করে।

সহজভাবে বললে, signed agent request এভাবে কাজ করে:

  1. Operator একটি key pair তৈরি করে। এটি private key গোপন রাখে এবং public key publish করে।
  2. Client কোন অংশ sign করবে তা বেছে নেয়। এটি request-এর component বেছে নেয়, যেমন target host বা URI এবং creation time। বর্তমান draft authority বা target URI-এর coverage প্রয়োজন করে, যাতে এক site-এর জন্য তৈরি signature সহজে অন্য site-এ replay করা না যায়।
  3. Client sign করে পাঠায়। request-এ একটি Signature-Input header থাকে যা কী sign হয়েছে এবং কোন key দিয়ে হয়েছে তা বর্ণনা করে, এবং একটি Signature header থাকে signature value-সহ। draft একটি web-bot-auth tag ব্যবহার করে এবং প্রতিটি signature-এ creation এবং expiry time আশা করে।
  4. Site verify করে। এটি public key খুঁজে পায়, যে request পেয়েছে সেখান থেকে signed component পুনর্গঠন করে, এবং signature check করে। check pass করলে request সেই key-এর holder দ্বারা sign করা হয়েছিল এবং covered অংশগুলো পরিবর্তিত হয়নি।

Draft-টি site-কে signature চাইতেও দেয়। একটি origin একটি Accept-Signature header পাঠাতে পারে, সাধারণত একটি refusal-সহ, যাতে সে signed request চায় তা signal করতে পারে।

Key directory ধারণা

যদি site সঠিক public key খুঁজে না পায়, signature-এর কোনো মূল্য নেই। Web Bot Auth সেটির সমাধান দেয় একটি key directory দিয়ে।

বর্তমান working group draft-এ, client একটি HTTPS URL সহ একটি Signature-Agent header যোগ করে। সেই URL operator-এর public key-এর একটি directory JSON Web Key Set হিসেবে serve করে। site directory fetch করে, signature-এ থাকা key identifier-এর সঙ্গে মেলে এমন key বেছে নেয়, এবং verify করে। draft-এ একটি well-known path-ও নির্ধারণ করা হয়েছে, /.well-known/http-message-signatures-directory, যেখানে operator তার directory serve করতে পারে।

Product team-দের জন্য useful idea হলো URL-ই identity হয়ে যায়। একজন agent operator তার key যেখানে publish করে সেখান দিয়েই চিহ্নিত হয়, যা signature-কে operator-এর নিয়ন্ত্রণাধীন একটি domain-এর সঙ্গে tie করে। Key rotation হয় নতুন key পুরোনোটির পাশে publish করে, তারপর পুরোনোটি সরিয়ে দিয়ে।

Verifying site-কে directory সাবধানে handle করতে হবে: normal HTTP rule অনুসারে cache করতে হবে, size limit এবং timeout সেট করতে হবে, এবং private network address থেকে fetch করা এড়াতে হবে। এগুলো standard engineering concern, এবং এটাই কারণ অনেক team এমন একটি component prefer করে যা তাদের জন্য verification করে দেয়।

একটি valid signature কী প্রমাণ করে, আর কী করে না

যে কেউ product policy লেখে তার জন্য এটি সবচেয়ে গুরুত্বপূর্ণ section।

একটি valid signature প্রমাণ করে:

  • Request একটি নির্দিষ্ট private key-এর holder দ্বারা sign করা হয়েছিল।
  • সেই key operator-এর নিয়ন্ত্রণাধীন একটি directory URL-এ publish করা আছে।
  • request-এর signed অংশগুলো transit-এর সময় পরিবর্তিত হয়নি, এবং signature তার validity window-এর মধ্যে আছে।

একটি valid signature প্রমাণ করে না:

  • Agent authorized কিনা সেই action করার জন্য। Identifiable হওয়া permission নয়। agent authorization দেখুন।
  • Agent কোনো নির্দিষ্ট person-এর হয়ে act করছে কিনা, বা সেই person যে authority দিয়েছে তার মধ্যে আছে কিনা। delegated authority দেখুন।
  • Operator trustworthy কিনা বা agent ভালোভাবে behave করবে কিনা। Reputation working group-এর scope-এর বাইরে।
  • Signed নয় এমন request সম্পর্কে কিছু। Unsigned traffic-কে এখনও আলাদাভাবে handle করতে হবে।

একটি valid signature-কে request কে পাঠিয়েছে তার strong evidence হিসেবে treat করুন, তারপর আপনার own access control দিয়ে নির্ধারণ করুন সেই sender কী করতে পারবে।

Product team-দের কী করা উচিত

Plan করার জন্য আপনাকে কোনো RFC-এর অপেক্ষা করতে হবে না। Signed agent traffic এখনই prepare করার মতো বিষয়, এই expectation নিয়ে যে draft-এর কিছু detail পরিবর্তিত হতে পারে।

1. Decide করার আগে measure করুন

আপনার traffic-এর কতটা automated, কোন route agent ব্যবহার করে, এবং কতটা signed তা খুঁজে বের করুন। observation mode-এ শুরু করুন, যাতে measurement আপনার user-দের জন্য কিছুই পরিবর্তন না করে।

2. Evidence এবং policy আলাদা করুন

Evidence যা বলে, verified, declared, inferred বা unknown, তা আপনি যা করার সিদ্ধান্ত নেন তার থেকে আলাদা করে record করুন। এতে policy পড়তে সহজ হয় এবং re-instrument না করেই আপনি সেগুলো tight বা relax করতে পারেন। evidence basis entry চারটি level ব্যাখ্যা করে।

3. Verified agent-দের জন্য ভালো path দিন

যেখানে মানায়, মানুষ-দের জন্য তৈরি page-এর বদলে verified agent-দের structured content বা agent-friendly flow দিন। AI agent-দের structured content serve করা guide-এ patternগুলো আছে।

4. Authorization নিজের code-এ রাখুন

Signature ব্যবহার করুন কে জিজ্ঞাসা করছে তা জানার জন্য। তারা কী করতে পারবে তা নির্ধারণ করতে আপনার existing permission, scope এবং confirmation ব্যবহার করুন। উচ্চ-প্রভাবযুক্ত action-এ এখনও human confirmation লাগতে পারে, request-এ কে signature দিয়েছে তা নির্বিশেষে। sensitive action-গুলো agent block না করে সুরক্ষিত করা দেখুন।

5. Unsigned এবং Unknown traffic-এর জন্য plan করুন

Signing-এর support agent এবং tool অনুসারে ভিন্ন, তাই কিছু সময় signed এবং unsigned request-এর মিশ্রণ আশা করুন। declared, inferred এবং Unknown traffic-এ প্রতি route-এ কী হবে তা ঠিক করুন, site-wide একক rule বেছে নেওয়ার বদলে। Unknown traffic handle করা guide-টি এটি ব্যাখ্যা করে।

Proof of Actor Web Bot Auth কীভাবে ব্যবহার করে

Proof of Actor আপনার application-কে বলে প্রতিটি interaction-এ কে বা কী act করছে, Human, Human + AI, Agent বা Unknown, এবং evidence basis কী। Web Bot Auth signature হলো evidence-এর সবচেয়ে শক্তিশালী উৎসগুলোর একটি।

যখন কোনো agent HTTP Message Signatures দিয়ে request sign করে, Proof of Actor operator-এর published key-এর বিপরীতে signature check করে। check pass করলে result-টি একটি verified basis সহ ফিরে আসে, এবং সেই evidence-ও থাকে যা আপনার team review করতে পারে। যদি কোনো client কেবল header-এ নিজের নাম দেয়, result হয় declared। যদি conclusion behavioral বা contextual signal-এর ওপর নির্ভর করে, এটি inferred হিসেবে labeled হয়। যদি evidence যথেষ্ট না হয়, result হয় Unknown।

এই context দিয়ে আপনার application কী করবে তা আপনারাই ঠিক করেন। Policy প্রতি route, প্রতি actor class এবং প্রতি basis অনুযায়ী লেখা হয়, এবং outcome হতে পারে allow, adapt, challenge, review এবং rate-limit। ডিফল্ট হিসেবে কিছুই enforce হয় না: আপনি বাস্তব traffic-এ policy preview করেন এবং route অনুযায়ী, নিজের code-এ enforce করেন।

Founding team-রা Node.js middleware, Next.js, একটি edge integration, approved page-এ browser collector, generic HTTP API, বা একটি MCP server integration-এর মাধ্যমে evidence সংগ্রহ করতে পারে। integrations এবং signed agent request verify করা guide-এ practical step আছে।

Proof of Actor standard-এর একই সীমা অনুসরণ করে: একটি verified signature আপনাকে বলে কোন key request sign করেছে, agent authorized কিনা তা নয়। Authorization আপনার কাছেই থাকে। evidence and limits page-এ স্পষ্টভাবে বলা আছে প্রতিটি result কী সমর্থন করতে পারে আর কী পারে না।

শুরু করুন

Proof of Actor private beta-তে আছে। Selected founding developer team-রা agreed usage limit-এর মধ্যে no automatic billing সহ up to 12 months-এর free access পেতে পারে। early access-এর জন্য আবেদন করুন এবং জানান কোন route-এ signed agent ব্যবহার হবে বলে আপনি আশা করছেন এবং তাদের নিয়ে আপনি কী করতে চান।

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

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

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

Web Bot Auth কী?

Web Bot Auth হলো একটি IETF working group-এর নাম, webbotauth, এবং তারা যে approach standardize করছে তা হলো: automated client-রা HTTP Message Signatures (RFC 9421) দিয়ে HTTP request sign করে এবং তাদের public key publish করে, যাতে website যাচাই করতে পারে কোন operator request পাঠিয়েছে।

Web Bot Auth কি সম্পূর্ণ standard?

এখনও নয়। November 2026 পর্যন্ত, main protocol document, draft-ietf-webbotauth-httpsig-protocol, revision 01-এ একটি working group Internet-Draft। RFC 9421, যার ওপর এটি built on, একটি published Proposed Standard।

একটি valid Web Bot Auth signature কি মানে agent act করার অনুমতি পেয়েছে?

না। এটি প্রমাণ করে কোন key request sign করেছে এবং signed অংশগুলো transit-এর সময় পরিবর্তিত হয়নি। সেই agent data পড়তে পারবে কি না, form submit করতে পারবে কি না, বা কোনো নির্দিষ্ট user-এর behalf-এ act করতে পারবে কি না, তা আপনার application-এর authorization decision।

Product team-দের কি নিজেরা Web Bot Auth implement করতে হবে?

Site signature verify করে; যদি তারা automated client-ও চালায়, তবেই তাদের কিছু sign করতে হবে। Verification-এর মধ্যে key directory fetch করা, সেগুলো safely cache করা এবং signature check করা অন্তর্ভুক্ত, যা Proof of Actor-এর মতো tool আপনার জন্য করতে পারে।

যে agent তাদের request sign করে না, তাদের ক্ষেত্রে আমাদের কী করা উচিত?

উপলব্ধ evidence অনুযায়ী তাদের treat করুন: declared, inferred বা Unknown। কিছু সময় signed এবং unsigned traffic-এর মিশ্রণ আশা করুন, এবং একটি site-wide rule-এর বদলে প্রতি route-এ fallback সেট করুন।

Proof of Actor Web Bot Auth কীভাবে ব্যবহার করে?

এটি published key-এর বিপরীতে HTTP Message Signatures check করে এবং check pass করলে result-টি verified basis সহ দেখায়। তারপর আপনার policy verified agent-দের declared বা Unknown traffic থেকে ভিন্নভাবে treat করতে পারে।

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

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

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

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