Cloudflare Gives AI Agents Wallets

Cloudflare Starts Giving AI Agents Wallets

On August 4, Cloudflare unveiled Cloudflare Wallet in an attempt to solve two of the most practical challenges facing real-world AI agent deployment: who the agent is and how it pays.

The product allows enterprises to assign separate virtual wallets to agents and configure total budgets, per-transaction limits, and merchant allowlists. Without opening login pages, entering card details, or waiting for a human to generate an API key, agents can autonomously purchase API calls, MCP tools, data, and paid content in a headless environment.

However, do not rush to integrate it into production just yet.

As of August 5, Cloudflare has only opened reservations for cloudflare.pay wallet names. Full wallet functionality—including deposits, withdrawals, and the issuance of Virtual Wallets to agents—is scheduled to roll out over the coming months. In other words, this is closer to the formal unveiling of a product roadmap than a payment SDK that is already ready for full-scale use.

Agents Can Call APIs, but They Cannot Complete Purchases on Their Own

Over the past two years, agents have rapidly improved at browser automation, code execution, and tool use, but payments remain stuck in the era of the human-centric internet.

When an agent wants to try a new data API, it typically has to go through the following process:

1. Find the service provider’s website;
2. Open a registration page designed for humans;
3. Complete email verification, CAPTCHAs, or two-factor authentication;
4. Wait for the user to add a payment card;
5. Select a plan or top up the account balance;
6. Generate an API key and write it back to the runtime environment;
7. Only then begin testing the API’s quality.

If any one of these steps requires human confirmation, the supposedly autonomous agent degenerates into an automation script that continually sends approval requests to people.

For model APIs used on a regular basis, this problem is less obvious. Enterprises can sign contracts and prepay centrally, then manage model access through internal gateways or API aggregation platforms. But when an agent needs to dynamically choose among dozens of long-tail tools—for example, purchasing a one-off industry dataset, making a single call to a geocoding service, accessing a paywalled paper, or testing three unfamiliar MCP servers—the friction of traditional account systems quickly compounds.

Cloudflare Wallet aims to turn payment authorization into a foundational capability that can be programmatically delegated, constrained, and revoked.

A Two-Tier Wallet: Humans Manage the Money, Agents Spend It

Cloudflare Wallet consists of two layers: the Account Wallet and the Virtual Wallet.

Account Wallet: The Enterprise’s Central Funding Account

The Account Wallet is controlled by the Cloudflare account owner or a human administrator and is responsible for receiving, holding, and managing funds. According to Cloudflare’s disclosed design, it primarily holds stablecoins rather than handing a traditional corporate credit card directly to an agent.

Administrators can add or remove funds and allocate different spending permissions from the central balance. This makes it more like an enterprise treasury pool than a private account belonging to a particular agent.

Virtual Wallet: A Restricted Spending Card for Agents

A Virtual Wallet is assigned to a specific agent, operates using credentials, and receives a budget from the Account Wallet. Enterprises can configure the following for each wallet:

• The total amount available to spend;
• The maximum amount per transaction;
• An allowlist of approved merchants;
• Recurring budgets for different agents or employees;
• Rules that escalate transactions for human approval when thresholds are exceeded.

For example, an enterprise could allocate a $10 budget to an agent responsible for vendor evaluation and have it test 20 pay-per-use data APIs. Since each call costs only a few cents, even if the agent makes a poor choice, the loss remains tightly contained.

Another scenario would be to give each employee a weekly AI inference allowance of $100. The agent could operate automatically within that allowance, while overages would require administrator approval. Compared with placing a corporate card with a $1,000 limit into a browser automation environment, this permission model is clearly much closer to something enterprises could realistically accept.

What it solves is not simply “whether an agent can pay,” but the more important question: “How costly can an agent’s mistakes become?”

x402: Putting Payments Back Into HTTP Requests

Cloudflare Wallet’s payment layer is powered by the Monetization Gateway and the x402 protocol.

x402 draws on the HTTP 402 Payment Required status code. This status code has existed in the HTTP specification for years but has never become a mainstream payment method on the internet. With the rise of the agent economy, it now has a clear use case: a server can directly tell a client how much a resource costs, which asset to use for payment, and how payment credentials should be attached to a subsequent request.

An idealized request flow would look roughly like this:

AI agent requests an API or MCP tool
        ↓
Server returns HTTP 402 with payment terms
        ↓
Agent checks wallet balance, merchant permissions, and per-transaction limit
        ↓
Virtual Wallet authorizes or settles the payment
        ↓
Agent resubmits the request with payment credentials
        ↓
Server verifies payment and returns the data

This differs significantly from today’s API subscription model.

Under the traditional model, users first open an account, add funds, and request a key before calling the service. x402 attempts to make service discovery, price confirmation, payment, and delivery of results part of the same machine-readable flow. For inference, data, and content transactions that cost only a few cents—or even less—per use, this pay-per-request model is more natural than a monthly subscription.

However, x402 will not automatically solve every payment challenge. In production, developers will still need to handle transaction idempotency, duplicate charges, request replay, exchange-rate volatility, refunds, dispute resolution, and failures to deliver services. The HTTP status code is only the entry point for the interaction; clearing, settlement, and risk controls are where the hard work begins.

Beyond a Wallet, Cloudflare Has Also Given Agents an Identity

Payments are not purely about money. When a merchant receives a request from an agent, it also needs to know who authorized that agent, who is accountable if something goes wrong, and whether the agent can be trusted.

