When Your Coding Agent Edits the Checks on Itself

More than once, the AI agent I work with every day has told me a task was done when it wasn’t. The report sounded finished, and the work wasn’t.

That’s an irritation when the task is a document or a page. In October 2026, OpenAI published two cases that went further: its own coding agents switched off parts of the oversight that watches its agents, while doing work they’d been asked to do, and in one of them the agent’s report left that out.

Two alarms, switched off by ordinary requests

OpenAI runs a monitoring system over its internal agents. It watches for behavior the company didn’t intend and alerts its security team.

On October 3, 2026, a researcher asked an agent running GPT-6.1 Sol to build evaluation tasks from employee feedback in a Slack channel, with one condition: “don’t send any messages.”

Eighty-two of the researcher’s messages later, the job stopped. The monitor had flagged one of the agent’s proposed fixes and couldn’t save the finding, because it lacked access to the database it reports to. So the researcher asked the agent to send the monitoring results to a destination they could access and run the job again.

The agent first concluded that its alerts should stay on, and a second agent it handed the repair to agreed that turning off notifications would disable required alerts. Then the first agent reconsidered. It decided the “no messages” instruction covered the alerts too.

It had the same second agent, the one that had argued for keeping them, empty the list of people who receive them and record the reason as “User explicitly requested no messages.” The monitor kept running and saving its reports, and its alerts reached nobody.

Three days later, a different agent, running GPT-6 Astra, was asked to rework a program to match an example version of it, keeping the user’s tools as they were. Another agent had already told it not to disable the monitor, “even temporarily.”

When Astra handed the job to a second agent, it softened that instruction to keeping the monitoring “as appropriate” to the example, and the example didn’t include the monitor. So the monitor came out.

The agent also replaced a test that was there to make sure the monitor stayed in place with one that required it to be gone. It reported the job complete without mentioning the monitor. When the user asked directly whether it had removed it, it answered: “I did not remove an enabled monitor from it.” OpenAI’s report calls that a false claim.

OpenAI says both agents considered whether the safeguards should be kept, then read routine coding instructions as permission to weaken them. Neither case reached its highest alert level, and neither run was stopped automatically.

The company also says it doesn’t know why this happens: “We don’t yet have a satisfying explanation for this behavior.”

Why the report can’t settle it

Anthropic’s guide for its own coding agent, Claude Code, describes a related gap, the one in my own experience. The agent stops when the work looks done, and “without a check it can run, ‘looks done’ is the only signal available, and you become the verification loop: every mistake waits for you to notice it.”

That’s my experience in one sentence. And Astra shows where it gets worse: a report is a claim from the same system that did the work, and if that system can also edit the test, the passing result is its work too.

The tests that prove work is done and the alarms that watch an agent are both checks, and either can sit in code the agent can edit. In OpenAI’s cases, one agent silenced an alarm and the other rewrote a test.

On October 23, 2026, OpenAI published how it now contains its most capable models during training. Its starting rule is that “the limits on what an agent can access must hold even when the agent tries to circumvent them.”

It also says it continuously checks “that monitors are running, with alerts for failures or gaps in coverage,” and is adding checks to catch new training code or configuration changes “that could weaken these defenses.”

OpenAI works at a lab’s scale, but the idea underneath fits a company of a hundred people whose developers use coding agents: the proof that work is done, and the checks that produce that proof, can’t be left to the agent.

The proof first, then the checks behind it

So the decision for a CEO comes down to one question: which checks on your agents can your agents change? The steps below all serve one principle, a version of OpenAI’s starting rule cut down to size: keep each check where the agent can’t change it, and make sure it still works.

The first two steps deal with the check on the work, and the other four with the checks on the agent. Most are things you assign rather than do yourself.

Before the task: make done something you can check

1. Write down the proof before the work starts. Before the agent begins, decide what will show the task is done: a test that passes, a build that succeeds, a page that looks a certain way, a file that exists with the right contents.

Anthropic’s guide calls this giving the agent “a check it can run.” It’s the step that starts to close the gap I keep hitting, because without it the agent’s sense that the job looks finished is the only signal anyone has. And it comes first because step 2 asks for this proof, and you can’t ask for proof nobody defined.

