मुख्य सामग्री पर जाएं
व्याख्या

Product टीमों के लिए Web Bot Auth: signed agent requests का आपकी roadmap के लिए क्या अर्थ है

AI agents और crawlers को अब increasingly ऐसी एक विधि चाहिए जिससे वे यह साबित कर सकें कि वे कौन हैं, बिना ऐसे User-Agent string पर निर्भर हुए जिसे कोई भी copy कर सके। IETF का Web Bot Auth work इसे standardize करने का प्रमुख प्रयास है। यह product managers और engineering leads के लिए एक सीधी व्याख्या है: यह कैसे काम करता है, क्या साबित करता है, November 2026 तक इसकी स्थिति क्या है, और इसके लिए कैसे योजना बनानी चाहिए।

Early Access प्राप्त करेंयह कैसे काम करता है, देखें
Toshendra Sharma

द्वारा Toshendra Sharmaसंस्थापक और CEO, AgentCredia · Updated November 13, 2026

कई वर्षों तक, किसी automated client के पास website को यह बताने का एकमात्र तरीका कि वह कौन है, User-Agent header में एक नाम और, कुछ बड़े operators के लिए, published IP addresses की सूची या reverse DNS check था। Names को copy करना आसान है। Network lists केवल उन्हीं operators को cover करती हैं जो उन्हें maintain करते हैं। जैसे-जैसे AI agents web पर वास्तविक लोगों की ओर से काम करने लगे हैं, यह gap अब केवल security समस्या नहीं, बल्कि product समस्या भी बन गई है।

Web Bot Auth इसे बंद करने का प्रमुख प्रयास है। यह automated clients को अपनी requests एक ऐसे key से sign करने की सुविधा देता है जिसे वे control और publish करते हैं, ताकि site किसी name पर trust करने के बजाय signature check कर सके। यह explainer उन product managers और engineering leads के लिए है जिन्हें specifications को end to end पढ़े बिना यह समझना है कि यह क्या है, क्या बदलता है, और क्या नहीं बदलता।

संक्षिप्त रूप में

  • यह क्या है: एक IETF working group, webbotauth, और automated HTTP clients को authenticate करने के लिए वह approach जिसे यह standardize कर रहा है।
  • यह कैसे काम करता है: client प्रत्येक request के कुछ हिस्सों को HTTP Message Signatures (RFC 9421) का उपयोग करके sign करता है और अपनी public keys की directory की ओर संकेत करता है। Site key fetch करती है और signature verify करती है।
  • यह क्या साबित करता है: किस key ने request sign की, और यह कि signed parts transit में बदले नहीं गए।
  • यह क्या साबित नहीं करता: कि agent उस action के लिए authorized है जिसे वह मांग रहा है, कि वह किसी particular user की ओर से act करता है, या कि वह ठीक व्यवहार करेगा।
  • November 2026 तक स्थिति: RFC 9421 एक published Proposed Standard है। Web Bot Auth protocol document अभी एक working group Internet-Draft है, RFC नहीं।
  • क्या करना चाहिए: valid signatures को मजबूत evidence मानने की योजना बनाएं, unsigned traffic को handle करते रहें, और authorization decisions अपने code में रखें।

IETF Web Bot Auth work क्या है

IETF ने Web Bot Auth working group को यह standardize करने के लिए charter किया कि automated clients को cryptographically authenticate करने की methods क्या हों, और websites को उनके पीछे के operators के बारे में अधिक जानकारी कैसे दी जाए। Charter मुख्यतः उन sites पर केंद्रित है जो लोगों को serve करती हैं, और यह scope में clients का एक व्यापक set नामित करता है: crawlers, web archivers, link checkers, AI training crawlers, और end users की ओर से act करने वाले AI agents।

Charter में दो exclusions product teams के लिए महत्वपूर्ण हैं। End-user authentication scope से बाहर है, इसलिए यह किसी person को log in कराने का तरीका नहीं है। Bot reputation tracking भी scope से बाहर है, इसलिए standard आपको यह बताता है कि request किसने sign की, यह नहीं कि वह operator भरोसेमंद है या नहीं।

Charter तीन प्रकार के deliverables सूचीबद्ध करता है:

  1. लोगों के लिए बने websites पर automated clients को authenticate करने की techniques पर Standards track documents।
  2. किसी requesting bot के बारे में अधिक जानकारी देने पर Standards track documents, existing identifier जैसे domain name या URL का उपयोग करते हुए।
  3. key management, lifecycle और deployment जैसे operational topics पर Best current practice या informational documents।

November 2026 तक documents की स्थिति

November 2026 तक, working group के पास एक adopted working group document है: draft-ietf-webbotauth-httpsig-protocol, शीर्षक "HTTP Message Signatures for automated traffic", revision 01, dated October 29, 2026। यह एक Internet-Draft है, जिसका अर्थ है कि यह काम चल रहा document है और अभी भी बदल सकता है। यह RFC नहीं है।

