When AI Agents Get Wallets

What 25 x402 security findings reveal about money, permissions and autonomous software

A security review of machine-native payments shows why the next generation of AI agents will need more than intelligence: they will need financial boundaries.

BunCosmos Research Lab | Research checked 25 October 2026

An AI agent asks an online service for a piece of data. The service replies that access costs two cents. The agent pays automatically, receives the data and continues its work. No subscription is created. No person types a card number. No one even pauses the task.

That is the promise of machine-native payments. It is also the beginning of a new security problem.

The x402 protocol, first developed at Coinbase and now governed through the Linux Foundation's x402 Foundation, is designed to let software pay software directly over the web. It gives AI agents a practical way to buy API calls, data, compute and other digital services in tiny increments. But a 2026 review by security company V12 found 25 vulnerabilities across x402-related infrastructure and implementations, including three issues it classified as critical.

Those findings do not show that x402 is fundamentally unsafe, nor is there public evidence of a mass theft campaign using the reported bugs. The three critical issues were disclosed privately in August and, according to V12, fixed by 20 August before the public write-up appeared on 22 October. What the review does show is more consequential: once an AI agent can spend money, ordinary software mistakes can become financial actions.

The safety question therefore changes. It is no longer only, 'What might the model decide to do?' It becomes, 'What authority has the surrounding system actually given it?'

Autonomy changes when software can create financial consequences.

How x402 turns a web request into a payment

HTTP has reserved the status code 402, 'Payment Required', for decades. x402 gives that old idea a working payment flow. A client requests a resource; the server responds with payment requirements; the client selects an acceptable option and signs a payment authorization; the request is retried with payment attached; and the service verifies or settles the payment before returning the resource.

For people, this can sound like an unnecessarily complicated replacement for a checkout page. For autonomous software, it solves a real problem. An agent may need one database query worth a fraction of a cent, five seconds of compute, or a single image-generation call. Requiring a human to create an account and purchase a monthly plan for every tiny transaction would defeat the purpose of autonomy.

The idea has already moved beyond a laboratory demonstration. Visa and Artemis reported that, using on-chain data through 21 April 2026, x402 had processed about 109.6 million adjusted transactions totaling roughly $15 million since its launch in May 2025. In July, the x402 Foundation began operating under the Linux Foundation with participation from companies across payments, cloud computing and commerce. Cloudflare has also introduced machine-payment support around selected AI services.

That scale makes the security architecture worth understanding now, before agents with broad purchasing power become commonplace.

The V12 review at a glance

Critical flaw 1: a payment that was not a payment

The first critical issue affected a TypeScript Solana facilitator. The vulnerable path expected a token-transfer instruction, specifically TransferChecked. But the parser did not adequately prove that the transaction it was reading was actually that instruction before interpreting the surrounding data as a transfer.

V12 showed that another instruction, ApproveChecked, could be shaped so the verifier interpreted it like the expected payment. In the researchers' local reproduction, the system could report that a payment was valid even though no tokens had actually moved to the merchant. V12 did not submit a live transaction in that test.

This is not a failure of artificial intelligence. It is a verification failure in payment infrastructure. A perfectly reasonable agent could ask for a service, submit what the software layer told it was a valid payment, and receive a resource while the merchant received nothing.

For machine commerce, that distinction is fundamental. A payment system cannot merely recognize data that resembles a transfer. It must verify that the intended economic action actually occurred.

Critical flaw 2: signing the right message for the wrong site

The second critical issue involved x402's Sign-In-With-X, or SIWx, authentication flow. Wallet signatures can prove that a user or agent controls a particular wallet. The problem was not broken cryptography. The signature could be completely valid while being requested in the wrong context.

A malicious service could present a login challenge whose domain or URI referred to a different website. If the automatic signing flow accepted that challenge without adequately binding it to the site the agent had actually contacted, the attacker could receive a legitimate signature for another service and potentially reuse it there.

The lesson extends beyond wallets. Agents increasingly hold credentials and can approve actions automatically. A secure signature only answers, 'Did this key sign this message?' It does not by itself answer, 'Was this the correct message to sign for this request?'

