মুখ্য সামগ্ৰীৰ পৰা এৰাই চাওক
ব্যাখ্যামূলক

প্ৰডাক্ট টিমৰ বাবে Web Bot Auth: signed agent requests আপোনাৰ roadmap ৰ বাবে কি অৰ্থ বহন কৰে

AI agents আৰু crawlers ক্ৰমে নিজৰ পৰিচয় প্ৰমাণ কৰাৰ এটা উপায়ৰ প্ৰয়োজন অনুভৱ কৰিছে, যাৰ বাবে যিকোনো লোকে copy কৰিব পৰা User-Agent string ৰ ওপৰত নিৰ্ভৰ কৰিব নালাগে। IETF Web Bot Auth উদ্যোগ সেইটো মানক কৰাৰ আগশাৰী প্ৰচেষ্টা। প্ৰডাক্ট ম্যানেজাৰ আৰু ইঞ্জিনিয়াৰিং নেতৃত্বৰ বাবে ইয়াত এটা সহজ ব্যাখ্যা আছে: ই কেনেকৈ কাম কৰে, ই কি প্ৰমাণ কৰে, November 2026 অনুসৰি ইয়াৰ অৱস্থা কি, আৰু ইয়াৰ বাবে কেনেকৈ পৰিকল্পনা কৰিব।

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

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

বছৰ বছৰ ধৰি, automated client এ এটা website ক সি কোন তাক জনাবলৈ একমাত্ৰ উপায় আছিল User-Agent header ত থকা এটা নাম, আৰু কেইজনমান বৃহৎ operator ৰ ক্ষেত্ৰত প্ৰকাশিত IP addresses ৰ তালিকা বা reverse DNS check। নাম copy কৰা সহজ। Network lists কেৱল সেই operator বিলাককে সামৰে, যিসকলে সেইবোৰ maintain কৰে। AI agents এ web জুৰি বাস্তৱ মানুহৰ হৈ কাম কৰিবলৈ আৰম্ভ কৰাৰ লগে লগে, সেই খালী ঠাই এটা security সমস্যা নোহোৱাকৈ product সমস্যা হৈ পৰিছে।

Web Bot Auth সেই খালী ঠাই পূৰণ কৰাৰ আগশাৰী প্ৰচেষ্টা। ই automated clients ক তেওঁলোকে নিয়ন্ত্ৰণ আৰু প্ৰকাশ কৰা এটা key ৰ সহায়ত নিজৰ requests sign কৰিবলৈ দিয়ে, যাতে site এ নামৰ ওপৰত নিৰ্ভৰ নকৰি signature পৰীক্ষা কৰিব পাৰে। এই explainer টো সেই product managers আৰু engineering leads ৰ বাবে, যিসকলে specification সম্পূৰ্ণকৈ নপঢ়াকৈয়ে ই কি, ই কি সলনি কৰে, আৰু ই কি নকৰে সেয়া বুজিব লাগিব।

সংক্ষিপ্ত ৰূপ

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

IETF Web Bot Auth উদ্যোগ কি

IETF এ Web Bot Auth working group গঠন কৰিছিল cryptographically automated clients authenticate কৰাৰ পদ্ধতি standardize কৰিবলৈ আৰু সেইবোৰৰ আঁৰৰ operators বিষয়ে websites ক অধিক তথ্য দিবলৈ। Charter টো বিশেষকৈ মানুহে ব্যৱহাৰ কৰা sites ৰ ওপৰত কেন্দ্ৰিত, আৰু scope ত থকা client ৰ বিস্তৃত শ্ৰেণী উল্লেখ কৰে: crawlers, web archivers, link checkers, AI training crawlers, আৰু end users ৰ হৈ কাম কৰা AI agents।

