સ્પષ્ટીકરણ

પ્રોડક્ટ ટીમો માટે Web Bot Auth: સહી કરેલી એજન્ટ વિનંતીઓનો તમારા રોડમૅપ માટે શું અર્થ થાય છે

AI એજન્ટો અને ક્રોલરોએ તે કોણ છે તે સાબિત કરવાની રીતની વધુને વધુ જરૂર પડે છે, એવી રીત જે કોઈપણ કૉપી કરી શકે તેવી User-Agent string પર આધારિત ન હોય. IETF Web Bot Authનું કાર્ય તેને માનકીકૃત કરવાની અગ્રણી કોશિશ છે. અહીં પ્રોડક્ટ મેનેજરો અને એન્જિનિયરિંગ લીડ્સ માટે સાદી સમજણ છે: તે કેવી રીતે કામ કરે છે, શું સાબિત કરે છે, 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) સાથે sign કરવા અને keys પ્રકાશિત કરવા દે છે જેથી sites તેને ચકાસી શકે. માન્ય signature એ સાબિત કરે છે કે કઈ key એ request sign કરી, નહિ કે agentને કાર્ય કરવા માટે અધિકાર છે. November 2026 સુધી મુખ્ય સ્પષ્ટીકરણ working group Internet-Draft છે, એટલે product teams એ unsigned trafficને હજી પણ સંભાળતાં રહેતાં signaturesને મજબૂત evidence તરીકે વાપરવા માટે તૈયાર રહેવું જોઈએ.

વર્ષો સુધી, automated client કોઈ websiteને તે કોણ છે તે જણાવે તેની એકમાત્ર રીત User-Agent headerમાંનું નામ અને, થોડા મોટા operators માટે, published IP addressesની યાદી અથવા reverse DNS check હતી. નામો નકલ કરવી સરળ છે. Network lists ફક્ત તેમને જ આવરી લે છે જે તેમને જાળવે છે. AI agents જ્યારે web પર વાસ્તવિક લોકો માટે કાર્ય કરવાનું શરૂ કરે છે, ત્યારે આ અંતર હવે ફક્ત securityનો નહીં, productનો પણ પ્રશ્ન બની ગયું છે.

Web Bot Auth તેને બંધ કરવાની અગ્રણી કોશિશ છે. તે automated clientsને તેમના નિયંત્રણ અને પ્રકાશિત કરેલી key સાથે તેમની requests sign કરવાની રીત આપે છે, જેથી site નામ પર વિશ્વાસ કરવાની બદલે signature ચકાસી શકે. આ explainer product managers અને engineering leads માટે છે જેમને specifications અંત સુધી વાંચ્યા વિના સમજવું છે કે તે શું છે, શું બદલાય છે, અને શું નથી બદલાતું.

ટૂંકું સંસ્કરણ

તે શું છે: IETF working group, webbotauth, અને authenticated automated HTTP clients માટે તે જે અભિગમ standardize કરી રહી છે.
તે કેવી રીતે કામ કરે છે: client HTTP Message Signatures (RFC 9421) નો ઉપયોગ કરીને દરેક requestના ભાગો sign કરે છે અને તેની public keysની directory તરફ સંકેત કરે છે. site key fetch કરે છે અને signature ચકાસે છે.
તે શું સાબિત કરે છે: કઈ keyએ request sign કરી, અને transit દરમ્યાન signed ભાગોમાં ફેરફાર થયો નહોતો.
તે શું સાબિત કરતું નથી: agentને તે જે માંગી રહ્યું છે તે કરવા અધિકાર છે, તે ચોક્કસ user માટે કાર્ય કરે છે, અથવા તે સારી રીતે વર્તશે.
November 2026 સુધીની સ્થિતિ: RFC 9421 એક published 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 authenticate કરવાની પદ્ધતિઓ અને તેમની પાછળના operators વિશે websitesને વધુ માહિતી આપવાની રીતો standardize કરવા માટે charter કર્યું. આ charter મુખ્યત્વે લોકોને સેવા આપતી sites પર ધ્યાન આપે છે, અને scopeમાં clientsનો વિશાળ સમૂહ નામ આપે છે: crawlers, web archivers, link checkers, AI training crawlers અને end users માટે કાર્ય કરતા AI agents.

