EXPLAINER

Web Bot Auth for product teams: what signed agent requests mean for your roadmap

AI agents and crawlers increasingly need a way to prove who they are without relying on a User-Agent string anyone can copy. The IETF Web Bot Auth work is the leading effort to standardize that. Here is a plain explanation for product managers and engineering leads: how it works, what it proves, its status as of November 2026, and how to plan for it.

Get Early Access Explore How It Works

By Toshendra SharmaFounder & CEO, AgentCredia · Updated November 13, 2026

For years, the only way an automated client could tell a website who it was came down to a name in the User-Agent header and, for a few large operators, a published list of IP addresses or a reverse DNS check. Names are easy to copy. Network lists cover only the operators that maintain them. As AI agents start acting for real people across the web, that gap has become a product problem, not just a security one.

Web Bot Auth is the leading effort to close it. It gives automated clients a way to sign their requests with a key they control and publish, so a site can check the signature instead of trusting a name. This explainer is for product managers and engineering leads who need to understand what it is, what it changes, and what it does not, without reading the specifications end to end.

The short version

What it is: an IETF working group, webbotauth, and the approach it is standardizing for authenticating automated HTTP clients.
How it works: the client signs parts of each request using HTTP Message Signatures (RFC 9421) and points to a directory of its public keys. The site fetches the key and verifies the signature.
What it proves: which key signed the request, and that the signed parts were not changed in transit.
What it does not prove: that the agent is authorized to do what it is asking, that it acts for a particular user, or that it will behave well.
Status as of November 2026: RFC 9421 is a published Proposed Standard. The Web Bot Auth protocol document is a working group Internet-Draft, not yet an RFC.
What to do: plan to treat valid signatures as strong evidence, keep handling unsigned traffic, and keep authorization decisions in your own code.

What the IETF Web Bot Auth work is

The IETF chartered the Web Bot Auth working group to standardize methods for cryptographically authenticating automated clients and for giving websites more information about the operators behind them. The charter focuses on sites that mainly serve people, and it names a broad set of clients in scope: crawlers, web archivers, link checkers, AI training crawlers and AI agents acting for end users.

Two exclusions in the charter are worth noting for product teams. End-user authentication is out of scope, so this is not a way to log a person in. Tracking bot reputation is also out of scope, so the standard tells you who signed a request, not whether that operator is trustworthy.

The charter lists three kinds of deliverables:

Standards track documents on techniques for authenticating automated clients to websites built for people.
Standards track documents on conveying more information about a requesting bot using an existing identifier such as a domain name or URL.
Best current practice or informational documents on operational topics such as key management, lifecycle and deployment.

Where the documents stand, as of November 2026

As of November 2026, the working group has one adopted working group document: draft-ietf-webbotauth-httpsig-protocol, titled "HTTP Message Signatures for automated traffic", at revision 01, dated October 29, 2026. It is an Internet-Draft, which means it is a work in progress that can still change. It is not an RFC.

Several individual drafts are also associated with the group and are under discussion, including proposals on a registry and agent card format, anonymous bot authentication, a JSON format for publishing the IP ranges of automated clients, and a header for signed agent metadata. Individual drafts are proposals; none of them has been adopted by the group as of this date.

The charter set milestones during 2026 for sending specifications to the IESG for approval. As of November 2026, the protocol document remains a working group draft. You can follow the current state on the IETF datatracker page for the working group and the protocol draft.

How HTTP Message Signatures work

Web Bot Auth builds on RFC 9421, HTTP Message Signatures, published in February 2024 as a Proposed Standard. RFC 9421 is a general mechanism: it defines how to sign selected parts of an HTTP message and how to carry the signature in headers. Web Bot Auth profiles it for automated clients.

In plain terms, a signed agent request works like this:

The operator creates a key pair. It keeps the private key secret and publishes the public key.
The client chooses what to sign. It picks components of the request, such as the target host or URI and a creation time. The current draft requires covering the authority or the target URI, so a signature for one site cannot simply be replayed against another.
The client signs and sends. The request carries a Signature-Input header describing what was signed and with which key, and a Signature header with the signature value. The draft uses a web-bot-auth tag and expects creation and expiry times on each signature.
The site verifies. It finds the public key, rebuilds the signed components from the request it received, and checks the signature. If the check passes, the request was signed by the holder of that key and the covered parts were not altered.

The draft also lets a site ask for a signature. An origin can send an Accept-Signature header, typically with a refusal, to signal that it wants signed requests.

The key directory idea

A signature is only useful if the site can find the right public key. Web Bot Auth answers that with a key directory.

In the current working group draft, the client adds a Signature-Agent header containing an HTTPS URL. That URL serves a directory of the operator's public keys as a JSON Web Key Set. The site fetches the directory, selects the key that matches the key identifier in the signature, and verifies. The draft also defines a well-known path, /.well-known/http-message-signatures-directory, where an operator can serve its directory.

The useful idea for product teams is that the URL becomes the identity. An agent operator is identified by where it publishes its keys, which ties the signature to a domain the operator controls. Key rotation works by publishing a new key alongside the old one, then removing the old one.

Verifying sites need to handle directories carefully: cache them following normal HTTP rules, set size limits and timeouts, and avoid fetching from private network addresses. These are standard engineering concerns, and they are part of why many teams prefer a component that does verification for them.

What a valid signature proves, and what it does not

This is the most important section for anyone writing product policy.

A valid signature proves:

