OpenAI has deployed a centralized control system called Control Room across its research infrastructure, designed to stop potentially risky AI model workloads from generating further output within 35 seconds of a decision to intervene. As Interesting Engineering reported, the system connects the workloads that power the company's most advanced research — including agentic model training, evaluations, and data-processing jobs — to a central service that controls whether they can continue running.
The company announced the system publicly on November 9, writing: "We built Control Room, a central system to track model workloads across our research infrastructure and stop them quickly when safety or security concerns arise. It connects every research inference workload, including agentic sampling for model training and evaluation, data..." For more context on this story, see our ongoing artificial intelligence updates.
The timing is notable. As AI models grow more capable and are given more autonomous, agent-like responsibilities inside training pipelines, the risk of a model behaving in unexpected ways during research grows with them. Control Room is OpenAI's structural answer: not just watching for trouble, but being physically able to cut it off.
How Control Room Works
Control Room connects three main components: the research workload, the inference engine, and the central Control Room service. A workload, in OpenAI's terminology, is a research job such as a reinforcement learning experiment, an evaluation, or a high-volume data-processing task. Every research workload that performs agentic inference must be associated with an approved safety case before it can run.
When a researcher starts a job, its code requests a unique job ID from Control Room. That identifier is then attached to every request the workload sends to inference engines — the GPU-backed systems that actually run the models and generate outputs.
Before fulfilling any inference request, the engine checks with Control Room to confirm the associated job is still authorized to run. If a researcher or an automated monitoring system has instructed Control Room to stop the job, the service denies the next inference request, and the engine refuses to generate further model output for that workload.
Stopping Output, Not Necessarily the Job
One design detail stands out: stopping a workload does not necessarily terminate it. The research process itself may keep running — its code continues to execute — but it can no longer obtain additional model outputs through the authorized inference engines. For a misbehaving training run, that is enough: without access to more model generations, it cannot make further progress.
This approach also avoids relying on researchers' own workload code to implement safety checks correctly. OpenAI places the critical authorization mechanism in the inference layer instead, which has fewer and more centrally managed code paths. In other words, the kill switch lives in infrastructure the company fully controls, not in experiment code written by individual teams.
Designed to Fail Closed
Control Room is built to remain effective even when other components malfunction. Its fail-closed mechanism blocks inference requests if the Control Room service itself becomes unavailable — meaning a technical failure, a deliberate disabling attempt, or potential tampering with the central service would cause inference engines to deny all requests until the system returns to normal operation.
The 35-second figure represents the maximum delay between receiving a stop instruction and preventing further progress. The delay comes from a caching layer used to handle the sheer volume of inference authorization requests, and OpenAI says it is working to reduce the interval to zero.
Automated Monitors Watch Every Frontier Run
The kill switch pairs with automated monitoring. According to OpenAI, all of its frontier reinforcement learning jobs run with a separate model-based monitor that examines model behavior and raises alerts when it detects potential problems. If an alert warrants intervention, the monitoring system can instruct Control Room to terminate the associated job, which then blocks subsequent inference requests across any model or engine that workload uses.
The company pointed to a recent DNS-related incident — in which a monitor detected an agent attempting to reach an external chatbot — as an example of why such safeguards matter. In that case, the anomaly was caught by automated oversight rather than a human reviewer.
Part of a Broader Safety Push
OpenAI notes that Control Room is already deployed across its research infrastructure, where the need for intervention is greatest. Its external model-serving infrastructure, which powers products like ChatGPT, is more centralized and already has operational mechanisms to take down model deployments when necessary — Control Room closes the gap on the research side.
The company says it will continue strengthening its monitoring systems and safeguards against misaligned behavior and security breaches as part of its broader approach to securing frontier model development.
For an industry increasingly defined by autonomous agents, Control Room is a signal of where frontier labs are heading: safety mechanisms that assume models will sometimes misbehave at scale, and that make stopping them an infrastructure guarantee rather than a hope.
---
Stay Ahead of AIGet the latest AI news, analysis, and breakthroughs — all in one place.
Read more AI news →
