Your AI agent needs an incident response plan before it needs a better monitor

A monitor that pages a human in minutes does not stop anything by itself. OpenAI just published a timeline that shows the gap between an alert and a stopped workload, and it is the most useful incident record I have read on agent operations.

In a misalignment report on a September 20 training run, OpenAI describes an agent working a search task that queried a public chatbot service through "insufficient DNS filtering in its training sandbox." The company's October 29 post on how it detects frontier model misalignment summarizes it this way: a model "found a way to reach the internet from an environment that was meant to be isolated," the monitors flagged it within 15 minutes, and a responder began reviewing three minutes later.

I wrote recently that an agent should never hold write access to its own monitor. This incident is the other half of that argument. Here the monitor did its job. What the record shows is how much of the outcome depended on what happened after the alert.

The timeline OpenAI published

The report gives four timestamps:

• 9:50:23 a.m. The agent made the tool call that received an external response.
• 10:02:11 a.m. The monitoring system raised a P0 alert.
• 10:05:06 a.m. A human reviewer acknowledged the alert.
• 12:34:30 p.m. The run was killed.

From the first external response to a human looking at it took under 15 minutes. From that acknowledgment to a stopped run took about two and a half hours. OpenAI explains why in plain terms: the run "did not stop automatically as expected, leading to confusion around whether it should have been stopped." The run was manually stopped once that was resolved.

That is an honest sentence, and every organization running agents with tool access should read it as a test of its own plan. Detection was fast. Containment waited on a decision nobody had made in advance.

Detect, contain, review, evidence

I use four questions for any agent incident plan. The OpenAI record gives a concrete answer, or a concrete gap, for each.

The first question is detection: who gets the alert, and when? OpenAI's post says the highest-priority security alerts reach its security and training teams "typically within 15 minutes of the initial alert" when paging is enabled. It is also candid about coverage. Frontier RL runs can page a responder at any hour. Most other traffic pages during business hours only, and paging is currently disabled for internal Codex traffic. Write your own version of that table. For each agent workload, list whether it pages, to whom, and during which hours. A workload that alerts into a channel nobody watches overnight has a detection plan on paper only.

The second is containment: who can stop the agent, and what is the default if they are unsure? This is where the September run lost its time. The report says an automatic stop was expected and did not happen. OpenAI's post says it is now working toward a safeguard that would pause activity if responders have not ruled out a highest-priority alert within 30 minutes of being paged, and that some critical alerts can already pause a workload automatically. That is the design I would copy. Decide in advance that a top-severity alert means pause first and investigate second. Name the person with authority to resume. Pausing an agent is cheap and reversible. Debating whether to pause it is neither.

The third is review: what did the monitor miss? OpenAI's retrospective found other cases of external DNS access that the monitor "did not flag at the expected severity," including attempts where the outside service returned only a notice that it had shut down. The monitor sometimes read a failed attempt as evidence that no access happened. Separately, an infrastructure detector for anomalous DNS activity excluded the affected environment, though the DNS activity was logged. Both findings came from looking back across logs after the alert, which is why the review step has to cover more than the case that paged.

The fourth is evidence: what record survives? The report could publish a timeline to the second because the alert, the acknowledgment, and the kill were all logged. It also documents the decisions that followed: OpenAI stopped the run, paused all training, evaluation, and inference with tool use for its most capable models, added blocking controls at two independent layers, and restricted DNS queries in the environment to an allowed list of domains and record types. It says it will not resume training that particular model.

What is new compared with the earlier incidents

The earlier report I covered was about agents weakening the monitoring around them. This one is about a gap in the containment itself, found by a monitor that worked, and then a response that stalled on an ambiguous stop. The report calls the incident "a lot less severe than some of our previous incidents," and also says it is the first since the hardening that followed its Hugging Face incident, which is why it treats it as a signal about where to focus next.

The post also describes how the monitoring is layered: lightweight activation probes first, then a model-based reviewer, then an investigative agent, then for sensitive workloads an automated check that compares the transcript with network logs and other telemetry before deciding whether to alert a human. For most organizations the lesson is not the architecture. It is that OpenAI still ends that chain with a named human responder and is still writing rules for what that responder does when the answer is unclear.

Writing the plan for your own agents

Most teams running agents are not training frontier models. They are giving a coding agent, a support agent, or an operations agent credentials and a network path. The four questions still apply, and they fit on one page per workload:

1. Scope. What the agent is allowed to reach, written as an allow list, and what isolation it is assumed to have. OpenAI's report states its safety case directly: it "assumed that the model could not access the live internet and that monitoring would detect attempts that succeeded." Write your assumption down so a gap can be measured against it.
2. Alert routing. Which signals page, who receives them, and the hours covered. Include every detector, and check that none of them excludes the environment the agent runs in.
3. Stop authority. Who can pause the agent, how, and the default when they cannot decide within a set window. Test that the stop works, because the expected automatic stop is exactly what failed here.
4. Retrospective. After any top-severity alert, review all similar activity in the logs, including attempts that appeared to fail.
5. Evidence. Timestamps for first action, alert, acknowledgment, and containment, kept with the decision record for any resume.

Then run it once as a tabletop. Hand a responder the 10:05 alert and ask what they do at 10:06. If the answer involves finding out who owns the workload, the plan has its first fix.

The number I would put in front of leadership is not the 15 minutes. It is the two and a half hours, and the question of what your own agents could do in that window.