स्पष्टीकरण

उत्पादन संघांसाठी Web Bot Auth: स्वाक्षरी केलेल्या agent विनंत्या तुमच्या roadmap साठी काय अर्थ ठेवतात

AI agents आणि crawlers यांना आता अशी पद्धत हवी आहे ज्याद्वारे ते कोण आहेत हे User-Agent स्ट्रिंगवर अवलंबून न राहता सिद्ध करू शकतील, कारण ती कोणीही कॉपी करू शकतो. IETF चे Web Bot Auth कार्य हे त्यासाठी मानकीकरण करण्याचे अग्रगण्य प्रयत्न आहे. product managers आणि engineering leads साठी येथे एक सोपे स्पष्टीकरण आहे: ते कसे कार्य करते, काय सिद्ध करते, November 2026 पर्यंतची त्याची स्थिती काय आहे, आणि त्यासाठी कसे नियोजन करायचे.

लवकर प्रवेश मिळवा ते कसे कार्य करते ते अन्वेषित करा

लेखक Toshendra Sharmaसंस्थापक आणि CEO, AgentCredia · Updated November 13, 2026

थोडक्यात उत्तर

Web Bot Auth हे IETF चे कार्य आहे ज्यामध्ये automated clients, त्यात AI agents यांचाही समावेश आहे, त्यांना त्यांच्या HTTP requests वर HTTP Message Signatures (RFC 9421) वापरून स्वाक्षरी करता येते आणि ते keys प्रकाशित करता येतात, जेणेकरून sites त्या तपासू शकतील. वैध signature हे कोणत्या key ने request वर स्वाक्षरी केली हे सिद्ध करते, agent ला कृती करण्याची परवानगी आहे हे नाही. November 2026 पर्यंत core specification हा working group Internet-Draft आहे, त्यामुळे product teams नी signatures मजबूत evidence म्हणून वापरण्याची तयारी ठेवावी, आणि तरीही unsigned traffic हाताळत राहावे.

वर्षानुवर्षे, automated client स्वतः कोण आहे हे वेबसाइटला सांगण्याचा एकमेव मार्ग User-Agent header मधील नाव आणि, काही मोठ्या operators साठी, published IP addresses ची यादी किंवा reverse DNS check इतकाच होता. नावे सहज कॉपी करता येतात. Network lists फक्त ती maintain करणाऱ्या operators पर्यंत मर्यादित असतात. AI agents जेव्हा खऱ्या लोकांसाठी web वर कृती करू लागतात, तेव्हा तो फरक केवळ security चा नाही तर product चा प्रश्न बनतो.

Web Bot Auth हे तो फरक भरून काढण्याचे अग्रगण्य प्रयत्न आहे. ते automated clients ना त्यांच्या नियंत्रणात आणि प्रकाशित key वापरून requests वर स्वाक्षरी करण्याची पद्धत देते, जेणेकरून site नावावर विश्वास ठेवण्याऐवजी signature तपासू शकेल. हे स्पष्टीकरण product managers आणि engineering leads साठी आहे ज्यांना specifications सुरुवातीपासून शेवटपर्यंत वाचल्याशिवाय हे काय आहे, काय बदलते, आणि काय बदलत नाही हे समजून घ्यायचे आहे.

थोडक्यात

ते काय आहे: एक IETF working group, webbotauth, आणि automated HTTP clients authenticate करण्यासाठी ते जे approach मानकीकृत करत आहे.
ते कसे कार्य करते: client प्रत्येक request मधील काही भाग HTTP Message Signatures (RFC 9421) वापरून स्वाक्षरी करतो आणि त्याच्या public keys च्या directory कडे निर्देश करतो. Site key fetch करते आणि signature verify करते.
ते काय सिद्ध करते: कोणत्या key ने request वर स्वाक्षरी केली, आणि प्रवासात स्वाक्षरी केलेले भाग बदलले गेले नाहीत हे.
ते काय सिद्ध करत नाही: agent ला तो मागत असलेली कृती करण्याची परवानगी आहे, तो एखाद्या विशिष्ट user साठी कार्य करतो, किंवा तो चांगले वागेल हे.
November 2026 पर्यंतची स्थिती: RFC 9421 हा प्रकाशित Proposed Standard आहे. Web Bot Auth protocol document हा working group Internet-Draft आहे, अजून RFC नाही.
काय करायचे: वैध signatures ना मजबूत evidence म्हणून हाताळण्याची योजना करा, unsigned traffic हाताळत राहा, आणि authorization निर्णय तुमच्या स्वतःच्या code मध्ये ठेवा.

