Web Bot Auth: a signature that tells a site whose agent is visiting
A user agent string can say anything. A signed request can be checked against keys the agent’s operator publishes on its own domain.
The site’s edge, checking an agent
- 10:42:07Request for /pricing arrivesSignature-Agent: agents.lanternhq.example
- 10:42:07Key directory fetched/.well-known/http-message-signatures-directory
- 10:42:07Signature checked against the published keySignature and Signature-Input match
- 10:42:07Operator identified: Lantern HQThe site applies its rule for this agent
- 10:42:08Page served as to any visitorNo account, no login
Lantern HQ and its shop are invented. The signature says whose agent it is; what the agent may see is still up to the site.
Web Bot Auth is a way for a bot or AI agent to sign each request it sends, so a website can check which company’s agent is visiting. It names the company that runs the agent, never the person it acts for. It is separate from a login, so a signed agent sees what any visitor sees until it has an account of its own.
On this page
How a Web Bot Auth signature works
Web Bot Auth builds on HTTP Message Signatures, an IETF standard from 2024 for signing parts of an HTTP request. Cloudflare’s developer docs set out what the operator of a bot does:
- Publishes its public keys as a JSON Web Key Set at /.well-known/http-message-signatures-directory on its own domain. Cloudflare supports Ed25519 keys.
- Adds 3 headers to each request: Signature-Input (what was signed), Signature (the signature itself) and Signature-Agent (where its keys live).
- Lets the site check: the site fetches the key, verifies the signature and knows which operator sent the request.
The IETF’s Web Bot Authentication working group is standardising it. Its working draft, HTTP Message Signatures for automated traffic, was last revised on 29 October 2026 and is still an Internet-Draft.
What a signed request tells a website
A valid signature tells a site which operator sent the request, so it can allow a known agent, slow it down or block it. The working group’s charter names the weakness of the old methods, IP allowlists and user agent strings. It also keeps authenticating the end user out of scope, along with tracking bots or scoring their reputation.
Web Bot Auth is no login. A signed agent still sees what any visitor sees, and an account at the site needs its own sign-up, as it would for a person.
How a declared agent introduces itself to people
A signature introduces an agent to a server. A declared agent also says what it is to the people it meets in chat, email or on the phone.
Obsession collects what companies show only to customers, step by step: their screens, emails and texts, member prices, trial limits, quotes and cancel offers, each dated with a screenshot. Teams and AI agents look up any company through the API or MCP, and a company not yet covered is added on request. Every Obsession agent is a declared agent, and says it’s an AI when it talks to a person.
An Obsession agent never gets round a CAPTCHA or a bot block. Where a site puts one in front of a step, the record of that visit names the step it couldn’t reach. The full set of lines is on the page for companies an Obsession agent visits.
No. It proves which company’s agent sent a request. A login proves who owns an account, and a signed agent still needs an account of its own to see what customers see.
Cloudflare documents it as a way to verify bots and agents. The IETF working group’s charter covers crawlers for search and for AI training, web archivers and link checkers. It covers AI agents acting for their users too.
No. The working group’s charter keeps authenticating the end user out of scope. The signature identifies the operator that runs the agent.
Declared agent, definedSources
In the order the page cites them. Every page was read on 11 Nov 2026.