The request was signed by the holder of a specific private key.
That key is published at a directory URL the operator controls.
The signed parts of the request were not changed in transit, and the signature is within its validity window.

A valid signature does not prove:

That the agent is authorized to perform the action. Being identifiable is not permission. See agent authorization.
That the agent acts for a specific person, or within the authority that person gave it. See delegated authority.
That the operator is trustworthy or that the agent will behave well. Reputation is explicitly out of scope for the working group.
Anything about requests that are not signed. Unsigned traffic still needs its own handling.

Treat a valid signature as strong evidence of who sent a request, then let your own access control decide what that sender may do.

What product teams should do about it

You do not need to wait for an RFC to plan. Signed agent traffic is something you can prepare for now, with the expectation that some details of the draft may change.

1. Measure before you decide

Find out how much of your traffic is automated, which routes agents use, and how much of it is signed. Start in observation mode so that measuring changes nothing for your users.

2. Separate evidence from policy

Record what the evidence says, verified, declared, inferred or unknown, separately from what you decide to do. That keeps policies readable and lets you tighten or relax them without re-instrumenting. The evidence basis entry explains the four levels.

3. Give verified agents a better path

Where it makes sense, serve verified agents structured content or an agent-friendly flow instead of pages built for people. The guide on serving AI agents structured content covers the patterns.

4. Keep authorization in your code

Use the signature to know who is asking. Use your existing permissions, scopes and confirmations to decide what they may do. High-impact actions may still need a human confirmation, whoever signed the request. See protecting sensitive actions without blocking agents.

5. Plan for unsigned and Unknown traffic

Support for signing varies across agents and tools, so expect a mix of signed and unsigned requests for some time. Decide per route what happens to declared, inferred and Unknown traffic, rather than picking one site-wide rule. The guide on handling Unknown traffic walks through this.

How Proof of Actor uses Web Bot Auth

Proof of Actor tells your application who or what is acting on each interaction, Human, Human + AI, Agent or Unknown, and states the evidence basis. Web Bot Auth signatures are one of its strongest sources of evidence.

When an agent signs its request with HTTP Message Signatures, Proof of Actor checks the signature against the operator's published key. If the check passes, the result carries a verified basis, along with the evidence your team can review. If a client only names itself in a header, the result is declared. If the conclusion rests on behavioral or contextual signals, it is labeled inferred. If the evidence is not enough, the result is Unknown.

Your application decides what to do with that context. Policies are written per route, per actor class and per basis, with outcomes such as allow, adapt, challenge, review and rate-limit. Nothing is enforced by default: you preview a policy against real traffic and enforce it route by route, in your own code.

Founding teams can collect evidence through Node.js middleware, Next.js, an edge integration, a browser collector on approved pages, the generic HTTP API, or an MCP server integration. See integrations, and the guide on verifying signed agent requests for the practical steps.

Proof of Actor follows the same limit the standard does: a verified signature tells you which key signed the request, not whether the agent is authorized. Authorization stays with you. The evidence and limits page sets out exactly what each result can and cannot support.

Get started

Proof of Actor is in private beta. Selected founding developer teams can receive up to 12 months of free access within agreed usage limits, with no automatic billing. Apply for early access and tell us which routes you expect signed agents to use and what you want to do with them.

FOR DEVELOPERS

What your code receives

Every interaction resolves to one result record. Your application reads the class and the basis and applies its own policy.

Result record

{
  "route": "GET /api/v1/catalog",
  "class": "agent",
  "basis": "verified",
  "evidence": [
    { "signal": "http_message_signature", "result": "valid", "keyid": "assistant.example" },
    { "signal": "client_declaration", "value": "assistant.example" }
  ],
  "observed_at": "2026-11-13T10:42:07Z"
}

class: Human, Human + AI, Agent or Unknown.
basis: How strong the evidence is: verified, declared, inferred or unknown.
evidence: The signals behind the result, so your team can see why.

Start in observation mode: record results next to your logs and change nothing until you choose a policy. Read the Node.js integration guide

Frequently asked questions

What is Web Bot Auth?

Web Bot Auth is the name of an IETF working group, webbotauth, and the approach it is standardizing: automated clients sign HTTP requests with HTTP Message Signatures (RFC 9421) and publish their public keys, so websites can verify which operator sent a request.

Is Web Bot Auth a finished standard?

Not yet. As of November 2026, the main protocol document, draft-ietf-webbotauth-httpsig-protocol, is a working group Internet-Draft at revision 01. RFC 9421, the signature format it builds on, is a published Proposed Standard.

Does a valid Web Bot Auth signature mean the agent is allowed to act?

No. It proves which key signed the request and that the signed parts were not altered. Whether that agent may read data, submit a form or act for a particular user is an authorization decision your application still makes.

Do product teams need to implement Web Bot Auth themselves?

Sites verify signatures; they do not need to sign anything unless they also run automated clients. Verification involves fetching key directories, caching them safely and checking signatures, which a tool like Proof of Actor can do for you.

What should we do with agents that do not sign their requests?

Treat them according to the evidence available: declared, inferred or Unknown. Expect a mix of signed and unsigned traffic for some time, and set a fallback per route instead of a single site-wide rule.

How does Proof of Actor use Web Bot Auth?

It checks HTTP Message Signatures against the published key and, when the check passes, reports the result with a verified basis. Your policies can then treat verified agents differently from declared or Unknown traffic.

Know who's using your app.

Private beta for a small group of founding developers.

Get Early Access View pricing

Prefer to talk first? Talk to the founders