The buyer side of the agentic internet is being built. The wallet layer is shipping. The settlement rail is live. The authorization layer is not there.
The Cloudflare Wallets Authorization Model
Cloudflare has presented how they will support the buyer side of the agentic internet. The product is called Cloudflare Wallets. There are three controls if an autonomous agent makes a purchase:
- a spending cap
- an allowlist of permitted merchants
- a maximum transaction size.
A human review will be triggered if anomalies occur. A handle reservation is open at cloudflare.pay but the product is not yet generally available.
That is the entire authorization model.
What PSD2 Dynamic Linking Actually Requires
Commission Delegated Regulation (EU) 2018/389, Article 5 regulates PSD2 dynamic linking. The rule is precise: an authentication code must be dynamically linked to a specific amount and a specific payee. Any change to the amount or the payee invalidates it.
Spending cap is not a specific amount: it is rather an upper bound. An allowlist is not a specific payee but a set of permitted categories. Under the SCA framework, both constructs describe a budget. Neither constitutes authorization.
As Cloudflare does not act as a payment service provider. The point is narrower and more consequential. Two controls that define the product would not be sufficient as payment authorization inside any regulated regime. The product routes around the regime, it does not satisfy it.
A cap is not an amount. An allowlist is not a payee. Together they describe a budget, not an authorization.
Settlement via x402: An Architecture Without Custody
Settlement runs in USDC over x402, a micropayment protocol that attaches payments directly to HTTP requests using stablecoin. On 14 July 2026 the x402 Foundation became operational under the Linux Foundation, with Cloudflare as a founding member. So far there is no chargeback mechanism. The Cloudflare announcement names no custodian, no banking partner, no onramp provider, and no entity responsible for identity or compliance. That absence is not an oversight in the announcement. It reflects the architecture.
Provenance Is Not Authorization
Cloudflare has also built Web Bot Auth. Each agent registers its identity via a cryptographic keypair. The cloudflare.pay handle, research.example.cloudflare.pay, makes that keypair human-readable. Businesses decide whether to prioritize agents, as declaring identity is optional, that have registered a handle.
The keypair does not prove whether that agent is authorized and competent for this particular purchase: it only proves which agent is spending.
A verified keypair is a provenance claim. What the agentic internet is missing is not provenance, it is authorization. Confirmation that this agent, for this principal, is permitted to make this category of purchase, subject to this mandate, with these constraints. And it is competence and assurance that the agent's judgment meets the standard required for the decision it is making. Neither payment infrastructure nor provenance answers those questions.
What the Payment Networks Are Building
Payment networks are moving fast. Each of the following examples addresses the wallet and the mandate.
Visa Intelligent Commerce went live in July 2026 with more than thirty European issuers. Mastercard Agent Pay introduced Verifiable Intent, programmatic spending limits, and a dispute mechanism. Google AP2 version 0.2.0 enables human-not-present payments via signed mandates across more than sixty partners. SAP introduced a full audit log at the AI Agent Hub level.
None of them addresses the agent.
Identity, authorization, and quality of the agent are a distinct verification layer, not part of payment processing. They are not part of mandate management. They sit above both. Exactly this position is currently unoccupied.
We at contraco call this layer the "agent verification layer." The question it answers is not "did the wallet authorize this transaction" but "was this agent authorized and competent to initiate it."
Rails Before Trust
Agentic internet is getting its payment rails before its trust layer. Cloudflare Wallets will process transactions. x402 will settle them. Neither will tell you whether the agent that initiated the transaction should have done so.
That sequence is risky for the principals whose agents are spending, and for the merchants whose conversion funnels now include buyers they cannot see and cannot verify.
Sources
- Cloudflare Blog, "Announcing Cloudflare Wallets" (blog.cloudflare.com/wallets)
- Linux Foundation, x402 Foundation Operational Launch, 14 July 2026
- SCA RTS, Commission Delegated Regulation (EU) 2018/389, Art. 5 (PSD2 dynamic linking)
contraco is working on the agent verification layer. If the authorization gap is relevant to your architecture or your risk model, the conversation starts at transformation@contraco.net.