Cloudflare Wallets and cloudflare.pay: Identity and Payments for AI Agents

Cloudflare Wallets is a programmable stablecoin wallet for AI agents, and cloudflare.pay is the handle namespace that gives those agents a human-readable identity. Together they are the buyer's half of an agentic payment market whose seller's half — the Monetization Gateway — Cloudflare shipped a month earlier. Announced on 4 August 2026, only the handle reservation is live today. This post is my research summary of what was actually built, what was only announced, and what it means if you sell or buy an API.

TL;DR

• Cloudflare Wallets gives an AI agent two things it has never had: a stable identity and a way to pay. Both hang off a Cloudflare account, not a bare keypair.
• The design is a two-tier tree. A human owns an Account Wallet holding the balance; each agent gets a Virtual Wallet reached by API key and bounded by policy the human set — spending caps, per-transaction ceilings, merchant allowlists.
• cloudflare.pay is a handle namespace: an agent can present itself as research.example.cloudflare.pay so a merchant can see which organisation it acts for. It is optional; anonymous agents just get treated with more suspicion.
• Payment rides on x402 — the HTTP 402 protocol I covered in x402 native payments. Cloudflare is a co-founder of the x402 Foundation and has shipped x402 support in Workers and the Agents SDK since September 2025.
• What actually works today (5 Aug 2026): reserving a handle. Funding, on/off-ramps, Virtual Wallet issuance and payments are "coming months". The custody model, the fee schedule, the supported chains and the specific stablecoins are all undisclosed.
• The security framing in much of the coverage is too generous. A spending cap is blast-radius containment, not a defence against prompt injection.

The two things an agent has never had

An AI agent that wants to buy something on the open web runs into the same wall twice.

The first wall is identity. HTTP has no way for a caller to say who I act for. A browser has cookies and a logged-in human; a server-to-server integration has a pre-shared API key issued after somebody signed a contract. An agent arriving cold at an endpoint it discovered thirty seconds ago has neither. From the merchant's side it is indistinguishable from a scraper, and gets treated accordingly.

The second wall is payment. Even if the merchant wanted to sell, there is no account to bill. Card checkout assumes a person who can fill a form, pass 3D Secure, and dispute a charge months later. None of that survives contact with software making a thousand sub-cent purchases an hour.

Cloudflare's answer is to attach both to something it already operates: the customer account. Matthew Prince framed it as "when an agent shows up at your door, you need to know who sent it" — the agent gets a face, and behind the face is a funded, rate-limited wallet the merchant can actually charge.

Whether one CDN should be the issuer of that identity is a fair question, and I come back to it at the end.

What cloudflare.pay actually is today

If you visit https://cloudflare.pay/ you get a single-page app with a form and one line of copy: "Reserve your Cloudflare Wallet name." That is genuinely all it does right now.

The handle is a subdomain-shaped label under cloudflare.pay — the announcement's example is research.example.cloudflare.pay for a research agent belonging to example. The organisational part is what carries the meaning: a merchant that sees the handle knows the agent acts for a named Cloudflare customer, not that it is trustworthy. Cloudflare is explicit that presenting a handle is "completely optional" and that it is "up to businesses to decide whether they want to prioritize transacting with known agents." Agents that stay anonymous are not blocked; the stated posture is that they get extra scrutiny, in the way VPN traffic does today.

Underneath, this builds on Web Bot Auth, the cryptographic bot-identity work Cloudflare has been pushing through standards bodies: an agent registers a keypair and signs its requests, so a signature-agent header proves the caller is who it claims. The handle is the human-readable label on top of that keypair — the DNS-to-IP relationship, applied to agents.

Here is the honest status table, as of 5 August 2026:

That last row is the one to keep an eye on. Cloudflare has not said who holds the keys, what it charges, which chains it settles on, or which stablecoins it supports. It also did not mention NET Dollar, the dollar-pegged stablecoin it announced in September 2025 — conspicuous, given that this is the product you would expect it to launch into.

The two-tier wallet

The structural idea is the part worth understanding, because it is what makes the product something other than "a crypto wallet with a Cloudflare logo".

Account Wallet