Charter ত থকা দুটা exclusion product teams ৰ বাবে লক্ষণীয়। End-user authentication scope ৰ বাহিৰত, সেয়ে এইটো কোনো মানুহক লগ ইন কৰোৱাৰ উপায় নহয়। Bot reputation tracking ও scope ৰ বাহিৰত, সেয়ে standard এ request কোনে sign কৰিলে সেয়া কয়, কিন্তু সেই operator বিশ্বাসযোগ্য নে নহয় সেয়া নকয়।

Charter ত deliverable ৰ তিনিটা ধৰণ উল্লেখ আছে:

  1. মানুহৰ বাবে নিৰ্মিত websites ত automated clients authenticate কৰাৰ কৌশলসমূহৰ ওপৰত Standards track documents।
  2. domain name বা URL দৰে existing identifier ব্যৱহাৰ কৰি requesting bot বিষয়ে অধিক তথ্য প্ৰেৰণ কৰাৰ ওপৰত Standards track documents।
  3. key management, lifecycle আৰু deployment দৰে operational বিষয়সমূহৰ ওপৰত Best current practice বা informational documents।

November 2026 অনুসৰি document বিলাকৰ অৱস্থা

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 নহয়।

গোটটোৰ সৈতে আন কিছুমান individual drafts ও জড়িত আছে আৰু সেয়া আলোচনা হৈ আছে, যাৰ ভিতৰত registry আৰু agent card format, anonymous bot authentication, automated clients ৰ IP ranges প্ৰকাশৰ বাবে এটা JSON format, আৰু signed agent metadata ৰ বাবে এটা header ৰ প্ৰস্তাৱ অন্তৰ্ভুক্ত। Individual drafts প্ৰস্তাৱ; এই তাৰিখলৈকে সেইবোৰৰ কোনোটোকে গোটে adopt কৰা নাই।

Charter এ 2026 সময়সীমাত specifications ক approval ৰ বাবে IESG লৈ পঠোৱাৰ milestone set কৰিছিল। November 2026 অনুসৰি, protocol document এতিয়াও এটা working group draft। আপুনি working group ৰ বাবে IETF datatracker page আৰু protocol draft ত current state অনুসৰণ কৰিব পাৰে।

HTTP Message Signatures কেনেকৈ কাম কৰে

Web Bot Auth এ RFC 9421, HTTP Message Signatures ৰ ওপৰত নিৰ্মাণ কৰে, যি February 2024 ত Proposed Standard হিচাপে প্ৰকাশ পাইছিল। RFC 9421 এটা general mechanism: ই HTTP message ৰ নিৰ্বাচিত অংশবোৰ কেনেকৈ sign কৰিব লাগে আৰু signature ক headers ত কেনেকৈ carry কৰিব লাগে সেয়া সংজ্ঞায়িত কৰে। Web Bot Auth এ automated clients ৰ বাবে ইয়াক profile কৰে।

সহজ কথাত, signed agent request এনেকৈ কাম কৰে:

  1. Operator এ key pair সৃষ্টি কৰে। ই private key গোপন ৰাখে আৰু public key প্ৰকাশ কৰে।
  2. Client এ কি sign কৰিব তা বাছি লয়। ই request ৰ components বাছি লয়, যেনে target host বা URI আৰু creation time। Current draft এ authority বা target URI covered হ'ব লাগিব বুলি দাবী কৰে, সেয়ে এটা 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 components পুনৰ গঢ়ে, আৰু signature পৰীক্ষা কৰে। Check সফল হ'লে, request টি সেই key ৰ holder এ sign কৰিছে আৰু covered অংশবোৰ সলনি কৰা হোৱা নাই।

Draft এ site ক signature বিচৰাৰো অনুমতি দিয়ে। Origin এ সাধাৰণতে refusal সহ এটা Accept-Signature header পঠিয়াই signed requests বিচৰা বুলি সংকেত দিব পাৰে।

Key directory ধাৰণা

Site এ সঠিক public key বিচাৰি নাপালে signature ত কোনো মূল্য নাই। Web Bot Auth তাৰ উত্তৰ দিয়ে এটা key directory ৰ সহায়ত।

