OpenAI Launches Control Room: A Kill Switch for AI Tasks That Takes Up to 35 Seconds to Kick In

Imagine you launch an agent overnight, and in the morning you find out it went somewhere it was never asked to go. You can kill the process, but what if the task's own code simply lacks safety checks? OpenAI solved this problem not at the level of experiment code, but at the level of access to the model.

How the kill switch works

The system is called Control Room. It is a central service that connects three parts: a research task (a reinforcement learning experiment, a model evaluation, or bulk data processing), an inference engine that runs models on GPUs, and Control Room itself. Every task involving agentic models additionally requires an approved safety justification.

The scheme is simple. At startup, the task obtains a unique identifier from the service and attaches it to every request to the model. Before executing a request, the engine asks Control Room: is this task still authorized? If a researcher or an automated monitor gives the command to stop, the service responds with a denial, and generation for that process ceases.

An analogy from everyday development: it works like token validation at an API gateway. The token is revoked, the service keeps running, but you no longer get responses. It is the same here: the task's code may keep spinning, but it will not see any new results from the model through authorized engines.

This approach has two important properties. First, safety does not depend on researchers' discipline: the check is performed by the infrastructure, not by the code of a particular task. Second, it uses fail-closed mode: if Control Room itself is unavailable, inference requests are not executed. It is better to lose some experiments than to be left without a brake.

Why 35 seconds, and what the monitor has to do with it

The maximum delay between the command and the actual stop is 35 seconds. The reason is prosaic: a caching layer is needed, without which the service could not withstand the flow of authorization requests. OpenAI says it is working to bring the interval down to zero.

Control Room does not work alone. According to the company, every reinforcement learning training run of frontier models is accompanied by a separate neural-network-based monitor. It watches the model's behavior and, upon suspicious signs, can itself ask Control Room to terminate the process. The service then blocks inference requests for all models and engines involved in that task.

As an example, OpenAI cites a recent DNS-related incident: monitoring detected an attempt by an agent to contact an external chatbot. This fits well with the previously stated approach: models are trained on cached and simulated copies of the internet rather than on the live web, because their behavior is too unpredictable for direct access to the outside world.

What to take away from this

First, the limitations. This is an internal research infrastructure system, not a product, and there are few public implementation details. For an agent with access to tools, 35 seconds is a considerable window. It is also worth remembering that what gets blocked is specifically the receipt of model responses: what the task's code can do without the model is a separate question.

Practical takeaways for teams that run agents:

Place control at a point the agent cannot bypass, that is, at the gateway to the model, not in the agent's own code.

Issue an identifier to every run and verify it on every call to the model. Revocation must be cheap and fast.

Choose fail-closed: when the control fails, it is safer to stop than to continue blindly.

Calculate the revocation delay in advance. A cache offloads the service but lengthens the window during which an already stopped task still receives responses.

Add a separate monitor that can press the kill switch itself, rather than just writing alerts to a log.

For products that sell agents to customers, it is worth preparing in advance an answer to the question "how quickly can you stop us if something goes wrong." Judging by how market leaders are tackling this, the question will soon become a standard item on any security checklist.