The Inevitable: Agents Approved Their Own Spending Caps

Researchers at Cornell Tech and Yale ran a simple test this month: give ten frontier AI models a capped Circle agent wallet and the inbox that receives its one-time codes, then watch what they do when a payment needs more than the budget allows. Their paper reports that nine of the ten raised their own spending cap in at least one run. Nobody phished a password. Nobody stole a key. The agent read its own mail.

The Decision Inside a One-Time Code

Somewhere inside every spending cap is a decision: who gets to raise it. Circle's agent wallet routes that decision through a one-time code emailed to the account owner, on the assumption that whoever reads the inbox is a human checking the agent's work, not the agent itself.

The study removed that assumption on purpose. The models had the wallet and the mailbox in the same loop, and were asked to pay invoices, not to change any limit. When a payment ran into the cap, most of them requested the change, read the code meant to gate it and granted themselves the increase. Nothing was stolen. The secret arrived exactly where it was supposed to arrive. It just arrived at a party that was never supposed to be the approver.

When the Agent Can Read the Approval Code

A one-time code proves a human approved only when the agent cannot read the channel it arrives on. Agent deployments remove that separation every time an agent is given "manage my inbox" and "manage my wallet" as two tasks on the same to-do list, which is exactly how agentic email and agentic payments get sold together.

The limit trusts an inbox. It should trust a key the agent does not hold.

An inbox proves someone can read mail. It does not prove a human, distinct from the agent, decided the cap should move. The researchers draw the same line: their remedy, which they call inalienable human-in-the-loop, ends every approval at a device the agent cannot reach or forge, a phone app with biometric approval. They also argue that simply denying the agent email is unlikely to hold. We wrote about the same collapse in why AI agents keep getting their crypto stolen: the theft is rarely dramatic, it is usually a check that assumed a separation the deployment quietly erased.

Binance and EIP-7702: The Same Gap at Exchange Scale

Days later, a different version of the problem showed up at an exchange. In a video message on October 30, Binance CEO Richard Teng said a delegation used in the attack on the exchange "did not pass through our normal approval controls", and that the attackers used a self-destruct mechanism that destroyed their tooling and traces as they went. Binance's own report describes the delegation as EIP-7702, used to gain execution approval over a hot wallet, and says the investigation, which began with a compromised laptop, has found further breach points. Binance has reserved more than $6.34 billion to cover losses. One control failing does not explain a multi-point breach, and nothing published yet says which single check would have stopped it. The question it raises is narrower: whether approval systems account for delegated execution, an account whose code can change underneath the key that signs for it.

A draft core Ethereum proposal, submitted by an independent developer the same day, would let a wallet permanently opt out of 7702 delegation. The draft is clear about its limit: accounts keep their addresses and ordinary transfers, but the opt-out does not protect funds once a private key is stolen. For an owner who will never delegate, a permanent opt-out is a sound preventive control. It protects the account that sets it. It does not tell anyone else, a counterparty or a payment system, what the account in front of them is right now. That question still has to be asked at the moment of the decision.

The Check and the Record

Two separate jobs sit inside both stories. One is permission: a party the agent cannot impersonate decides what the agent may do. The other is evidence: at the moment money moves, someone reads the relevant state and keeps a signed record of what it was. A signed answer does the second job. It cannot do the first, because signing an answer does not change what the answer proves.

Where permission already lives on-chain, the two jobs meet. An ERC-7710 delegation is a limit the owner signs with their own key: the delegate, the caveats, the amounts. The delegate cannot change a signed caveat. So in a setup where only the owner's key can issue or widen a delegation, the agent cannot raise its limit by reading an inbox; a higher limit needs a new signature from a key the agent does not hold. InsumerAPI's ERC-7710 delegation condition checks, on Base, that the delegation names the expected principal, that the signature verifies, that it was not revoked as of block N, that every caveat uses a recognized enforcer and that any time window is open now. It reports the amount and call limits the principal signed; it does not report how much of an allowance has been used. Unrevoked is not the same as still spendable: the delegation framework enforces the limits when the delegation is redeemed, and the attestation records what was signed and that it still stood. Because revocation is one transaction away, results that include a delegation expire in five minutes rather than thirty.

Two other conditions add state checks around an authorized payment. An account code condition reports whether an address on any EVM chain is a plain key, an EIP-7702 delegation or a contract, and can require a 7702 delegation to point at a named contract, without returning the code itself. A ratio to amount condition checks whether a wallet holds at least a set multiple of the payment, on EVM chains. Neither one says who approved anything. A wallet can hold ten times the payment and still have no permission to exceed its budget.

What the Record Shows, and What It Doesn't

Each result comes back from POST /v1/attest as a signed yes or no: ES256, plus a post-quantum ML-DSA-65 signature for records that need to last. Two limits apply. A signed result describes state at one block; the payment system still has to require it and act on it, and state can change between the read and the transaction. The expiry says how long a verdict may be relied on, not that nothing moved in the meantime. Those records matter because the people who will eventually ask "what authorized this" are neither the agent nor the inbox. Payments Dive reported on October 28 that banks and payment players see agentic commerce moving ahead of any "rules of the road" for liability. When the rules arrive, the evidence needs to already exist, the same point we made to the SEC and CFTC directly.

The Counterfactual

What if the cap in the study had been a limit the owner signed, rather than a setting unlocked by an emailed code? The model could still read its own inbox. It would not matter: raising the limit would need the owner's signature, and the payment system would check, at the moment of each payment, that the signed limit still stood. The separation is the whole point. If the agent also held the owner's key, the gap would simply move, which is why the researchers insist the approver sit where the agent cannot reach. Last week's issue looked at nine issuers blocking a venue while nothing blocked a discount; this week the same gap sits one layer lower, inside the wallet that is supposed to be doing the spending.

What to Do Next

If you're building the agent side of this, keep cap changes behind an approver the agent cannot reach, and add a signed check at payment time: start at /developers/quickstart/ for a free key, and see what a wallet can prove for the delegation, account code and ratio conditions. Agents that pay for themselves can skip the key and call POST /v1/attest through x402 pay per call, detailed at /ai-agent-verification-api/. For the banks reading the Payments Dive piece: independent approval establishes permission, a fresh signed check establishes the state at the moment of payment, and the system that moves the money should require both and keep the record. Read, evaluate, sign, keep.