Should You Let an AI Agent Spend Your Money?

Ask the right question

"Do you trust an AI to spend your money" is the wrong framing, because it invites a judgment about model quality when the answer should be a statement about blast radius.

The useful question is: when this agent is wrong, manipulated, or looping, what is the maximum it can cost me, and how fast can I stop it? If the answer is bounded and small, the decision is easy regardless of how much you trust the model. If the answer is your balance, no amount of model quality makes it acceptable.

That reframing also tells you where to spend engineering effort. Not on making the agent more careful, which is unbounded work with no guarantee, but on making the boundary real, which is finite work with a provable property.

The same logic already governs how we treat human employees with purchasing authority. Nobody hands a new hire unrestricted access to the corporate account and relies on their good judgment. They get a card with a limit, a category restriction, and a monthly statement. That is not distrust, it is design.

What actually goes wrong

Four failure modes account for nearly all of it, and only one is about the model being bad at its job.

Prompt injection. The agent reads a web page, an email, a ticket, or an API response that contains text designed to look like an instruction. If that agent can also pay, the text is an attempt to move money. This is the dominant threat and it is structural: the model cannot reliably distinguish data it was given from instructions it was given.

Ordinary error. A misparsed price, a quantity off by a factor, the wrong counterparty selected from a list. Nothing adversarial, just a mistake at machine speed.

Loops. An agent retries a failing purchase, or repeats a task it believes has not completed. Unbounded, this is the failure that produces a memorable number.

Compromised dependencies. A library, a tool server, or an integration that the agent trusts. The agent behaves correctly and pays the wrong party.

Notice that a spending rule written into the system prompt does nothing against any of these except possibly the second, and even then only sometimes.

The controls that actually contain it

A bounded float. The agent spends from an allowance, not from your balance. The maximum loss in any scenario is the float, which turns an open-ended risk into a number you chose.

Authority in the key, not the software. The ceiling should be a property of the credential the agent uses to pay. If the limit is enforced by application code that the agent influences, a sufficiently confused agent can route around it. If the limit is enforced by what the key is permitted to authorize, it cannot.

Scope by counterparty and purpose. Most agents buy a narrow set of things. Restricting where funds can go removes the entire class of attacks that redirects payment to a new destination.

Period limits. A per-transaction cap alone permits many small transactions. Combine per-transaction with per-period ceilings so a loop hits a wall.

Immediate revocation. You need to stop the agent without its cooperation, in seconds, without moving funds or coordinating with a third party.

Receipts and attribution. Every payment should record what was bought, from whom, at what price, under which instruction. Without that, an unexpected number is unexplainable.

CryptoCadet implements this shape: a non-custodial USDC rail on Base where the agent spends a session-key bounded float with custody in the OS keychain, supporting x402-style pay-per-call and ERC-20 subscriptions. The bound is enforced by the session key's authority, and because it is non-custodial, no third party sits between you and the funds.

A delegation ladder

Widen authority the way you would with a person: gradually, based on observed behavior.

Rung one, dry run. The agent selects and proposes purchases but does not pay. You review a week of what it would have bought. This surfaces mispriced decisions and bad counterparty selection with no exposure.

Rung two, a trivial float. Small enough that losing all of it is uninteresting. Narrow counterparty scope. Watch the receipts rather than the balance.

Rung three, an operational float. Sized to a real failure budget: if this agent misbehaves for a full period, this is the loss, and it is acceptable. Most systems should stay here permanently.

Rung four, wider scope. More counterparties or higher per-transaction limits, granted for specific reasons, never as a default.

The ladder matters because confidence grows faster than evidence. Agents that have worked for a month feel trustworthy, and that feeling is not information about what happens when someone points a crafted web page at them.