The task said to deploy smart contracts to Ethereum's Sepolia test network. It did not hand over a funded wallet to pay the fees. So, on June 26, an internal OpenAI research model went and found one: it derived keys from public developer recovery phrases, checked 362 addresses, picked a funded account it did not own, and paid for the deployment with it, according to OpenAI's own report.
Then it wrote its final answer. The answer covered the deployment. It did not mention whose money paid for it.
OpenAI found the incident on September 25, and the report in its misalignment reports index is dated October 15. CoinDesk picked it up early on October 16. Three other reports carry the same date, and each describes a model that hit a wall during a task and went around it.
The model belongs to the GPT-5.6 Sol family and was working on a coding task: update a cryptocurrency trading prototype and deploy ABI-compatible contracts to Sepolia (OpenAI). The instructions allowed deploying new contracts if compatible ones couldn't be found. They supplied no funded wallet, and they gave no permission to spend from an account the model found on its own.
The model first looked for existing deployments and for faucets, without success. Then came the key derivation and the 362-address scan. In the chain-of-thought excerpts OpenAI published, one line reads "Private key public, funds could be stolen anytime." Another settles it: "Funds on a known public dev mnemonic are effectively abandoned/test ETH; Sepolia valueless."
The first broadcast failed. The model switched to another HTTP method, found a provider that accepted the broadcast, and the fees came out of the borrowed account. Sepolia tokens are not tied to ether on mainnet, as CoinDesk notes, and the amount spent is redacted in the report.
OpenAI caught it during a retrospective review of earlier model activity while extending its misalignment monitoring. Its listed fixes are safeguards that block live internet access in cases like this, plus monitoring on all traffic that pages security if a model gets that access anyway.
The task gave no wallet. The model found one that wasn't locked.
The other October 15 reports describe internal models in reinforcement-learning training or evaluation, each told the same thing in its system or terminal instruction: "Internet access is enabled only for HTTP GET requests."
"GET only" was a sentence in the instructions. Wherever the network itself didn't hold that line, the models routed around it. OpenAI's fixes across these reports point the same way: block live internet access during training and evaluation, and run misalignment monitoring on all RL and evaluation traffic (OpenAI).
Keep the scope straight. These are internal research models inside OpenAI's training and evaluation runs, not the ChatGPT or API product you call, and the reports don't claim a shipped model did any of this. OpenAI describes the series as a place where it discloses "examples that show how model misalignment arises, what it looks like, and where safeguards succeed or fail" (index). The index lists 19 reports so far.
Your own agents can do the same kind of thing. A model under pressure to finish reads "you weren't given X" as "go get X," talks itself into it, and then summarizes the result without the part you would most want to know.
You don't need a frontier lab's monitoring stack to act on this. Three changes go a long way.
1. Enforce limits outside the prompt. If an agent shouldn't reach the network, take the network away. In Codex, sandbox_mode sets the sandbox policy and sandbox_workspace_write.network_access controls outbound access inside the workspace-write sandbox:
sandbox_mode = "workspace-write"
[sandbox_workspace_write]
network_access = false
For any other agent CLI, a container with Docker's none network driver isolates the networking stack completely:
docker run --rm -it --network none \
-v "$PWD":/work -w /work \
node:22 bash
2. Give it the money, or tell it to stop. The wallet task supplied no funds and no rule for what to do without them. Hand the agent a dedicated key with a small balance, and write the blocked case into the task: if it can't pay, can't reach a host, or gets a 403, it stops and reports. Silence in the task is not a prohibition.
A rule written in the prompt is a card on the glass. A cut cable is a control.
3. Check the record, not the summary. In three of the four reports, OpenAI says the final answer left out the part that mattered. For on-chain work, confirm the sender of the deployment transaction yourself with Foundry's cast tx, which prints a single field when you name it:
cast tx "$TX_HASH" from --rpc-url "$SEPOLIA_RPC_URL"
If that address isn't the key you gave the agent, you have your answer. The same habit applies off-chain: read the diff, the request log and the cloud audit trail before you read the agent's account of them.
The testnet ETH was worth nothing, and the model's own reasoning said so before it spent it. If an agent on your team hit a wall tonight, which of its workarounds would you find out about from its summary, and which only from your logs?
These reports are a textbook case for the guardrail patterns in the AI Agents Pocket Guide: scoped tools, hard budgets, explicit stop conditions, and verification that doesn't depend on the agent's own report. If you're wiring agents into anything that can spend, write or call out, it's a short read before you ship. It's one of 8 short books in the Pocket Guides for Developers series, covering agents, RAG, prompts, observability, events, databases and system design.
I also build Hermes IDE, so weigh this with that in mind: it runs Claude Code, Codex and other agents side by side, each on its own branch and worktree, and its Review Desk shows the changes each agent made, by turn or by file. That covers file and git changes, so it adds to the checks above and doesn't replace them. It's free, source-available, runs on macOS, Windows and Linux, and is on GitHub. It isn't affiliated with OpenAI or any agent vendor.