Web Bot Auth

What Web Bot Auth is

Web Bot Auth is the name of an IETF working group and its Internet-Draft work on authenticating automated web traffic. The idea is straightforward: crawlers, AI assistants and autonomous agents sign their HTTP requests using HTTP Message Signatures (RFC 9421), and publish the public keys that verify those signatures under an identifier they control. A website can then confirm that a request really came from the operator it names, instead of relying on a user-agent string anyone can copy. For what this means for a product team, see Web Bot Auth for product teams; for implementation steps, see the guide on how to verify signed AI agent requests.

As of November 2026, the working group's core document is draft-ietf-webbotauth-httpsig-protocol, which defines a Signature-Agent header for in-band key discovery, a key directory format based on JSON Web Key Sets and a well-known URI where that directory is served. The working group documents page lists it alongside related individual drafts. These are Internet-Drafts, which means they are works in progress. Details such as how keys are discovered, which request components must be signed and which headers carry operator information can change between versions. Implementers should track the current drafts rather than any snapshot.

Why it matters

Websites and APIs have long identified bots by user-agent strings and IP ranges. Both have limits: user-agent strings are trivially spoofed (see user-agent spoofing), and IP ranges shift and are shared across cloud providers. As AI agents begin to browse, call APIs and use MCP servers on behalf of people, applications need a sturdier way to tell cooperating automated clients apart from anonymous ones.

Signed requests give that sturdier footing. A verified signature lets an application recognize a known operator consistently, give it a structured path instead of a human-shaped interface, and measure its activity accurately.

How it works at a high level

1. The operator generates a key pair and publishes the public key at a location tied to its identity, typically the http-message-signatures-directory well-known path under its domain.
2. Each request includes Signature-Input and Signature headers covering selected request components, plus a key identifier, and a Signature-Agent header pointing to the key directory.
3. The receiving site fetches or caches the operator's published keys, rebuilds the signature base and verifies the signature.
4. On success, the site knows the request was produced by the holder of that key, associated with that published identifier.

What it establishes, and what it does not

A Web Bot Auth signature authenticates the automated client. It does not answer:

• whether the operator is permitted to do what it asks (agent authorization),
• whether a person instructed or approved the action (delegated authority),
• whether the action is safe or the content returned will be used appropriately.

Those remain decisions for the receiving application's own authentication, authorization and policy. Our blog post on what signed AI agent requests prove, and what they don't explores this boundary.

Common misconceptions

• "Every bot will sign soon." Adoption grows client by client. Applications will see a mix of signed, declared and anonymous traffic for a long time, so they need a clear way to handle each.
• "A signature makes a bot good." It makes a bot known. Known is the starting point for a policy, not the policy itself.
• "The draft is final." It is an evolving Internet-Draft. Build against the current text and expect revisions.

How Proof of Actor relates

Proof of Actor treats a validated signature as evidence with the basis verified, scoped to the key and identifier it proves. It keeps that separate from declared names and inferred signals, and it never turns identity into permission. Proof of Actor is designed to verify signed requests as these standards mature; your own policies in Route decide what a verified agent may do.

See how this fits into APIs and MCP servers, or apply for early access.

Sources

• IETF Web Bot Auth working group: charter, chairs and status
• Web Bot Auth working group documents: current working group and related drafts
• draft-ietf-webbotauth-httpsig-protocol: Signature-Agent, the JWKS key directory and its well-known URI (work in progress as of November 2026)
• RFC 9421: HTTP Message Signatures: the signature standard Web Bot Auth builds on