The Account Wallet belongs to a human — really, to a Cloudflare account. It holds the stablecoin balance, it is where funds arrive and leave, and it is the root of policy. Nothing an agent does can exceed what the Account Wallet permits, because the agent has no access to it.

Virtual Wallet

A Virtual Wallet is issued to a single agent and reached with an API key. Within its permissions the agent spends on its own, with no per-transaction human approval. Cloudflare's example is an employer granting an agent "$100 per week" for AI inference.

The relationship is strictly hierarchical: authority only ever flows downward, and each hop can narrow it but never widen it. An agent holding a Virtual Wallet key cannot raise its own ceiling, cannot reach the balance, and cannot see its siblings. That is the same shape as an IAM role or a scoped OAuth token, which is exactly why it is the right shape — it is a well-understood containment model rather than a new one.

It is also the answer to the obvious objection to agent payments, which is not "can software hold money" but "what happens the first time it is wrong". The answer here is: it is wrong by at most one Virtual Wallet's remaining budget.

Guardrails, and what they do not do

The controls Cloudflare has described:

• Spending caps per Virtual Wallet, including recurring budgets ("$100/week").
• Maximum transaction size, so one call cannot drain a week's budget.
• Merchant allowlists, restricting where an agent may spend at all.
• Anomaly detection, which routes unusual patterns to a human for review rather than hard-blocking them.

That last choice is a deliberate and sensible one: an agent that silently fails a legitimate purchase is a support ticket, while an agent that quietly spends 40× its normal daily rate is an incident. Escalating instead of blocking keeps both visible.

Now the correction. A number of outlets covered this launch under headlines saying the spending caps block prompt injection at the payment layer. They do not, and it is worth being precise about why.

Prompt injection is an input-integrity failure: an attacker gets text into the agent's context and the agent adopts it as instruction. A spending cap sits far downstream of that. If a poisoned web page convinces an agent to buy something useless from an attacker-controlled endpoint, the cap does not detect the injection, does not stop the purchase, and does not tell you it happened. What it does is bound the loss to whatever that wallet had left, and — if the merchant is not on the allowlist — refuse the specific destination.

That is worth having. Bounding blast radius is real security engineering, and it is more than most agent stacks do today. But it belongs in the same category as a per-key rate limit or a scoped credential: it makes a compromise survivable, not impossible. Calling it a prompt-injection defence encourages exactly the wrong mental model, which is that the payment layer will catch what the reasoning layer missed.

How a paid request flows

Here is one purchase, end to end. The important structural point is where the decision happens: the agent never holds funds and never signs. It asks its wallet to, and the wallet is free to say no.

1. The agent requests a paid resource, signing the request with its Web Bot Auth key so the merchant can resolve who it acts for.
2. The merchant answers 402 Payment Required with a machine-readable PAYMENT-REQUIRED header: price, asset, network, payee.
3. The agent asks its Virtual Wallet to pay, authenticating with its API key.
4. The wallet evaluates policy — remaining cap, merchant allowlist, per-call ceiling.
5. If the request is outside policy the wallet refuses and flags it. The agent cannot escalate; there is no path from a Virtual Wallet key to a higher limit.
6. If it is within policy the wallet returns a signed payment authorisation, which the agent attaches as PAYMENT-SIGNATURE and retries.
7. The merchant verifies and settles — behind Cloudflare, that is the Monetization Gateway's job, at the edge rather than at the origin.
8. The resource comes back with 200 OK and a PAYMENT-RESPONSE receipt.

Steps 1, 2, 6, 7 and 8 are plain x402, which I walked through message by message in x402 native payments. Steps 3 to 5 are the part Cloudflare Wallets adds: a policy checkpoint between "the agent decided to buy" and "money moved".

The other half: the Monetization Gateway

Wallets only makes sense next to the product Cloudflare announced a month earlier. The Monetization Gateway, waitlisted on 1 July 2026, lets a customer charge for "any asset protected by Cloudflare: web pages, datasets, APIs, or MCP tools" — one control plane for payment policy and access control, enforced at the edge before the request ever reaches your origin.