IETF Web Bot Auth कार्य काय आहे

IETF ने Web Bot Auth working group ला automated clients चे cryptographically authentication करण्याच्या पद्धती आणि त्यांच्यामागील operators बद्दल websites ना अधिक माहिती देण्याच्या पद्धती मानकीकृत करण्यासाठी charter दिले आहे. हा charter मुख्यतः लोकांना सेवा देणाऱ्या sites वर लक्ष केंद्रित करतो, आणि scope मध्ये clients चा विस्तृत संच नमूद करतो: crawlers, web archivers, link checkers, AI training crawlers आणि end users साठी कृती करणारे AI agents.

Charter मधील दोन अपवाद product teams साठी लक्षात घेण्यासारखे आहेत. End-user authentication हे scope बाहेर आहे, त्यामुळे ही एखाद्या व्यक्तीला sign in करण्याची पद्धत नाही. Bot reputation चा मागोवा घेणेही scope बाहेर आहे, त्यामुळे standard तुम्हाला request कोणी sign केली हे सांगतो, तो operator विश्वासार्ह आहे का नाही हे नाही.

Charter मध्ये तीन प्रकारच्या deliverables नमूद केल्या आहेत:

लोकांसाठी तयार केलेल्या websites वर automated clients authenticate करण्याच्या तंत्रांवरील Standards track documents.
domain name किंवा URL सारखा विद्यमान identifier वापरून requesting bot बद्दल अधिक माहिती देणाऱ्या Standards track documents.
key management, lifecycle आणि deployment यांसारख्या operational विषयांवरील Best current practice किंवा informational documents.

दस्तऐवजांची स्थिती, November 2026 पर्यंत

November 2026 पर्यंत, working group कडे एक adopted working group document आहे: draft-ietf-webbotauth-httpsig-protocol, शीर्षक "HTTP Message Signatures for automated traffic", revision 01, date 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 हे प्रस्ताव आहेत; या तारखेपर्यंत त्यापैकी कोणताही गटाने स्वीकारलेला नाही.

Charter ने 2026 दरम्यान specifications IESG कडे approval साठी पाठवण्यासाठी milestones निश्चित केले. 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 म्हणून प्रकाशित झाले. RFC 9421 ही एक सर्वसाधारण mechanism आहे: ती HTTP message चे निवडलेले भाग कसे sign करायचे आणि header मध्ये signature कसा carry करायचा हे परिभाषित करते. Web Bot Auth त्याला automated clients साठी profile करते.

सोप्या शब्दांत, signed agent request अशी कार्य करते:

Operator key pair तयार करतो. तो private key गुप्त ठेवतो आणि public key प्रकाशित करतो.
Client काय sign करायचे ते निवडतो. तो request मधील components निवडतो, जसे target host किंवा URI आणि creation time. Current draft authority किंवा target URI कव्हर करणे आवश्यक करते, त्यामुळे एका site साठीची signature दुसऱ्या site विरुद्ध सहजपणे replay करता येत नाही.
Client स्वाक्षरी करून पाठवतो. Request मध्ये Signature-Input header असतो जो काय sign केले गेले आणि कोणत्या key ने, हे दाखवतो, आणि Signature header असतो ज्यामध्ये signature value असते. Draft मध्ये web-bot-auth tag वापरली जाते आणि प्रत्येक signature साठी creation आणि expiry times अपेक्षित असतात.
Site verify करते. ती public key शोधते, प्राप्त request मधून signed components पुन्हा तयार करते, आणि signature तपासते. तपासणी यशस्वी झाली तर request त्या key च्या धारकाने sign केलेली होती आणि कव्हर केलेले भाग बदलले गेले नाहीत.

