Cloudflare Wallets Delayed on x402 with Limited Spending Controls

Cloudflare Wallets arrived late to the x402 payment network, offering AI agents a stablecoin balance and a cloudflare.pay handle for transactions. The launch is currently limited to handle claiming, with funding and actual payments expected in the coming months. The one feature that is live has already drawn criticism regarding username availability.

Without domain validation, the system has already led to confusion. On Hacker News, a commenter named merek reported that his company name and several variants were taken immediately after the announcement. He noted he already has an impersonator running a website under his brand that is confusing customers. Another commenter, nikolay, compared the rollout unfavorably to how Meta handled reserved usernames, stating that Cloudflare’s approach pushed him away from using the offering because he could not secure his username.

The announcement has also been interpreted as a move toward establishing a universal identity provider. Commenter eddythompson80 argued that agent identity has been trapped inside individual systems, such as AWS IAM, which do not work on unrelated websites. He noted that OIDC federation is too complex for ordinary sites to adopt, and that the problem has always been agreeing on a single provider rather than the mechanism itself. Commenter wxw pointed out that teams already using Cloudflare’s Durable Objects and Workers may as well take the wallet, sandbox, and AI gateway as well.

Spending Limits vs. Policy

The control model describes a budget rather than a full policy. Each account holder gets an Account Wallet and can create separate Virtual Wallets per agent, funded from the main account and bounded by three controls: an allowance, an allow-list of approved merchants, and a maximum transaction size. The stated intent is that an agent can test and buy services without a human approving each payment, with a hard ceiling on the damage.

Those primitives describe a budget rather than a policy. An allowance is a running total. An allow-list is a set membership test. A maximum transaction size is a per-request bound. Each evaluates the current payment against a fixed limit, and none expresses a relationship between payments. Rules that platform teams tend to want do express relationships. An agent may only pay a vendor it has already checked against an approved catalog. It may not pay two vendors for the same thing within an hour. It must obtain approval before a first purchase from a new merchant. Each requires reasoning about the sequence rather than the current request.

Concurrency raises a related question. Agents issue actions in parallel, so several payments can be checked against an allowance that none of them has yet reduced, and each passes a ceiling their sum exceeds. Cloudflare has not published how its allowance behaves under concurrent spending, and that is worth establishing before letting an agent transact without per-payment approval. The pattern is not particular to Cloudflare. Providers in this space ship limits rather than policy languages, and each leaves the composition of those limits to the application above.

For teams evaluating agent payments, the questions are narrow. Where does the spending policy live, at the wallet or in the application? What happens when several agent actions run in parallel against one budget? And whether a provider ships limits or a language, because that determines how much has to be built in-house.