ప్రధాన కంటెంట్‌కు దాటవేయండి
వివరణ

ఉత్పత్తి బృందాల కోసం Web Bot Auth: సంతకం చేసిన agent అభ్యర్థనలు మీ roadmap కోసం ఏమి అర్థం చేస్తాయి

AI agents మరియు crawlers, ఎవరైనా కాపీ చేయగల User-Agent string‌పై ఆధారపడకుండా, తాము ఎవరో నిరూపించే మార్గం increasingly అవసరం అవుతోంది. IETF Web Bot Auth పని, దాన్ని standardize చేయడానికి leading effort. ఇది product managers మరియు engineering leads కోసం సరళమైన వివరణ: ఇది ఎలా పనిచేస్తుంది, ఏమిని నిరూపిస్తుంది, November 2026 నాటికి దాని స్థితి ఏమిటి, మరియు దానికి ఎలా సిద్ధమవాలి.

తొందరగా యాక్సెస్ పొందండిఇది ఎలా పనిచేస్తుందో అన్వేషించండి
Toshendra Sharma

రచన Toshendra SharmaFounder & CEO, AgentCredia · Updated November 13, 2026

ఏళ్ల తరబడి, ఒక automated client తాను ఎవరో ఒక website‌కు చెప్పగలిగిన ఏకైక మార్గం, User-Agent headerలోని పేరుకు, అలాగే కొన్ని పెద్ద operators కోసం published IP addresses జాబితా లేదా reverse DNS check కు పరిమితమై ఉండేది. పేర్లు సులభంగా copy చేయవచ్చు. Network lists వాటిని maintain చేసే operators‌కే పరిమితం. AI agents web అంతటా నిజమైన వ్యక్తుల కోసం act చేయడం ప్రారంభించడంతో, ఆ gap security సమస్య మాత్రమే కాదు, product సమస్య కూడా అయింది.

Web Bot Auth దాన్ని మూసివేయడానికి leading effort. ఇది automated clients‌కు తాము control చేసి publish చేసే keyతో తమ requests‌ను sign చేయడానికి మార్గం ఇస్తుంది, తద్వారా ఒక site పేరును trust చేయకుండా signature‌ను check చేయగలదు. ఈ explainer product managers మరియు engineering leads కోసం, స్పెసిఫికేషన్లను పూర్తిగా చదవకుండానే ఇది ఏమిటి, ఏమి మారుస్తుంది, ఏమి మారదు అన్నది అర్థం చేసుకోవాల్సిన వారికి.

సంక్షిప్తంగా

  • ఇది ఏమిటి: ఒక IETF working group, webbotauth, మరియు automated HTTP clients‌ను authenticate చేయడానికి అది standardize చేస్తున్న approach.
  • ఇది ఎలా పనిచేస్తుంది: client ప్రతి request‌లోని భాగాలను HTTP Message Signatures (RFC 9421) ఉపయోగించి sign చేసి, తన public keys directoryకి సూచిస్తుంది. Site ఆ keyను fetch చేసి signature‌ను verify చేస్తుంది.
  • ఇది ఏమిని నిరూపిస్తుంది: ఏ key request‌ను sign చేసిందో, మరియు transitలో signed parts మారలేదో.
  • ఇది ఏమిని నిరూపించదు: agent అది అడుగుతున్న పనిని చేయడానికి authorized అని, అది particular user కోసం act చేస్తోందని, లేదా అది మంచిగా ప్రవర్తిస్తుందని కాదు.
  • November 2026 నాటికి స్థితి: RFC 9421 published Proposed Standard. Web Bot Auth protocol document ఇంకా working group Internet-Draft, ఇప్పటికీ RFC కాదు.
  • ఏమి చేయాలి: valid signatures‌ను strong evidence‌గా treat చేయాలని plan చేయండి, unsigned traffic‌ను handle చేస్తూనే ఉండండి, మరియు authorization నిర్ణయాలను మీ స్వంత codeలో ఉంచండి.

IETF Web Bot Auth పని ఏమిటి