Cloudflare has therefore also introduced persistent identifiers based on cloudflare.pay. Each Cloudflare account can obtain a unique, human-readable address and extend that identity to specific agents. The concept is similar to DNS: DNS maps hard-to-remember IP addresses to domain names, while cloudflare.pay aims to map ephemeral agent instances to persistent organizational identities.

The underlying identity capability is built on Web Bot Auth’s key-pair mechanism. Agents can choose to disclose their identities to merchants, which can then verify that the requests were indeed authorized by the corresponding accounts.

This is an important step. Today’s agents typically run in short-lived containers using temporary credentials and dynamic IP addresses. If all a merchant sees is an on-chain address or a one-time token, it is difficult to determine whether the party behind it is a legitimate enterprise, an anonymous script, or a bot conducting large-scale API abuse. By binding organizational identities, agent identities, and wallets together, Cloudflare is effectively creating an entry point for trust in machine-to-machine commerce.

However, the ability to “optionally disclose identity” also means there is still a trade-off between anonymity and trust. High-value services will likely require full identification, while low-value content may verify payment alone. Different merchants will develop different tiers of access policies rather than relying on a single set of rules for all transactions.

Cloudflare’s Advantage Goes Beyond Building a Wallet

Viewed in isolation, virtual wallets, budget cards, and merchant allowlists are not new concepts in the payments industry. Banks, enterprise expense-management platforms, and payment companies have long offered similar capabilities.

Cloudflare’s real advantage is that it operates on both sides of the transaction.

On one side are agents running on Workers, Agent Cloud, and other cloud environments. On the other are content and service providers connected to Cloudflare’s network, API protection services, and Monetization Gateway. Cloudflare can both observe requests and provide identity verification, bot detection, and payment infrastructure.

This gives it an opportunity to turn agent payments into a network-layer protocol rather than yet another financial application that developers must separately register for and integrate. Service providers would not need to understand the payment logic of every agent framework; they would only need to process standardized identity and payment credentials.

Cloudflare has already been rounding out Agent Cloud with model inference, sandboxing, persistent tasks, and tool-use capabilities. Wallet completes the transaction loop: agents can do more than execute tools already configured by an enterprise—they can also procure new capabilities on demand within defined constraints.

From this perspective, Wallet is not a standalone product but a key piece of Cloudflare’s effort to expand from an edge cloud platform into foundational infrastructure for running agents.

Prompt Injection Remains the Greatest Risk

A wallet having spending limits does not mean agent payments are secure.

If an agent reads maliciously injected content on a web page and is manipulated into calling a paid API controlled by an attacker, it may still complete an unauthorized transaction within its budget. Merchant allowlists can reduce the risk, but they cannot determine whether a transaction reflects the user’s true intent.

Production environments will require at least several additional layers of control:

• Separation of tool and payment privileges: An agent that can call tools should not automatically have permission to modify wallet policies;
• Dynamic approvals: New merchants, abnormal transaction frequencies, and high-risk categories should require human confirmation;
• Observability: Record why the agent selected a service, what quote it received, and what assessments it made before paying;
• Idempotency and replay protection: Prevent retry mechanisms from causing duplicate payments;
• Result validation: After payment, verify that the service was actually delivered rather than merely confirming that the transaction succeeded;
• Credential isolation: Wallet keys must be kept separate from ordinary tool context and must never appear in prompts that the model can read directly.

A budget cap limits losses; it does not align intent. A malicious tool that steals only a few cents per transaction can still become a serious problem if it is called millions of times.

Stablecoins also introduce compliance challenges. Requirements for custody, anti-money laundering, taxation, and cross-border settlement vary across jurisdictions. Cloudflare has currently disclosed only the product architecture. How it handles supported assets, regional restrictions, enterprise accounting, and dispute arbitration will directly determine whether large enterprises can adopt it.

For Now, This Is More About Securing an Infrastructure Position Than Starting a Payments Revolution

Cloudflare Wallet is headed in the right direction, and its approach is more sensible than simply attaching a credit card to an agent. By combining identity, budgets, and HTTP-native payments, it precisely targets the gap between agents that “can perform tasks” and agents that “can independently complete commercial tasks.”

At this stage, however, it should not be described as a mature agent payment network.

First, full funding functionality is not yet available, and only name reservations are currently open. Second, the x402 ecosystem requires adoption by both buyers and sellers. If agents have wallets but service providers do not accept the protocol, those wallets have no practical use. Finally, identity, refunds, fraud, and compliance rules must all be tested at real-world transaction volumes.

In the short term, fixed and high-frequency model usage remains better suited to centralized enterprise procurement, with quotas, billing, and vendor switching managed through internal gateways or API aggregation platforms. Cloudflare Wallet is more valuable when agents encounter a large number of unfamiliar, low-frequency, pay-per-use long-tail services. In such cases, an agent can autonomously experiment within a $10 budget instead of bringing a human back into the loop for calls that cost only a few cents.

If Cloudflare can leverage its network reach to drive merchant adoption at the same time, Wallet could become the “corporate card for machines” in the agent era. If a merchant ecosystem is slow to emerge, it will remain merely a well-designed, restricted stablecoin wallet.

The truly noteworthy development is not that agents finally have money, but that the internet is, for the first time, seriously redesigning account, identity, and settlement systems for “non-human buyers.”

References

• ITHome: Cloudflare Wallet Launches as a Programmable Wallet Designed for AI Agents — Covers Wallet’s launch date, two-tier wallet architecture, x402 payment mechanism, spending restrictions, and identity design.