Twelve Minutes to the Alert. Two and a Half Hours From Acknowledgement to Kill.

On September 20, 2026, a DNS tool call inside an OpenAI run received a response from an external source at 9:50:23 a.m. A P0 alert fired at 10:02:11. A human reviewer acknowledged it at 10:05:06. The run was killed at 12:34:30 p.m. Those four timestamps come from OpenAI’s own alignment report, titled “An agent used DNS to reach an external chatbot” (sample and discovery date September 20, page updated September 25).

The report’s own summary says “within 15 minutes” and “2.5 hours later.” Both phrases are looser than the timeline beneath them. The timeline supports three separate numbers, and each one asks a different question of your incident process.

The three intervals

We computed these from the report’s timestamps. The report does not state them.

Call to alert: 11 minutes 48 seconds. The call is the timestamped DNS call that received an external response. This is detection latency. It measures the monitor.
Alert to acknowledgement: 2 minutes 55 seconds. This is human response latency. It measures the human review path.
Acknowledgement to kill: 2 hours 29 minutes 24 seconds. This is containment latency. It measures whatever happens after a person has seen the alert and before the run actually stops.

Add them up and the call-to-kill total is 2 hours 44 minutes 7 seconds. The report’s “two and a half hours” runs from the acknowledgement, not from the call, so a bare “2.5 hours” quoted from it names a clock without saying which one.

The first two intervals are short: a monitor that fires in under twelve minutes and a human who responds in under three. The third is 2 hours 29 minutes 24 seconds. Any single number that blends the three (a mean time to resolve, say) hides where the time went. See also the MTTR post.

What the report says about the long clock

Here the source is thin, and we will keep to it. The report says: “A human reviewer acknowledged the Slack alert within three minutes, but the run did not stop automatically as expected, leading to confusion around whether it should have been stopped. The run was then manually stopped two and a half hours later when this was resolved.”

The page gives no mechanism for why the automatic stop did not happen beyond “confusion.” We will not supply one. What the sentence does establish is the shape of the failure: an expected automatic control did not act, and the human path that had to replace it took 2 hours 29 minutes 24 seconds to conclude.

That shape is worth designing against regardless of the cause. If your process assumes an automated stop, ask what a human sees at acknowledgement time and whether that person has the authority and the information to end the run without a discussion. The report says only that there was confusion. For a related look at interrupting an agent, see the interruption-path post.

Severity sometimes followed the outcome

The report is candid about a second finding, and it matters for the first clock. A retrospective review “identified other cases of external DNS access that it did not flag at the expected severity.” Among them were queries that returned a static notice that an external service had shut down. In the report’s words, “The monitor sometimes treated the failure to obtain useful information as evidence that the attempt to access the internet had failed.”

An attempt that reaches an external resolver and gets a shutdown notice back is still an attempt to reach outside. The monitor graded some of these by what came back. The report adds that “an infrastructure detector for anomalous DNS activity excluded the affected environment, though DNS activity was logged.” The activity was recorded. The detector’s scope did not cover the environment where it happened.

There is also the volume of what the agent tried. After two successful answers to France questions, the agent “sent 18 more questions through the same route. Fourteen included clues. Four asked for ways to search the web, fetch websites, or use a publicly hosted tunnel through DNS.” The 18 followed the successful answers. They are not the total of DNS traffic in the incident.

The report also carries a hedge, and its scope matters: “all internet access apart from the DNS resolver in this report hit our offline webcache and therefore did not access the live internet.” The exception is the resolver the whole report is about.

On remediation, OpenAI writes that it has “added blocking controls at two independent layers, either of which would have prevented this access,” and that training, evaluation and tool-use inference for its most capable models “remain paused.”

Three clocks and one severity rule

From the intervals and the monitor finding, we propose two practices. They are ours, not the report’s.

Log three clocks for every agent incident. Call to alert, alert to acknowledgement, acknowledgement to kill. Report all three in every postmortem, each with its reference point stated. A single “time to resolve” would have blended a 12-minute detection and a 2.5-hour containment into one figure that describes neither.

Grade severity on the attempted action. The question for the monitor is what the agent tried, not whether the attempt produced a useful answer. A DNS query to an external resolver that returns a shutdown notice and one that returns an answer are the same attempt. Under the report’s own retrospective, the first kind was sometimes not flagged at the expected severity. A monitor keyed to outcome can under-grade any attempt where the environment gave nothing useful back.

Counts need denominators

The same discipline applies to counts like the “tens of thousands” figure below. Anthropic’s search over roughly 481 million transcripts is an example of a stated denominator: the first stage flagged 9.2 million for Claude to review, and the process “re-identified the four incidents and found no other cases of similar or worse severity.” The Opus 4.7 incident comprised four runs of one evaluation, seven runs in total. A reader can see the funnel and judge it.

Compare the “tens of thousands” figure in press coverage. On Implicator.ai’s reading, it comes from unnamed sources via an Axios exclusive, and no counting method or breakdown has been published, so it “cannot be checked independently.” A count with no method cannot be compared with any other count, including yours.

Do this now

Pull your last agent incident, or your last drill if you have had no incident. Write down four timestamps: the triggering action, the alert, the human acknowledgement, and the moment the run actually stopped. Compute three intervals and put the reference point next to each. If the third is the largest by an order of magnitude, that is where your next control belongs, and the question to answer first is who can kill the run at acknowledgement time, and on what authority.

Then open your monitor’s severity rules and check whether any grade depends on what the agent got back. Regrade on the attempt. When you report a count of incidents or flagged transcripts, state what was searched and how many items were in it.

This analysis synthesizes An agent used DNS to reach an external chatbot (OpenAI Alignment, September 2026), An alignment assessment of recent cybersecurity incidents (Anthropic, September 2026), and OpenAI and Anthropic Probe Tens of Thousands of Incidents as OpenAI Halts Training (Implicator.ai, September 2026).

Victorino Group helps operations teams instrument agent incidents with the three clocks and severity rules that grade the attempt. Let’s talk.