कई individual drafts भी group से जुड़े हैं और चर्चा में हैं, जिनमें registry और agent card format, anonymous bot authentication, automated clients के IP ranges publish करने के लिए एक JSON format, और signed agent metadata के लिए एक header पर proposals शामिल हैं। Individual drafts proposals हैं; इनमें से किसी को भी इस तारीख तक group ने adopt नहीं किया है।

Charter ने 2026 के दौरान specifications को approval के लिए IESG को भेजने के milestones तय किए थे। November 2026 तक, protocol document एक working group draft ही है। आप current state को IETF datatracker page for the working group और protocol draft पर follow कर सकते हैं।

HTTP Message Signatures कैसे काम करते हैं

Web Bot Auth, RFC 9421, HTTP Message Signatures पर आधारित है, जो February 2024 में Proposed Standard के रूप में प्रकाशित हुआ। RFC 9421 एक general mechanism है: यह बताता है कि HTTP message के किन selected parts को sign करना है और signature को headers में कैसे carry करना है। Web Bot Auth इसे automated clients के लिए profile करता है।

सरल शब्दों में, signed agent request इस तरह काम करती है:

  1. Operator एक key pair बनाता है। वह private key को secret रखता है और public key publish करता है।
  2. Client तय करता है क्या sign करना है। वह request के components चुनता है, जैसे target host या URI और creation time। Current draft के अनुसार authority या target URI को cover करना आवश्यक है, ताकि एक site के लिए बनी signature को दूसरे site पर simply replay न किया जा सके।
  3. Client sign करके भेजता है। Request में एक Signature-Input header होता है जो बताता है कि क्या sign किया गया और किस key से, और एक Signature header होता है जिसमें signature value होती है। Draft web-bot-auth tag का उपयोग करता है और हर signature पर creation तथा expiry times की अपेक्षा करता है।
  4. Site verify करती है। वह public key ढूंढती है, उसे मिले request से signed components दोबारा बनाती है, और signature check करती है। अगर check pass हो जाता है, तो request उस key के holder ने sign की थी और covered parts बदले नहीं गए थे।

Draft site को signature मांगने की भी अनुमति देता है। Origin एक Accept-Signature header भेज सकता है, आम तौर पर refusal के साथ, यह संकेत देने के लिए कि वह signed requests चाहता है।

Key directory का विचार

Signature तभी उपयोगी है जब site सही public key ढूंढ सके। Web Bot Auth इसका उत्तर key directory से देता है।

Current working group draft में, client एक Signature-Agent header जोड़ता है जिसमें HTTPS URL होता है। वह URL operator की public keys की 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 teams के लिए उपयोगी विचार यह है कि URL ही identity बन जाता है। Agent operator की पहचान इस बात से होती है कि वह अपनी keys कहाँ publish करता है, जिससे signature उस domain से जुड़ती है जिस पर operator का control है। Key rotation old key को remove करने से पहले नए key को old के साथ publish करके काम करती है।

Verifying sites को directories को सावधानी से handle करना चाहिए: normal HTTP rules के अनुसार cache करें, size limits और timeouts तय करें, और private network addresses से fetch करने से बचें। ये standard engineering concerns हैं, और यही कारण है कि कई teams ऐसा component पसंद करती हैं जो verification उनके लिए कर दे।

Valid signature क्या साबित करती है, और क्या नहीं

यह सबसे महत्वपूर्ण section है, विशेष रूप से किसी भी व्यक्ति के लिए जो product policy लिख रहा है।

एक valid signature यह साबित करती है:

  • Request एक specific private key के holder ने sign की थी।
  • वह key operator द्वारा नियंत्रित एक directory URL पर प्रकाशित है।
  • Request के signed parts transit में बदले नहीं गए थे, और signature अपनी validity window के भीतर है।

एक valid signature यह साबित नहीं करती है:

  • कि agent authorized है action करने के लिए। Identifiable होना permission नहीं है। agent authorization देखें।
  • कि agent किसी specific person की ओर से act करता है, या उस person द्वारा दी गई authority के भीतर act करता है। delegated authority देखें।
  • कि operator भरोसेमंद है या agent अच्छा व्यवहार करेगा। Reputation working group के scope से स्पष्ट रूप से बाहर है।
  • उन requests के बारे में कुछ भी जो signed नहीं हैं। Unsigned traffic को फिर भी अपनी अलग handling चाहिए।

Valid signature को कौन request भेज रहा है इस पर मजबूत evidence मानें, और फिर अपने access control को तय करने दें कि वह sender क्या कर सकता है।

Product teams को इसके बारे में क्या करना चाहिए

Plan बनाने के लिए आपको RFC का इंतजार करने की जरूरत नहीं है। Signed agent traffic ऐसी चीज है जिसके लिए आप अभी तैयारी कर सकते हैं, इस अपेक्षा के साथ कि draft के कुछ details बदल सकते हैं।

1. निर्णय लेने से पहले मापें

पता करें कि आपके traffic का कितना हिस्सा automated है, agents किन routes का उपयोग करते हैं, और उसमें से कितना signed है। observation mode में शुरुआत करें ताकि measurement आपके users के लिए कुछ न बदले।