పరిపాలన చేయడానికి అవసరమైన పద్ధతులను standardize చేయడానికి, అలాగే websitesకు వాటి వెనుక ఉన్న operators గురించి మరింత సమాచారం ఇవ్వడానికి IETF Web Bot Auth working group‌ను charter చేసింది. ఈ charter ప్రధానంగా మనుషులకు సేవ చేసే sites‌పై దృష్టి పెట్టింది, మరియు scopeలో విస్తృతమైన clients‌ను పేర్కొంటుంది: crawlers, web archivers, link checkers, AI training crawlers, మరియు end users కోసం act చేసే AI agents.

Charterలో product teams గుర్తుంచుకోవాల్సిన రెండు exclusions ఉన్నాయి. End-user authentication scopeలో లేదు, కాబట్టి ఇది ఒక person‌ను log in చేయించే మార్గం కాదు. Bot reputation tracking కూడా scopeలో లేదు, కాబట్టి standard request‌ను ఎవరు sign చేశారో చెబుతుంది, ఆ operator trustworthy కాదా అనేది కాదు.

Charter మూడు రకాల deliverables‌ను సూచిస్తుంది:

  1. మనుషుల కోసం రూపొందించిన websitesకు automated clients‌ను authenticate చేయడానికి techniquesపై Standards track documents.
  2. Domain name లేదా URL వంటి existing identifier‌ను ఉపయోగించి requesting bot గురించి మరింత సమాచారం ఇవ్వడానికి Standards track documents.
  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, తేదీ October 29, 2026. ఇది ఒక Internet-Draft, అంటే ఇంకా మారే అవకాశం ఉన్న work in progress. ఇది RFC కాదు.

Several individual drafts కూడా group‌తో associated‌గా ఉన్నాయి, ఇంకా చర్చలో ఉన్నాయి, వీటిలో registry మరియు agent card formatపై proposals, anonymous bot authentication, automated clients యొక్క IP ranges‌ను publish చేయడానికి JSON format, మరియు signed agent metadata కోసం ఒక header ఉన్నాయి. Individual drafts proposals మాత్రమే; ఈ తేదీ నాటికి వాటిలో ఏదీ group ఆమోదించలేదు.

2026 సమయంలో specifications‌ను approval కోసం IESGకి పంపే milestones charterలో ఉన్నాయి. November 2026 నాటికి, protocol document working group draftగానే ఉంది. మీరు current state‌ను IETF datatracker page for the working group మరియు 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ను headersలో తీసుకెళ్లడం ఎలా అనేదాన్ని నిర్వచిస్తుంది. 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‌పై replay చేయడం సాధ్యం కాదు.
  3. Client sign చేసి పంపుతుంది. Requestలో ఏది sign చేయబడిందో, ఏ keyతో చేయబడిందో వివరిస్తున్న Signature-Input header, మరియు signature valueతో ఒక Signature header ఉంటాయి. 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 భాగాలు మారలేదు.

Draft ఒక siteకు signature అడిగే అవకాశం కూడా ఇస్తుంది. Origin ఒక Accept-Signature header, సాధారణంగా refusalతో, పంపి signed requests కావాలని signal చేయగలదు.

Key directory ఆలోచన

Site సరైన public key‌ను కనుగొనగలిగితేనే signature ఉపయోగకరం. Web Bot Auth దానికి key directoryతో సమాధానం ఇస్తుంది.

ప్రస్తుత working group draftలో, client ఒక HTTPS URLను కలిగిన Signature-Agent header‌ను జోడిస్తుంది. ఆ 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ను operator నియంత్రించే domainతో tie చేస్తుంది. Key rotation పాత keyతో పాటు కొత్త keyను publish చేయడం ద్వారా, తరువాత పాతదాన్ని తీసివేయడం ద్వారా పనిచేస్తుంది.

Verifying sites directoriesను జాగ్రత్తగా handle చేయాలి: normal HTTP rules ప్రకారం cache చేయాలి, size limits మరియు timeouts set చేయాలి, మరియు private network addresses నుంచి fetch చేయకుండా ఉండాలి. ఇవి standard engineering concerns, మరియు చాలా teams verificationను తమ కోసం చేయగల component‌ను ఎందుకు ఇష్టపడతారో దానికి ఇవి కారణం.

Valid signature ఏమి నిరూపిస్తుంది, ఏమి నిరూపించదు

Product policy రాస్తున్న ఎవరైనా కోసం ఇది అత్యంత ముఖ్యమైన section.

