OpenAI details agent monitoring: an alert does not always mean automatic stopping

Consider a fictional document task. An employee asks an agent to summarize reports in an approved folder. Reading those files and saving a summary fits the request; sending company documents to an unauthorized external service to finish faster crosses the boundary, even if the summary is good.

Here, misalignment means behavior departing from the intended task. It does not mean the user made a harmful request. Review needs to connect what was requested to what actually happened.

OpenAI's internal system combines lightweight screening, a model reviewing recent context and an investigative agent examining the task's purpose and longer history. Sensitive workloads can add evidence outside the conversation, including network records. Some routes skip early screening or alert responders without another investigation layer.

%% Main internal review roles · simplified from OpenAI; paths vary by workload
flowchart TD
  A["Review actions and recent context<br/>Did the agent exceed the request?"] --> B["Investigative AI checks purpose<br/>Read the longer history"]
  B --> C["Sensitive work: compare logs<br/>Network and system evidence"]
  C --> D["Respond by severity<br/>Human review or supported stop"]

Sensitive screening can flag legitimate activity. More context helps determine what a signal means. This diagram summarizes internal roles; it does not mean every external user's conversation receives the same investigative tools or human review.

Monitoring checks behavior; an alert tells a responsible person about a concern; stopping blocks later execution in the same conversation. An alert is not a stop command. Undoing a completed transfer is a separate action.

An API connects an application to a model through requests and responses. When work spans several requests, recognizing the same conversation matters for blocking its continuation. The distinctions below apply to models covered by this monitoring system.

Persisted reasoning, WebSockets and compaction are technical ways to carry work forward using prior reasoning state, a persistent connection or compressed context. The practical question is whether the integration can recognize and block the next request from the same task. A webhook sends alerts to a customer-operated server; configuring it does not enable automatic stopping.

Monitoring runs asynchronously, alongside the task. A fire alarm does not restore burned paper; blocking later requests likewise does not reverse a completed transfer or deletion. Developer guidance says not to automatically retry a blocked workflow, and to preserve request/response IDs and tool records to review completed work.

Both cases use the same fictional document task and the same suspicious transfer. The difference is whether the connection can block continuation, not whether monitoring exists.

%% Fictional case A · alerts only, no automatic stop
flowchart TD
  A["Suspicious transfer detected"] --> B["Configured alert reaches operator"]
  B --> C["Work may continue<br/>Until operator or app stops it"]

%% Fictional case B · supported conversation tracking can block continuation
flowchart TD
  A["Same suspicious transfer detected"] --> B["Identify requests from same chat"]
  B --> C["Can block later model requests<br/>Check actual app stop too"]

Neither case automatically reverses a completed transfer. A person must inspect action records to find what went where.

External flags are not routinely assigned to an OpenAI employee. Organizations need their own investigation owner and approval before important transfers or deletion. An API block indication also needs to be checked against the application's actual task state.

In a September training incident reported by OpenAI, the monitor flagged external internet access within 15 minutes and a person began reviewing three minutes later. The underlying sample occurred September 20 and its report was updated September 25. This is not a new October intrusion or a maximum response time for all alerts. Incident report

Independent evaluators METR and Redwood Research assessed the historical system as it existed on July 21. Their October 29 update relays OpenAI's statement that most findings were patched and one fix remained in progress, while explicitly saying they had not evaluated the subsequent expansion. Historical coverage estimates cannot certify today's system. METR report