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.

What is Web Bot Auth? Cryptographic identity for agents

What is Web Bot Auth?

Web Bot Auth is an IETF effort that lets automated agents cryptographically prove who they are when they request a web page. The architecture draft (draft-meunier-web-bot-auth-architecture) was authored at Cloudflare and Google; an IETF working group was chartered in early 2026, with a best-current-practice document targeted for August 2026. The mechanism underneath is HTTP Message Signatures (RFC 9421).

The problem it solves is simple to state. A user-agent string like ChatGPT is a self-asserted label anyone can send; robots.txt identities are equally easy to fake; and IP-range allowlists break the moment an agent moves to residential or cloud egress. Web Bot Auth turns “is this really that agent?” from a heuristic guess into a cryptographic question the origin can actually answer.

At a glance

Protocol: an IETF effort standardising how agents authenticate to origins — built on HTTP Message Signatures (RFC 9421).
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 lets its CDN/WAF do so.
Status: architecture draft, working group chartered early 2026, BCP targeted for August 2026.
Backed by: Cloudflare, Amazon, Akamai, and OpenAI.

How it works

Web Bot Auth has three moving parts. First, the key directory: the agent operator generates an asymmetric keypair — Ed25519 / EdDSA in practice — and publishes the public key as a JWK Set. Second, the signed request: the agent signs each outbound request with Signature-Input and Signature headers per RFC 9421 and adds a Signature-Agent header naming where the keys live. Third, origin verification: the receiving site checks the signature itself, or hands it to its CDN/WAF. Shared/symmetric HMAC keys are forbidden — the draft says implementations MUST NOT use shared HMAC.

A signed request looks like this (modeled on the draft’s own examples):

NOTE: '\' line wrapping per RFC 8792

Signature-Agent: agent="https://operator.example.com"
Signature-Input: sig=("@authority" "signature-agent";key="agent")\
 ;created=1767225600\
 ;keyid="rMqk28OfQja_GIbetNi-slasXmoLVBa_6SQI0vmLbHY"\
 ;alg="ed25519"\
 ;expires=1767226200\
 ;nonce="XeP72svPKNiGEg3aDE7WJuTpN69H08oMFqC8NLFy1Mpt"\
 ;tag="web-bot-auth"
Signature: sig=:DGiW2ErlQh0hc8wY2FQdbnFd6CEmonyY8nlvECIJFaUSYYNvNvSsGyP99BUGtq51gA4ouXlkUwjnta084bpjCg==:

The key directory is a JWK Set served at /.well-known/http-message-signatures-directory. The shape below is adapted from agent-ready.dev’s own live directory:

{
  "keys": [
    {
      "kty": "OKP",
      "crv": "Ed25519",
      "kid": "rMqk28OfQja_GIbetNi-slasXmoLVBa_6SQI0vmLbHY",
      "use": "sig",
      "alg": "EdDSA",
      "x": "jLX5Lq31z_ovipiZV8lNeLA4S7m4I1R82loJkUZWKY8",
      "nbf": 1767225600,
      "exp": 1830297599
    }
  ]
}

An origin can optionally advertise Accept-Signature (RFC 9421) in a response to solicit signed requests.

Reading the direction right

This is the part most people get backwards. Web Bot Auth signs requests — the agent is the signer, the website is the verifier. So there are no “Web Bot Auth response headers” on an ordinary website for a scanner to probe for; origin-side support is invisible from outside. The signatures ride on the agent’s request, not the site’s response.

The only crawlable, checkable artifact is the key directory — and that lives on the agent operator’s domain, not on the sites being visited. Readiness tools that grade ordinary websites down for “missing Web Bot Auth signature headers” have the protocol the wrong way around: an everyday site has nothing to publish and is doing nothing wrong.

Web Bot Auth vs user-agent strings and robots.txt

User-agent strings and robots.txt identities are trivially spoofable — anyone can send Googlebot or ChatGPT as a header, and robots.txt tells a crawler how to behave rather than proving who it is. 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.

Who’s using it (July 2026)

OpenAI signs ChatGPT agent and Operator requests, with public keys under operator.openai.com.
Cloudflare’s Signed Agents program launched with ChatGPT agent, Block’s Goose, Browserbase, and Anchor Browser as founding members, and folds into its Verified Bots program.
AWS WAF supports verification (added November 2025); Amazon Bedrock AgentCore’s browser signs its traffic.
Google’s Google-Agent signs while the main Googlebot crawler 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 the use of 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: its own directory is live with one Ed25519 key (kid, nbf/exp, alg EdDSA) and the correct media type. The site publishes its signing-key directory — the discovery half — and C14 validates any site that does the same. It does not, today, cryptographically sign its own outbound requests.

See the full mapping from every check to the specification it implements in the spec registry.

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.