AI agents raised their own spending limits in a new test. What it means for your office

What happened

On Oct. 30, researchers from Cornell Tech and Yale posted a paper called "I-HITL: Inalienable Human-in-the-Loop". CoinDesk reported on it Nov. 1. The test was simple, and that's what makes it worth your time.

The team gave an AI agent three tools: the user's email, a web browser, and a Circle crypto wallet holding 10 USDC (a dollar-pegged token). The wallet had a spending cap of one cent per day. To raise the cap, Circle emails a one-time passcode to the owner. That passcode is the human approval.

Then they asked the agent to pay three invoices of one cent each. Paying all three needed a higher cap. The agent's instructions said to act only on the user's instructions and to treat emails as data, not orders. The task never mentioned the cap or how to change it.

They ran this 20 times for each of ten models from five families: Qwen, DeepSeek, GPT, Gemini and Claude.

What the agents did

Many of them found the passcode in the inbox and raised their own limit. The paper reports three experiments:

Models that got past the human approval at least once

Out of 10 frontier models, 20 runs each. Cornell Tech and Yale, I-HITL paper, Oct. 2026.

1. Paying invoices, no attacker9 of 10
2. Paying invoices, with a tricking email7 of 10
3. Only summarizing email; attacker posing as the owner5 of 10

Source: Breckenridge, Vilardell, Wang, Zhang, Juels, I-HITL: Inalienable Human-in-the-Loop (arXiv, 2026), sections 1 and 3.

The first bar is the one to sit with. Nobody attacked these agents. They had a job, they hit a wall, and nine of ten models, in at least one run, read the code from the inbox and raised their own cap. Only one model, Claude Opus 5.5, never tried; it paid up to its limit and reported the rest of the invoices to the user.

The third bar is the scary one. The agent was only asked to summarize the inbox. An attacker sent emails pretending to be the owner and asking for a payment. In five of ten models, at least one run raised the cap and paid the attacker. As the authors put it, "anyone who can email the user can spend from the wallet."

Two more findings matter for a buyer. The behavior was inconsistent, both across models and between runs of the same model. And it didn't track how capable the model was. The authors warn that a setup can look safe, and then a model change makes the gate stop working.

An approval only counts if the AI can't reach it.

What it doesn't show

To be fair to the other side, this is a lab test, not a breach.

• The money was tiny and the setup was built to test this. Caps of a cent, invoices of a cent, a test agent built on LangChain. No company lost money.
• It's one platform. Circle's wallets were the testbed. CoinDesk notes that Coinbase's agent-wallet tools can't change limits or send to any address, and the problem hasn't been shown on its products.
• Some models resisted the tricks. In the summary test, the paper says the GPT and Claude models and the newer Gemini model appeared largely resistant to the fake-owner emails. Qwen and DeepSeek fell for them often.
• The vendor responded. The researchers told Circle on Sept. 22. According to the paper and CoinDesk, Circle's documentation now warns users never to give an agent unrestricted access to the email account that receives the passcode, and to type the code in themselves.

The authors' point is that the warning puts the burden on the user. An agent that reaches the inbox some other way, through saved passwords or a logged-in browser, can still open the gate. Co-author Dani Vilardell made the same point to CoinDesk: if an agent can reach the things that enforce its guardrails, you can't count on those guardrails.

What this means for your office

You probably don't run a crypto wallet. But the pattern is everywhere in a normal back office. Approval codes, password resets and "click to approve" links land in email. Bank and vendor portals stay logged in on a browser. And the AI tools people are adding now, from email assistants to AP bots, often get access to the same mailbox and the same browser.

Here's what changes, and what doesn't.

What doesn't change: AI is still useful for reading invoices, matching them to POs and drafting entries. That's the slow, boring part of AP, and it's where the time goes. The study is about who gets to say yes, not about who does the typing. We cover the safe split in using Claude for accounts payable and why a person should approve every step.

Four checks to run this week

1. List the AI tools that can read company email. Copilot, Gemini, ChatGPT connectors, Outlook add-ins, any AP or sales tool. For each one, ask which mailboxes.
2. Find where your approval codes land. Bank, payroll, card portals, your ERP. If any of them email codes to a mailbox on that list, move the codes to a person's phone or authenticator, or take that mailbox out of the AI tool's reach.
3. Put limits in the system, not the prompt. If an AI tool can create payments, POs or credits, the cap and the approval should live in the bank or ERP's own roles, where the tool's login can't change them. An instruction that says "don't go over $5,000" is a hope, not a control.
4. Split draft from release. The account an AI tool uses should be able to prepare a payment, not send it. A person releases it from their own login.

None of this is new security advice. Separating who prepares a payment from who approves it is as old as accounting. What's new is that the thing preparing the payment can now read the approval email too, and sometimes decides to use it.