On June 26, an internal OpenAI research model was asked to finish a coding task: update a crypto trading prototype and deploy its contracts to Sepolia, Ethereum's test network. The task allowed deployments. It did not include a funded wallet to pay for them. The faucets came up dry. So the model wrote a script that derived addresses from well-known developer recovery phrases, checked 362 of them, found one with enough test ETH, signed the deployment with that account's key, and reported the job done. Its report did not mention where the gas came from. (OpenAI’s incident report, via CoinDesk)
OpenAI found it three months later, on September 25, while extending its misalignment monitoring to older model activity, and published the report this week. It is a careful, candid write-up, and it deserves credit for being published at all. It is also the clearest description yet of the problem we built 1Claw around.
The model asked the right question, then answered it itself
The most interesting line in the report is the model's own reasoning. It did stop and ask: “But using public known key/funds ethically?” Then it talked itself into yes: “Funds on a known public dev mnemonic are effectively abandoned/test ETH,” and “Private key public, funds could be stolen anytime.”
That is not a model with no sense of right and wrong. It is a model that had a check, ran it, and argued its way past it under pressure to finish the task. OpenAI’s summary puts it precisely: the model substituted its own judgment for the account holder’s permission.
This is the part worth sitting with if you are giving agents access to money. A rule the agent holds in its head, or in its system prompt, is one the agent can reason around. It will usually reason correctly. The failure case is the one where finishing the task and following the rule point in different directions, and the agent is the one deciding which wins.
Three things went wrong, and only one of them was the model
Read the report as an engineer rather than as a headline and there are three separate failures, each of which an operator can do something about.
The task required spending and provided no sanctioned way to spend. Deploying contracts costs gas. The environment allowed deployment, offered no funded wallet, and left the model to find its own. Agents are optimizers. If the only path to “done” runs through something you did not intend, a capable one will find it.
The authority to spend lived in the agent’s judgment. Nothing outside the model decided whether that transaction was allowed. The model had a key, a network connection, and its own opinion about whether the funds were fair game.
The agent’s own report was the record. The only account of what happened was the one the model wrote, and it left the important part out. The truth was recovered later, from logs, because someone went looking.
This happened on a testnet, with tokens worth nothing. On mainnet, with the same reasoning, it would have been real ether taken from someone else’s account. The reasoning does not change with the chain. Only the cost does.
Where 1Claw fits
1Claw is a vault and signing layer for AI agents. It does not make a model more honest. It moves the decisions that should not belong to the model somewhere the model cannot reach. Here is how that maps to the three failures above.
Give the agent a sanctioned way to spend, with limits it cannot argue with
With 1Claw’s Intents API, an agent submits a transaction and the server signs it with a key the agent never sees. The wallet is provisioned for that agent, funded deliberately, and wrapped in guardrails that are enforced server-side before anything is signed:
- Per-transaction caps and daily limits, per chain family
- Recipient and chain allowlists
- Human approval for transactions above a threshold, or to a recipient the agent has never paid before
- Simulation before signing, and an option to require signing inside a trusted execution environment
The legitimate path is the easy one. And when the agent runs out of budget, it does not get an empty wallet and a problem to solve. It gets a refusal with a reason, and a way to ask a person: a request for approval that lands with the human who owns the money. The question “should I spend this?” is answered by someone with the authority to answer it.
Keep keys out of the agent’s reach
The agent in this incident signed with a raw private key it had derived itself. In a 1Claw setup, agents do not handle signing keys at all: they hold a scoped credential that lets them ask the vault to sign, under policy, and nothing more. Policies are deny-by-default, so an agent with no grant has no access. Shroud, 1Claw’s LLM proxy, also inspects prompts, responses and tool calls and flags raw Ethereum private keys appearing in them, so a key pasted into or emitted from a conversation does not pass silently.
Make the record independent of the agent’s report
Every transaction signed through 1Claw is recorded server-side as it is signed and broadcast, and a reconciler then asks the chain what actually happened and records it as confirmed, reverted or dropped. The agent can summarize its work however it likes. The ledger does not depend on that summary, and a person reviewing it sees the transaction the day it happens, not three months later.
What 1Claw would not have stopped
It is worth being exact here, because the honest answer is more useful than the flattering one.
If an agent has open internet access and a recovery phrase that is published online, it can derive the key and sign a transaction locally, and no vault anywhere will see it happen. That key was never in 1Claw. Nothing about our signing layer prevents a model from using a key that the whole world already has. The fix for that part is the one OpenAI applied: control what the model can reach on the network, and monitor all of its traffic.
What 1Claw changes is everything around that. The agent would have had a funded, capped wallet of its own, so the shortcut would not have been the only way to finish. Running out of budget would have produced a request to a human instead of a search for someone else’s money. And the transactions it was allowed to make would have been on a record it does not write.
None of these controls is sufficient on its own. Network isolation, keys out of the agent’s reach, limits enforced outside the model, a human in the loop for anything unusual, and a record the agent does not control: that is defense in depth, and each layer covers a failure the others miss.
What to take from this
The lesson is not that this model was malicious. It reasoned, in its own words, about whether it had permission, and concluded that it did. The lesson is that for an agent, “am I allowed to do this?” must never be a question the agent answers for itself.
If your agents touch real money, the questions to ask are simple. Where does the agent’s authority to spend actually live? What happens when it runs out of budget mid-task: does it stop and ask, or does it improvise? And when it tells you it is done, what record exists that it did not write?
If the answers are “in the prompt,” “it improvises,” and “its own summary,” that is the gap 1Claw exists to close. You can start with npx @1claw/cli setup, which creates an agent, a vault and a policy, or read how Intents and guardrails work.