x402 Flaw: A Malicious API Can Drain Your AI Agent's Balance

Security firm V12 alerted on October 22 to a serious problem in the SDKs of x402, the standard that allows AI agents to pay for API calls with tokens. According to its analysis, the default client of those SDKs did not establish any spending limit, so a malicious API could request a payment for the full balance of the supported token and the agent would sign it without further ado. The fix arrived with the versions published on August 18, which incorporate a spending cap.

The scope, however, has nuances worth understanding before panicking. The risk affected agents configured to sign payments automatically and whose applications had not defined their own controls. That is, we are not talking about any deployment with x402, but about those where automation takes precedence over oversight.

What x402 is and why it matters to an SMB

x402 has long been touted as one of the ways for AI agents to pay for services without human intervention: the agent requests data from an API, the API responds with a payment request, and the agent signs the transaction with the tokens it has available. It is convenient and removes friction, but it also shifts an economic decision to a software component that acts in milliseconds.

For an SMB starting to build agents for support, prospecting, or data query tasks, this means the agent's wallet becomes one more attack surface. No one needs to compromise the infrastructure: it is enough for the agent to call an API controlled by a malicious third party that asks for "everything you have."

The pattern repeats: overly generous defaults

What is striking about this case is not only the flaw but its form. An SDK that, by default, does not limit how much an automated client can spend is a design decision that prioritizes ease of use over security. And we have seen that pattern before in the ecosystem: components that start with broad permissions and leave the integrator the task of closing them down.

At ForgeNEX we insist that AI agent security is not solved with a single control, but with a complete lifecycle: design, permissions, limits, monitoring, and review. This incident fits squarely into that idea, as we already analyzed in our article on AI agent security. If the agent can move money, it needs the same safeguards we would apply to any automated financial process.

What we recommend doing now

If your team has integrated x402 or is evaluating it, these are the actions we prioritize:

1. Update the SDKs. The versions from August 18 onward incorporate a spending limit. If you are still on an earlier one, the risk is open.
2. Define your own caps. Do not rely only on the SDK's default value: set limits per operation, per session, and per period at your application layer.
3. Review which agents sign payments automatically. Any flow that signs without human validation must have a maximum threshold and, if possible, a list of trusted APIs.
4. Audit external APIs. An agent that discovers endpoints on its own may end up talking to a service you do not control. Restrict the catalog of allowed destinations.
5. Monitor spending. Alerts for anomalous consumption of the agent's wallet allow detecting an ongoing drain before it is emptied.

The detail many will overlook

The news stresses that the flaw affected those who signed payments automatically and had not configured their own controls. It is tempting to read it as "it is not that bad," but in practice many SMBs build agents precisely to automate end to end. Convenience is the feature, and that is why the misconfiguration is likely.

Our underlying recommendation is to treat an agent's wallet as you would treat a corporate card: with a limit, with a record of transactions, and with periodic review. And, as in any third-party integration, apply the principle of least privilege to money as well.

An agent that can pay without limit is, in practice, a financial credential without a password. The spending limit is not an extra: it is part of the design.

If you are deploying agents with integrated payments, at ForgeNEX we can help you review the configuration, permissions, and limits before the first incident forces you to do so in a hurry. The lesson of x402 is simple: an SDK's defaults are not your security policy.

Source: The Hacker News. Analysis and adaptation: ForgeNEX.