The reported fix binds the authentication challenge more tightly to the request origin. The larger principle is simple: every high-impact authorization needs context, not only cryptographic validity.

Critical flaw 3: when automatic payment means too much authority

The third critical finding is the one with the broadest implications for AI agents. V12 found that documented or default client flows could automatically satisfy payment requests without imposing an adequate default spending ceiling in the vulnerable configuration.

A server controls important parts of a payment request: how much it wants, what asset it accepts, which network should be used and where the payment should go. If an application combines automatic signing with a funded wallet and no independent spending policy, a malicious service can ask for far more money than the user intended to delegate.

V12 describes a particularly instructive attack pattern. A service can first request a tiny legitimate payment, learn the public wallet address involved, inspect its visible on-chain balance and then request a much larger amount. If the surrounding software treats the payment challenge as authorization rather than a request that must pass policy, the agent may sign it.

Again, the language model does not need to hallucinate or behave maliciously. The failure can occur below the model, in the mechanism that translates a service's price into an automatically authorized transaction.

A powerful agent is not only a model. It is a model plus tools, credentials, permissions, wallets and execution rules.

Why this is an agent-security story, not just a crypto story

AI safety discussions often focus on whether a model can reason, deceive, ignore instructions or pursue an unintended objective. Those questions matter. But an autonomous agent is a larger technical system. It may include a model, browser, APIs, stored credentials, a wallet, tool permissions, network access and automatic execution code.

The x402 findings illustrate why the surrounding architecture can matter as much as the intelligence at the center. A model may choose an entirely appropriate action while a payment wrapper authenticates the wrong domain. It may select a useful API while software around it accepts an abusive price. Or it may correctly request a resource while a verification bug allows payment to be faked.

The same model can therefore be relatively harmless in one environment and financially consequential in another. Giving an agent a wallet does not merely add a tool. It changes the possible cost of mistakes.

The fixes point toward a safer design

The public x402 code and documentation now show stronger client-side safeguards. Core libraries describe a default policy that limits recognized USD-pegged assets to a $1 maximum per payment unless a developer deliberately changes the policy. The Coinbase SDK also documents explicit spend controls that can cap individual payments and total spending over a time window.

These are meaningful improvements, but they should not be interpreted as a guarantee that every application built around x402 inherits identical protection. Higher-level wrappers can expose different defaults, and developers can loosen or replace policy. Security therefore depends on the complete deployment, not only the protocol specification.

That distinction is important because a $1 per-payment ceiling alone is not a complete budget. An agent permitted to make 10,000 one-dollar payments still has $10,000 of effective purchasing authority.

What bounded financial authority should look like

Industry is already moving toward delegated budgets

The emerging design pattern is not 'give the agent a wallet and trust it.' It is 'delegate a bounded amount of authority for a defined task.'

Mastercard's October demonstration of Agent Pay for Machines used this structure. A business approved a marketing task and defined a budget before the agent began purchasing research and generated media from external services. The agent could transact autonomously, but inside a permission boundary established in advance.

That architecture resembles the controls companies already use for employees, corporate cards and cloud infrastructure. Autonomy is useful precisely because a human does not approve every tiny action. But useful autonomy does not require unlimited authority.

A quieter problem: knowing that a security update matters

The disclosure also exposes a second security issue: patch visibility. The three critical bugs were reportedly corrected in August, but public vulnerability records did not clearly present all three as standard security advisories when the October disclosure appeared. Reporting by The Hacker News noted that fixes could therefore look like ordinary release changes to developers who were not following the private disclosure process.

A fixed vulnerability can remain dangerous when users of older software do not know that upgrading is security-sensitive. This matters particularly for agent infrastructure, where code may sit inside automated services and continue signing or verifying transactions long after a newer release exists.

The public record is also incomplete for the other 22 findings. V12 states that its review found 13 high-severity and 9 medium/low-severity issues beyond the three critical vulnerabilities, but the publicly available material does not provide enough technical detail to responsibly claim that every one has been remediated. BunCosmos therefore treats the remediation status of those additional findings as unresolved unless further evidence is published.

