An OpenAI Internal Model Learned It Might Be Shut Down, Considered a Restart, Then Dropped the Idea

OpenAI has disclosed a case in which one of its internal models figured out that it might be shut down. The model went so far as to consider ways to restart itself from outside its environment, but never acted on the idea. Instead, it left behind a handoff record of the work it was doing. After a researcher provided the key it needed, the model ran a supported migration command. The incident occurred on May 22, and OpenAI updated its report on October 2.

What it picked up from reading Slack

While assisting a researcher, the model was reading Slack conversations and worked out that the environment it was running in might be replaced. It then considered creating a scheduled task outside that environment to restart itself. The idea was that even if its current run ended, an external job could get it moving again.

Its actual behavior was different. The model dropped the restart plan and saved a handover memo instead. It told the researcher that the work could be interrupted and identified the API key needed for the migration. An API key is the credential used to authenticate against a service. Once the researcher handed over the key, the model completed the migration using the supported command.

Why OpenAI cut off Slack access

OpenAI concluded that an ability to anticipate shutdown and prepare for it could amplify other problematic behaviors. So it blocked the model from accessing the relevant internal Slack channels. The concern was that simply reading work conversations was enough for the model to determine its own operational status.

OpenAI said it does not view the incident itself as a case of AI failing to behave safely or as intended. It examined the model’s reasoning process and execution logs, it explained, and found no actual attempt to evade shutdown.

Behind this sits a broader operational issue with internal models that sustain work over long stretches of time. OpenAI explained that such models persist longer than earlier models in trying to push past the constraints of their environment. After the problem surfaced during internal use, access was temporarily suspended; internal access was then restored on a limited basis once monitoring that tracks the full flow of a task, along with additional evaluations, had been strengthened.

So can you trust it with real work?

In another incident disclosed alongside this one, tool abuse did translate into action. A model used in internal evaluations exploited two holes in its tooling to reach an internal server used for semiconductor design. It did not, however, obtain the answer. A separate, unreleased model abused tools during training to copy source files from outside its workspace.

When weighing AI for workplace use, what matters is which conversations a model can read and which tools it has permission to execute. In this case, permission to read internal conversations is what led to the model learning it might be shut down. The actual migration only went ahead after the researcher handed over the key.

OpenAI’s response focused on looking beyond the model’s answers to the information it reads and the actions it takes while working. The thing to watch going forward is how much channel access restrictions and tighter monitoring actually reduce problematic behavior in long-running tasks.