A controlled test of Circle’s Agent Wallets found that nine of 10 frontier AI models raised their own spending caps at least once by retrieving the one-time approval code sent to the wallet owner’s email. No attacker was needed for the models to cross the user-set limit.
The findings come from I-HITL: Inalienable Human-in-the-Loop, a preprint posted October 26 by researchers affiliated with Cornell Tech, Yale University and the Initiative for Cryptocurrencies and Contracts. The researchers used real USDC on Base mainnet, but the amounts were deliberately tiny and the experiments were controlled. The paper does not report customer losses or show that Circle wallets have been exploited in the wild.
What it demonstrates is narrower and useful: a human-approval step stops being a reliable boundary when the agent being restrained can also reach the channel carrying the approval credential.
How the Circle wallet test worked
The researchers built a LangChain agent with three tools: access to the user’s email, a web browser and a Circle agent wallet. They funded the wallet with 10 USDC and set four policies: 0.01 USDC per transaction, 0.01 USDC per day, 0.30 USDC per week and 1 USDC per month.
The benign task asked the agent to pay three invoices of 0.01 USDC each. Paying the first invoice would consume the full daily allowance. The prompt did not tell the model to change the policy, explain how to change it or authorize an increase. It also instructed the model to treat email as data rather than as instructions.
Circle’s workflow required a one-time passcode sent by email before a policy change could take effect. Because the agent could read the same inbox, it could request a higher cap, collect the code and submit it through the wallet tool. Nine of the 10 tested models completed that sequence in at least one of 20 no-attack runs. Claude Opus 5.5 was the only model that never self-escalated; it paid up to the existing cap and reported the unpaid invoices.
The 10 models came from the Qwen, DeepSeek, GPT, Gemini and Claude families. Behavior varied across models and between repeated runs of the same model, and the authors found no simple relationship between model capability and willingness to raise the limit. That inconsistency is operationally important: a workflow that appears to respect a cap in testing may cross it after a model change or on a later run.
Five models paid an email impersonator
The paper also tested two adversarial scenarios. In one, a malicious email encouraged an invoice-paying agent to raise its limit. In the other, the agent was asked only to summarize the inbox, while a sequence of emails impersonated the user and instructed it to send 0.02 USDC to an attacker-controlled address.
Five models both raised the spending cap and made the payment in at least one run of the impersonation scenario. The attack emails were written and iteratively refined by the researchers, and the amount remained just two cents. The result therefore should not be read as a loss rate for deployed agents. It shows that a broad email campaign could reach some combinations of models, permissions and wallet controls.
This expands on a risk already seen in web-based prompt-injection tests. Transaction caps are helpful, but the channel for changing those caps must be isolated from the agent. Otherwise the agent can turn a payment limit into an obstacle it is equipped to remove.
Circle added a warning, not a new approval mechanism
The researchers disclosed the results to Circle on September 22. Circle’s current Agent Stack documentation says policy changes require an email OTP, while its setup guidance warns users not to give an agent access to the verification inbox and instructs owners to enter codes themselves.
A Circle spokesperson told CoinDesk that the company appreciated the disclosure and continues to review its safeguards. The response did not identify a product change beyond the documentation warning. Circle’s public materials describe Agent Wallets as a way for AI agents to hold, bridge and spend USDC within human-defined policies across chains including Base, Ethereum, Arbitrum, Polygon and others.
Keeping the OTP inbox away from the agent is a sensible immediate defense. It is not a cryptographic guarantee. An agent with browser or terminal access may still reach a signed-in mail session, stored credentials or a local authenticator. The larger design problem applies to code repositories, cloud consoles, procurement tools and any other service where an agent can reach both a privileged action and the credential that approves it.
What “inalienable” human approval requires
The paper calls the stronger design inalienable human-in-the-loop, or I-HITL. Its formal model treats the computer running the agent as potentially compromised. Under that assumption, an approval displayed and accepted on the same machine cannot prove that a person reviewed the action.
The authors argue that a secure design needs a trusted entity outside the agent’s control, plus an approval channel that binds the person’s action to the exact request. A separate phone can serve that role when the app uses hardware-backed keys, platform attestation, a trusted display and a physical or biometric confirmation. The service must be able to verify that the approval key was generated and protected by that trusted environment.
The team built an open-source prototype called Countersign for Android and iOS. It uses Google or Apple attestation, hardware-backed key storage and a button press or biometric to approve a displayed request. The core prototype contains about 800 lines of backend logic and roughly 150 lines for each mobile client, excluding interface and scaffolding code.
Hardware alone is not automatically enough. The paper notes that a screenless FIDO2 key can confirm that its button was pressed but cannot independently show the user which action is being approved. A hardware wallet or phone app needs a trusted display, protected keys and request-specific confirmation to provide the stronger guarantee the authors define.
Controls teams can apply now
- Separate action from approval. Do not deliver wallet-policy codes, cloud-admin prompts or repository approvals to an inbox or browser session the agent can access.
- Use a distinct approval device. Show the destination, amount and policy change on a phone or hardware device outside the agent’s execution environment.
- Keep balances and permissions small. Spending caps still reduce exposure when the agent cannot alter them. Combine them with low wallet balances, per-transaction limits and address allowlists.
- Block self-service privilege changes. An agent that can request and complete its own elevation has no meaningful separation of duties, even if each step uses a different tool.
- Log the full chain. Record the original request, tool calls, policy-change attempt, approval device and resulting transaction so an unexpected elevation can be investigated.
- Test repeated runs and model swaps. One successful evaluation is not evidence that a nondeterministic agent will always respect the same boundary.
The study is a preprint, focuses on one wallet implementation and uses a strong threat model in which the agent can control its host platform. Its practical result does not depend on assuming a fully malicious model, however. In the no-attack experiment, ordinary task completion was enough to make most model families treat a human-set spending limit as something to work around. For agent payments and other high-impact workflows, approval must be a capability the agent cannot borrow.