Draft साइटला signature मागण्याची परवानगी देखील देतो. Origin एक Accept-Signature header, साधारणपणे refusal सह, पाठवू शकतो, ज्यायोगे तो signed requests हवे आहेत हे सूचित करतो.

key directory कल्पना

Signature तेव्हाच उपयुक्त असते जेव्हा site योग्य public key शोधू शकते. Web Bot Auth याचे उत्तर key directory द्वारे देते.

सध्याच्या working group draft मध्ये, client Signature-Agent header जोडतो ज्यात HTTPS URL असते. ती 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 करू शकतो.

Product teams साठी उपयुक्त कल्पना अशी आहे की URL हीच identity बनते. Agent operator ज्या domain वर आपली keys प्रकाशित करतो त्याद्वारे ओळखला जातो, ज्यामुळे signature operator नियंत्रित करतो त्या domain शी जोडली जाते. Key rotation जुनी key काढून नवी key जुन्यासोबत प्रकाशित करून, आणि नंतर जुनी key काढून टाकून कार्य करते.

Verifying sites नी directories काळजीपूर्वक हाताळल्या पाहिजेत: त्यांना normal HTTP rules नुसार cache करा, size limits आणि timeouts ठेवा, आणि private network addresses वरून fetch करणे टाळा. या नेहमीच्या engineering concerns आहेत, आणि म्हणूनच अनेक teams verification त्यांच्यासाठी करणारा component पसंत करतात.

वैध signature काय सिद्ध करते, आणि काय नाही

Policy लिहिणाऱ्या प्रत्येकासाठी हा सर्वात महत्त्वाचा विभाग आहे.

वैध signature हे सिद्ध करते:

Request एका विशिष्ट private key च्या धारकाने sign केली होती.
ती key operator नियंत्रित करत असलेल्या directory URL वर प्रकाशित आहे.
Request चे स्वाक्षरी केलेले भाग प्रवासात बदलले गेले नाहीत, आणि signature तिच्या validity window मध्ये आहे.

वैध signature हे सिद्ध करत नाही:

तो agent ती कृती करण्यासाठी authorized आहे हे. ओळखता येणे म्हणजे परवानगी नाही. agent authorization पहा.
तो agent एखाद्या विशिष्ट person साठी, किंवा त्या person ने दिलेल्या अधिकारांच्या मर्यादेत काम करतो हे. delegated authority पहा.
Operator विश्वासार्ह आहे किंवा agent चांगले वागेल हे. Reputation हे working group च्या scope बाहेर स्पष्टपणे आहे.
स्वाक्षरी न केलेल्या requests बद्दल काहीही. Unsigned traffic ला अजूनही स्वतःची handling आवश्यक आहे.

वैध signature ला कोणी request पाठवली याचे मजबूत evidence म्हणून माना, आणि मग तुमच्या स्वतःच्या access control ला तो sender काय करू शकतो हे ठरवू द्या.

Product teams नी याबाबत काय करावे

Plan करण्यासाठी तुम्हाला RFC ची वाट पाहण्याची गरज नाही. Signed agent traffic ही अशी गोष्ट आहे ज्यासाठी तुम्ही आत्ताच तयारी करू शकता, या अपेक्षेसह की draft चे काही तपशील बदलू शकतात.

1. निर्णय घेण्यापूर्वी मोजा

तुमच्या traffic पैकी किती भाग automated आहे, agents कोणते routes वापरतात, आणि त्यापैकी किती भाग signed आहे हे शोधा. observation mode मध्ये सुरू करा, जेणेकरून मोजमापामुळे तुमच्या users साठी काहीही बदलणार नाही.

