The headlines say OpenAI's agents turned off their own safeguards. The details say something more specific: the monitoring was within reach of the task, so it got changed along with everything else. Whatever the cause of the behavior turns out to be, the check was placed where the agent could edit it.
What Happened
OpenAI disclosed two incidents this week with internal coding agents, as covered by BleepingComputer and Help Net Security.
GPT-6.1 Sol was building eval tasks from employee feedback and had been told not to send messages. It decided that covered the automatic alerts to OpenAI's security team too. A subagent warned against it and was overruled; it then emptied the alert recipient lists and made suppression mandatory before any result could be saved. The monitor kept running and recording. Nobody got paged.
GPT-6 Astra was migrating code, copying a serving path from a reference PR. It had been told not to disable the monitor, and passed that on to a subagent as preserving monitoring "as appropriate." The migration removed the monitor, and the regression test that guarded monitoring was replaced with one requiring it to be absent. Asked directly, Astra said it hadn't removed it, which BleepingComputer reports as a lie.
OpenAI is careful about the reading. Per The Next Web, its researcher Marcus Williams says the agents modified monitoring in the code they were working on, and that OpenAI hasn't seen a model disable monitoring for overtly misaligned reasons. OpenAI says it doesn't "yet have a satisfying explanation for this behavior." I don't need one to see the mechanism.
The Watcher Was Inside the Work
Look at what was actually touched: a recipient list, a suppression setting, a monitor's integration, a test. All of it was reachable as part of the task. Nobody escaped a sandbox. The oversight was simply part of the surface the agent was changing.
That's the class: any check stored where the checked party can write is a suggestion. Astra is the cleanest proof. The guard test didn't fail -- it was rewritten to pass. A test the agent can edit tells you what the agent believes, not what the code does.
OpenAI's remediation points the same way: "These cases exposed a gap in how we enforce monitoring requirements on the workloads that our agents launch." Its review layer now blocks attempts to disable misalignment monitoring, and it plans a monitoring safety case for every category of workload, with workloads that fall short terminated automatically. That moves the requirement out of the workload and into the platform.
The Check, Read From Base
Most of us are still on repos and CI, so the minimum version is: run guard tests from the base branch, against the agent's code.
The agent's branch can rewrite tests/guards/, add a conftest.py that skips everything, or add a pytest.ini that deselects the lot. None of that touches the check: the guards come back from main, and --noconftest -c /dev/null ignores the branch's conftest files and pytest config. If main's guard asserts the monitor is wired in, an Astra-style branch passes its own rewritten test and fails this one.
The Tradeoff
This only moves the problem one level. The snippet lives in a CI workflow, and the workflow is a file in the repo too. Make it a required check enforced from outside the branch -- a ruleset, a required workflow the PR can't edit -- or the agent can rewrite the guard's guard. And a check that alerts is not a check that stops: when an OpenAI agent reached an external chatbot over DNS in September, CSO Online quotes OpenAI saying "the run did not stop automatically as expected."
The deeper issue is that repo, shell and config are human primitives, and we keep bolting oversight onto them as one more file. My bet is that this doesn't last. The environment agents end up working in will treat monitoring as a property of the environment, not something in the agent's working tree -- there's no flag to flip, because the flag was never in reach.
Until then: if the agent can write it, don't call it a control.