Valid signature నిరూపించేది:

  • Request ఒక specific private key holderచే sign చేయబడింది.
  • ఆ key operator నియంత్రించే directory URLలో publish అయింది.
  • Requestలోని signed parts transitలో మారలేదు, మరియు signature దాని validity windowలో ఉంది.

Valid signature నిరూపించనిది:

  • Agent ఆ action చేయడానికి authorized అని కాదు. Identifiableగా ఉండటం permission కాదు. agent authorization చూడండి.
  • Agent ఒక specific person కోసం, లేదా ఆ person ఇచ్చిన authority పరిధిలో act చేస్తోందని కాదు. delegated authority చూడండి.
  • Operator trustworthy అని, లేదా agent మంచిగా ప్రవర్తిస్తుందని కాదు. Reputation working group scopeలో explicitly లేదు.
  • Signed కాని requests గురించి ఏమీ కాదు. Unsigned traffic‌కు ఇంకా తన స్వంత handling అవసరం.

Valid signature‌ను requestను ఎవరు పంపారో అన్న దానికి strong evidenceగా treat చేయండి, తర్వాత మీ own access control ఆ sender ఏమి చేయగలడో నిర్ణయించనివ్వండి.

దీని గురించి product teams ఏమి చేయాలి

Plan చేయడానికి RFC కోసం wait చేయాల్సిన అవసరం లేదు. Signed agent traffic ఇప్పుడు సిద్ధం చేసుకోవాల్సిన విషయం, draftలోని కొన్ని details మారవచ్చన్న అంచనాతో.

1. Decide చేయడానికి ముందు measure చేయండి

మీ trafficలో ఎంత automated ఉంది, ఏ routes agents ఉపయోగిస్తున్నాయి, మరియు వాటిలో ఎంత signedగా ఉంది తెలుసుకోండి. observation modeలో ప్రారంభించండి, తద్వారా measure చేయడం మీ users కోసం ఏమీ మార్చదు.

2. Evidenceను policy నుండి వేరు చేయండి

మీరు ఏమి decide చేస్తారో దానికి వేరుగా, evidence ఏమి చెబుతుందో verified, declared, inferred లేదా unknownగా record చేయండి. అలా చేస్తే policies చదవడానికి సులభంగా ఉంటాయి మరియు మళ్లీ instrumentation చేయకుండా వాటిని tight లేదా relax చేయవచ్చు. evidence basis entry ఈ నాలుగు levels‌ను వివరిస్తుంది.

3. Verified agentsకు మెరుగైన path ఇవ్వండి

అర్థవంతంగా ఉన్న చోట, మనుషుల కోసం రూపొందించిన pagesకి బదులుగా verified agents‌కు structured content లేదా agent-friendly flow ఇవ్వండి. serving AI agents structured content guide patterns‌ను covers చేస్తుంది.

4. Authorizationను మీ codeలో ఉంచండి

Signature‌ను ఎవరు అడుగుతున్నారో తెలుసుకోవడానికి ఉపయోగించండి. వారు ఏమి చేయవచ్చో నిర్ణయించడానికి మీ existing permissions, scopes మరియు confirmations‌ను ఉపయోగించండి. High-impact actions‌కు ఇంకా human confirmation అవసరం కావచ్చు, request‌ను ఎవరు sign చేసినా సరే. protecting sensitive actions without blocking agents చూడండి.

5. Unsigned మరియు Unknown traffic కోసం plan చేయండి

Signing‌కు support agents మరియు tools అంతటా వేరుగా ఉంటుంది, కాబట్టి కొంతకాలం signed మరియు unsigned requests మిశ్రమంగా ఉంటాయని ఆశించండి. Single site-wide rule ఎంచుకోవడం కాకుండా, ప్రతి routeలో declared, inferred మరియు Unknown traffic‌కు ఏమి జరుగుతుందో నిర్ణయించండి. handling Unknown traffic guide దీన్ని వివరంగా చూపుతుంది.

Proof of Actor Web Bot Auth‌ను ఎలా ఉపయోగిస్తుంది

Proof of Actor ప్రతి interactionలో పనిచేస్తున్నది Human, Human + AI, Agent లేదా Unknown ఏదో మీ applicationకు చెబుతుంది, మరియు evidence basis‌ను state చేస్తుంది. Web Bot Auth signatures దాని strongest evidence sourcesలో ఒకటి.

