The web needs an agent checkout

I keep running into the same awkward question when I give an agent a real task: how is it supposed to use the web when it finds something worth paying for?

It can search and find a page, dataset, API, report, or MCP tool that would make the answer better. Then it hits the internet built for people. Create an account. Enter a card. Confirm an email. Choose a plan. Save another API key somewhere. Remember to cancel it later.

So we give the agent a browser session, a company card, or long-lived credentials. None of those were designed as a spending boundary. The agent can do more than we meant to authorize.

I wrote about my own assistant finding my SSH key and making a decision I had not asked it to make. It followed the path that looked useful from inside its permissions. Money has the same problem. An agent needs enough authority to finish work without access to a company card and room to improvise.

An agent with somebody else's credentials is an automated process with an unclear blast radius.

Earlier this month, Cloudflare announced Wallets and cloudflare.pay. Wallet handles can be reserved now. The full wallet product is planned for the coming months.

The proposed model gives an agent a separate virtual wallet with a spending cap, merchant allowlist, and per-transaction limit. That is a useful permission model. I can give an agent a small budget for a job instead of handing it the company card.

On the seller side, Cloudflare's Monetization Gateway is exploring a way to charge for a protected page, API, dataset, or MCP tool. In an x402-style flow, a resource can return HTTP 402 Payment Required with payment terms. A compatible client authorizes the payment, retries the request, and the seller verifies it before serving the resource.

No account-creation flow in the middle. No subscription for a source the agent may need once.

Say I ask an agent to research a market. It finds a specialised dataset that costs a few cents per query, a publisher page, and a tool that can verify a claim. Today, I either need subscriptions already set up or I have to stop it and approve the purchase. Usually it falls back to free sources because that is what it can access. This pushes agents toward the same public material, even when a better source exists behind a small payment.

With a direct payment route, the agent could spend 20 cents on a source if it fits a budget I already set. For some low-value requests, the seller can avoid a traditional account-creation or subscription flow. I can see what the agent bought and revoke future spending.

This is the version of agent checkout I want to see on the web.

Cloudflare did not invent all of these pieces. x402 is an open protocol built around HTTP 402, and Cloudflare and Coinbase have launched a foundation around it. Pay Per Crawl is a separate private-beta experiment. It is intended to settle crawler payments later instead of charging request by request.

Cloudflare is connecting these ideas to paid content, MCP tools, and constrained wallets. I can picture the workflow. That is more useful than another demo where an agent has broad credentials and somebody watches closely.

The difficult part starts at the purchase decision. A prompt injection can still convince an agent to buy junk. Sellers can game prices or put useless data behind a payment request. Where these flows use stablecoin settlement, they bring operational, treasury, and compliance baggage.

The policy needs to be clear at the moment money moves: which agent, which resource, what price, and what purpose. There also needs to be a record, a limit, and a revocation path after the request.

What I want is straightforward. Give an agent $20. Define where it can spend it. Pull the permission when something looks wrong.

Until that exists, every agent purchase is still borrowing a human checkout flow.