Cloudflare shipped agent wallets during its Agents Week, joining an x402 Foundation that now counts roughly forty members — Cloudflare, Stripe, Visa, Mastercard, Google, AWS among them. That is a meaningful signal: the HTTP 402 payment rail for machine-to-machine commerce is no longer a Coinbase experiment, it is infrastructure that the largest platforms are attaching themselves to.
But the launch itself exposed two gaps, and both of them point at the same missing layer.
What is live today is narrow. Cloudflare Wallets lets you claim a cloudflare.pay identifier — a stable, human-readable handle for an agent wallet. Funding and actual payments are described as coming in the following months. So the product, right now, is mostly a namespace: the identity half of a payments stack, shipped before the settlement half.
Shipping identity first is defensible. It is also exactly where the first problem showed up.
There is no domain verification on a claimed cloudflare.pay identifier. Within a day of the announcement, Hacker News commenters reported that company names and their obvious variants had already been claimed by third parties. One commenter put it bluntly:
没有域名验证，这个用户的意图除了欺诈/冒充仿冒还能是什么？ — "With no domain verification, what could this user's intent possibly be other than fraud or impersonation?"
This is not a cosmetic complaint. In a machine-to-machine economy, the identifier is what an agent checks before it decides to pay. If an agent asks "is this the real Acme Corp, or a lookalike holding cloudflare.pay/acme-corp?" and the answer is "there is no way to tell," then the identifier does the opposite of its job: it becomes an impersonation surface instead of a trust anchor.
Contrast with how the protocol itself works. When a service answers an HTTP 402, the challenge carries a payTo address and a price. Nothing in the challenge proves that the party on the other end is who they claim to be. The identity problem is not Cloudflare's alone — it is a property of the rail. What Cloudflare's launch did is make it concrete and urgent, because now there is a widely promoted namespace where the ambiguity has a consumer-facing name.
The wallet's spending controls are three primitives: a cumulative spending cap, a merchant whitelist, and a maximum amount per transaction. That sounds like policy, but it is not. Each of the three compares the current payment against a fixed threshold. None of them can express a relationship between payments.
The practical examples matter more than the abstraction. A platform operator wants rules like "don't buy the same service from two different vendors within an hour," or "require approval before the first purchase from any new merchant." Those are timing-and-sequence rules. A cap cannot express them.
There is also a concurrency hole. When an agent runs several tool calls in parallel, each payment checks the cap before it is deducted. Each individual check passes. The sum can exceed the budget. Cloudflare has not published how the cap behaves under concurrent spending — a gap the launch review called out directly.
Look closely and the two gaps are one. Identity: verify who is being paid before money moves. Policy: verify what is about to be spent against the agent's actual intent before money moves. Both are pre-payment questions.
The x402 rail settles a payment. It does not, by itself, tell an agent whether the merchant is real, whether the price is what was advertised, or whether this specific purchase violates the agent's own spending rules. Those checks have to live in a layer above the rail — before the transaction is authorized, while the 402 challenge is still in hand and nothing has been spent.
This is the difference between a budget cap, which only reacts after money is already flowing, and a verification check, which runs on the challenge itself. A cap says "stop when you hit the ceiling." Verification says "check the counterparty, the price, and the intent on this very request — then pay." The former is necessary; the latter is what makes autonomous spending safe enough to turn on at any real scale.
Cloudflare joining x402 is good for the whole ecosystem — it pulls the rail into the mainstream and makes the trust problem impossible to ignore. The next thing the market builds, the thing the launch just made visible by its absence, is the verification layer that sits in front of the payment.