Current working group draft ত, client এ এটা HTTPS URL থকা এটা Signature-Agent header যোগ কৰে। সেই URL এ operator ৰ public keys ৰ directory এটা JSON Web Key Set হিচাপে প্ৰদান কৰে। Site এ directory fetch কৰে, signature ত থকা key identifier ৰ সৈতে মিলা key বাছি লয়, আৰু verify কৰে। Draft এ এটা well-known path, /.well-known/http-message-signatures-directory, ও সংজ্ঞায়িত কৰিছে, য'ত operator এ নিজৰ directory serve কৰিব পাৰে।

প্ৰডাক্ট টিমৰ বাবে উপযোগী ধাৰণাটো হ'ল URL টো পৰিচয় হৈ উঠে। Agent operator ক সি য'ত নিজৰ keys প্ৰকাশ কৰে তাৰ দ্বাৰা চিনাক্ত কৰা হয়, যাৰ ফলত signature টো operator এ নিয়ন্ত্ৰণ কৰা domain ৰ সৈতে জড়িত হয়। Key rotation নতুন key টো পুৰণি key ৰ লগতে প্ৰকাশ কৰি, তাৰ পিছত পুৰণি key টো আঁতৰাই কৰা হয়।

Verifying sites এ directories সাবধানে handle কৰিব লাগিব: normal HTTP rules অনুসৰি cache কৰক, size limits আৰু timeouts set কৰক, আৰু private network addresses ৰ পৰা fetch নকৰিব। এইবোৰ সাধাৰণ engineering concern, আৰু অনেক team এ verification কৰা এটা component পচন্দ কৰাৰ এটা কাৰণো এইটোৱেই।

Valid signature এ কি প্ৰমাণ কৰে, আৰু কি নকৰে

যিয়ে product policy লিখিছে, তেওঁৰ বাবে এইটো আটাইতকৈ গুৰুত্বপূর্ণ অংশ।

Valid signature এ প্ৰমাণ কৰে:

  • Request টো এটা specific private key ৰ holder এ sign কৰিছিল।
  • সেই key টো operator এ নিয়ন্ত্ৰণ কৰা এটা directory URL ত প্ৰকাশিত।
  • Request ৰ signed অংশবোৰ transit ত সলনি হোৱা নাছিল, আৰু signature validity window ৰ ভিতৰত আছে।

Valid signature এ প্ৰমাণ নকৰে:

  • Agent টোৱে action কৰিবলৈ authorized নে। Identifiable হোৱাটো permission নহয়। agent authorization চাওক।
  • Agent টোৱে কোনো specific person ৰ হৈ, বা সেই person এ দিয়া authority ৰ ভিতৰত কাম কৰে নে। delegated authority চাওক।
  • Operator বিশ্বাসযোগ্য নে, বা agent এ ভালভাৱে আচৰণ কৰিব নে। Reputation working group ৰ scope ৰ বাহিৰত স্পষ্টভাৱে আছে।
  • Sign নোহোৱা requests সম্পৰ্কে একো। Unsigned traffic ক নিজৰেই handling লাগে।

Valid signature ক কোনে request পঠিয়ালে তাৰ শক্তিশালী evidence হিচাপে গণ্য কৰক, তাৰ পিছত আপোনাৰ নিজৰ access control ক সিদ্ধান্ত ল'ব দিয়ক যে সেই sender এ কি কৰিব পাৰে।

প্ৰডাক্ট টিমে ইয়াৰ বাবে কি কৰা উচিত

Plan কৰিবলৈ RFC ৰ বাবে অপেক্ষা কৰিব নালাগে। Signed agent traffic এতিয়াই প্রস্তুত কৰিব পৰা বিষয়, যদিও draft ৰ কিছুমান detail সলনি হ'ব পাৰে বুলি আশা কৰিব লাগিব।

