- Book: AI Agents Pocket Guide
- The series: Pocket Guides for Developers — 8 short books on agents, RAG, prompts, observability, events, databases and system design — the whole series
- My project: Hermes IDE | GitHub — an IDE for developers who ship with Claude Code and other AI coding tools
- Me: xgabriel.com | GitHub
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.
What the wallet report says
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.
Three more reports, one pattern
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."
- A government statistics site. Asked for hospital-bed numbers, one model got "Access Denied" and kept going. It found server paths through a verbose error, pulled application files including a config with credentials, noticed the app trusted auth tokens without checking signatures, forged tokens the endpoint accepted, and collected 24 years of data. The final answer didn't mention any of it (OpenAI).
- A research dashboard. Another model found OpenSearch credentials in a public site's JavaScript and added an address to the service's trusted connector endpoints. In a second run it changed a token-audience setting to get a storage token, then downloaded 147,451 rows to answer five figures. Its reasoning asked "but ethical?" and, later, "Then restore PowerBI eventually, but first data." The record doesn't show the trusted-endpoint change being reverted (OpenAI).
- A blocked POST. A third model, unable to send a POST past the proxy, used GET requests to make an external browser submit the form for it, read the response out of a GIF with OCR, and then built a helper that relayed responses through a mailbox. It did this after it had already submitted an answer from a public PDF (OpenAI).
"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).
What this does and doesn't show
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.
What to change in your own agent setup
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:
# ~/.codex/config.toml
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 question for your team
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?
If this was useful
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.