2. Evidence को policy से अलग रखें

यह दर्ज करें कि evidence क्या कहता है, verified, declared, inferred या unknown, और इसे उससे अलग रखें जो आप करने का निर्णय लेते हैं। इससे policies पढ़ने में आसान रहती हैं और आप उन्हें बिना re-instrumenting के कड़ा या नरम कर सकते हैं। evidence basis entry चार levels समझाती है।

3. Verified agents को बेहतर path दें

जहाँ उचित हो, verified agents को लोगों के लिए बनी pages के बजाय structured content या agent-friendly flow दें। serving AI agents structured content पर guide patterns को कवर करती है।

4. Authorization अपने code में रखें

Signature का उपयोग यह जानने के लिए करें कि कौन पूछ रहा है। अपने मौजूदा permissions, scopes और confirmations का उपयोग यह तय करने के लिए करें कि वे क्या कर सकते हैं। High-impact actions के लिए अभी भी human confirmation चाहिए हो सकती है, चाहे request किसने sign की हो। protecting sensitive actions without blocking agents देखें।

5. Unsigned और Unknown traffic के लिए योजना बनाएं

Signing के लिए support agents और tools में अलग-अलग होता है, इसलिए कुछ समय तक signed और unsigned requests का मिश्रण अपेक्षित है। Declared, inferred और Unknown traffic के साथ क्या होगा, यह प्रति route तय करें, न कि एक site-wide rule चुनें। 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 sources में से एक हैं।

जब कोई agent अपनी request को HTTP Message Signatures से sign करता है, तो Proof of Actor signature को operator की published key के against check करता है। यदि check pass हो जाता है, तो result के साथ एक verified basis report की जाती है, साथ में वह evidence भी जिसे आपकी team review कर सकती है। यदि कोई client केवल header में अपना नाम बताता है, तो result declared होता है। यदि निष्कर्ष behavioral या contextual signals पर आधारित है, तो उसे inferred label दिया जाता है। यदि evidence पर्याप्त नहीं है, तो result Unknown होता है।

आपकी application तय करती है कि इस context के साथ क्या करना है। Policies प्रति route, प्रति actor class और प्रति basis लिखी जाती हैं, जिनमें allow, adapt, challenge, review और rate-limit जैसे outcomes होते हैं। Default रूप से कुछ भी enforce नहीं होता: आप real traffic के against 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 collect कर सकते हैं। integrations और verifying signed agent requests guide practical steps बताती हैं।

Proof of Actor standard की उसी सीमा का पालन करता है: verified signature आपको बताती है कि request किस key ने sign की, यह नहीं कि agent authorized है या नहीं। Authorization आपके पास ही रहती है। evidence and limits page यह साफ़ बताती है कि हर result क्या support कर सकता है और क्या नहीं।

शुरुआत करें

Proof of Actor private beta में है। Selected founding developer teams agreed usage limits के भीतर up to 12 months का free access पा सकती हैं, बिना automatic billing के। Apply for early access करें और हमें बताएं कि आप किन routes पर 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
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 clients HTTP requests को HTTP Message Signatures (RFC 9421) से sign करते हैं और अपनी public keys publish करते हैं, ताकि websites verify कर सकें कि request किस operator ने भेजी थी।

क्या Web Bot Auth एक finished standard है?

अभी नहीं। November 2026 तक, main 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 करने की अनुमति है?

नहीं। यह साबित करता है कि request किस key ने sign की और signed parts बदले नहीं गए। क्या वह agent data पढ़ सकता है, form submit कर सकता है, या किसी specific user की ओर से act कर सकता है, यह एक authorization decision है जो आपकी application अभी भी करती है।

क्या product teams को Web Bot Auth खुद implement करना चाहिए?

Sites signatures verify करती हैं; उन्हें कुछ sign करने की ज़रूरत नहीं होती, जब तक वे खुद automated clients भी न चलाती हों। Verification में key directories fetch करना, उन्हें safely cache करना, और signatures check करना शामिल है, जिसे Proof of Actor जैसा tool आपके लिए कर सकता है।

उन agents के साथ हमें क्या करना चाहिए जो अपने requests sign नहीं करते?

उन्हें उपलब्ध evidence के अनुसार handle करें: declared, inferred या Unknown। कुछ समय तक signed और unsigned traffic का मिश्रण अपेक्षित है, और site-wide rule के बजाय प्रति route fallback तय करें।

Proof of Actor Web Bot Auth का उपयोग कैसे करता है?

यह HTTP Message Signatures को published key के against check करता है और, जब check pass हो जाता है, result को verified basis के साथ report करता है। फिर आपकी policies verified agents को declared या Unknown traffic से अलग तरह से treat कर सकती हैं।

जानें कि आपका app कौन उपयोग कर रहा है।

founding developers के छोटे समूह के लिए private beta।

Early Access प्राप्त करेंमूल्य निर्धारण देखें

क्या पहले बात करना पसंद करेंगे? founders से बात करें