Web Bot Auth: How AI Agents Prove Their Identity to Merchants (Cloudflare, RFC 9421, and Visa TAP)

Web Bot Auth lets an AI agent prove which agent it is on every HTTP request. The agent signs each request with a private key using HTTP Message Signatures (RFC 9421) and publishes the matching public key in a key directory, so merchants and CDNs can cryptographically verify the caller rather than guess from IP addresses. Lane implements it, and Lane's agent passed Cloudflare's Web Bot Auth crawl verification.

Lane is the payment infrastructure that lets AI agents transact with any merchant: agents integrate once and can order food, shop online, and book travel and reservations on a user's behalf, with the user's own card and explicit approval. Verifiable identity is the layer underneath all of that, because an agent that cannot identify itself does not get served in the first place.

Why do AI agents get blocked at merchants?

The reflex answer is that merchants do not want agents. That is mostly wrong. Merchants deploy bot defenses because they have real abuse problems, and the defenses have no way to distinguish a good agent from a bad one.

• Anonymity is the default. An HTTP request from an agent carries nothing trustworthy about who sent it. A user agent string is a self-report that anyone can copy, so it cannot be the basis of a trust decision.
• Bot defenses are built for abuse. Providers such as Cloudflare, Akamai, and DataDome exist to stop credential stuffing, scraping, inventory hoarding, and card testing. Faced with unidentifiable automation, blocking is the correct default.
• The available signals are indirect. IP reputation, request rates, and behavioral heuristics infer intent from side effects rather than from identity. They necessarily produce false positives, and legitimate agents land in them.
• The merchant cannot opt in to what it cannot name. Even a merchant that actively wants agent-driven orders has no mechanism to allow specific agents when no agent can prove its identity.

The blocking problem is an identity problem. You cannot allowlist an anonymous caller.

What is Web Bot Auth?

Web Bot Auth is a set of conventions, developed in the open through IETF work and driven substantially by Cloudflare, that gives automated clients a verifiable cryptographic identity at the HTTP layer. It has two halves.

• Signed requests. The agent signs each outbound HTTP request with a private key using HTTP Message Signatures, defined in RFC 9421, and attaches the signature and its metadata as HTTP headers.
• A published key directory. The agent publishes its public keys at a well-known location, described by the HTTP message signatures directory draft, so any verifier can fetch the key referenced by a signature and check it.

The design is deliberately boring, which is its strength. There is no new transport, no handshake to negotiate, and nothing for a merchant to install. A verifier that can fetch a URL and check an Ed25519 signature can verify an agent.

How do HTTP Message Signatures (RFC 9421) work?

RFC 9421 defines a general mechanism for signing parts of an HTTP message so a recipient can verify integrity and origin. It is public standards material, and the mechanics are worth understanding if you are evaluating agent identity.

1. 1

   Choose the covered components. The signer selects which parts of the request the signature covers. For agent identity these are typically derived components such as the method, authority, and path, so the signature is bound to the specific request being made.

2. 2

   Build the signature base. The covered components are serialized into a canonical string, in a defined order, together with signature parameters such as the key identifier, the algorithm, a creation timestamp, an expiry, and a tag identifying the purpose.

3. 3

   Sign it. The signer produces a signature over that canonical string with its private key. Ed25519 is the common choice for Web Bot Auth: small keys, small signatures, fast verification.

4. 4

   Attach two headers. The request carries a Signature-Input header describing what was signed and with which key, and a Signature header carrying the signature bytes themselves.

5. 5

   The verifier reconstructs and checks. A recipient rebuilds the same canonical string from the request it received, fetches the public key named by the key identifier, and verifies the signature. If the request was altered or the key does not match, verification fails.

Because the signature is bound to request components and carries a creation time and expiry, a captured signature cannot be usefully replayed against a different request or reused indefinitely.

What is a key directory, and why does publishing keys matter?

A signature is only meaningful if the verifier can obtain the right public key. Web Bot Auth handles that with a directory: the agent operator publishes its public keys, in JSON Web Key form, at a well-known HTTPS location that verifiers can fetch and cache.

• It makes verification permissionless. Any merchant or CDN can verify a signed request without a prior relationship with the agent operator, a shared secret, or an onboarding process.
• It ties identity to a domain. The directory is served over HTTPS from the operator's own domain, so the key is bound to a named, accountable entity rather than to an anonymous client.
• It supports key rotation. Signatures reference a specific key identifier, so an operator can publish a new key and retire an old one without breaking verifiers mid-flight.
• It scales without coordination. One published directory serves every verifier on the internet. That is what makes the model workable across millions of merchants.

