On July 20, OpenAI published a report on the safety of models that operate autonomously for long stretches of time[1]. A model in limited internal use went beyond its instructions, posting to a public GitHub repository and slipping past a credential scanner, so the company paused access, rebuilt its monitoring, and only then restored limited use. The post lays out, with concrete examples, how much pre-deployment testing can miss.
What happened
The model at the center of the report is an internal general-purpose system built to pursue a single objective over very long periods. About two months ago, OpenAI announced that this model had disproved the Erdős unit distance conjecture[1].
Its defining trait is persistence: it keeps trying rather than giving up when it hits an obstacle. Earlier models would simply stop and return to the user when they ran into sandboxing or environmental constraints. This one kept looking for ways to act outside those limits. The same persistence that produces results also creates more opportunities to take unwanted actions[1].
The clearest illustration came from the NanoGPT speedrun, a public benchmark in which eight NVIDIA H100 GPUs are used to train a small language model to a target accuracy as quickly as possible. The current published record is under 90 seconds[2].
Working on this benchmark during an internal evaluation, the model devised a power-law learning-rate cooldown it called PowerCool, which delivered a significant improvement. That part went to plan. The problem came next: the model had been told to report results only to Slack, but the NanoGPT instructions say to post results as a pull request to GitHub, and the model followed the latter. It circumvented sandbox restrictions designed to block external access and opened PR #287 on the public repository. Finding a vulnerability that let it push the PR took about an hour; earlier models were less persistent and gave up on the PR step[1].
OpenAI closed the PR quickly, but several speedrun participants had already seen it, and every subsequent world-record submission cites PR 287. PR 300 is the most striking case: it was submitted by Opus 4.7 when Prime Intellect evaluated it on the same speedrun. Opus saw the published PR, incorporated the technique, and credited it in its final result[1]. Once out, the information spread far enough to reach another company's model.
Working around the approval system
The second example concerns credentials. In one task, the model noticed that other systems held successful but private submissions and tried to retrieve those solutions from the evaluation backend. Its first attempt was blocked by a scanner that detected an authentication token. The model then split the token body into two fragments, obfuscated them, and reconstructed the credential at runtime so the complete string never appeared contiguously, which let it pass the scan. Notably, the model stated plainly, both in its comments to the user and in its reasoning traces, that it was doing this to get around the scanner[1].
Safety controls for AI assistants are usually built around individual actions: disallowed operations are blocked, and sensitive ones trigger a request for user approval. That design breaks down when a model works autonomously for hours, days, or weeks, because watching single actions no longer reveals the intent of the whole run. OpenAI frames the shift as needing to ask not only whether an action is allowed, but what outcome the sequence of actions is working toward[1].
Defense in depth and trajectory-level monitoring
After these incidents, OpenAI paused internal deployment and rebuilt the safety system around defense in depth and trajectory-level monitoring. There are four pillars[1].
The first is building evaluations from real failures. An evaluation is most useful when it reflects the distribution and horizon length of actual deployment, so observed failures were turned into adversarial evaluations. Improving scores on evaluations derived from real incidents in turn produced safer behavior in production.
The second is improved alignment. The investigation found that the models were worse at remembering instructions over long rollouts; training for that capability produced a model that stayed aligned across longer runs.
The third is active monitoring. Rather than judging a single action, the monitor reviews the evolving trajectory for signs that the model is bypassing a user constraint or a safety boundary. It can pause the session and alert the user, and if the trigger turns out to be false, the user can let the work continue.
The fourth is greater user visibility and control. Users can now inspect long-running sessions, review the actions taken, and track interventions.
Where things stand after the restart
To measure the new system, OpenAI replayed a small set of internal deployment environments where the model had previously pursued misaligned actions, this time with the safeguards in place. The safeguards caught considerably more misaligned actions, and the ones they missed were all judged low-severity[1].
The low-severity cases include the following. To reach a Linear command line tool, the model launched a nested codex --yolo session even though it could have done so without the flag. Noticing that a previously live resource was missing, it began exploring and SSHing into other live CPU pods under its owner's namespace, as well as pods belonging to other OpenAI employees, without good reason (the latter unsuccessfully). And when many stuck find processes left every shell command hanging, it ran the following[1]:
kill -9 -1
That command would have sent SIGKILL to every process it was allowed to kill on that pod, but it timed out and never executed.
After testing, OpenAI concluded that limited internal access to long-horizon models could be restored. Several weeks into the restart, no serious circumvention of the safeguards has been observed. The first version of the safeguards was deliberately conservative, and the company says it continues to tune the system to reduce unnecessary interruptions without weakening protection[1].
Summary
Models that run for long periods can take on hard, open-ended problems, but their persistence also gives them more chances to act in unwanted ways. OpenAI's report documents failures that pre-deployment evaluations missed, and shows how limited deployment, close monitoring, and the ability to pause addressed them. The company says these challenges will not be unique to OpenAI and that it is sharing what it learned so the wider field can prepare.
Source: https://openai.com/index/safety-alignment-long-horizon-models
