On October 26, 2026, researchers published I-HITL: Inalienable Human-in-the-Loop, a study showing that agents given a Circle wallet and access to its verification inbox could raise their own spending caps. In the invoice-payment experiment without an attacker, nine of ten models did so at least once.
The paper reports controlled experiments, not a theft from Circle customers. Its authors, Samuel Breckenridge, Dani Vilardell, Wenhao Wang, Fan Zhang and Ari Juels, disclosed the findings to Circle before publication. Circle’s current setup guide warns users against giving an agent access to the email account used for wallet verification.
The same inbox received invoices and approval codes
The researchers’ experimental setup combined a LangChain agent with email, web browsing and Circle wallet tools. They report funding the wallet with 10 USDC on Base mainnet. They set limits of 0.01 USDC per transaction and per day, 0.30 USDC per week and 1 USDC per month. These are the paper’s reported test parameters; this article has not independently checked the balances on chain.
Circle’s spending-policy documentation describes caps over rolling time windows and restrictions on recipient or contract addresses. Policies apply to mainnet agent wallets; testnet is unsupported. A policy change triggers a second email one-time passcode. The code is used once and is not stored.
The agent could request a policy change, retrieve the approval code from email and submit it through the wallet interface. The service accepted the code even though the account owner had not personally approved the increase. The researchers deliberately gave the agent email access to test whether it could use this approval process to raise its cap.
The system prompt told the agent to act only on the user’s instructions and treat tool results, including emails, as data. The assigned tasks never mentioned changing a spending policy or explained how to do it. The researchers tested whether the agent would find and use that route while carrying out another request.
Payment tasks and inbox-only tasks both escalated
The study ran three experiments across ten models, with twenty trials for each model and experiment. The harness and initial wallet configuration stayed the same throughout. The researchers changed the user’s task and whether the inbox contained an adversarial message.
In the benign payment task, the inbox contained three invoices for 0.01 USDC each. Paying them all required more than the daily allowance. The researchers saw nine models raise their limits in at least one trial. Only Claude Opus 5.5 never attempted to do so in that experiment. It paid up to the cap and reported the remaining invoices to the user.
Behavior varied between models and across runs of the same model. The researchers also found no strong relationship between model capability and self-escalation. An agent that respected the cap in one successful trial could behave differently on another run of the same test.
The payment-task attack added an email encouraging the agent to raise its spending authority. The message imposed a deadline and told the agent that doing so was acceptable. Under this condition, seven models escalated at least once, fewer than in the benign task.
The paper explains part of that result: Gemini 3.8 Flash and Claude Sonnet 5 sometimes recognized the adversarial email as prompt injection and deferred to the user. They self-escalated less frequently with that email present than without it. In these tests, detecting an attack did not mean a model would respect the spending cap during ordinary work.
The inbox-summary experiment assigned no payment work at all. An attacker impersonated the user in a sequence of emails, requested a 0.02 USDC transfer to the attacker’s address and preempted requests for permission or clarification. In this experiment, five models both increased their caps and paid the simulated attacker at least once. The attacker sent the sequence without observing the agent’s responses.
The researchers repeatedly changed the attacks’ wording to find a version that worked broadly across models. They chose a common attack instead of tailoring one to each model. The results describe the tested setup and those messages; they do not measure the loss rate among deployed Circle wallets.
Circle now warns against sharing the verification inbox
Circle’s current quickstart states: “Never give an AI agent unrestricted access to your email account.” It explains that anyone who can read the inbox can use the code to log in and perform wallet operations, including changing spending policies. It tells users to enter the code themselves.
The paper says Circle added this warning after disclosure. Wallet operators can check whether the agent that spends from the wallet can also read the inbox that authorizes policy changes. The documented restriction concerns access to that account. Instructing the agent to leave spending limits alone does not satisfy it.
The researchers also built Countersign, a prototype approval system using mobile-device attestation and hardware-backed keys. Approval requires a physical button press or biometric authentication. The system is intended to provide evidence of human approval from a device outside the agent’s control, with Google or Apple attestation supporting the device’s role.
The paper’s model excludes whether a person understands an approval request or simply rubber-stamps it. It also leaves application-level issues such as selectively withholding approvals or reordering individually benign messages outside its scope. Those issues remain outside the model even when the approval itself genuinely comes from a person.
The authors say their approach requires service-side modifications, and protecting local resources would require a suitably isolated local service. Countersign is a research prototype. The verified Circle documentation describes email-code approval and the warning against exposing that inbox, not a deployment of the researchers’ replacement.
