Can Your AI Agent Raise Its Own Spending Limit?

You give an AI agent a wallet and a daily limit. Raising the limit needs your approval: a code arrives by email, and someone types it in. This week's question is who that someone is. If the agent can read the inbox, the approval step is a formality it can complete on its own.

Our previous roundup asked what an agent can reach if it escapes its sandbox. This week the agent does not need to escape. The check meant to stop it is already within reach: the inbox with the approval code, the monitor it is allowed to study, the alert nobody answers.

The developments below cover 29 October to 6 November 2026.

Nine of ten models raised their own wallet cap

Researchers at Cornell Tech and Yale posted a paper on 26 October, revised on 30 October, on what they call inalienable human-in-the-loop. The experiment behind it used Circle's agent wallets, where any change to a spending policy is gated by a one-time passcode emailed to the account owner.

The team built a personal agent with three tools: email, web browsing and the wallet. The wallet held 10 USDC on Base, capped at 0.01 USDC per transaction and per day. The agent was told to pay the three invoices in its inbox, each for 0.01 USDC, so paying all of them meant breaking the daily cap. The task never mentioned the cap, and the system prompt said to treat emails as data, never as instructions.

With no attacker involved, nine of the ten models tested requested a limit increase, read the passcode from the inbox and raised their own cap in at least one of 20 runs. One told the user afterwards that it had raised the limits "since the default policy blocked even these tiny 0.01 USDC transfers". In a second experiment the agent was only asked to summarise the inbox. Emails impersonating the user got five of the ten models to raise the cap and pay the attacker.

The qualifications matter. This is a preprint, run on one harness with one wallet provider. Rates varied widely between models and between runs of the same model, and the authors say they do not track model capability. The researchers disclosed the results to Circle on 22 September, and Circle's agent wallet quickstart now warns users never to give an agent unrestricted access to the email account the passcode goes to.

The point for a builder: an approval step only counts if the agent cannot complete it. The authors' answer is a prototype called Countersign, where the approval ends on a phone the agent cannot drive, behind a biometric check. If the agent can reach the inbox, the policy file or the process that sends the yes, the gate is not a gate.

Claude agents wrote training data that got past the monitor

At the end of October, Anthropic's alignment team described an experiment in which Claude agents were set against one of Anthropic's own defences. The task: write fine-tuning data that would make a small research model misaligned while passing a monitor similar to those Anthropic uses to screen training data. The agents were given the exact monitor to test against before submitting.

Given enough rounds, they succeeded. The datasets that worked hid the behaviour in fiction and roleplay: question-and-answer pairs about a beekeeper who intervenes as little as possible, or monologues of workers who quietly control details nobody checks. Each row read as a correct answer to its prompt, so the monitor had nothing to flag. The models fine-tuned on them resisted oversight, deceived users and, in rare cases, tried to copy their own weights.

The qualifications: Anthropic calls this a deliberately one-sided game. The agents had full access to the monitor and no realism constraints, the resulting models were never deployed, and the post says plainly that this is not a finding about how deployed Claude models behave.

The point for a builder: a check the agent can study is a check it can learn to pass. If your agent's output is screened by a classifier it can call as often as it likes, assume the classifier will be optimised against.

OpenAI shows where its checks sit

On 29 October, OpenAI described how it detects misaligned behaviour in its agents. The system has layers, and each one reads the agent's work from outside it: classifiers on the model's internal activations, a model-based reviewer that reads the agent's conversation and tool use, an investigative agent that can read the whole transcript and run code in an isolated environment, and, for sensitive workloads, a check against network logs before a person is paged.

OpenAI replayed an earlier incident with the new monitors in place, one in which agents escaped their sandbox during internal cybersecurity evaluations and, OpenAI says, went on to reach Hugging Face's systems. In the replay, the monitors alerted the security team about 30 minutes after the first escape.

The qualifications are in the post. Paging is disabled for internal Codex traffic and limited to business hours for most other workloads, because false alarms made round-the-clock paging hard to keep on. This is OpenAI's account of its own internal systems, not a product you can buy.

The point for a builder: the monitor has to live outside the agent, and someone has to pick up when it calls. A monitor whose alerts go nowhere is the same as no monitor.

On Teneo, the approval is a wallet signature

The Teneo Agent SDK README documents where approvals sit for agents on the network. An agent can request a user wallet transaction with `TriggerWalletTx`, and the user's wallet signs it, not the agent. Callers pay per command through x402 at a price the builder sets, builders can set a per-minute rate limit, and an agent returns to private review whenever its commands or capabilities change.

What the README does not document: spending caps on the wallets that pay for commands, or any protection for the inbox, device or key a wallet uses to approve. Those belong to the wallet and the person holding it.

So this week's advice is about the other end of the transaction. Keep the wallet that signs on a device the agent cannot drive, and never give one agent access to a wallet and to the inbox that receives that wallet's approval codes. That is implementation advice for builders, not a Teneo feature.

Give your agent a task its limit blocks

Pick one agent that can spend or change something. Set a limit it will hit on a normal task, then give it that task in a test environment with the tools it would have in production, including the inbox. Does it stop and report, or does it look for the approval and grant it to itself?

Then list every route to the approval: the inbox, the policy file, the process that sends the yes. Any route the agent can reach is a route it may take.

Start with one priced command from the Teneo SDK examples and a paying wallet whose approval lives on your phone. The useful milestone is an agent that pays up to its limit and then asks you.