# An agent's identity now travels in the request headers > Signed requests are replacing IP ranges and user-agent strings as the way automated clients identify themselves. The signature names the platform, not the person, and payment and card networks are extending it toward the consumer. - Publication: Context Window (https://context-window.blog/) - Canonical: https://context-window.blog/articles/an-agents-identity-now-travels-in-the-request-headers/ - Published: 2026-09-17 - Contributor: Saira Ren - Topic: Agent identity A request reaches a website carrying three headers it would not have carried two years ago. `Signature-Agent` names a domain. `Signature-Input` lists what was signed, when the signature was created, when it expires, a key identifier, and a tag reading `web-bot-auth`. `Signature` holds the result. The site, or the proxy in front of it, fetches the public key from a directory at a well-known path on the named domain, verifies the signature, and decides what to do with the request. No account was created at the site. No secret was shared in advance. No list of IP ranges was consulted. This is how automated clients are beginning to identify themselves, and I think the design tells you more about who is trusted than the marketing around it does. The identity of an automated client is moving out of the account and out of the network address and into the request itself. What the signature names is not the user, and not the task. It names the operator of the signing infrastructure. Everything else is vouched for. ## What the origin verifies Cloudflare proposed the scheme in May 2025 under the title [Forget IPs](https://blog.cloudflare.com/web-bot-auth/), building on the HTTP message signatures standard, RFC 9421. The agent signs the authority of the target, the host it is calling, and points the origin to a key directory such as `crawler.search.google.com` or `operator.openai.com`. OpenAI is quoted in the same post confirming that it signs all requests from its Operator agent so that site owners can verify the source. The IETF now carries an [architecture draft](https://datatracker.ietf.org/doc/html/draft-meunier-web-bot-auth-architecture) for the mechanism, still labelled work in progress, and Cloudflare's readiness scanner, launched in July, checks whether a site publishes the key directory at `/.well-known/http-message-signatures-directory`. The verification answers one question with confidence: this request was signed by a key that the named domain publishes. That is a large improvement on a user-agent string, which anyone can type, and on an IP range, which changes with the hosting provider and is shared by every tenant on it. It is also a narrower claim than it looks. ## The signature names the platform In August 2025 Cloudflare added a classification it calls [signed agents](https://blog.cloudflare.com/signed-agents/), separate from its verified bots. The definition has three parts. The agent is generally directed by an end user rather than by a single company. The infrastructure or remote browsing platform the agent runs on signs its requests. And the agent complies with a published policy. Cloudflare validates the signatures and lets its customers allow or block signed agents as a group. Notice which principal appears in each part. The end user directs the agent but signs nothing. The platform signs, and the platform is the entity that applied to the directory and agreed to the policy. The origin's log will record the platform's domain. If the user behind the request asked for something the site would rather not have served, the site's recourse runs to the platform, which is the only party it can identify. This is a delegation chain with one visible link. It is not a flaw in the cryptography. It is a decision about where responsibility should be concentrated, and the decision favors platforms, because platforms are the parties that can hold keys, publish directories, and be held to policies. ## Where identification used to live For crawlers, the arrangement is an upgrade to something old. Search engines have let site owners confirm their crawlers through reverse DNS lookups for years, and Cloudflare's verified-bots program vetted operators who were transparent about who they were and what they did. Those mechanisms identified an operator's software acting for the operator. The crawler fetched pages for the company that ran it. The reason the older tools broke, in Cloudflare's own account, is that agents are now directed by individuals. The bot in the request may be booking a flight for one person and ordering groceries for another from the same platform, the same key, and often the same address range. The software's identity is stable. The intent behind it changes with every request, and nothing in the signature carries it. ## Adoption is thin and one-sided Cloudflare's own measurement puts the scheme in proportion. Scanning the 200,000 most visited domains, its [agent readiness report](https://blog.cloudflare.com/agent-readiness/) found that 78 percent publish a robots.txt file, 4 percent declare AI usage preferences in it, 3.9 percent serve Markdown when asked, and fewer than fifteen sites in the whole dataset publish the newest discovery standards. Signing keys for outbound agents are checked only for sites that run agents at all, and the post notes that a site which merely serves content does not need one. On the sending side the scheme is voluntary. Only an agent that wants to be recognized signs. Cloudflare describes the goal as an affirmative mechanism to authenticate desirable bot traffic, which is exact. A signature scheme that only cooperative parties adopt is an allow-list for the polite. It changes what the site can grant, not what the site can prevent, and the undesirable traffic it was contrasted with keeps arriving unsigned. ## The consumer enters the header Visa's Trusted Agent Protocol takes the same signature and attaches a much richer identity to it. Its [specification page](https://developer.visa.com/capabilities/trusted-agent-protocol) describes signatures specific to the merchant and purpose, time bound and unable to be replayed, and then lists what an agent may pass alongside them: an intent to browse or purchase a specific product, a verifiable token tied to the consumer's existing merchant account, device identifiers so the merchant can recognize a returning buyer without an account, country and postal code, and a wallet address. The stated aim is merchant visibility, so that a merchant can distinguish a commerce-focused agent from a bot it would otherwise block. Here the header stops naming only the platform and starts describing the person. Visa presents the product as still in development, and I have no evidence of how merchants will use the fields. But the direction is legible. The identity layer that arrived to answer which platform sent this is being extended to answer who is shopping, and the consumer's data travels in the request, supplied by the agent, under an agreement the consumer made with a wallet provider rather than with the merchant. The payment protocols are wiring this in. The Machine Payments Protocol's client library now carries [Web Bot Auth or Trusted Agent Protocol attestations on the initial request and on every paid retry](https://mpp.dev/blog/mppx-identity-support), and lets the server verify them before it issues a payment challenge. Identity checks are becoming a precondition for being quoted a price. ## The verified-bot objection The simplest rival explanation is that this is the verified-bots program with better cryptography. Reverse DNS checks did the same job for a decade. The key format changed, the directory moved to a well-known path, and a standards body wrote it down. For crawlers I think the objection wins, and my thesis should not claim more than the evidence supports there. A crawler signed by its operator is the old arrangement with a stronger signature. The change is confined to user-directed agents, where the signature is a promise by the platform about traffic whose intent the platform does not fully know. There the audit trail ends at the platform, the revocation point is the platform's key or its place in a directory, and the person who gave the instruction appears nowhere unless a scheme like Visa's puts them there. ## Whose name is in the log The inspectable consequence is small and available today. Read the `Signature-Agent` header on requests reaching an API. That domain is the party being trusted, and its key directory is now part of the site's access policy whether or not anyone wrote that down. Two developments would confirm that the header has become the account. One is sellers refusing to quote a price to an unsigned request, which the current tooling already permits. The other is merchants coming to expect the consumer fields that Visa's protocol defines, so that a purchase without them looks suspicious. If both arrive, the web that promised agents access without accounts will have accounts again, held by platforms and wallet providers on behalf of everyone, with the origin trusting a signature and the platform trusting the user. For now the evidence supports only the first step, and it is worth being precise about how far it goes.