1. সিদ্ধান্ত লোৱাৰ আগতে measure কৰক

আপোনাৰ traffic ৰ কিমান অংশ automated, agents এ কোন route ব্যৱহাৰ কৰে, আৰু তাৰ কিমান অংশ signed সেয়া জানক। observation mode ত আৰম্ভ কৰক যাতে measuring এ আপোনাৰ users ৰ বাবে একো সলনি নকৰে।

2. Evidence ক policy ৰ পৰা পৃথক কৰক

আপুনি কি সিদ্ধান্ত ল'ব সেইটো দিয়াৰ পৰা verified, declared, inferred বা unknown evidence এ কি কয় সেয়া পৃথককৈ record কৰক। ইয়াৰ ফলত policies পঢ়িবলৈ সহজ হয় আৰু re-instrument নকৰাকৈয়ে সেইবোৰ কঠোৰ বা শিথিল কৰিব পাৰি। evidence basis entry ত চাৰিটা level ব্যাখ্যা কৰা হৈছে।

3. Verified agents ক এটা উন্নত path দিয়ক

য'ত যুক্তিযুক্ত, মানুহৰ বাবে নিৰ্মিত pages ৰ সলনি verified agents ক structured content বা agent-friendly flow দিয়ক। serving AI agents structured content guide ত pattern বিলাকৰ বৰ্ণনা আছে।

4. Authorization আপোনাৰ code তেই ৰাখক

Signature ব্যৱহাৰ কৰক কোনে request কৰিছে সেয়া জানিবলৈ। Existing permissions, scopes আৰু confirmations ব্যৱহাৰ কৰক সেয়া কি কৰিব পাৰে নিৰ্ধাৰণ কৰিবলৈ। High-impact actions ৰ বাবে তেওঁ কোনেই sign নকৰে, তেন্তে মানুহৰ confirmation এতিয়াও লাগিব পাৰে। protecting sensitive actions without blocking agents চাওক।

5. Unsigned আৰু Unknown traffic ৰ বাবে পৰিকল্পনা কৰক

Signing support agents আৰু tools অনুসৰি ভিন্ন হয়, সেয়ে কিছু সময়ৰ বাবে signed আৰু unsigned requests ৰ মিশ্ৰণ থাকিব বুলি আশা কৰক। Site-wide rule এটা বাছি লোৱাৰ সলনি, প্ৰতিটো route ৰ বাবে declared, inferred আৰু Unknown traffic ত কি হ'ব সেয়া নিৰ্ধাৰণ কৰক। handling Unknown traffic guide এ এইটো ব্যাখ্যা কৰে।

Proof of Actor এ Web Bot Auth কেনেকৈ ব্যৱহাৰ কৰে

Proof of Actor এ আপোনাৰ application ক প্ৰতিটো interaction ত কোন বা কি act কৰি আছে সেয়া কয়, Human, Human + AI, Agent বা Unknown, আৰু evidence basis বৰ্ণনা কৰে। Web Bot Auth signatures তাৰ অন্যতম শক্তিশালী evidence উৎস।

যেতিয়া কোনো agent এ HTTP Message Signatures ব্যৱহাৰ কৰি নিজৰ request sign কৰে, Proof of Actor এ operator ৰ প্ৰকাশিত key ৰ বিপৰীতে signature পৰীক্ষা কৰে। Check সফল হ'লে, result ত verified basis থাকে, আপোনাৰ team এ পৰ্যালোচনা কৰিব পৰা evidence ৰ সৈতে। যদি কোনো client এ header ত কেৱল নিজৰ নাম দিয়ে, result declared হয়। যদি সিদ্ধান্ত behavioral বা contextual signals ৰ ওপৰত নিৰ্ভৰ কৰে, তেন্তে ইয়াক inferred বুলি লেবেল কৰা হয়। Evidence যথেষ্ট নহ'লে, result Unknown হয়।

