Web Bot Auth: Identifying an Agent Request Without Granting Checkout Authority

A merchant wants to distinguish an identified shopping agent from an anonymous bot. Matching a User-Agent string is weak evidence: another client can send the same text. Web Bot Auth offers a cryptographic signal at the HTTP layer, which the merchant can use alongside its own access and transaction policies.

A verified signature still leaves an important question unanswered: what is this requester allowed to do here?

Research boundary: official integration documentation and standards texts reviewed November 1, 2026. Web Bot Auth’s referenced architecture and directory documents are Internet-Drafts; RFC 9421 is the underlying HTTP-signature standard. We did not register a bot, alter a firewall or test a signed request.

The key directory connects identity to verification

The architecture draft describes an agent signing an HTTP request and an origin or fronting verifier checking it. The Signature-Agent mechanism helps locate verification keys. A site must still decide what trust and access to associate with the verified key.

Conceptual authentication flow, not a tested deployment. Checkout approval is intentionally outside signature verification.

Keep the signing key separate from payment authority in the architecture. A key that identifies a crawler or agent service need not be the key that controls a wallet, and the two should not be conflated in a product’s permission screen.

Ask what the signature actually covers

RFC 9421 defines signatures over selected HTTP components. The existence of a valid signature does not establish that every relevant part of a request was covered. Applications must select and enforce the components needed for their purpose.

For a merchant, this suggests a concrete review: identify which signed material binds the request to its intended destination and which mechanism protects any transaction-sensitive content. Do not infer that the amount in a checkout body is authenticated merely because a bot-identification signature is valid.

The verifier should also report enough structured evidence for the application to apply policy, rather than replacing the full decision with a generic “trusted bot” label. A known requester may be permitted to browse a catalogue but still require customer authorization to purchase.

Cloudflare integration has specific compatibility rules

Cloudflare’s documentation describes its own supported key algorithm, directory requirements and signed-header format. It currently documents the directory-03 structured-string form of Signature-Agent and warns that a later draft’s dictionary form is not accepted by that integration.

This is a reason to pin the actual verifier profile. “We implement the newest draft” is not evidence that an existing verifier will accept the request. Maintain compatibility fixtures for the signing library, proxy path and receiving implementation together.

The same documentation states that Cloudflare does not currently validate nonce uniqueness with a seen-nonce database. A nonce field therefore should not be presented as automatic one-use enforcement. Short validity windows reduce exposure, but an application handling purchases still needs its own replay and duplicate-action controls.

Key rotation is an operational workflow

The directory draft discusses overlapping key validity and verifier caching. An agent service should plan publishing, switching and retiring keys as a coordinated change, rather than deleting the old key as soon as the new one exists.

Our proposed preproduction checks are deliberately specific:

• Sign with an expired key and verify rejection under the chosen policy.
• Change a required signed component and confirm verification fails.
• Exercise the actual proxy path, not just a direct local request.
• Rotate keys while the verifier has a cached directory.
• Repeat a purchase request within the signature window and verify that business idempotency prevents a second order.

These are suggested tests, not reported Cloudflare outcomes. Keep logs sufficient to diagnose key identifiers, profile versions and failure stages without exposing private keys or unnecessary customer data.

Authentication should improve decisions, not bypass them

For a site evaluating agent traffic, Web Bot Auth can add a verifiable identity signal. It does not require the site to allow every identified agent, and it does not replace rate limits, account authorization or payment checks.

Our view is to start with a narrow permission such as identified catalogue access, then evaluate checkout separately. See the Web Bot Auth reference and KYA/KYAPay for the adjacent question of represented-principal and payment claims. Neither should be treated as a blanket allowlist for autonomous purchases.