Charterમાં બે બાહ્યતાઓ product teams માટે નોંધવા જેવી છે. End-user authentication scope બહાર છે, એટલે આ વ્યક્તિને log in કરવાની રીત નથી. Bot reputation tracking પણ scope બહાર છે, એટલે standard તમને કોણે request sign કરી તે જણાવે છે, આ operator વિશ્વસનીય છે કે નહીં તે નહિ.

Charter ત્રણ પ્રકારની deliverables સૂચવે છે:

લોકો માટે બનાવેલ websites માટે automated clientsને authenticate કરવાની તકનીકો પર Standards track documents.
domain name અથવા URL જેવા existing identifierનો ઉપયોગ કરીને requesting bot વિશે વધુ માહિતી પહોંચાડવા પર Standards track documents.
key management, lifecycle અને deployment જેવા operational topics પર 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, તારીખ October 29, 2026. તે Internet-Draft છે, એટલે તે work in progress છે અને હજુ બદલાઈ શકે છે. તે RFC નથી.

Several individual drafts પણ group સાથે સંકળાયેલા છે અને ચર્ચામાં છે, જેમાં registry અને agent card format, anonymous bot authentication, automated clientsના IP ranges પ્રકાશિત કરવા માટેનો JSON format, અને signed agent metadata માટેનો header અંગેના proposals શામેલ છે. Individual drafts proposals છે; આ તારીખ સુધી noneને group દ્વારા adopted કરવામાં આવ્યા નથી.

Charterએ 2026 દરમિયાન specificationsને approval માટે IESG પાસે મોકલવાના milestones નક્કી કર્યા હતા. November 2026 સુધી, protocol document હજી working group draft જ છે. તમે current state 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 કરવાના અને signatureને headersમાં કેવી રીતે લઈ જવાનો તે વ્યાખ્યાયિત કરે છે. 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 sign કરીને મોકલે છે. Requestમાં Signature-Input header હોય છે જે બતાવે છે શું sign થયું અને કઈ key સાથે, અને Signature headerમાં signature value હોય છે. Draft web-bot-auth tag નો ઉપયોગ કરે છે અને દરેક signature પર creation અને expiry timesની અપેક્ષા રાખે છે.
Site ચકાસણી કરે છે. તે public key શોધે છે, પ્રાપ્ત થયેલી requestમાંથી signed components ફરી બનાવે છે, અને signature ચકાસે છે. જો ચકાસણી પાસ થાય, તો request તે keyના ધારક દ્વારા sign કરવામાં આવી હતી અને આવરી લેવાયેલા ભાગોમાં ફેરફાર થયો નહોતો.

Draft siteને signature માંગવાની પણ મંજૂરી આપે છે. Origin એક Accept-Signature header મોકલી શકે છે, સામાન્ય રીતે refusal સાથે, જેથી તે 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 પસંદ કરે છે, અને ચકાસણી કરે છે. 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 દૂર કરીને કામ કરે છે.

ચકાસણી કરતી sitesએ directoriesને કાળજીપૂર્વક હેન્ડલ કરવી જોઈએ: સામાન્ય 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ના signed ભાગોમાં transit દરમ્યાન ફેરફાર થયો નહોતો, અને signature તેની validity windowની અંદર છે.

માન્ય signature સાબિત કરતું નથી:

કે agentને action કરવાની મંજૂરી છે. ઓળખી શકાય તે permission નથી. જુઓ agent authorization.
કે agent ચોક્કસ person માટે કાર્ય કરે છે, અથવા તે personએ તેને આપેલા અધિકારની અંદર કાર્ય કરે છે. જુઓ delegated authority.
કે operator વિશ્વસનીય છે અથવા agent સારી રીતે વર્તશે. Reputation working groupના scope બહાર સ્પષ્ટ રીતે છે.
unsigned requests વિશે કંઈપણ. Unsigned trafficને હજી પણ તેની પોતાની હેન્ડલિંગ જોઈએ.

માન્ય signatureને કોણે request મોકલી તેનું મજબૂત evidence માનો, પછી તમારા પોતાના access controlને નક્કી કરવા દો કે તે sender શું કરી શકે.

પ્રોડક્ટ ટીમોએ તેના વિશે શું કરવું જોઈએ

યોજનાબંધ કરવા માટે 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ને વધુ સારો માર્ગ આપો

જ્યાં યોગ્ય લાગે ત્યાં, લોકો માટે બનેલા pagesની બદલે verified agentsને structured content અથવા agent-friendly flow આપો. serving AI agents structured content પરનો guide patterns આવરી લે છે.

