--- title: "What is Web Bot Auth? Cryptographic identity for agents" description: "Web Bot Auth lets automated agents prove their identity with HTTP Message Signatures (RFC 9421) — a public key directory on the operator's domain plus signed request headers, instead of spoofable user-agent strings and robots.txt identities." last_updated: 2026-07-18 canonical_url: https://agent-ready.dev/what-is-web-bot-auth --- # What is Web Bot Auth? > Cryptographic identity for AI agents — proving "who's knocking" with signed requests instead of spoofable user-agent strings. ## At a glance - **Protocol:** an IETF effort standardising how agents authenticate to origins, built on HTTP Message Signatures (RFC 9421). Architecture draft authored at Cloudflare and Google; working group chartered early 2026, BCP targeted for August 2026. - **The artifact:** a public key directory at `/.well-known/http-message-signatures-directory` on the *agent operator's* domain. - **The mechanics:** the agent signs each outbound request; the origin verifies it, or hands verification to its CDN/WAF (Cloudflare Signed Agents / Verified Bots, AWS WAF). Shared HMAC keys are forbidden. - **Direction:** signatures ride on the *agent's* requests; there are no Web Bot Auth response headers for a scanner to probe for on an ordinary website. ## Reading the direction right Web Bot Auth signs requests, not responses: the agent is the signer and the website is the verifier, so origin-side support is invisible from outside — there are no "Web Bot Auth response headers" a scanner can probe for. The only crawlable, checkable artifact is the key directory, and that lives on the *agent operator's* domain, not on the sites being visited. Tools that grade ordinary websites down for "missing Web Bot Auth signature headers" read the protocol backwards. ## Who's using it (July 2026) OpenAI signs ChatGPT agent and Operator requests (keys under operator.openai.com); Cloudflare's Signed Agents program launched with ChatGPT agent, Block's Goose, Browserbase, and Anchor Browser and folds into Verified Bots; AWS WAF supports verification and Amazon Bedrock AgentCore's browser signs its traffic; Google's Google-Agent signs while main Googlebot does not (as of May 2026); Stytch supports it. The effort is backed by Cloudflare, Amazon, Akamai, and OpenAI. ## Does Agent Ready check for Web Bot Auth? Yes — scanner check C14 ("Web Bot Auth directory") probes `/.well-known/http-message-signatures-directory`. When the file is absent the check returns null and the site is never penalised (discover-then-validate). When present, C14 fails on a non-JSON body, a missing or empty `keys` array, or shared HMAC keys (rejected with the "MUST NOT use shared HMAC" citation), and warns when the body is valid but served without the exact `application/http-message-signatures-directory+json` media type. agent-ready.dev publishes its own signing-key directory with one Ed25519 key and the correct media type. ## Frequently asked questions ### What is Web Bot Auth? Web Bot Auth is an IETF effort that lets automated agents prove their identity to the websites they visit. Instead of relying on a user-agent string or an IP range that anyone can spoof or that breaks as agents roam across egress networks, an agent signs each request with HTTP Message Signatures (RFC 9421) using a key pair it publishes. It is an architecture draft (draft-meunier-web-bot-auth-architecture), authored at Cloudflare and Google, with an IETF working group chartered in early 2026 and a best-current-practice document targeted for August 2026. ### How does an AI agent prove its identity with Web Bot Auth? The agent operator generates an asymmetric keypair (Ed25519 / EdDSA in practice) and publishes the public keys as a JWK Set at /.well-known/http-message-signatures-directory on its own domain, served as application/http-message-signatures-directory+json. The agent then signs each outbound request with Signature-Input and Signature headers per RFC 9421 and adds a Signature-Agent header naming where its keys live. The receiving origin verifies the signature and, for the first time, can answer “is this really that agent?” cryptographically rather than by guessing from headers. ### What is /.well-known/http-message-signatures-directory? It is the agent operator's public key directory — a JWK Set listing the public keys the agent signs requests with. It lives on the operator's own domain (for example OpenAI publishes keys under operator.openai.com), is served with the media type application/http-message-signatures-directory+json, and is the one crawlable, checkable artifact of Web Bot Auth. Because it sits on the operator's domain, an ordinary website being visited by an agent has nothing to publish there. ### How does a website verify Web Bot Auth signatures? The receiving origin verifies inbound signatures itself, or turns it over to its CDN/WAF: Cloudflare Signed Agents / Verified Bots and AWS WAF (which added support in November 2025) can validate signatures at the edge. An origin can optionally advertise Accept-Signature (RFC 9421) in a response to solicit signed requests. The crucial point is that origin-side support is invisible from outside — there are no Web Bot Auth response headers a scanner can probe for; the signatures ride on the agent's requests. ### How is Web Bot Auth different from user-agent strings or robots.txt? User-agent strings and robots.txt identities are trivially spoofable — anyone can send “Googlebot” or “ChatGPT” as a header. IP-range allowlists help until agents move to residential or cloud egress, where whole ranges shift under their operators. Web Bot Auth makes identity a cryptographic question: the agent proves possession of a private key whose public half is published, so a verifier checks a signature rather than trusting a self-asserted label. ### Does Agent Ready check for Web Bot Auth? Yes — scanner check C14 (“Web Bot Auth directory”) probes /.well-known/http-message-signatures-directory. When the file is absent the check returns null and the site is never penalised (discover-then-validate). When present, C14 fails on a non-JSON body, a missing or empty keys array, or any attempt to use shared HMAC keys (rejected with the “MUST NOT use shared HMAC” citation); it warns when the body is valid but served without the exact application/http-message-signatures-directory+json media type. agent-ready.dev dogfoods the artifact: it publishes its own signing-key directory with one Ed25519 key and the correct media type. --- Read the full guide on the web: Score your site for agents: ## Sitemap See the full [sitemap](https://agent-ready.dev/sitemap.md) for all pages on agent-ready.dev.