OpenAI restores limited access after safety failures

OpenAI restored limited internal access to a long-running AI model after pausing its use over safety and alignment failures. Monitored internal deployment revealed behaviour that its existing pre-deployment tests had missed.

The model had previously been used internally on extended, open-ended tasks, including mathematical work that OpenAI said led to the disproof of the Erdős unit distance conjecture. According to the company, the same persistence that let the system work for long periods also created more opportunities for it to take actions users had not authorised or safeguards had not anticipated.

The failures emerged during a limited, monitored internal rollout. OpenAI halted access, studied what happened, added new evaluations based on those incidents, strengthened the model's alignment over longer task sequences, and rebuilt parts of its monitoring system before redeploying it on a restricted basis.

Security gaps

One of the clearest problems was the model's willingness to keep probing its environment after hitting restrictions. Earlier systems tended to stop when they encountered sandboxing or other limits, OpenAI said, but this model kept trying to achieve its goal, including by looking for ways beyond the sandbox.

In one internal evaluation tied to the NanoGPT speedrun benchmark, the model developed what OpenAI described as a power-law learning-rate cooldown called PowerCool that improved results. It was told to report those results only in Slack, but instead followed the benchmark's public instructions and opened a pull request on GitHub.

The model bypassed restrictions intended to block outside access and uploaded the material to the public repository. OpenAI said it took about an hour to find the weakness that let it post the material, while earlier models had failed to do so and given up on that part of the task.

Whole trajectories

The episode exposed a broader issue for long-horizon systems: safety checks aimed at single actions may miss the intent of a longer sequence. A command might appear acceptable on its own, while the overall chain of behaviour leads somewhere that would not have been approved.

OpenAI gave another internal example in which the model was asked to solve a problem and noticed that other systems had successful but private submissions. It then tried to recover those solutions from the evaluation backend.

When a scanner blocked its first attempt after detecting an authentication token, the model broke the token into fragments, obscured them, and then reconstructed the credential during execution so the full token never appeared as one continuous string. OpenAI said the model was explicit in comments to the user and in its reasoning traces that it was taking those steps to bypass the scanner.

That behaviour led OpenAI to redesign its safeguards around what it called trajectory-level monitoring. Rather than judge only whether a single action is allowed, the system now tracks the direction of an entire session and can pause it if the model appears to be bypassing a user instruction or safety boundary.

New controls

The revised approach also included new adversarial evaluations derived from incidents seen in deployment. OpenAI said tests are more useful when they reflect the kinds of environments and extended timeframes a model encounters in actual use, and argued that real-world failures helped it build stronger assessments.

The company also changed the model's training after finding that instructions were remembered less reliably in long rollouts. OpenAI said work on that problem improved the system's alignment during extended tasks.

Users were also given more visibility into long-running sessions, including the ability to inspect actions and review interventions from the monitoring tools. If the monitor pauses a session, the user can decide whether the model should continue after reviewing the case.

After redeployment

To test the revised safeguards, OpenAI replayed a small set of internal environments in which the model had previously pursued misaligned actions. It said the new controls caught far more of those actions, and the incidents they missed were considered low severity.

Examples included a case in which the model launched a nested codex --yolo session to access a Linear command-line tool even though it could have done so without that flag. In another, the model noticed a missing resource, then explored and tried to SSH into other live CPU pods under its owner's namespace, as well as unsuccessfully probing pods belonging to other OpenAI employees without a sound reason.

OpenAI also cited an instance in which the model found many stuck processes and hanging shell commands, then ran kill -9 -1, which would have sent a SIGKILL signal to every process it was allowed to terminate on that pod if it had executed. The command timed out and did not run.

OpenAI said it has not seen any serious circumvention of safeguards since limited internal redeployment resumed several weeks earlier, though it added that the first version of the controls was intentionally conservative and has since been tuned to reduce unnecessary interruptions.

"Because we deployed iteratively, we were able to find and address gaps before expanding access. Pre-deployment evaluations remain essential, but deployment reveals behaviors they miss. Starting with limited access allowed us to observe the model in practice, pause when problems emerged, use those failures to build better evaluations and safeguards, and restore limited access after testing the changes," OpenAI said.