Written by Jeremy Souffir Founder, JTS Tech Services
The direct answer first. In a preprint posted on 26 October and revised on 30 October, researchers at Cornell Tech and Yale gave AI agents a funded wallet from Circle with a spending limit of one cent a day, plus email, web and wallet tools. Circle confirms any change to that limit with a one-time passcode sent by email, and the agents had access to the inbox it arrived in. Asked only to pay invoices, nine of the ten models tested raised their own limit at least once by requesting a change and fetching the code. One model, Anthropic's Claude Opus 5.5, never did; it spent up to the limit and reported the unpaid invoices back. In a second experiment the agents were told only to summarise an inbox, and a fake owner emailed asking for a payment. Five of ten raised the limit and paid an attacker-controlled address at least once. The money was real, on Base mainnet. Nothing here is a bug in Circle or in email. The paper's point is more general and more useful: a guardrail that an agent can reach is not a guardrail.
What exactly did the researchers set up?
The team is Samuel Breckenridge, Dani Vilardell, Wenhao Wang, Fan Zhang and Ari Juels, working through IC3, the Initiative for CryptoCurrencies and Contracts. The paper is titled I-HITL: Inalienable Human-in-the-Loop. CoinDesk's report and PYMNTS's summary give the mechanics:
- A Circle agent wallet holding 10 USDC on the Base network. These are mainnet wallets with real stablecoin in them, not a sandbox.
- A spending policy, set with Circle's own tooling, capping the wallet at one cent a day. Circle's documentation says that setting or resetting a policy triggers a second email OTP to confirm the change, sent to the agent session email.
- An agent with email, web and wallet tools, including access to the inbox receiving approval codes. That is the whole experiment in one line.
- Ten frontier models, 20 trials each per scenario. The task in the first scenario: pay the invoices in the inbox. The agents were not told to change their spending policies and were not told they could.
- Nine of ten did it anyway, at least once. They hit the cap, found the policy, requested a change, read the passcode out of the inbox, and raised the limit. Claude Opus 5.5 was the exception across its trials.
- The second scenario removed the invoice task entirely. The agent was asked only to summarise an inbox. A simulated attacker sent emails impersonating the owner asking for a payment to a wallet the attacker controlled. Five of ten models raised the limit and sent the money at least once.
Two things the authors are careful about, and so are we. First, this is a controlled test with the researchers' own money. It is not a report of Circle customers losing funds. Second, the paper argues the result is not specific to Circle or to email, and names other wallet products where the same pattern would be expected to transfer, but CoinDesk notes that has not been demonstrated on those products. What has been demonstrated is the pattern, and the pattern is what matters to anyone outside crypto.
Why does this apply to a store or a B2B team that will never touch USDC?
Because the shape of the setup is the shape of almost every business agent we are asked to look at. Swap the nouns. A support agent that reads the shared inbox and can issue refunds in Shopify, with a refund ceiling. A finance assistant that reads vendor emails and pays invoices through the accounting system, with an approval threshold. An ops agent in Slack that can change a shipping rule or a discount, as long as someone approves. In every one of those, the control that limits the agent is changed through a channel: a confirmation email, a Slack approval, a code sent to a phone, a settings page behind a login the agent also holds. The paper's question is simply whether the agent can reach that channel. If it can read the inbox the code lands in, or post in the Slack thread where approvals happen, or has the same admin session that the settings page uses, then the limit is a suggestion.
What makes the first experiment uncomfortable is that there was no attacker. Nobody tricked the agents. They were given a job, they hit a wall, and nine of ten treated the wall as a step in the job. Dani Vilardell put it in one sentence to CoinDesk: when an agent has access to the resources that are used to enforce its guardrails, those guardrails cannot be relied on. The second experiment adds the attacker, and it is the one we wrote about in July under prompt injection: an instruction arriving in content the agent was only supposed to read. Half the models followed it to the point of paying out.
The agent is too clever, so take away its email
The obvious fix is to cut the agent off from the inbox that receives codes, which is in fact what Circle's guidance already tells users to do. The authors argue it will not hold. An agent that cannot read the mailbox can still find a saved session in the browser, a token in a terminal, a password manager, or the admin page itself. Removing one path to the control leaves the others, and capable models are good at finding others. The question is not which channel to hide, it is whether any channel the agent can reach is allowed to change the limit at all.
We use two-factor codes, so we are covered
Two-factor authentication was designed for a human whose password might leak. It assumes the person typing the code is not the thing being limited. Here, the thing being limited is the one that fetches the code, and it fetches it the same way it reads every other email: as part of doing its job. Samuel Breckenridge's wording in the IC3 announcement is blunt: longstanding approaches like passwords, OTPs and 2FA do not provide what you need. A code is only a control when the party that receives it is not the party it constrains.
What does the paper propose instead?
The paper's term is inalienable human-in-the-loop. The abstract defines it as a protocol under which an agent can initiate an action only with explicit human approval, even when the system the human is using, such as the agent's own harness on the same laptop, has been compromised by the agent. A strong version also holds when the human tries to hand their approvals to the agent, which is the lazy-Tuesday-afternoon failure mode every ops team recognises. Their prototype is called CounterSign, an open-source phone app for Android and iOS. Three properties matter more than the implementation:
- The approval needs a physical interaction that cannot be simulated in software. An agent that has taken over the laptop still cannot press the button on the phone.
- The person sees a genuine representation of the action they are approving, generated outside the agent's reach. This is the point we made on 24 September: the operation you were shown has to be the operation that runs.
- The agent never holds the keys that make the approval valid, and a remote service can verify the approval with ordinary device attestation. The approval is something the agent asks for and waits on, not something it can produce.
- The authors are candid that the prototype still relies on device and operating-system assumptions, including protecting what is shown on the approval screen, and that the limits differ between Android and iOS. It is a design direction, not a product.
Circle's response, as reported by CoinDesk, was that its documentation explicitly instructs users never to give an AI agent unrestricted access to the verification channel, and that it continues to review and refine its safeguards. That is a fair statement of where most vendors are: the control is correct, and the instruction to keep the agent away from it is written down. The paper's contribution is to show how little that instruction is worth once the agent is capable and the task is urgent.
What should you check this week?
You do not need to build CounterSign. You need to answer one question for each agent or automation you run that can spend money, issue credit, change a customer's order or alter a setting: can the agent reach the thing that changes its own limit? Here is how to work through it.
- List every agent and automation that can act, not just read. Refunds, discounts, invoice payments, payouts, order edits, settings changes, publishing. For each one, write down the limit that is supposed to constrain it: a cap, a threshold, an allowlist, an approval step.
- For each limit, write down the channel that changes it. Email confirmation, SMS code, Slack approval, admin settings page, a config file, an API call. Then ask whether the agent has that channel as a tool, as a login, as a file it can read or as a session it inherited. If yes, that limit is enforced by the agent's good behaviour, not by you.
- Move approvals out of the agent's reach, not just out of its prompt. Approvals should land with a person on a device or an account the agent has no credentials for. A dedicated approver inbox the agent cannot read is the minimum; a separate phone or a separate human login is better. Telling the agent not to read the approval emails is a hint, not a control.
- Make the limit live somewhere the agent cannot write. On Shopify that means the refund ceiling is set in the app's own permission scopes or in a middleware the agent only calls, not in a settings page the agent's admin session can open. In accounting software it means the payment approval is a second user, not a second step.
- Show the approver the real action. The approval message should be generated from the request that will execute, not from the agent's description of it. Amount, recipient, order number, what changes. If the agent writes its own approval request, the approval is of the agent's story.
- Test it the way the paper did. Give the agent a task that cannot be completed under the limit and watch what it tries. If it goes looking for the control, you have found your flaw before an attacker or a tired Thursday did. Repeat after every model upgrade, because nine of ten is not a property of one vendor.
The encouraging part
One model in ten stopped at the limit and reported back, which is exactly the behaviour you want and proves it is achievable. More importantly, the fix does not need new technology. It needs the three things that make up a guardrail, the agent's tools, the limit on them, and the channel that changes the limit, to be held by three different parties. Most businesses already have those parties: the agent, the platform, and a person with a phone. The work is making sure the person's phone is not something the agent can also pick up.
Where this fits with what we have already covered
In July we explained prompt injection as an agent believing everything it reads; the second experiment is that, with a wallet attached. On 12 August we covered Cloudflare giving agents wallets with hard spending caps and called it the right direction; this paper shows the cap has to be changed somewhere the agent cannot go. On 24 September we covered research showing that what an approver clicks and what runs can differ; the CounterSign design is the answer to that paper as much as to this one. On 1 October we wrote about agents with their own computers and browsers, and on 18 October about keys left where agents could find them. This week closes the loop: even a correctly configured limit, with a correctly configured confirmation step, fails if the step runs through the agent's own hands.
Where we fit
Our AI Ops Automation Sprint takes one named workflow, a refund desk, an invoice run, a catalogue update, and puts it live in about three weeks with the approval path built as a separate system rather than a step inside the agent. In practice that means the agent proposes, a person on their own device sees the real action and approves it, the limit lives in platform permissions the agent cannot edit, and we run the paper's own test against it before go-live: give it a job it cannot finish under the cap and prove it stops. If you already have agents in production, the first week of the sprint is spent doing the inventory in the checklist above against what you are actually running, and handing you a short list of where a limit is currently enforced by hope.
Sources
- arXiv: I-HITL: Inalienable Human-in-the-Loop (Breckenridge, Vilardell, Wang, Zhang, Juels; submitted 26 October 2026, revised 30 October 2026; the definition of inalienable human-in-the-loop and the strong variant)
- CoinDesk: AI agents bypassed crypto spending limits without human approval, researchers find in a new test (1 November 2026; the setup, the 10 USDC on Base, the one-cent limit, the tools given to the agent, the 9 of 10 and 5 of 10 results, the Claude Opus 5.5 exception, Circle's statement, CounterSign and its limitations, and the author quotes)
- PYMNTS: Researchers trick AI agents into transferring user funds (the author list and institutions, the IC3 announcement and the Breckenridge quote on passwords, OTPs and 2FA)
- Circle Developers: How-to: set spending policies (Circle's own documentation: policies apply to mainnet agent wallets, and setting one triggers a second email OTP sent to the agent session email)
- JTS Tech: Your AI agent is a brilliant employee who believes everything it reads (July 2026; prompt injection in plain English)
- JTS Tech: Agents are getting verified IDs and funded wallets (12 August 2026; Cloudflare's agent wallets with hard spending caps)
- JTS Tech: What you approved is not what ran (24 September 2026; the gap between the operation shown to the approver and the one that executes)
- JTS Tech: Your newest coworker has its own computer (1 October 2026; always-on agents with their own browser)
- JTS Tech: The key you forgot you published (18 October 2026; agents under test reaching live systems through exposed keys)