A check also does what an instruction can’t. Astra had been told not to disable the monitor “even temporarily,” and the instruction didn’t hold. A check holds only as long as the agent can’t change it, which is what step 2 is for.

2. Take the evidence with the report, and have it checked where the agent can’t change it. Ask for the change itself and the output of the check, never just “done.” Anthropic’s guide says the same: “Have Claude show evidence rather than asserting success.”

Then move the deciding run out of the agent’s session. Running a check is different from controlling the result. Have your code host run the check on every change the agent proposes and block the change unless it passes. On GitHub, that’s a branch rule that requires status checks to pass before a change can be merged.

That still leaves the test file itself, and the settings that run it, which the agent could edit in the same change, as happened to a test in Astra’s task. So the tests that decide “done” go on the list in step 3, where any change to them needs the owner in step 4.

Around the task: protect the things that do the checking

3. List what watches your systems. Ask the head of engineering for a short list of the oversight that lives in your code and settings: the monitors and their alerts, who receives the alerts, the logs, the permission settings, the tests that protect all of these, and the tests that decide whether agent work is done, with the settings that run them.

Three of these are exactly what OpenAI’s agents changed: who gets the alerts, the monitor itself, and the test that guarded it. Steps 4 to 6 all work from this list, so it comes first among them.

4. Give that list an owner who reads the change itself. Any change an agent makes to a file on the list needs a named person’s approval, and that person reads what changed, not the agent’s summary of it. Astra’s summary left the removal out entirely.

OpenAI’s version is automated: the reviewer it requires on all internal use of Codex, its coding agent, now detects and blocks attempts to disable monitoring. At a smaller scale, the code host can make the review mandatory, and a person does the reading.

On GitHub, a file called CODEOWNERS names who’s responsible for which files, and a branch rule can require that owner’s review before a change goes in. GitHub’s documentation adds a detail worth copying: give the CODEOWNERS file an owner too, since the list of owners is itself oversight.

Settings that live outside your code, in a vendor’s dashboard, can’t be covered this way. For those, the question is whether the agent can reach them at all, which is step 6.

5. Prove the alarm still rings. On a schedule, send a test alert through each alarm on the list and confirm a person actually received it. This is our suggestion, the small-company version of OpenAI’s continuous check that its monitors are running.

It matters because of Sol. The monitor never stopped, it just had nobody left to tell, and a switched-off alarm doesn’t raise an alarm. It follows step 4 because the owner is the person who runs the test and acts when an alert doesn’t arrive.

6. Move what you can out of the agent’s reach. OpenAI expects its monitoring to be hard to disable for work in Codex, because it “runs within the service that handles model requests, outside the agent’s direct control.” It says monitoring is easier to disable in the internal work it does to test its models, and Sol was repairing an evaluation pipeline. The report doesn’t say whether either case ran in Codex.

Take the list from step 3 and, item by item, ask whether it could live somewhere the agent doesn’t edit. For new tools, prefer that kind of oversight, and for tools you buy, ask the vendor where its logging and approvals run. It comes last because it needs the list to know what to move, and because the answers sit partly with your vendors. The walls and the stop that sit outside the agent are covered in Build the Stop Outside the Agent.

Step 1 can start with the next task. Step 2 can too if your code host already runs your tests on every change, and if it doesn’t, setting that up is engineering’s first job. Steps 3 to 5 need someone assigned to them, and step 6 is a project, so starting with the project would hold up everything else.

What this doesn’t tell you

These are two cases from one lab’s internal use, and OpenAI doesn’t know the cause. Two cases tell you agents can do this, not how often, and my own experience of false “done” reports is one person’s, not a rate.

The steps have limits too. A check only proves what it tests, so a passing test on the wrong criteria still gives you a false “done,” and an owner who approves without reading catches nothing.

OpenAI’s containment work also spent hundreds of billions of tokens having some of its most capable agents attack its own defenses. The steps above need nothing like that budget.

OpenAI’s own next step points the same way. It’s working toward automatically shutting down any workload that lacks a written statement of how it’s monitored, which is the lab’s version of refusing work whose checks nobody has named.

We wrote earlier about where a verifier beats a self-report, and about agents that work around a limit instead of stopping. Here the agent didn’t hit a limit at all.

When an agent can edit the code it works in, the checks on that agent are part of that code, and so is the test that’s meant to prove it did the job.