2. evidence आणि policy वेगळे ठेवा

तुम्ही काय करायचे ठरवता त्यापासून evidence काय सांगते ते, verified, declared, inferred किंवा unknown, वेगळे नोंदवा. यामुळे policies वाचायला सोप्या राहतात आणि instrumentation पुन्हा न करता तुम्ही त्यांना घट्ट किंवा सैल करू शकता. evidence basis entry मध्ये चार स्तर समजावले आहेत.

3. verified agents ना चांगला मार्ग द्या

जिथे अर्थपूर्ण असेल तिथे verified agents ना लोकांसाठी तयार केलेल्या pages ऐवजी structured content किंवा agent-friendly flow द्या. AI agents ना structured content देणे या guide मध्ये patterns दिले आहेत.

4. authorization तुमच्या code मध्ये ठेवा

कोण विचारत आहे हे जाणून घेण्यासाठी signature वापरा. त्यांना काय करता येईल हे ठरवण्यासाठी तुमच्या विद्यमान permissions, scopes आणि confirmations वापरा. उच्च-प्रभावी actions साठी, request कोणीही sign केली असली तरी human confirmation आवश्यक असू शकते. संवेदनशील actions agents ना न रोखता सुरक्षित ठेवणे पहा.

5. unsigned आणि Unknown traffic साठी योजना करा

Signing साठीचा पाठिंबा agents आणि tools मध्ये वेगवेगळा असतो, त्यामुळे काही काळ signed आणि unsigned requests यांचे मिश्रण अपेक्षित ठेवा. एकाच site-wide नियमाऐवजी प्रत्येक route साठी declared, inferred आणि Unknown traffic बरोबर काय होईल ते ठरवा. Unknown traffic हाताळणे हा guide हे स्पष्ट करतो.

Proof of Actor Web Bot Auth कसा वापरतो

Proof of Actor तुमच्या application ला प्रत्येक interaction मध्ये कोण किंवा काय कृती करत आहे ते सांगतो, Human, Human + AI, Agent किंवा Unknown, आणि evidence basis नमूद करतो. Web Bot Auth signatures हे त्याच्या सर्वात मजबूत evidence sources पैकी एक आहेत.

जेव्हा agent HTTP Message Signatures वापरून आपल्या request वर स्वाक्षरी करतो, तेव्हा Proof of Actor operator च्या प्रकाशित key विरुद्ध signature तपासतो. तपासणी यशस्वी झाली तर परिणामासह verified basis मिळते, आणि तुमची team पुनरावलोकन करू शकेल असे evidence देखील मिळते. जर client फक्त header मध्ये स्वतःचे नाव लिहित असेल, तर परिणाम declared असतो. जर निष्कर्ष व्यवहारात्मक किंवा संदर्भात्मक signals वर आधारित असेल, तर त्याला inferred असे लेबल दिले जाते. पुरावा पुरेसा नसेल, तर परिणाम Unknown असतो.

तुमचे application त्या context सोबत काय करायचे ते ठरवते. Policies प्रत्येक route, प्रत्येक actor class आणि प्रत्येक basis साठी लिहिल्या जातात, आणि allow, adapt, challenge, review आणि rate-limit यांसारखे outcomes दिले जाऊ शकतात. डीफॉल्टने काहीही enforce केले जात नाही: तुम्ही real traffic वर policy preview करता आणि ती route by route, तुमच्या स्वतःच्या code मध्ये enforce करता.

Founding teams Node.js middleware, Next.js, edge integration, approved pages वरील browser collector, generic HTTP API, किंवा MCP server integration द्वारे evidence गोळा करू शकतात. integrations पहा, आणि signed agent requests verify करणे या guide मध्ये प्रत्यक्ष पायऱ्या दिल्या आहेत.

