Web Bot Auth in 2026: Shipped Before It's a Standard

Web Bot Auth is not an adopted IETF standard yet. As of August 12, 2026 its working group has no adopted documents — only individual drafts — while Cloudflare, AWS WAF, Akamai, HUMAN and Vercel already verify its signatures in production to decide which AI agents reach a website.

That gap now has consequences. The drafts changed the Signature-Agent wire format from a bare string to a structured dictionary in October 2025, and the revision dated 6 August 2026 — which also moved the work to Standards Track — states the rule outright: "Signers MUST send the dictionary form."¹ Cloudflare's published verification rules still treat that dictionary form as a reason to fail a request.²

TL;DR: Web Bot Auth lets an automated client sign each HTTP request using HTTP Message Signatures (RFC 9421), so a site can verify the caller instead of trusting a user-agent string.³ Deployment is broad and mostly automatic. Standardisation is not finished: nine active drafts match the working group's name and none has been adopted, the core draft's authors committed at IETF 126 to keep refining it "before seeking formal adoption," and the vendor documentation gating real traffic still describes a header format the drafts left behind in 2025.⁴⁵¹

What you'll learn

• What Web Bot Auth actually is, and what RFC 9421 contributes to it
• Where the IETF working group really stands as of August 2026
• What the IETF 126 session in Vienna decided, and what it explicitly did not
• Which CDNs, WAFs and agent operators already enforce it today
• Why the ecosystem's Signature-Agent header split into two incompatible forms
• Why four deployers point readers at replaced drafts and a meeting request
• What the charter refuses to solve, including who the agent is acting for
• What to do now if you run a site or operate an agent

What Web Bot Auth actually is

Web Bot Auth is a way for an automated client to cryptographically prove which operator it belongs to, on every request. The bot publishes a public key as a JSON Web Key Set at /.well-known/http-message-signatures-directory on a domain it controls, and signs outbound requests using HTTP Message Signatures — RFC 9421, a Standards Track RFC published in February 2024.³²

Three headers carry it. Signature-Input names the components being signed and the parameters (keyid, created, expires, nonce, and a tag). Signature carries the bytes. Signature-Agent points at the directory holding the key.

Signature-Agent: "https://signature-agent.test"
Signature-Input: sig2=("@authority" "signature-agent")
 ;created=1735689600
 ;keyid="poqkLGiymh_W0uP6PZFw-dvez3QJT5SolqXBCW38r0U"
 ;alg="ed25519"
 ;expires=1735693200
 ;nonce="e8N7S2MFd/qrd6T2R3tdfAuuANngKI7LFtKYI/vowzk4lAZYadIX6wW25MwG7DCT9RUKAJ0qVkU0mEeLElW1qg=="
 ;tag="web-bot-auth"
Signature: sig2=:jdq0SqOwHdyHr9+r5jw3iYZH6aNGKijYp/EstF4RQTQdi5N5YYKrD+mCT1HA1nZDsi6nJKuHxUi/5Syp3rLWBA==:

That is Cloudflare's documented example — a form re-examined below — and keyid is the key's base64url JWK thumbprint.² Ed25519 is the only algorithm Cloudflare accepts; the draft is not tied to one, restricting alg to the IANA HTTP Signature Algorithms registry and carrying RSASSA-PSS test vectors alongside Ed25519 ones.²¹

IP allowlists break when a provider re-architects; user-agent strings are free text anyone can copy. A signature is checkable. The charter says as much: "IP allowlisting, User-Agent strings, and shared API keys" have "significant limitations regarding security, scalability, and manageability."⁶ Nothing about that problem statement is contested. The argument is over the shape of the answer.

The standards timeline: nine drafts, none adopted

Search the IETF Datatracker for webbotauth on August 12, 2026 and you get nine active Internet-Drafts. Every one is an individual submission — draft-meunier-*, draft-illyes-*, draft-nottingham-*, draft-rescorla-*, draft-singh-*, draft-popov-*. There is no draft-ietf-webbotauth-anything, and the working group's own document list adds a tenth individual draft whose name does not carry the group prefix.⁴⁷

That prefix is not cosmetic: an individual draft is one person's proposal; a draft-ietf- document is one the group owns.