Agent HTTP Message Signatures‌తో తన request‌ను sign చేసినప్పుడు, Proof of Actor operator యొక్క published key against signatureను check చేస్తుంది. Check pass అయితే, resultతో పాటు మీరు review చేయగల evidence‌తో verified basis వస్తుంది. ఒక client headerలో తానేనని మాత్రమే చెప్పితే, result declared అవుతుంది. Conclusion behavioral లేదా contextual signals‌పై ఆధారపడితే, అది inferredగా labeled అవుతుంది. Evidence సరిపోకపోతే, result Unknown.

ఆ context‌తో ఏమి చేయాలో మీ application నిర్ణయిస్తుంది. Policies ప్రతి route, ప్రతి actor class, మరియు ప్రతి basisకి విడిగా వ్రాయబడతాయి, outcomesగా allow, adapt, challenge, review, మరియు rate-limit వంటి వాటితో. ఏదీ defaultగా enforced కాదు: మీరు real 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 చూడండి, మరియు practical steps కోసం verifying signed agent requests guide చూడండి.

Proof of Actor standard పెట్టిన అదే limit‌ను అనుసరిస్తుంది: 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 లేకుండా, లభించవచ్చు. early access కోసం apply చేయండి మరియు 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
evidence ఎంత బలంగా ఉందో: 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, మరియు అది standardize చేస్తున్న approach పేరు: automated clients HTTP requests‌ను HTTP Message Signatures (RFC 9421) తో sign చేస్తాయి మరియు తమ public keys‌ను publish చేస్తాయి, తద్వారా websites ఏ operator request పంపిందో verify చేయగలవు.

Web Bot Auth పూర్తైన standardా?

ఇంకా కాదు. November 2026 నాటికి, ప్రధాన protocol document అయిన draft-ietf-webbotauth-httpsig-protocol, revision 01లో ఉన్న working group Internet-Draft. ఇది ఆధారపడే signature format అయిన RFC 9421 ఒక published Proposed Standard.

Valid Web Bot Auth signature అంటే agent‌కు act చేయడానికి అనుమతి ఉందని అర్థమా?

కాదు. ఇది ఏ key request‌ను sign చేసిందో, మరియు signed parts మార్చబడలేదో నిరూపిస్తుంది. ఆ agent data చదవచ్చా, form submit చేయచ్చా, లేదా ఒక particular user కోసం act చేయచ్చా అనే విషయం ఇంకా మీ application తీసుకునే authorization నిర్ణయం.

Product teams తాము స్వయంగా Web Bot Auth implement చేయాలా?

Sites signatures‌ను verify చేస్తాయి; automated clients కూడా run చేయకపోతే ఏదైనా sign చేయాల్సిన అవసరం లేదు. Verificationలో key directories fetch చేయడం, వాటిని safely cache చేయడం, మరియు signatures check చేయడం ఉంటాయి, ఇది Proof of Actor వంటి tool మీ కోసం చేయగలదు.

తమ requests‌ను sign చేయని agents‌తో ఏమి చేయాలి?

లభ్యమయ్యే evidence ప్రకారం వాటిని handle చేయండి: declared, inferred, లేదా Unknown. కొంతకాలం signed మరియు unsigned traffic మిశ్రమంగా ఉంటుందని ఆశించండి, మరియు single site-wide rule కాకుండా ప్రతి route‌కు ఒక fallback set చేయండి.

Proof of Actor Web Bot Auth‌ను ఎలా ఉపయోగిస్తుంది?

ఇది published key against HTTP Message Signatures‌ను check చేస్తుంది, మరియు check pass అయినప్పుడు result‌ను verified basisతో report చేస్తుంది. తరువాత మీ policies verified agents‌ను declared లేదా Unknown traffic నుంచి వేరుగా treat చేయగలవు.

మీ app ను ఎవరు ఉపయోగిస్తున్నారో తెలుసుకోండి.

founding developers యొక్క చిన్న group కోసం private beta.

తొందరగా యాక్సెస్ పొందండిధరలను చూడండి

ముందుగా మాట్లాడాలనుకుంటున్నారా? foundersతో మాట్లాడండి