AI Agent Wallet and Payments Risk: Authority Design

On 20 August 2026 a major exchange shipped a standardised way for agents to reach trading, wallets and payments. AI agent wallet and payments risk is not really about the model's judgement, and treating it that way is the mistake. An agent's spending is contained by the account it can reach, never by the instructions you gave it.

Why can prompts not constrain spending?#

Because a prompt is a request and an account balance is a fact. Telling a system not to spend more than a set amount relies on the system correctly interpreting, remembering and honouring that instruction on every path, including paths taken after a confusing tool result or a partially failed retry.

The architecture that shipped reflects this. Execution is kept inside user-funded sub-accounts while the agent logic lives outside the platform entirely, which is a clear admission that the reasoning cannot be the control. The boundary is the account, its balance, its permissions, and the ability to revoke.

That inversion is the whole design. You are not trying to build an agent that behaves; you are trying to build a container where misbehaviour is survivable, and then putting the agent inside it. One of those is achievable today.

One of these holds when the model is confused. That is the entire difference and it decides the design.

What shipped is a bundle rather than a single feature: exchange APIs, an agentic wallet hub, programmable payments, a skill hub and support for the Model Context Protocol, usable from at least 4 different coding and chat clients. The breadth is the point, and it is also why the authority question arrives all at once rather than gradually.

The corollary is uncomfortable and worth stating. If an agent can reach an account, assume the entire balance of that account is at risk, and size the account accordingly rather than sizing your confidence in the prompt.

What does the containment actually look like?#

A dedicated sub-account, funded deliberately, with per-agent permissions and limits, and revocation available at any time. Each of those four controls is doing separate work, and dropping any one of them quietly collapses the guarantee that the other three appear to provide.

Funding is the one people get wrong. A sub-account topped up to cover a quarter of activity is a quarter of your money exposed to a loop, and a sub-account topped up weekly is a week's worth. The refill cadence, not the balance, is what actually sets the blast radius over time.

Each failure column is an ordinary operational decision rather than a mistake anybody would flag at the time.

Revocation deserves particular attention because it is the only control that works after something has already gone wrong. It is also the one that depends on a human noticing, which means the real question is what monitoring sits alongside it rather than whether the button exists.

Who is actually responsible for the limits?#

You are, and coverage of the launch made that point directly: keeping agents in check is largely left to users. That is not a criticism of the design so much as a description of where the boundary sits, and it is the same boundary in every agent platform that grants real authority.

The platform provides mechanisms. Choosing conservative values, reviewing them, and noticing when something is wrong are the parts nobody can provide for you, and they are exactly the parts that decay quietly after the first month when nothing has gone wrong.

Each is irreversible or expensive to undo, which is the property that matters rather than the amount involved.

What generalises beyond financial accounts?#

Almost all of it. An agent holding a payment card, a cloud account, a metered API key or an ad budget is in the same position, and the same four controls apply with different names. Scope the account, narrow the permissions, enforce the limit outside the model, and keep revocation available.

The failure that recurs across all of them is a retry loop meeting an unmetered resource. Nothing about it requires bad judgement from the model; a transient error, an over-eager retry policy and a resource that bills per call are sufficient on their own, and the cost accrues at machine speed rather than human speed.

No step here requires poor judgement from the model. The sequence runs on ordinary components.

Put a number on it before it happens. An agent retrying a failing call 5 times a second against an endpoint costing a tenth of a cent per request burns roughly $432 in a day, and a loop nobody notices across a 3 day weekend is closer to $1,300. Neither figure requires the model to do anything unreasonable.

Rate limiting is therefore a spending control and should be treated as one. A cap on actions per minute bounds the damage of a loop far more reliably than a cap expressed in currency, because the loop hits the action limit long before anyone reads a balance alert.

When should an agent not have this authority at all?#

When the action is irreversible and the verification is weak. Moving money, executing a trade and sending an external payment share the property that undoing them ranges from expensive to impossible, which puts them in the category where an agent proposes and a person commits.

Reversibility is the first gate. Everything after it assumes a mistake can be undone.

That split costs less than it sounds. An agent that prepares a complete, reviewable action and waits captures most of the value while leaving the irreversible step with someone accountable. Deciding what an agent may do alone is the general form of this decision, and what happens when it gets one wrong is why the split is worth the friction.