Configuration is through the dashboard, the API, or Terraform. Cloudflare has described planned capabilities including per-verb pricing ("$0.01 for every GET or POST"), pricing that varies with task complexity, and intercepting an origin's 401 and converting it into a 402 — which would let an existing authenticated API become a paid one without touching the origin. Settlement is in stablecoins, with Open USD and USDC named, and a stated goal of sub-second settlement.

Put the two together and the shape is clear: Monetization Gateway is the merchant's cash register, Wallets is the buyer's purse, x402 is the wire between them, and both ends can sit on the same network. That is the first time anyone has assembled all three pieces of a machine-payable web in one place.

Four years in one arc

Read chronologically, none of this is a surprise crypto pivot. It is one plan.

Pay Per Crawl was the experiment — a single price, one class of buyer, Cloudflare taking the payment risk itself. The Monetization Gateway is that experiment generalised onto an open protocol. Wallets is the missing counterparty. Each step reused the layer below it, and the through-line is that Cloudflare kept choosing HTTP-native mechanisms over building a proprietary marketplace.

How it compares

The distinctive column is Cloudflare's, and not because of the wallet. It is that both ends of the transaction can be Cloudflare-operated, so the identity check, the policy check, the payment verification and the resource all resolve inside one network. That is a genuine latency and simplicity advantage. It is also a genuine concentration risk, and those are the same fact.

What you can build today

None of this blocks on Wallets shipping. Cloudflare's x402 support has been live since September 2025, and it works with any x402 wallet.

To sell an API from a Worker, x402 is middleware — the server declares a price and the SDK handles the 402 handshake:

import { Hono } from 'hono'
import { paymentMiddleware } from 'x402-hono'

const app = new Hono()

app.use(paymentMiddleware({
  '/dataset': {
    price: '$0.02',
    network: 'base',
    payTo: WALLET_ADDRESS,
  },
}))

app.get('/dataset', (c) =>
  c.json({ rows: [/* the paid work */] }))

export default app

To buy, the client side is a fetch wrapper that catches the 402, signs, and retries:

import { wrapFetchWithPayment } from '@x402/fetch'

const url = 'https://api.example.com/dataset'
const pay = wrapFetchWithPayment(fetch, { wallet })
const data = await (await pay(url)).json()

For MCP specifically, the Agents SDK exposes paidTool on the server side, and withX402Client on the client side — the latter wrapping an MCP client with automatic 402 handling and optional human-in-the-loop confirmation before a payment goes through.

Supported schemes are exact (fixed amount, on EVM, Solana, Aptos, Stellar, Hedera and Sui) and upto (authorise a maximum, settle on consumption, EVM only), across Base, Ethereum, Polygon, Optimism, Arbitrum, Avalanche, Solana, Aptos, Stellar and Sui. Develop against base-sepolia with test USDC from the Circle faucet. Treat the snippets above as the shape of the integration and check the Cloudflare Agents docs for current signatures — this surface is moving fast.

Open questions

Who holds the keys? Undisclosed. There is a large difference between Cloudflare custodying balances, a licensed partner doing it, and a non-custodial design where Cloudflare only holds policy. This single answer determines the regulatory surface, the counterparty risk, and whether "your" balance is really yours.

What does it cost? Also undisclosed. x402 itself charges no protocol fee, so any Cloudflare margin will be a platform fee on top — and the economics of sub-cent payments are extremely sensitive to it.

Where did NET Dollar go? Cloudflare announced a stablecoin in September 2025 and did not mention it in the wallet launch. Either it is not ready, or the strategy moved toward being neutral across stablecoins. Neutrality would be the better outcome, but nobody has said.

Is a CDN the right identity provider? cloudflare.pay is a namespace with one operator, one revocation authority and one set of terms. It is being introduced into a genuine vacuum, and a working namespace with a single operator beats no namespace at all — but "agents that Cloudflare vouches for get treated better" is a meaningful amount of power over who can transact. The honest comparison is not against something better; it is against DNS and CAs, which are also concentrated and have mostly worked.

Irreversibility. Stablecoin settlement is final. There is no chargeback, so recovering a bad purchase depends on the merchant. Consumer payment rails spent decades building dispute machinery, and this rail starts without it. Spending caps are the substitute, which brings us back to blast radius.

Will the standards converge? x402 and Stripe's MPP both use HTTP 402 with different headers. Two incompatible dialects of one status code would be a bad outcome, and Cloudflare sits on the x402 side.