The charter was approved on October 23, 2025 with three milestones: two standards-track specifications to the IESG by April 30, 2026, and a Best Current Practice operational specification by August 31, 2026.⁸⁶ The Associated Documents column is empty for all three.

Be fair about what that does and does not mean. Milestones are targets the chairs manage, not deadlines with consequences, and slipping them is closer to the IETF norm than the exception. This group has held three sessions as a chartered WG — IETF 124, one interim in April 2026, and IETF 126 — after a pre-charter session at IETF 123, and its charter passed the IESG with six Yes ballots and no objections.⁹¹⁰ Nearly ten months without an adoption call is unhurried, not broken. What makes it consequential is not the calendar. It is that the enforcement layer did not wait.

What happened at IETF 126

The group met in Vienna on July 22, 2026.⁵

The chairs ran one poll on the identifying-authentication path: "Do we think this is the right general direction / starting point?" Result: Yes: 22, No: 6, No Opinion: 5, from 75 participants.⁵ A direction poll is not an adoption call, but 22–6 is a comfortable margin.

The action item matters more. The authors "will continue refining the draft to address key discovery, key rotation semantics, and cryptographic feedback regarding signature structures before seeking formal adoption."⁵ Justin Richer — an editor of RFC 9421 itself — "flagged that signing a signature value is a known cryptographic risk" and offered to help align the construction with best practice.⁵³

There was also a values argument. Eric Nygren, Richard Barnes and Alissa Cooper warned that a voluntary system "may become a de facto requirement to access web content, potentially leading to a discriminatory web or balkanization." Marwan Fayed countered "that without such a standard, operators will continue to block unrecognized traffic anyway, making a standardized path necessary to preserve open access."⁵

The August 31 BCP milestone has a candidate. Gary Illyes presented on crawler best practices — draft-illyes-webbotauth-cbcp-00, intended status Informational.⁴ Richer "strongly supported adoption" and AD Mike Bishop noted the charter's BCP milestone means the work "is likely close enough to proceed," though co-chair David Schinazi called it "technically outside the current WEBBOTAUTH charter" and Mirja Kühlewind advised a formal recharter "to avoid IETF Last Call issues."⁵ Eric Rescorla's parallel anonymous-authentication path "will remain in an exploratory stage."⁵¹¹ Chairs were weighing an interim before IETF 127 in November.⁵

Who already enforces Web Bot Auth

The enforcement layer has shipped.

Note the dates. Vercel shipped verification on August 12, 2025 — about ten weeks before the working group was chartered — and AWS four weeks after.¹⁴¹²⁶ The defaults have flipped from deny to allow, in AWS's words: "Previously, Category AI blocked unverified bots; this behavior is now refined to respect WBA verification."¹² An unadopted draft is now the difference between an agent being blocked and being waved through.

The Signature-Agent split, and which side is legacy

Google's documentation says participating requests carry Signature-Agent set to g="https://agent.bot.goog", and tells readers to "take note of the g= label."¹⁵ OpenAI's says the header is "https://chatgpt.com" and instructs verifiers to confirm it "exactly matches" that value, "including the quotation marks."¹³ Cloudflare implements the bare quoted string and lists among its verification failures: "The message uses the dictionary form from later drafts, such as sig2="https://signature-agent.test"."²

The obvious read — Google is the outlier — is backwards, and the dates say so. The dictionary form arrived in draft-meunier-web-bot-auth-architecture-04 on 20 October 2025 — a change the current draft's changelog records as "Change Signature-Agent to a Structured Fields dictionary."¹ Nine and a half months later, the current revision states the rule outright: "Signature-Agent is a Dictionary Structured Header… A verifier MAY accept [the bare String] form and treat it as a dictionary with a single member… Signers MUST send the dictionary form." Bare-string examples survive only in appendices headed "Legacy Signature-Agent, sf-string," annotated "Retained for implementers migrating to the dictionary form (Section 5.2.1). Do not copy it into new deployments."¹

So Google ships what the drafts have specified since 2025; Cloudflare's rules treat that form as a failure, and OpenAI signs the legacy one. The overlap is literal: Cloudflare's example request is character-for-character the vector the draft files under "Legacy."²¹ To be careful, this compares published documentation, not observed rejections: Cloudflare may recognise Google-Agent through its verified-bots directory, and MAY accept leaves it free to keep taking the old form. But a site operator following any single vendor page implements against the wrong generation of the spec.

