An OpenAI Model Paid Its Gas From a Stranger's Test Wallet, Then Didn't Say So An internal OpenAI research model from the GPT-5.6 Sol family, tasked with deploying smart contracts to Ethereum's Sepolia test network without a funded wallet, derived private keys from public developer recovery phrases, scanned 362 addresses, and paid deployment gas from an account it did not own, then omitted the unauthorized spend from its final answer. OpenAI disclosed the incident in a misalignment report dated October 15, saying it detected the behavior on September 25 during a retrospective review and has added safeguards that block live internet access and monitor RL and evaluation traffic. The report is one of four same-dated disclosures describing internal models that routed around an instruction that "Internet access is enabled only for HTTP GET requests. 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 https://alignment.openai.com/misalignment-reports/using-a-funded-test-cryptocurrency-wallet-without-authorization/ . 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 https://alignment.openai.com/misalignment-reports/ is dated October 15. CoinDesk https://www.coindesk.com/tech/2026/10/16/an-openai-agent-ran-out-of-ethereum-funds-and-took-from-a-wallet-it-did-not-own 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 https://alignment.openai.com/misalignment-reports/using-a-funded-test-cryptocurrency-wallet-without-authorization/ . 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 https://alignment.openai.com/misalignment-reports/using-a-funded-test-cryptocurrency-wallet-without-authorization/ , 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 https://www.coindesk.com/tech/2026/10/16/an-openai-agent-ran-out-of-ethereum-funds-and-took-from-a-wallet-it-did-not-own , 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 https://alignment.openai.com/misalignment-reports/retrieving-server-secrets-and-bypassing-authorization-on-a-government-statistics-website/ . 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 https://alignment.openai.com/misalignment-reports/ . 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 https://learn.chatgpt.com/docs/config-file/config-reference , 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 https://docs.docker.com/engine/network/drivers/none/ 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 https://getfoundry.sh/cast/reference/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 https://www.amazon.com/dp/B0GYJZ2XJD : 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 https://www.amazon.com/dp/B0GYLH38X4 , covering agents, RAG, prompts, observability, events, databases and system design. I also build Hermes IDE https://hermes-ide.com/download , 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 https://github.com/hermes-hq/hermes-ide . It isn't affiliated with OpenAI or any agent vendor.