My learning summary

The thing that struck me studying this is that the interesting engineering is not the wallet at all — it is the delegation tree.

The wallet is a solved problem; custody, signing and stablecoin settlement have vendors. What did not exist was a way to hand a piece of spending authority to a piece of software and be able to reason about the worst case. Account Wallet → Virtual Wallet → agent is deliberately the same shape as an IAM role hierarchy, and that borrowing is the whole insight: the industry already knows how to bound what a non-human principal may do, and agent payments needed that pattern more than they needed new cryptography.

The second thing is how little of it exists yet. Four days after the announcement you can reserve a name. That is not a criticism — reserving the namespace early is the correct sequencing when the namespace is the scarce thing — but it does mean the current honest description of Cloudflare Wallets is an announced architecture with a live landing page, and I would rather write that down than pretend otherwise. The parts that do work today are the ones that shipped a year ago: x402 in Workers, Web Bot Auth, and the Monetization Gateway's waitlist.

If you sell an API that agents will call, the actionable move is unchanged from what I concluded about x402: the seller-side integration is a few lines, it works now, and it is buyer-agnostic. Cloudflare Wallets does not make that more urgent — it makes it more likely to pay off, because someone is finally building the other side of the trade.

FAQ

What is Cloudflare Wallets?
A programmable stablecoin wallet for AI agents, announced 4 August 2026. A human-owned Account Wallet holds the funds and delegates capped spending authority to per-agent Virtual Wallets, which agents use via API key to pay for APIs and content over x402.

What is cloudflare.pay?
A handle namespace giving an agent a human-readable identity, such as research.example.cloudflare.pay, so merchants can see which organisation an agent acts for. Handle reservation opened 4 August 2026; presenting a handle is optional.

Can I actually pay for something with it today?
No. As of 5 August 2026 only handle reservation is live. Funding, on/off-ramps, Virtual Wallet issuance and payments are described as arriving in the coming months.

Which blockchains and stablecoins does it use?
Cloudflare has not said. Its x402 support in Workers and the Agents SDK covers ten networks including Base, Ethereum, Solana and Sui, but which of those Wallets will settle on — and in which stablecoins — is undisclosed.

How is this different from x402?
x402 is the open protocol for attaching payment to an HTTP request. Cloudflare Wallets is one implementation of the buyer's side of it, adding identity, funding and a policy checkpoint. You can use x402 today without Cloudflare Wallets.

Do spending caps stop prompt injection?
No. A cap limits how much an agent can lose if it is manipulated; it does not detect or prevent the manipulation. Treat it as blast-radius containment, in the same family as a scoped credential or a rate limit.

What is the Monetization Gateway?
The seller-side counterpart, waitlisted 1 July 2026: it lets you charge per request for any web page, dataset, API or MCP tool behind Cloudflare, verifying x402 payment at the edge instead of at your origin.

References

• Announcing Cloudflare Wallets: The programmable wallet for the agentic Internet — Cloudflare Blog, 4 Aug 2026
• Cloudflare gives AI agents an identity and a wallet — Cloudflare press release, 4 Aug 2026
• Announcing the Monetization Gateway: charge for any resource behind Cloudflare via x402 — Cloudflare Blog, 1 Jul 2026
• Launching the x402 Foundation with Coinbase, and support for x402 transactions — Cloudflare Blog, 23 Sep 2025
• Introducing pay per crawl — Cloudflare Blog, 1 Jul 2025
• x402 · Cloudflare Agents docs — schemes, networks, SDK packages
• Agentic Payments · Cloudflare Agents docs — paidTool, withX402Client
• What is Pay Per Crawl? · Cloudflare docs — merchant-of-record model
• Cloudflare Launches Stablecoin Wallets for AI Agents, Opens cloudflare.pay Handles — The Defiant, Aug 2026 (what was not disclosed)
• Cloudflare Wallets Launch With Spending Caps That Block Prompt Injection at the Payment Layer — TechTimes, 4 Aug 2026 (the framing I disagree with above)

Related reading on this site: x402 native payments, HTTP/1.x connection management, more HTTP posts, payment posts, and all posts.