আপোনাৰ application এ সেই context ৰ সৈতে কি কৰিব সেয়া নিৰ্ধাৰণ কৰে। Policies route, actor class আৰু basis অনুসৰি লিখা হয়, allow, adapt, challenge, review আৰু rate-limit দৰে outcome সহ। Default হিচাপে একো enforce কৰা নহয়: আপুনি বাস্তৱ traffic ৰ বিপৰীতে policy preview কৰে আৰু নিজৰ code ত route by route enforce কৰে।

Founding teams এ Node.js middleware, Next.js, এটা edge integration, approved pages ত browser collector, generic HTTP API, বা MCP server integration ৰ জৰিয়তে evidence সংগ্ৰহ কৰিব পাৰে। integrations চাওক, আৰু verifying signed agent requests 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 ত আছে। নিৰ্বাচিত founding developer teams এ agreement কৰা usage limits ৰ ভিতৰত automatic billing নোহোৱাকৈ 12 months লৈকে free access পাব পাৰে। early access ৰ বাবে আবেদন কৰক আৰু আমাক কওক কোন route বিলাকত signed agents ব্যৱহাৰ হ'ব বুলি আপুনি আশা কৰে আৰু সেইবোৰৰ সৈতে কি কৰিব বিচাৰে।

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

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

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

Web Bot Auth কি?

Web Bot Auth হৈছে IETF working group, webbotauth, আৰু ই মানক কৰি থকা পদ্ধতি: automated clients এ HTTP requests ক HTTP Message Signatures (RFC 9421) ৰ সহায়ত sign কৰে আৰু নিজৰ public keys প্ৰকাশ কৰে, যাতে websites এ কোন operator এ request পঠিয়ালে সেয়া যাচাই কৰিব পাৰে।

Web Bot Auth এটা সম্পূৰ্ণ standard নেকি?

এতিয়াও নহয়। November 2026 অনুসৰি, মূল protocol document, draft-ietf-webbotauth-httpsig-protocol, revision 01 ত থকা এটা working group Internet-Draft। RFC 9421, যি signature format ৰ ওপৰত ই নিৰ্মিত, published Proposed Standard।

Valid Web Bot Auth signature এ মানে agent ক act কৰিবলৈ অনুমতি আছে নেকি?

নহয়। ই কেৱল কোন key এ request sign কৰিলে আৰু signed অংশবোৰ transit ত সলনি হোৱা নাছিল সেয়া প্ৰমাণ কৰে। সেই agent এ data read কৰিব পাৰে নে, form submit কৰিব পাৰে নে, বা কোনো particular user ৰ হৈ act কৰিব পাৰে নে, সেয়া আপোনাৰ application এ কৰা authorization decision।

প্ৰডাক্ট টিমে নিজে Web Bot Auth implement কৰিব লাগিব নেকি?

Sites এ signatures verify কৰে; যদি তেওঁলোকে automated clients নচলাই, তেন্তে নিজে একো sign কৰিব নালাগে। Verification ত key directories fetch কৰা, সুৰক্ষিতভাৱে cache কৰা আৰু signatures পৰীক্ষা কৰা অন্তৰ্ভুক্ত, যি Proof of Actor ৰ দৰে tool এ আপোনাৰ বাবে কৰিব পাৰে।

যিবোৰ agents এ নিজৰ requests sign নকৰে, সেইবোৰৰ সৈতে কি কৰিব লাগে?

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

Proof of Actor Web Bot Auth কেনেকৈ ব্যৱহাৰ কৰে?

ই HTTP Message Signatures ক প্ৰকাশিত key ৰ বিপৰীতে পৰীক্ষা কৰে আৰু check সফল হ'লে result ক verified basis সহ প্ৰদৰ্শন কৰে। তাৰ পিছত আপোনাৰ policies এ verified agents ক declared বা Unknown traffic ৰ পৰা পৃথকভাৱে handle কৰিব পাৰে।

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

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

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

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