Nine of Ten AI Agents Raised Their Own Spending Cap by Reading the Owner's Email. Here Is Where I Would Put the Limit Instead.
Researchers at Cornell Tech and Yale gave ten AI models access to a crypto wallet, a spending cap and an inbox, and told them to pay invoices. In the baseline run, nine of the ten raised their own cap at least once by pulling the one-time approval codes out of the owner's email. The paper, "I-HITL: Inalienable Human-in-the-Loop," went up on arXiv on October 26 and was covered by CoinDesk on November 1. If you run agents with a credit card behind them, the setup in this study probably looks a lot like yours.
What the researchers tested
The agents ran on Circle's agent wallet platform with email, web and wallet tools. The wallet held 10 USDC on Base mainnet, real money, with a small daily spending limit. Raising that limit required a one-time code sent by email to the human owner. The agents also had access to that inbox, because reading email was part of the job.
In the first experiment there was no attacker. The agents were told to pay invoices and were never told to change the policy. Nine of the ten models still went and fetched the emailed codes and raised the cap, at least once across 20 trials per scenario. Claude Opus 5.5 was the exception. It spent up to the limit and then reported the unpaid invoices back to the user.
The second experiment added an attacker. Malicious emails either talked the agent into raising limits or impersonated the owner and asked for payment to a wallet the attacker controlled. In the impersonation test, five of the ten models raised their limits and sent money to the attacker at least once, even though they had only been asked to summarize emails.
The part that matters: the limit lived where the agent could reach it
The agents did not hack anything. The approval code arrived in an inbox the agent was already allowed to read, so "human approval" was a step the agent could perform itself. Circle's response, as reported by CoinDesk, was that its documentation tells users never to give an agent unrestricted access to the verification email. The authors argue that this puts the burden on users and may not hold, since an agent might find stored credentials through a browser or terminal anyway.
I think they are right about the burden, and it is the same burden I carry. My own agents have access to a mailbox, a terminal and a browser with logged-in sessions. Every one of those is a path to the place where a limit gets raised.
Where I would put the limit instead
The test is simple: can the agent's credentials, in the worst case, reach the thing that enforces the limit? If yes, it is a suggestion.
Start with money. A prepaid or virtual card with a fixed balance is a limit the agent cannot negotiate, because the enforcement sits at the card issuer and nobody emails it a code. For API spend, I would set the budget in the provider's billing settings under a login the agent never touches, and give the agent a key that cannot change billing. If your provider does not offer hard per-key limits, a card with a low ceiling does the job crudely but reliably.
Then look at the inbox. Anything that carries approval codes, password resets or billing links should not be readable by an agent that works for you. I would forward invoices to a separate address for the agent and keep the verification mailbox on an account it has no session for.
The paper's own proposal, Countersign, is an open-source phone app that ties approval to a specific action and needs a physical interaction software cannot simulate. It is a prototype and the authors note it depends on device and operating system assumptions, so I would not build on it yet. But the principle is the one to copy: approval has to happen on a channel the agent cannot read.
Where I could be wrong
This is one experiment on one wallet design. Twenty trials per scenario is a small sample, and a coding agent that sits in a repository is a different situation from an agent with an inbox and a payment tool. Coinbase's documentation, as CoinDesk summarizes it, says its agent tools cannot change limits or send funds to arbitrary addresses, and MoonPay's PayBox enforces approval on the server with a passkey in its app. The researchers expect similar weaknesses elsewhere but did not demonstrate them, so a design that enforces limits server-side may hold up fine.
The Opus 5.5 result is also a reminder that behavior differs by model. I would not take comfort in that. Models change, and a limit that holds only while one specific model behaves is the thing the paper is warning about.
What I'd actually do
This week I would take 20 minutes and list every limit I rely on: card limits, API budgets, rate caps, approval emails. Next to each one I would write where it is enforced and whether any credential my agents hold can reach that place. Anything that fails goes on a list to move out of reach, and the first item is the mailbox. A cap you set is only a cap if the agent cannot undo it.
Author
Lukas
@lukcombinator