What does a bot prove when it signs a request? Less than you might assume, and more than a user-agent string ever could.
The usual way to identify a bot is still its user-agent string, the line of text every browser and crawler sends with each request, and that string is easy to copy and easy to invent. Web Bot Auth adds a signature a site can check. On 24 September, the first day of Edition 002's window, signed requests from four operators were already arriving at sites the Index monitors.
What a signed request carries
Under Web Bot Auth a request carries three extra headers, Signature, Signature-Input and Signature-Agent, all built on HTTP Message Signatures, the IETF standard published as RFC 9421. For identification the one that matters is Signature-Agent, which names an HTTPS address where the signer publishes its public keys, while Signature-Input carries a keyid saying which of those keys made the signature. On 1 September the IETF's Web Bot Auth working group adopted the protocol as a working-group document, with authors from Cloudflare and Google. The wire-level walk-through takes a signed request apart header by header.
Who was signing
Signatures from four operators appeared that first day, and they do not all do the same job.
The first is Grok Bot, which xAI launched as "AI teammates you can give real work to" that sign in to a customer's tools and use them the way a person does. This is the acting layer in its plainest form, software running a person's errand. Its user agent matched none of the patterns the Index's instrument recognises, so without the Signature-Agent header the instrument would have had nothing to name it by.
The header named cursorusercontent.com, a name that says nothing about xAI. What tied it to Grok Bot was Cloudflare's bot directory, which lists that host as Grok Bot's key directory and classes Grok Bot as an agent whose activity end users can direct. The host a signature points to and the company behind the agent are two separate facts, and a registry such as Cloudflare's, or the operator's own documentation, is what joins them.
The other three read rather than act; signing declares them without making them agents. Exa states on its crawler page that every ExaSearchBot request is cryptographically signed under Web Bot Auth, with its Ed25519 keys published for anyone to check. DuckDuckGo describes DuckAssistBot as a crawler that fetches pages in real time for its AI-assisted answers and says the data is not used to train models; Cloudflare lists its key directory at assistbot.duckduckgo.com. Ahrefs, whose crawlers index and audit sites for search marketing, publishes a key directory of its own.
What a signature proves, and what it does not
The working-group draft is precise about its own limits. Of the address a Signature-Agent header names, it says a valid signature "proves that a holder of a key that URL publishes signed the covered message." It then adds that the signature "says nothing about who operates the Agent, whether the Agent is benign, or whether the request is authorized. Those are origin policy."
That line matters because a signature is easy to mistake for a pass. It is not one.
Instead, a signature turns a claim into something a site can check. The site fetches the directory the request names, finds the key its keyid points to and verifies the signature against the parts of the request it covers. A copied user-agent string passes a string check anywhere, whereas a copied signature stops verifying once it is sent to another host or its expiry passes, and the draft recommends an expiry of no more than 24 hours. Within that window, though, it can still be replayed against the same site; the signed host and the expiry are the limits of its reach.
Seen against this week's news, Web Bot Auth answers the first half of what Amazon asked of Meta's Muse, that an agent identify itself. The second half, whether to serve it, route it to a lane or decline it, remains the business's call, which is what the draft means by origin policy. A signature is identification shown at the door, not permission to walk through it.
What changes for the Index
Edition 002 will be the first to count signed requests by the key directory they name. It covers 24 September to 23 October 2026, and those requests will be reported alongside the crawler, agent-fetch and unknown-bot counts. The method page sets out how each channel is counted, and the current edition is the baseline the next one will be read against.
In practice, the cheapest first step for any site is the one the Index took: log the three headers when they appear. The next is to fetch the directory a request names and verify the signature before relying on it, and the walk-through lists the edge networks that already run that check. For a request that does not sign, the standards page sets out the challenge that stands in for a block.