Implement Web Bot Auth

Verify visiting agents by checking their Ed25519-signed requests under RFC 9421 and publishing your own key directory for others to check.

What is Web Bot Auth?

Web Bot Auth is a cryptographic way to prove which bot is which: an agent signs its HTTP requests with an Ed25519 key using HTTP Message Signatures, RFC 9421 (IETF, 2024), and a Signature-Agent header names the host where its public keys are published (Cloudflare, 2025). Two IETF drafts by Thibault Meunier (Cloudflare) and Sandor Major (Google) describe the scheme — an architecture and a key-directory format, both at revision -05 of March 2026 — and the IETF's Web Bot Auth working group now carries the work as draft-ietf-webbotauth-httpsig-protocol-00 (IETF, 2026).

Why does Web Bot Auth matter for agents?

Web Bot Auth matters because access control only works if you can tell a real agent from an impersonator, and User-Agent strings are trivially faked while IP ranges drift. A verified identity is something policy can attach to — allow this agent, rate-limit that one, charge a third via pay-per-crawl. OpenAI already signs all Operator requests with HTTP Message Signatures so that site owners can verify them (Cloudflare, 2025). It is the verification backbone of the access-control dimension.

How do you implement Web Bot Auth?

Implement Web Bot Auth on two sides: as a verifier of incoming agents and, if you operate an agent, as a signer with a published key directory.

1. To verify incoming agents, parse the Signature-Input, Signature and Signature-Agent headers, fetch the JWKS at the signer's /.well-known/http-message-signatures-directory, and validate the signature per RFC 9421 before applying your access policy (Cloudflare, 2026).
2. To be verifiable yourself, generate an Ed25519 keypair, publish the public key as a JWKS at that well-known path with Content-Type: application/http-message-signatures-directory+json, and sign every outbound request; Cloudflare's verified-bots program accepts such a directory through its bot submission form (Cloudflare, 2026).
3. Verify: a signed request validates, and an unsigned or tampered request is rejected.

The Agent-Readiness Audit's web-bot-auth check (5 of 100 points) passes when a site's /.well-known/agents.json advertises an identity block for the scheme; it does not exchange signatures. This site is a verifier, not a signing agent: /api/whoami reconstructs the RFC 9421 signature base, verifies the Ed25519 signature and reports verified (key possession) and trusted (keyid listed in its trusted-key registry) separately, taking the key from a Signature-Key header or that registry rather than from a Signature-Agent directory. node scripts/webbotauth-demo.js signs a request with the bundled demo key and shows both flags true.

Web Bot Auth — frequently asked questions

Which headers does a Web Bot Auth request carry?

Three: Signature-Input and Signature, defined by RFC 9421 (IETF, 2024), plus Signature-Agent, which names the host of the signer's key directory (Cloudflare, 2026).

Where does a verifier find the signer's public key?

In a JWKS at the signer's /.well-known/http-message-signatures-directory, served as application/http-message-signatures-directory+json, as the IETF directory draft specifies (IETF, 2026). Cloudflare supports Ed25519 keys there.

Does agentswelcome.dev verify Web Bot Auth signatures?

Yes. /api/whoami verifies the Ed25519 signature on a request and reports verified and trusted separately; it takes the public key from a Signature-Key header or its trusted-key registry and publishes no key directory of its own, because the site verifies agents rather than acting as one.

Related: the Web Bot Auth spec entry · verify agents in the Crawler Registry · Web Bot Auth defined · the access-control dimension · audit your site

← Agent-Readiness · .md