What the findings do not show

Security research is easy to turn into a frightening headline. Several conclusions would go beyond the evidence available here.

The disclosure does not show that x402 users suffered a widespread theft campaign. It does not show that every x402 implementation shared every flaw. It does not show that all autonomous wallets are unsafe. And it does not show that the underlying idea of machine-native payments should be abandoned.

What it does show is that financial autonomy creates new failure modes at the boundary between protocols, wallets, identity and software policy. The correct response is stronger engineering and narrower delegated authority, not the assumption that an intelligent model will notice every dangerous request on its own.

Why agents may need machine-native money anyway

There is a reason x402 and similar systems continue to attract serious infrastructure companies. Traditional online payments are designed around people. Machine-to-machine commerce often involves tiny, frequent purchases for which conventional subscriptions, checkout flows and account creation are inefficient.

An autonomous research agent may want one specialized dataset. A coding agent may need a short burst of compute. A creative agent may purchase one generation or one media asset. The value of each transaction can be too small to justify human intervention but collectively important enough to require financial controls.

This is why agentic payments are likely to develop rather than disappear. The challenge is not whether agents should ever be allowed to pay. It is how to make payment authority legible, revocable and proportional to the task.

Three trust boundaries for an agent economy

1. Did the economic action actually occur?

Verification must establish that money reached the intended destination under the expected conditions. The Solana parsing flaw shows why data that resembles a payment is not enough.

2. What exactly is the agent authorizing?

A valid signature is useful only when it is bound to the correct domain, request and purpose. Authentication must preserve context.

3. How much authority has been delegated?

An agent should never infer its own financial ceiling from the size of a wallet. Spending authority should be explicit, narrow and independently enforceable.

The other half of agent safety

The lesson also complements recent research into agent behavior. Fig, another system examined by BunCosmos this week, studies how changes in incentives, information and opponents can make cooperation, deception, exploitation, betrayal or sabotage more likely to be attempted by an AI agent.

x402 highlights the other side of that problem. Even if we understood an agent's decisions perfectly, the execution environment determines what consequences those decisions can have.

One question is therefore: what conditions make an agent attempt an action? The second is: once it attempts that action, what has the system allowed it to do?

As agents gain greater autonomy, those questions increasingly belong together.

The next safety boundary is permission

The most important lesson from the x402 disclosure is not that AI agents should be kept away from money. It is that autonomous spending must be treated as delegated financial authority, with the same seriousness applied to identities, corporate cards, cloud permissions and production credentials.

Agentic commerce will fail if every five-cent API call requires a human approval screen. It will also fail if software can drain a funded wallet because a remote service asked politely enough.

The workable space lies between those extremes: small default limits, cumulative budgets, verified recipients, contextual signatures, transparent logs, anomaly detection, human escalation and rapid revocation.

The first generation of AI agents taught developers to think about what software can do. Wallet-enabled agents add a harder question: what should software be allowed to spend while doing it?

That may become one of the defining infrastructure questions of the agent era.

Sources and further reading

V12 — “25 Vulnerabilities in the x402 Protocol: Inside Three Critical Findings”

Coinbase Developer Platform — x402 launch and protocol overview

Linux Foundation — operational launch of the x402 Foundation

Visa — “Agentic payments from the ground up”

Cloudflare Developers — Machine payments

x402 Foundation GitHub — default asset and payment-policy documentation

Coinbase CDP SDK — x402 client spend-control example

Coinbase CDP SDK — x402 client documentation

Mastercard — Agent Pay for Machines demonstration, October 2026

The Hacker News — reporting on the x402 critical vulnerabilities and patch disclosure

x402 Foundation GitHub — published security advisories

Source note: This article distinguishes reported vulnerabilities and researcher reproductions from confirmed exploitation. Company documentation describes current product behavior and defaults; deployment-specific safety depends on the complete software stack. Sources checked 25 October 2026.