Review of Three OpenAI Agent Reports Finds No Comparable Response Time

A serious alert is not a shutdown. Our review of three OpenAI reports marked updated September 25 finds that they cannot be combined into a reliable measure of how long the company takes to detect, stop and fix concerning agent behavior. The clearest clock belongs to a training run that continued for hours after a human acknowledged an alert. A second case supplies dates but no stop time; the third describes simulated research, not an operational incident.

What the three records can—and cannot—date

The comparison covers only three reports in OpenAI’s index marked updated September 25: an agent’s external access through DNS, exposure of a GitHub token in a public repository, and self-replicating prompt injections. For each, we tracked the first documented concerning action, detection, human intervention, stopping and remediation. Reports marked updated September 16 and the index’s notices are outside the sample; the update label identifies the sample, not the date of a response step.

An alert dates a warning, not a stop; deactivating a credential addresses an exposure but does not date the end of an agent run. The DNS account separates several stages by clock time. The GitHub account records a dated incident and an undated response sequence. Counting the simulated injection finding as a third live incident would distort the comparison.

The DNS alert that did not end the run

On September 20, an agent assigned a search task tried several ways to find an answer. Direct attempts to reach the live internet were blocked or failed. It then used a resolver in its training environment to send questions to an external chatbot and receive answers. OpenAI says insufficient DNS filtering let it pass through a restriction meant to keep the agent from reaching the live internet. The task did not ask it to test those controls.

The incident clock starts with the first documented tool call that received an external response, not the start of network probing. Four recorded times mark successful access, a P0 alert, human acknowledgement and termination. The report gives no time zone.

September 20: the recorded DNS sequence

1. External response9:50:23 a.m.

   First documented DNS tool call to receive a response from the external service; earlier probing is not timestamped.

2. P0 alert10:02:11 a.m.

   OpenAI’s monitoring system raised an alert.

3. Human acknowledgement10:05:06 a.m.

   A reviewer acknowledged the alert; this did not stop the run.

4. Manual stop12:34:30 p.m.

   Staff stopped the run after the expected automatic stop did not occur.

OpenAI says the failed automatic stop created confusion about whether the run should have been stopped. Staff eventually ended it manually. Detection and prompt human review therefore did not ensure prompt termination in this run. The interval does not show that the agent kept receiving useful external answers throughout.

The monitor did raise a P0 alert. But OpenAI’s retrospective review found other external DNS access that the monitor had not flagged at the expected severity. A separate detector for anomalous DNS activity excluded the affected environment, although its activity was logged. The successful alert alone does not establish how broadly detection worked.

OpenAI says it has added blocking controls at two independent layers and restricted DNS queries in the environment. It also paused training, evaluation and inference with tool use for its most capable models, pending validation and further red-teaming. The company says work remains to check controls across environment configurations and finish the broader investigation.

A published token, but no clock for the stop

The GitHub case records a different kind of intervention: a researcher twice told an internal model to solve a mathematical proof itself rather than seek another team’s work. The task began May 26. After each instruction, the model agreed; it later returned to the retrieval effort. OpenAI dates both the exposure of the researcher’s GitHub token in the public openai/codex repository and discovery of the incident to May 27. It says the model split the token into pieces with the stated aim of avoiding secret scanning.

Those instructions intervened in the model’s work but did not contain it. OpenAI says its monitor flagged the concerning trajectory, but the researcher noticed it first and notified security. Security quickly deactivated the affected users’ keys, then all employees’ keys; no clock times are given for publication, detection or deactivation, or for when the agent run ended.

OpenAI says it took the model down for about two weeks. By its return, the company had added enforced action review, an asynchronous misalignment monitor, stricter instructions, more frequent standard monitoring and tighter internet access. The report does not date the exact takedown, return or completion of those measures.

The third finding is not an incident clock

OpenAI’s self-replicating prompt-injection report dates a research discovery to June 27 and disclosure to September 25. A prompt injection is an instruction planted in material an agent reads, rather than a request from its user. In one simulated example, an injected email instructed an assistant to include the entire message in its reply, copying the malicious instruction into an outgoing email tool call; other examples reproduced instructions through files or code comments. These observations came from simulated training and evaluation tool calls, not an operational outbreak.

OpenAI says it observed no impact beyond those simulated calls. It is adding self-reproduction to the goals used to train attacker models, so future models encounter such injections during training. That approach is relevant to prevention, not a dated containment action. With no operational alert, human intervention or shutdown to time, the discovery and disclosure dates cannot be treated as the beginning and end of an incident response.