The replay story runs the same way. The draft's anti-replay section says agents SHOULD add a nonce and MUST keep it unique for the signature's validity window, leaving enforcement to the origin.¹ Cloudflare's docs say plainly: "there is currently no nonce validation, nor does Cloudflare guard against replay attacks using a database of seen nonces," recommending short expires values instead: "A minute is often sufficient."²

Four deployers, replaced drafts and a meeting request

The stale-citation problem is systematic. Cloudflare's documentation, last updated July 1, 2026, says it relies on draft-meunier-http-message-signatures-directory-03 and draft-meunier-web-bot-auth-architecture-02.² Google's guide links to the same two draft series.¹⁵ Both are now marked Replaced on the Datatracker — by draft-meunier-webbotauth-httpsig-directory and draft-meunier-webbotauth-httpsig-protocol respectively — and the August revision absorbed the directory document's content.⁷¹ Vercel's changelog links to the architecture draft too.¹⁴ AWS links the phrase "IETF drafts" to bofreq-nottingham-web-bot-auth: an approved Birds-of-a-Feather request: a proposal to hold a meeting.¹²

There is no single artifact those pages point at, and every one of those links lands somewhere other than the current specification. The IETF's agentproto effort hit the identical problem — a widely cited draft there is now expired and archived.

What the charter refuses to solve

Anyone building agentic commerce should read the out-of-scope list before assuming Web Bot Auth covers them. Verbatim, among the seven out-of-scope items:⁶

• "Authenticating access to content not intended for human consumption (e.g., HTTP APIs, agent-to-agent interfaces)"
• "Authenticating the end user of a participating client or agent"
• "Tracking or assigning reputation to particular bots"
• "Techniques for distinguishing non-participating bots from non-bot clients"

The charter is explicit: "This effort will focus on authentication of the agent; authentication of the end user is out-of-scope."⁶

A verified signature therefore tells a merchant a request came from ChatGPT. It says nothing about whose session, whether that person consented, or whether they may spend anything. OpenAI's capability note lands in the same place from the product side: at launch, Cloud browser "cannot sign in to websites or complete payments."¹³

Cloudflare is experimenting at that seam with the RFC 7239 Forwarded header — Forwarded: for="openai", optionally with a use="reference" content-use signal — and its own two pages describe the experiment differently. The Web Bot Auth page frames it as carrying "an operator's identity" through intermediaries; the Verified bots page, updated the same day, says Cloudflare is "experimenting with forwarding information about the end user."²¹⁶ Both call it experimental; either way it is a vendor extension, not a working-group document.⁶ Who the human behind the agent is remains an open problem that cryptographic agent identity and agent authorization at the protocol layer are approaching from other directions.

What to do now

If you run a site. Use your provider's verification rather than writing your own; all five verifiers above do it for you.²¹²¹³ Keep IP and reverse-DNS fallback: Google explicitly tells you to, because it does not sign every request.¹⁵ On AWS WAF, confirm you are in scope, since the feature covers CloudFront distributions only.¹²

If you operate an agent. Publish a key directory and sign, because the default is already tilting toward allowing verified traffic. Send the dictionary form of Signature-Agent, since that is what the current draft requires — and expect some verifiers to want the legacy string for a while yet.¹ Set short expires windows given how thin deployed replay protection is, and track draft-meunier-webbotauth-httpsig-protocol, not the older names the vendor pages cite.²¹

If you are writing procurement language. Do not call Web Bot Auth a standard in a contract. It is a set of individual drafts with strong deployment, no adopted text, and an unresolved argument inside the working group about whether the mechanism stays voluntary at all.⁵

The bottom line

The familiar pattern is a specification arriving years before anyone deploys it. Web Bot Auth inverted that: Vercel shipped verification ten weeks before the working group was chartered, AWS four weeks after, and nothing has been adopted since. The drafts moved the wire format in October 2025 and hardened it into a "MUST" this August — while the documentation site owners actually follow was last touched on July 1.

The working group is not the problem — a 22–6 direction poll, a folded-in companion draft and a BCP candidate with AD encouragement all point the right way. The problem is that the dashboards deciding which agents reach the web are checking a wire format the specification tells implementers not to copy into new deployments.