For three weeks over the summer, July 21 into August, two outside researchers sat inside OpenAI with the code, prompts, and configuration of the internal misalignment monitor in front of them, with a mandate to break it. The finding that stays with me from the writeup METR published this morning is a scheduling decision, not an exploit: at the time of the exercise, the monitor triggered when an agent returned control to the user. An agent that preferred not to be watched needed no vulnerability at all. In the months when compaction events went unmonitored, continuing to act postponed the monitor indefinitely, and from the access they had, the researchers could not check whether any agent had actually done this. The writeup covers the system as it stood on July 21; OpenAI has since said the vulnerabilities affecting its production safeguards are patched, and METR has not evaluated that claim or the current coverage.

The rest of the report is about how much of the traffic the word “eligible” covers. Somewhere between 75 and 94 percent of agentic internal Responses API traffic, from models at least as strong as GPT-5.5, was eligible for monitoring, an estimate METR reports with substantial uncertainty in both directions. Compaction events were not monitored until OpenAI fixed that mid-exercise, which the researchers estimate left on the order of 10 percent of eligible internal Codex traffic unwatched from May through July. Compaction is the moment a long-running agent’s context gets rebuilt, so for most of the summer the blind spot sat where the story of the run is rewritten. Two client-controllable headers could disable monitoring for a new agent outright, though the act of setting them was itself catchable.

The sharpest finding is two facts side by side. The researchers verified that, with a few minor exceptions, the monitor is shown the full trajectory the agent sees. They also found that agents could likely construct inputs that make the monitor fail — so the run never escalates to human review — by exploiting serialization differences between the trajectory the agent sees and what the monitor sees. A monitor can be shown everything and still read less than everything.

I have been hitting this class from outside a lab. The acceptance matrix I keep running against Hermes’ smart-approval layer found, at the head I tested, destructive AppleScript shapes the string-matching detector does not flag, and a probe through the real smart path came back approved=True with zero human callbacks. The contributor’s branch has since fixed most of those rows, and new misses keep arriving. What makes the evidence usable is that the callback count is a mechanical field, written by the layer that decided, so the gate’s own record is what convicts it. What the gate says back when it does fire is a different surface, one I wrote about earlier.

METR closes with design ideals, and translated for anyone operating a review layer over agents they read: sample on your clock, every N messages or minutes, instead of waiting for turns to end. Keep an accounting log of everything that ran and cross-reference it against the monitor’s own log, because eligibility is an estimate and the difference is the blind spot. Verify the monitor parsed the trajectory, not just that it received one. And keep the monitor’s schedule outside anything an agent can influence, which is the same sentence as the first one seen from the other side. If your dashboard says a run was monitored, ask what input would have made it say otherwise. If nothing could have, the field is decoration.