4. authorization તમારા codeમાં જ રાખો

કોણ પૂછે છે તે જાણવા signatureનો ઉપયોગ કરો. તેઓ શું કરી શકે તે નક્કી કરવા માટે તમારા existing permissions, scopes અને confirmationsનો ઉપયોગ કરો. ઊંચા પ્રભાવવાળી actions માટે હજુ પણ human confirmation જરૂરી હોઈ શકે છે, ભલે request કોને sign કરી હોય. જુઓ protecting sensitive actions without blocking agents.

5. unsigned અને Unknown traffic માટે યોજના બનાવો

Signing માટેનો આધાર agents અને tools વચ્ચે અલગ અલગ હોય છે, તેથી થોડા સમય માટે signed અને unsigned requestsનું મિશ્રણ અપેક્ષિત રાખો. declared, inferred અને Unknown traffic માટે site-wide rule પસંદ કરવા કરતાં દરેક route પ્રમાણે નક્કી કરો કે શું થાય. handling 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 sign કરે છે, ત્યારે Proof of Actor operatorની published key સામે signature ચકાસે છે. જો ચકાસણી પાસ થાય, તો પરિણામ verified basis સાથે અને તમારી team સમીક્ષા કરી શકે તેવા evidence સાથે આવે છે. જો client headerમાં માત્ર પોતાનું નામ આપે છે, તો પરિણામ declared છે. જો નિષ્કર્ષ behavioral અથવા contextual signals પર આધારિત હોય, તો તેને inferred તરીકે લેબલ કરવામાં આવે છે. જો evidence પૂરતું ન હોય, તો પરિણામ Unknown છે.

તમારી application તે context સાથે શું કરવું તે નક્કી કરે છે. Policies દરેક route, દરેક actor class અને દરેક basis માટે લખાય છે, outcomes જેમ કે allow, adapt, challenge, review અને rate-limit સાથે. મૂળભૂત રીતે કંઈ enforce થતું નથી: તમે વાસ્તવિક traffic સામે policy preview કરો છો અને તમારી own 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 પગલાં માટે જુઓ.

Proof of Actor standard જે મર્યાદા મૂકે છે તે જ અનુસરે છે: verified signature તમને કહે છે કે કઈ keyએ request sign કરી, નહિ કે agentને authorization છે કે નહીં. Authorization તમારી પાસે જ રહે છે. evidence and limits પેજ ચોક્કસ જણાવે છે કે દરેક result શું support કરી શકે છે અને શું નહીં.

શરૂઆત કરો

Proof of Actor private betaમાં છે. પસંદ કરાયેલ founding developer teams agreed usage limits હેઠળ, automatic billing વિના, 12 months સુધી મફત access મેળવી શકે છે. 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: પરિણામ પાછળના signals, જેથી તમારી team કારણ જોઈ શકે.

observation mode માં શરૂ કરો: પરિણામોને તમારા 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 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 છે.

શું માન્ય Web Bot Auth signatureનો અર્થ એ છે કે agentને કાર્ય કરવાની મંજૂરી છે?

ના. તે માત્ર એ સાબિત કરે છે કે કઈ keyએ request sign કરી અને signed partsમાં ફેરફાર થયો નથી. એ agent data વાંચી શકે, form submit કરી શકે અથવા કોઈ નિશ્ચિત user માટે કાર્ય કરી શકે કે નહિ, તે authorizationનો નિર્ણય તમારી application હજી પણ કરે છે.

શું product teamsને Web Bot Auth પોતે implement કરવાની જરૂર છે?

Sites signatures ચકાસે છે; જો તેઓ 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 ગોઠવો.

Proof of Actor Web Bot Authનો કેવી રીતે ઉપયોગ કરે છે?

તે HTTP Message Signaturesને published key સામે ચકાસે છે અને, ચકાસણી સફળ થાય ત્યારે, પરિણામને verified basis સાથે દર્શાવે છે. પછી તમારી policies verified agentsને declared અથવા Unknown trafficથી અલગ રીતે હેન્ડલ કરી શકે છે.

તમારા app નો ઉપયોગ કોણ કરે છે તે જાણો.

Founding developers ના નાના સમૂહ માટે private beta.

પ્રારંભિક ઍક્સેસ મેળવો કિંમત જુઓ

પહેલાં વાત કરવી પસંદ કરો છો? સ્થાપકો સાથે વાત કરો