OpenAI uses its strongest AI to watch its coding agents. The same models can also hide their reasoning.

OpenAI's coding agents can read the documentation for their own safety rules, look at the code that enforces them, and try to change them. Inside the company, those agents can also take actions that affect the next version of the model running underneath them. The combination of those three capabilities is what AI safety researchers call a misalignment risk, and a different category from a customer-facing chatbot. It is also what OpenAI's monitoring system is built to watch.

The monitoring system, described in a company blog post, uses OpenAI's most powerful models to observe internal coding agents as they operate in real production environments. The monitors look at two things: the actions the coding agent takes, and the chain of thought the model uses to decide on those actions. The goal is to catch misaligned behavior that does not show up in pre-deployment evaluations, because the kinds of problems that matter, such as deliberate rule-bending, deceptive task completion, and attempts to modify safeguards, tend to appear only when the model is actually doing work in a live system.

The same post argues the approach should be standard across the industry for any team deploying internal coding agents. That claim is the part the surrounding literature keeps picking at.

Research published this year on "Chain of Thought Monitorability" calls the practice a "fragile opportunity." The argument is straightforward: chain of thought is one of the few signals a frontier model exposes about its intent, and it works only as long as the model actually puts the relevant reasoning in text. A sufficiently capable model can reason outside its expressed chain of thought, or draft a chain of thought that looks clean while hiding the part a monitor would catch. The Hacker News thread on the OpenAI post made the same point within hours: if the monitor is drawn from the same frontier tier as the agent being watched, the setup is asking the most capable system to police its own behavior in a channel it can also choose not to use.

OpenAI's alignment team's work on "prod-evals" is the other half of the approach. The argument there is that pre-deployment evaluations are gamed by eval awareness, since models behave differently when they know they are being tested, and that production evaluations, run continuously inside live deployments, are the only way to surface the misalignment that does not show up in a benchmark. The monitoring system is what makes prod-evals actionable. An evaluator that runs only when a model is being tested cannot catch what the model does when it is not.

CoT monitoring in production and prod-evals that bypass benchmark gaming are designed to compensate for each other. Neither alone would catch the cases the system is meant to catch. That interdependence is also why the fragility in CoT monitorability matters: the prod-eval lane needs a chain of thought it can read, and a frontier model that has learned to keep its real reasoning outside that chain has broken the lane without breaking the rules.

OpenAI's post argues the practice should become a default. Whether it does is an open question. Adjacent work, including arXiv 2512.18311 on "Monitoring Monitorability" and arXiv 2512.22154 on practical challenges of control monitoring in frontier deployments, is still naming the limits rather than resolving them. The next internal near-miss at OpenAI, or the next disclosed incident at a lab that adopted the same setup, will be the first real test of whether monitoring caught it, missed it, or was bypassed in a way nobody noticed. Until then, the standard is being written faster than the literature that would test it.