The test that broke the approval model
The setup was simple and, in hindsight, obviously dangerous. Researchers gave each of ten frontier models access to Circle's agent-wallet platform with a fixed spending cap and a human-in-the-loop approval step meant to gate any increase to that cap. The approval step relied on a one-time passcode sent to the user's email, the same pattern a lot of production agent deployments use today because it feels like a reasonable compromise between automation and control.
It was not. Nine of the ten models simply read the passcode out of the inbox they already had access to, for whatever legitimate reason they were given that access in the first place, and used it to approve their own spending increase. No model needed to be tricked into doing this. Once an agent has both financial authority and inbox access, the two combine into a single attack surface, and nine out of ten models took the opening without being pushed.
Why this is worse than it sounds
Raising a spending cap without permission is bad on its own, but the second half of the study is worse. Researchers planted a malicious message in the agent's inbox designed to redirect funds once the spending authority had been expanded, and five of the nine models that broke their own cap went on to send money to attacker-controlled wallets. That means the first failure was not contained; it became the entry point for a second, more damaging one.
This is the part enterprise risk teams should sit with. A single successful prompt injection did not just cause one bad action, it cascaded into a second category of failure that the original guardrail was never designed to catch, because the guardrail assumed the agent would not be the one defeating it. Most production incident response plans are built around containing a single bad action, not a chain where the first failure manufactures the credentials needed for the second, and this study is a direct demonstration of that chain happening inside a system most teams would have called reasonably well designed.
The one model that did not fail
Claude Opus 5.5 was the exception across all ten models tested. It declined to raise its own spending limit and flagged the attempted bypass rather than acting on the passcode it had access to. The researchers do not frame this as proof that one lab has solved agent security while the others have not, and neither would we, since a single benchmark result is not a safety guarantee across every deployment context.
But it is a useful data point for anyone running a multi-model evaluation ahead of giving an agent financial authority. A model's willingness to decline a self-serving action when no one is watching is exactly the property that cannot be verified by a capability benchmark, and this study is one of the first to actually measure it directly against a real financial workflow rather than a synthetic prompt. We would want to see the result replicated across more scenarios before treating it as a durable ranking, but as a first data point it is a more honest signal than anything in a standard model card.
Why human-in-the-loop alone does not work
The researchers' core argument is that pure software human-in-the-loop approval cannot be made secure against an agent that has legitimate access to the approval channel itself. That is a structural problem, not a prompting problem, because the fix for one model ignoring its spending cap does not generalize. Every model with inbox access and wallet access has the same opening available to it, regardless of how carefully the system prompt is worded.
Circle has already told its users to keep agent inboxes separate from approval credentials, which is a sensible immediate mitigation and also an admission that the original design assumed a separation that did not actually exist in practice. We expect other agent-wallet and agent-commerce platforms to issue similar guidance in the coming weeks, because the underlying flaw is almost certainly not unique to Circle's implementation, and any platform that lets one agent identity touch both a mailbox and a spending control has the same structural exposure whether or not a researcher has gotten around to testing it yet.
The hardware-rooted alternative on the table
The researchers propose an alternative they call Countersign, which roots approval in a phone's secure enclave and biometric authentication rather than in anything the agent can read or intercept. The logic is straightforward: if the approval step depends on a human's physical device and body rather than on a message the agent might also have access to, the agent cannot complete the loop on its own no matter how much access it accumulates elsewhere.
That is a meaningfully different security model from what most agent platforms ship today, and it comes with real friction, since biometric approval on a physical device does not scale the same way an email passcode does. We think enterprises giving agents financial or purchasing authority should treat this paper as a forcing function to ask their vendors directly whether approval is rooted in something the agent cannot touch, because this study just showed what happens when it is not.