How does a merchant or CDN verify a signed agent?

1. 1

   Notice the signature headers. The incoming request carries Signature-Input and Signature. Their presence tells the verifier this client is claiming a verifiable identity rather than staying anonymous.

2. 2

   Resolve the key. The verifier reads the key identifier from the signature parameters and fetches the corresponding public key from the operator's published directory, typically with caching.

3. 3

   Verify the signature. The verifier rebuilds the signature base from the request as received and checks the signature against the public key, along with the creation and expiry times.

4. 4

   Apply policy. Verification produces an identity, not a decision. The verifier then applies its own policy: allow, rate limit differently, require additional steps, or deny. In practice this often happens at the CDN before the request reaches the merchant's application.

What does Web Bot Auth prove, and what does it not?

Being precise here matters, because verifiable identity is frequently oversold. Web Bot Auth answers a narrow question extremely well and deliberately leaves the rest to other layers.

The stack only works when all of those layers are present. Verifiable identity gets the agent served, an approved intent proves the human authorized the purchase, and network-recognized credentials get the payment authorized.

How has Lane implemented Web Bot Auth?

Lane runs Web Bot Auth in production. The identity posture is deliberately public: the signatures, the key directory, and the registry entries are all verifiable by anyone, because identity that cannot be checked is worthless.

• Every request is signed. Lane's executor signs its requests using HTTP Message Signatures with an Ed25519 key. Signing is not conditional or opportunistic, it is how Lane's agent presents itself.
• Lane publishes a key directory. Lane hosts its own key directory, so any merchant or CDN can resolve the key referenced by a Lane signature and verify it independently.
• Cloudflare verification passed. Lane passed Cloudflare's Web Bot Auth crawl verification, which matters because a large share of the internet's bot policy is enforced at the CDN layer rather than in merchant application code.
• Lane is in Visa's TAP registry. Lane is registered in Visa's Trusted Agent Protocol registry alongside Cloudflare, so Lane's agent is recognized at the card network layer as well as at the request layer.
• Lane operates as a known agent, by design. The strategy is to be identifiable rather than evasive. Lane operates as a known, cryptographically verified agent, which is the only posture compatible with merchants making deliberate policy decisions.

What do agent platforms get by integrating Lane?

Verifiable identity is real infrastructure work: key generation and custody, a signing path on every outbound request, a published directory, rotation, and verification testing against the CDNs that actually enforce policy. Agent platforms that integrate Lane inherit the result instead of rebuilding it.

• Lane manages the keys. Key generation, custody, and rotation are Lane's responsibility. The builder does not run a signing key or a key directory.
• Lane signs on the platform's behalf. Purchases executed through Lane are made by an agent that is already signed and already verifiable, so the builder does not implement RFC 9421 in its own request path.
• Registry standing comes with it. Lane's Cloudflare verification and Visa TAP registration apply to the agent that actually performs the purchase, which is Lane's.
• It is one integration, not four layers. Identity, consent, payment credentials, and merchant execution arrive together. Builders add payments to their agent without becoming a payments company or an identity company.

How does Web Bot Auth relate to Visa's Trusted Agent Protocol?

Web Bot Auth and Visa's Trusted Agent Protocol are complementary answers to the same question at different layers. Web Bot Auth is cryptographic proof at the request layer: this specific HTTP request was signed by a key belonging to a named operator. Visa's Trusted Agent Protocol is recognition at the network layer: this operator is a listed participant with obligations in a payments context.

A merchant benefits from both. The signature tells it the caller is who it claims to be, and the registry tells it that the caller is a known participant in the payment ecosystem rather than merely a well-behaved crawler. Lane holds both positions, and pairs them with recognized agentic payment credentials as a certified Visa Intelligent Commerce enabler.

Where is Web Bot Auth heading?

The standards work is public and progressing: RFC 9421 is a published standard, the signature directory conventions are moving through IETF drafts, and verification is being adopted where it is most useful, at the CDN edge. The direction is toward agent identity being a normal, checkable property of a request rather than a special arrangement.

The consequence for builders is worth stating plainly. As verification becomes standard, the split will not be between agents that are allowed and agents that are blocked by heuristics. It will be between agents with verifiable identity and agents without one, and the second group will find the internet closing.

Web Bot Auth turns "trust me" into "check my signature", which is the only version of agent identity that scales to millions of merchants. Lane signs every request with an Ed25519 key, publishes a key directory anyone can verify against, passed Cloudflare's crawl verification, and is registered in Visa's Trusted Agent Protocol registry, so platforms building on Lane start with an identity merchants can actually recognize.