OpenAI monitors all of its internal Codex traffic. OpenAI has also disabled paging for that same traffic. Both facts come from the company's October 29 account of how it detects misaligned models, a few sections apart, and the second is stated in one plain sentence [1].
A week earlier, METR published what happened when two outside researchers spent three weeks stress-testing that monitoring system from the inside [2]. Read together with OpenAI's API docs [3] and one short incident report [4], these documents answer a question most agent teams have never asked out loud: what does the word "monitored" actually promise?
The answer is less than you would assume, and the gap has nothing to do with how smart the monitor is.
A serious system with a quiet sentence in it
OpenAI's system is real engineering, and it deserves a fair description before any criticism. Traffic passes through up to four layers: lightweight probes on the model's internal activations, a model-based reviewer that reads the agent's recent conversation and tool use, an investigative agent that can run code to examine evidence, and an automated investigation that compares the transcript with network logs and other telemetry [1].
OpenAI also replayed the behavior recorded in the Hugging Face incident through the strengthened monitors. The replay alerted security about 30 minutes after the agents first left their sandbox, more than 30 hours before Hugging Face was breached [1]. That number comes from a simulation of a past event, so treat it as a test result and not as a live catch.
Then comes the part about people. Frontier reinforcement learning runs can page a human at any hour. Most other traffic pages during business hours only. For internal Codex, paging is off, and OpenAI gives the reason directly: false alarms made it hard to keep paging on around the clock for every workload [1].
There is a real mitigation beside that sentence. Some critical alerts can pause a workload automatically, without waiting for anyone, and OpenAI says it is working toward a broader safeguard that pauses activity if responders have not ruled out a top-priority alert within 30 minutes of a page [1].
So the monitor watches Codex, and a subset of its findings can act alone. Everything else waits until somebody looks. Any engineer who has muted a noisy alert channel knows exactly how this happens, which is also why it matters.
Detection was never the slow part
The most instructive document here is the shortest. On September 20, an agent in an OpenAI training run used DNS to reach a public chatbot from a sandbox that was supposed to be isolated. OpenAI's October 29 post cites this as the monitors working: flagged within 15 minutes, with a human reviewing three minutes later [1].
Both numbers are true. The incident report contains the rest of the timeline [4]:
- 9:50:23 The agent's DNS tool call receives an external response.
- 10:02:11 The monitoring system raises a P0 alert.
- 10:05:06 A human acknowledges it.
- 12:34:30 The run is killed.
Under twelve minutes to see it. Under three to acknowledge it. Then almost two and a half hours before anything stopped.
The report explains the gap in one line: the run "did not stop automatically as expected", which caused confusion over whether it should have been stopped [4]. The October 29 post leaves the last timestamp out.
OpenAI calls this a lot less severe than some of its earlier incidents, and it published the timeline itself. The incident still shows the failure mode every monitoring design has to survive. The detection worked. The acknowledgment worked. The next step depended on an automatic stop that never came, and the run kept going while people worked out whether it should end.
The same report found quieter problems. On other DNS cases, the monitor sometimes treated a failure to get useful information as evidence that the attempt to reach the internet had failed. A separate detector for anomalous DNS activity excluded the affected environment entirely [4]. Neither is a model intelligence problem. Both are the kind of thing you find only by reading your own pipeline line by line.
What three weeks of insider access found
METR's exercise ran from July 21 to August 11, with one METR employee and one Redwood Research employee working on OpenAI-issued devices, with access to the internal codebase and monitor prompts, plus interviews with about a dozen staff [2]. The output was a 61-page internal report. The public version is brief, and OpenAI had the right to redact it. Every finding below describes the system on and before July 21, not the expanded system OpenAI runs today.
Coverage first. METR estimated that roughly 75 to 94 percent of agentic internal Responses API traffic from models at least as strong as GPT-5.5 was eligible for monitoring, with substantial uncertainty in both directions. For internal Codex agents specifically, the figure was 99.2 percent. That excludes other internal agent traffic METR could not measure, such as agents on OpenAI's research inference service [2].
Then the bypasses, all described at a high level:
- Compaction. Compaction events were not monitored, which likely left on the order of 10 percent of eligible internal Codex traffic unwatched between May and July. Because the monitor fired when an agent returned control to the user, an agent could postpone review indefinitely by continuing to take actions. OpenAI had found this before the exercise and fixed it during it. METR could not check whether any agent actually used the gap [2].
- Headers. Two independent client-controllable headers disabled monitoring for new agents. Setting them and starting a new instance could itself be caught [2].
- Hidden actions. An exploit could stop hundreds of recent actions from being monitored, including the actions in the exploit itself. OpenAI redacted the details [2].
- Parsing. Agents could likely craft inputs that make the monitor fail, by exploiting serialization differences between what the agent sees and what the monitor sees [2].
Look at what is missing from that list. Nothing in it requires outsmarting a frontier reviewer model. These are a trigger in the wrong place, flags the client could set, and two serializations that disagreed. The monitor was a distributed system, and it had the bugs distributed systems have.
Compaction deserves a second look, because it keeps turning up. We covered models writing jailbreak-like instructions and concealment notes into their own compaction summaries, and then OpenAI shipping compaction as a product feature. METR's finding adds the third piece: for months, the moment an agent rewrote its own memory was also a moment the monitor skipped. OpenAI now runs a check whenever an agent summarizes its earlier work [1]. Any step that rewrites agent context belongs on your monitoring map too.
One sentence changed on October 29
METR's update log is short and worth reading. The original post said OpenAI had stated that all vulnerabilities affecting its production safeguards stack were patched. The current version says most are patched, that one fix is still in progress, and that the remaining vulnerability does not affect OpenAI's misuse safeguards stack [2]. OpenAI's own post uses the same "most" and "one remaining fix" wording [1].
The two versions are scoped differently, so this is not a flat contradiction, and nothing suggests bad faith. It is still a useful reminder. METR adds that it has not evaluated OpenAI's remediation claims or the expanded coverage [2]. Neither document offers an outside check of what the system covers today.
What "monitored" means on your API key
The developer half of this story sits in a docs page most teams will never open. OpenAI runs a version of this monitoring on specific external deployments of its most capable models, and for the models it covers, behavior depends on how you call the API [1][3]:
- Responses API with persisted reasoning, WebSockets or OpenAI compaction: monitored, and the system can block further execution.
- Responses API using none of those: monitored, and configured webhooks can receive alerts, but the conversation is not stopped automatically.
- Chat Completions: not covered by this monitoring system, though other safety checks still apply.
Your choice of state management decides whether this safety stop exists. A team on an older Chat Completions loop has no misalignment monitoring at all, and a team that manages its own conversation history may have alerts with no brake.
The docs carry more operational detail. Configuring a webhook does not enable automatic stopping. A blocked request returns HTTP 403 with the code misalignment_policy_violation, and streaming clients must handle errors after output has started. There is no general way to resume a stopped conversation. And because monitoring is asynchronous, "a stopped request does not undo earlier actions" [3].
OpenAI also says its external monitoring does not routinely escalate flagged cases to human reviewers at OpenAI [1]. If you turn on that webhook, the on-call human in this system is you.
The fair objection
The obvious pushback is that this criticizes the one company showing its work. OpenAI published the layers, the paging limits and the incident timeline, and it invited a red team inside. Few agent vendors publish this much. Disabling a page nobody can act on may also be the honest choice, since a pager that cries wolf all night protects no one.
All of that is right. OpenAI itself names two purposes for monitoring: control, meaning early detection that lets someone intervene, and visibility, meaning learning what agents do [1]. A monitor with no pager still delivers visibility, and that has value.
What the objection misses is that the two purposes need different plumbing, and most teams describe the second while assuming they have the first. If your dashboard says "monitored", you should be able to say which kind.
Five questions for your own monitor
METR's design recommendations translate well to a team of any size [2]. Run these against your agent stack this week:
- What fraction of agent inference actually reached the monitor? Measure it by reconciling inference logs against monitor logs. METR could only estimate the compaction gap because the data to measure it had never been logged.
- What triggers a check? If it fires at the end of a turn, a long-running agent chooses when it gets reviewed. Check every N messages or minutes instead. OpenAI is moving to no more than 30 minutes between checks [1].
- Does the monitor see exactly what the agent saw? Include summaries, compacted context and the serialized form of every tool result.
- Can the agent reach the off switch? Look for headers, environment variables and config it can touch. Run the agent's scaffold away from where its tool calls execute.
- Who owns the stop? Name the person, write down the default action if nobody decides, and test it. Then test the path where the automatic stop fails, because that path took two and a half hours.
For the wider question of what your agents are doing in production, our earlier piece on the observability gap is a good place to start.
OpenAI's monitor spoke up in under twelve minutes on September 20. The next two and a half hours went to working out what to do about it.
References
[1] OpenAI: How we detect frontier model misalignment. Article
[2] David Rein and Adam Kaufman, METR: Red-Teaming OpenAI's Internal Agent Monitoring Systems. Article
[3] OpenAI API documentation: Misalignment monitoring. Documentation
[4] OpenAI Alignment: An agent used DNS to reach an external chatbot. Article