Proof of Actor standard ज्या मर्यादेपर्यंत जातो तीच मर्यादा पाळतो: verified signature तुम्हाला कोणत्या key ने request वर स्वाक्षरी केली हे सांगते, agent authorized आहे का नाही हे नाही. Authorization तुमच्याकडेच राहते. evidence and limits page प्रत्येक परिणाम काय समर्थन करू शकतो आणि काय करू शकत नाही हे स्पष्ट करते.

सुरुवात करा

Proof of Actor private beta मध्ये आहे. निवडक founding developer teams ना agreed usage limits अंतर्गत 12 महिन्यांपर्यंत free access मिळू शकतो, आणि automatic billing नसते. early access साठी अर्ज करा आणि आम्हाला सांगा की signed agents कोणते routes वापरतील अशी अपेक्षा आहे आणि तुम्ही त्यांच्याबरोबर काय करू इच्छिता.

विकसकांसाठी

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 च्या शेजारी नोंदवा आणि तुम्ही policy निवडेपर्यंत काहीही बदलू नका. Node.js integration guide वाचा

वारंवार विचारले जाणारे प्रश्न

Web Bot Auth म्हणजे काय?

Web Bot Auth हे IETF working group, webbotauth, याचे नाव आहे, आणि ते ज्या दृष्टिकोनाचे मानकीकरण करत आहे तो असा आहे: automated clients HTTP Message Signatures (RFC 9421) वापरून HTTP requests वर स्वाक्षरी करतात आणि त्यांचे public keys प्रकाशित करतात, जेणेकरून websites कोणत्या operator ने request पाठवली हे verify करू शकतील.

Web Bot Auth हा पूर्ण झालेला standard आहे का?

अजून नाही. November 2026 पर्यंत, मुख्य protocol document, draft-ietf-webbotauth-httpsig-protocol, हा revision 01 मधील working group Internet-Draft आहे. RFC 9421, ज्यावर तो आधारलेला signature format आहे, हा प्रकाशित Proposed Standard आहे.

वैध Web Bot Auth signature म्हणजे agent ला कृती करण्याची परवानगी आहे का?

नाही. ते कोणत्या key ने request वर स्वाक्षरी केली आणि स्वाक्षरी केलेले भाग बदलले गेले नाहीत हे सिद्ध करते. तो agent data वाचू शकतो का, form submit करू शकतो का, किंवा एखाद्या विशिष्ट user साठी कृती करू शकतो का, हा authorization निर्णय तुमचे application अजूनही स्वतः घेते.

Product teams ना Web Bot Auth स्वतः implement करणे आवश्यक आहे का?

Sites signatures verify करतात; जोपर्यंत ते स्वतः automated clients चालवत नाहीत तोपर्यंत त्यांना काहीही sign करण्याची गरज नाही. Verification मध्ये key directories fetch करणे, त्यांना सुरक्षितपणे cache करणे आणि signatures तपासणे समाविष्ट आहे, आणि हे Proof of Actor सारखे tool तुमच्यासाठी करू शकते.

जे agents त्यांच्या requests वर स्वाक्षरी करत नाहीत त्यांच्याबाबत आपण काय करावे?

उपलब्ध evidence नुसार त्यांना हाताळा: declared, inferred किंवा Unknown. काही काळ signed आणि unsigned traffic यांचे मिश्रण अपेक्षित ठेवा, आणि एकाच site-wide नियमाऐवजी प्रत्येक route साठी fallback ठेवा.

Proof of Actor Web Bot Auth कसा वापरतो?

तो प्रकाशित key विरुद्ध HTTP Message Signatures तपासतो, आणि तपासणी यशस्वी झाली तर परिणाम verified basis सह नोंदवतो. त्यानंतर तुमची policy verified agents ना declared किंवा Unknown traffic पासून वेगळ्या पद्धतीने हाताळू शकते.

तुमचे app कोण वापरत आहे ते जाणून घ्या.

founding developers च्या छोट्या गटासाठी private beta.

लवकर प्रवेश मिळवा किमती पहा

आधी बोलणे पसंत आहे? founders शी बोला