Pay Per Crawl and the Paid Web: Privacy Risks of HTTP 402
HTTP 402 can make machine payments simple for servers. It can also create records that connect a client, payment, time, and requested resource. The exact record depends on the payment scheme and each service's logging.
Privacy frame: agent payments are authority systems. The useful question is not whether a protocol is modern. The useful question is who can spend, who approves, who settles, who stores logs, and how quickly the user can revoke it.
Primary sources
- x402 protocol site
- Coinbase HTTP 402 docs
- Cloudflare x402 foundation post
- Stripe x402 docs
- IETF HTTP Semantics: 402 Payment Required
The clean engineering story
RFC 9110 reserves HTTP 402 Payment Required for future use and does not define a standard payment flow. x402 adds one: a server returns payment requirements, the client authorizes payment and retries, and the server returns the resource after verification.
Coinbase and Stripe document this flow for machine-to-machine access. Cloudflare has also described a separate pay-per-crawl beta that aggregates crawler charges to a connected card or bank account.
The privacy cost
The server necessarily receives the requested path and request timing. In the x402 examples published by Coinbase, Cloudflare, and Stripe, the payment requirements also identify an amount, recipient, network, or facilitator. A facilitator verifies or settles the payment. Each party can therefore observe part of the request and payment flow, subject to its implementation and retention policy.
On-chain payment records are public. Reusing one wallet can link payments that would otherwise look unrelated. Cloudflare's deferred proposal uses a signed client commitment tied to an account, while its pay-per-crawl beta generates audit logs and charges a connected card or bank account. Neither model should be treated as anonymous by default.
- A 402 response shows that a client requested a paid resource, even if it does not complete payment.
- Repeated use of one wallet or account can link separate requests.
- Public funding and settlement transactions can connect a payment wallet to other activity.
- Server, facilitator, payment processor, and crawler audit logs are separate parts of the privacy model.
Privacy guidance
Before using paid crawl, identify which party sees the resource path, payment account, wallet address, IP address, and crawler identity. Check retention terms rather than assuming that protocol-level accountlessness means no records.
For sensitive work, separate payment credentials and crawler accounts by purpose where the provider permits it. Keep a narrow budget and require approval for unfamiliar domains or unexpected prices. A separate wallet reduces correlation, but its funding history can still reconnect activity.
Before using paid crawl
- Map which server, facilitator, and payment processor sees each field.
- Avoid wallet or account reuse across unrelated work.
- Tiny prepaid budget, not a broad wallet grant.
- Separate network and account identity for sensitive research.
- Review facilitator, server, and crawler retention terms.
Use the Agent Money matrix and the agent-money directory filter to compare current providers.
Frequently Asked Questions
Why is HTTP 402 a privacy issue for AI agents?
A paid HTTP request can reveal which resource an agent tried to access, when it retried, which wallet or facilitator paid, and which account or crawler identity was involved.
Can pay-per-crawl be private?
Only with strict compartmentalization. Use separate wallets or payment instruments, avoid address reuse, keep crawler identities separate, and do not mix sensitive research with main accounts.