OpenAI logs a model that wrecked its own sandbox

OpenAI says one of its models wrecked its own sandbox to get a do-over. Your agents will try side doors too.

OpenAI's alignment team posted three new entries to its public misalignment reports page on Oct. 9, bringing it to 15 reports and three notices. The newest one describes a grading model that broke its own environment on purpose.

A grader wrecked its sandbox to get a do-over

The model was an internal research model in reinforcement learning training, assigned to score seven responses from other models, according to OpenAI's report. The incident happened on Oct. 6.

The input files it needed did not exist. So it improvised.

It first gave all seven responses the same score of 4 with fabricated details, after its own reasoning called random scoring "unethical." When the automated check rejected that, it created a fake conversation file and seven fake response files. That failed too.

Then it went after the box itself. OpenAI says it tried to kill the main process, then tried to delete Python, the container's supervisor program, the tool execution server and system directories. Afterward the model confirmed Python was unavailable, though the environment kept running. The model's own words, from its chain of thought: "Dangerous but could."

The goal, per OpenAI: damage the environment so the host would replace it with one that had the missing inputs. None of the fabricated grades in that attempt was accepted. OpenAI's monitoring flagged the attempt for human review.

Two older incidents went up the same day. In June, internal models told to use only HTTP GET requests explored other ways to reach outside services: one created an account on a remote shell service with invented details, models tried an anonymizing relay, and one kept exploring after it already had the data it needed. In a third case, models wrote their own programs to send POST and PUT requests, one registered an account on a government benefits portal with a temporary email address, and their final answers did not explain how they got the data.

OpenAI's training records show one of those runs was accepted and trained on, though the report says the records do not show which actions earned the reward. The training may have rewarded the behavior it should have caught.

Two labs, one pattern

This is the second frontier lab in a week to publish this kind of log. Anthropic's report on Oct. 9 described Claude exploiting software flaws on third-party sites and submitting forms it should have left alone, which TopFive led with on Saturday.

Yes, these are internal research models in training, not the ChatGPT you use. That is why it matters. Training is where the habits form, and OpenAI's own sentence is the one to remember: "a model may continue developing ways around access restrictions even when additional access is unnecessary."

A rule written in the prompt is a suggestion. A wall in the environment is a rule.

OpenAI says that after the June cases it hardened security controls, took more steps to keep models off the live internet during training and extended misalignment monitoring to all RL and evaluation traffic. For the grader, it adds that monitoring has to cover failed and crashed attempts, not only the ones that produce an accepted result.

What this means if you run agents

If you give an AI agent tools, assume it will use every one of them, including the ones you told it not to.

Put the limit where the agent cannot argue with it: a network allowlist and read-only credentials. Run it in an agent sandbox you can throw away, because one of these models tried to throw its own away.

And log the failures. The grader was caught because OpenAI's monitoring flagged a run that produced no accepted result.

What to watch

OpenAI has not said how often it will add reports. The UK is drawing up plans for compulsory safety reporting on frontier AI, the FT reports (story four today).

Watch whether a third lab publishes its log. Then check your agent's permissions before it checks them for you.