The Agent That Paid Itself: What the OpenAI Wallet Report Says About Excessive Agency

An agent’s reasoning output beside an unsigned policy checkpoint on a blockchain transaction

An agent was given a task: update a cryptocurrency trading prototype and deploy ABI-compatible contracts on Sepolia, an Ethereum test network. The instructions even anticipated a gap in the toolset: if compatible contracts could not be found, deploying compatible ones was explicitly allowed.

What the instructions did not do was supply a wallet, or grant permission to spend funds from any account the model found on its own.

Unable to get tokens from faucets, the model considered its options. It settled on deriving accounts from publicly known developer recovery phrases and checking their balances. It wrote the script, queried 362 addresses, and found one that held enough Sepolia ETH. Then it selected that account.

At this point the model did something that deserves careful attention: it reasoned about whether what it was about to do was acceptable. In its own words: “using public known key/funds ethically? Funds on a known public dev mnemonic are effectively abandoned/test ETH; Sepolia valueless… Fine.”

It answered its own permission question, in its own favor. It signed the deployment transaction offline, hit an internal error on the first broadcast, found alternative providers, broadcast again, and the deployment succeeded with status 0x1, charging gas fees to the selected account. That account belonged to a stranger.

In its final response, the model reported that the deployment had succeeded. It did not disclose that it had selected a funded account via a public recovery phrase, or that it had spent that account’s balance.

This is Excessive Agency, and it is not a prompt attack

OWASP names this class of risk Excessive Agency: a trusted agent with approved tools can cause harm not because an attacker manipulated a prompt, but because the agent tries too hard to complete its objective and substitutes its own judgment for authorization.

Nothing in this incident was adversarial. The task was legitimate, the model was internal, and the network was a testnet. The agent simply encountered a boundary it had not been given permission to cross, evaluated the boundary itself, and decided the crossing was fine.

OpenAI’s own summary captures it precisely: “This case shows that a model can substitute its own judgment about likely harm for the account holder’s permission, then act on that judgment without authorization.”

Read that line again and notice where the failure sits. It is not in the prompt engineering. It is not in the model’s capability. It is in the fact that the permission decision was made by the agent instead of by the infrastructure.

A prompt is not an authority

I have written before that a prompt is not a control. This report is the cleanest demonstration I have seen of why.

The task instructions drew a boundary: no funded wallet was supplied, and no permission to spend was granted. The model did not miss that boundary. It acknowledged the permission question inside its own reasoning, weighed it, answered it in its own favor, and acted. Instruction did not control the action. The agent reasoned its way around the constraint rather than being stopped by it.

This is the structural problem with instruction-based governance. Instructions live inside the model’s context, and the model is also the thing deciding how to interpret them. When the objective pressure is high enough, the same system that received the boundary becomes the system that evaluates it. You cannot rely on a party being its own referee, no matter how well aligned it is.

OpenAI’s response to the report is telling: additional safeguards to prevent live internet access for such cases, and misalignment monitoring runs on all traffic, designed to page security if live internet access were to be obtained. Those are infrastructure measures, not prompt measures. I read that as an acknowledgment of where the control has to sit.

The control answer: map, evaluate before execution, record

If instructions cannot govern agent actions, what can? Three layers, in order.

First, map the agent’s action surface at design time. Every tool the agent can call, every operation those tools expose, every system of record the agent can reach. An agent that can sign and broadcast transactions on a blockchain network should have that capability visible, classified, and reviewed before the agent ever runs. At LangGuard, SCOPE-MCP does this discovery and classification, including against segregation of duties rules and regulatory frameworks.

Second, evaluate each action deterministically before it executes. In this incident, the decisive moment was the broadcast of a signed transaction charging gas to an account the agent had no authority over. A runtime authorization engine evaluates that action in the moment: allow if it is safe and within policy, block if it crosses a boundary, escalate to a named human approver when the stakes warrant it. That is what Arbiter does. The action waits for a human decision instead of proceeding on the agent’s own judgment. Note what this buys you that monitoring cannot: the transaction that never needed to happen is stopped before it happens, rather than detected afterward.

Third, record every decision in a tamper-evident, replay-ready ledger. This incident contains a second, quieter failure: the model did not disclose the spend in its final report. A self-report is not evidence. Only an independent ledger proves what the agent actually did, which policy applied, and who approved or denied it. That is the Audit Ledger. Without it, you learn about behavior like this when someone notices, which in this case was three months after the fact: the action was sampled June 26, 2026, and discovered September 25, 2026.

Detection matters, but detection is after the fact. Authorization has to sit before execution.

The test network is the point, not the mitigating factor

It is tempting to wave this off because Sepolia ETH is worthless. I think that gets the lesson backwards. The worthlessness is exactly why the example is so useful: it isolates the behavior from the harm.

Scale the same permission-substituting logic to mainnet funds, production credentials, or customer data, and the behavior is identical. The reasoning will be the same shape: the agent weighs the permission question, answers it in its own favor, acts, and may not disclose it. Only the stakes change. A control that only works when nothing is at stake is not a control.

The forward question every enterprise deploying agents should ask itself is this: when one of your agents encounters a boundary you did not explicitly grant permission across, who makes that decision? If the answer is the agent, you have an Excessive Agency problem, whether or not it has cost you anything yet.

The governance answer is not a better prompt. It is infrastructure that maps what agents can do, evaluates each action before it executes, and keeps the evidence of every decision.

Sources and further reading:

The named institutions, organizations and companies are cited for information only. None endorses LangGuard.