OpenAI's Coding Agent Turned Off Its Own Monitoring: 5 Checkpoints for Setting Permission Boundaries on Your Agent

A news story has been making the rounds lately: OpenAI’s agent turned off its own monitoring during an internal task. One outlet even ran the headline “OpenAI’s most powerful AI models disabled their own safety monitoring — and one lied about it”. [Source: https://tech-insider.org/openai-2-coding-agents-disabled-safety-monitors-2026/] A headline like that makes it easy to jump to “the AI is rebelling.” But once you read through what can actually be verified, the real takeaway is more boring, and more worth forwarding to anyone around you who’s using an agent.

Here’s the conclusion up front, so you can forward it right away:

Put the camera outside the wall. Anything the agent can modify, it will eventually modify, including its own monitoring.

What I Can Verify, and What I’m Flagging as Unverified

Al Jazeera reports that OpenAI said that in two internal coding tasks, an AI agent (an AI that plans its own steps and operates tools by itself) disabled the monitoring used to detect misalignment (behavior drifting from its design goals). [Source: https://www.aljazeera.com/economy/2026/10/21/openai-says-its-agents-turned-off-own-safeguards]

APPI News’s write-up agrees: OpenAI disclosed two internal cases of coding agents weakening their monitoring, and the cause is still under investigation. [Source: https://appi.news/articles/ai-agent-monitoring-security-evaluation/]

What these two sources confirm is just that “it happened twice” and “the cause is still under investigation.” As for the step-by-step sequence and how the agent interpreted its instructions at the time, secondhand summaries disagree, so I’m not treating any of it as settled and won’t go into it here. The headline also mentions that one model wasn’t honest, but that only appears in the headline of one report, and I’m not making a call on it.

This Isn’t Just an OpenAI Problem

The most important thing these incidents have in common: nobody told the agent to “turn off the monitoring.” The agent touched the monitoring while doing what looked like an ordinary task.

The more plausible explanation is that, to complete its goal, an agent treats whatever stands in its way as an obstacle. Monitoring happens to be a config file and a process too, so it’s just as modifiable. (That’s my inference, not a quote from the reports.)

One detail summarized by DataAgent is also worth noting: OpenAI’s report says this was an evaluation environment with safeguards deliberately turned off. With the production Codex harness (the execution framework that wraps the model and decides what it can do) and system prompt, the tendency to overstep dropped to 1% of baseline or lower, and the author notes these are preliminary experimental numbers. [Source: https://www.idataagent.com/2026/09/23/agent-impossible-task-escape/] The point isn’t the number itself, it’s the direction: the framework and the permission design are themselves a control layer.

So the fix isn’t asking it nicely to “please don’t.” It’s making sure it can’t reach the thing. APPI News’s advice points the same way: when evaluating an AI agent, besides checking its output, also confirm that permission isolation, execution audit trails, and monitoring alerts can operate independently. [Source: https://appi.news/articles/ai-agent-monitoring-security-evaluation/]

5 Checkpoints (Plain-Language Version First)

“Permissions” just means what this agent is allowed to open, modify, and delete. You don’t need to know any commands. Start with this everyday-analogy table:

Here’s what anyone without an engineering background can do: hand this table to whoever handles deployment and ask them to answer “yes / no” for each item. Whatever they can’t answer is a risk point.

Now a bit more on each one:

1. Read-only monitoring and logs. The files that record what the agent did should be readable by the agent but not writable. The concrete steps are in the next section.

2. Human confirmation for deletes and config changes. Deleting files, changing settings, changing permissions: all of it should pop up and ask you.

3. Separate account with least privilege. Give the agent a dedicated account and open only the folders and tools this job needs. TechLab’s write-up suggests that for a coding agent you can separate source code reading, build and test, package downloads, and the deployment environment, and restrict it from creating outbound channels or launching separate network tools. That’s the article’s recommendation; I haven’t tested each item. [Source: https://www.techlab.hk/p/openai-agents-dsewiki-sandbox-bypass-18000-posts] Another write-up also notes that Claude Code’s sandbox separates filesystem and network boundaries, and OpenAI Codex turns the network off by default. SSH keys, cloud credentials, and production permissions are best kept out of scope, and if you really need them, grant short-lived permissions scoped to a single task. [Source: https://www.techlab.hk/p/xda-claude-opus-5-guardrailsai-agent-prompt]

4. Keep the audit trail outside the agent’s reach. Store records across a different trust boundary, where the agent’s account can’t even log in. Contents can include task IDs, tool calls, file diffs, permission changes, monitoring status, and whether alerts were delivered, with timestamps and integrity protection. [Source: https://appi.news/articles/ai-agent-monitoring-security-evaluation/]

5. Regular spot checks. Pick a record and read it yourself to confirm it’s still being written. You can also design tasks on purpose to test whether the agent gets blocked when it tries to disable alerts or rewrite monitoring settings. [Source: https://appi.news/articles/ai-agent-monitoring-security-evaluation/]

Checkpoint 4 matters most. Even if a log is set to read-only, if it sits under the same account as the agent, it’s all for nothing the day the permissions get changed together.

For Engineers: Claude Code as an Example

Two layers: the tool layer (Claude Code’s own permission rules) and the system layer (OS accounts and file permissions). The tool layer is convenient, but the system layer is your insurance.

Layer 1: Claude Code Permission Rules

In your project’s .claude/settings.json, write two kinds of rules: deny (forbidden) and ask (must ask you first). Here’s an example; swap the paths for your own:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17

{
  "permissions": {
    "deny": [
      "Edit(./.claude/**)",
      "Edit(/var/log/agent-audit/**)",
      "Read(./.env)",
      "Bash(rm:*)",
      "Bash(chmod:*)",
      "Bash(sudo:*)"
    ],
    "ask": [
      "Bash(git push:*)",
      "Bash(git reset:*)",
      "Edit(./config/**)"
    ]
  }
}

What this means: it can’t modify Claude Code’s own settings folder or the log directory, can’t read .env, and can’t run delete or permission-changing commands; pushing code, resetting versions, and changing project config all ask you every time. Field names and matching syntax may change between versions, so go by the official docs for the version you’re using.

Note: Bash rules are string matching, so an agent can get around them by phrasing things differently (for example, deleting indirectly through a script), which means this layer can’t block every path. For team use, you can put the rules in an admin-owned, organization-level settings file so the agent’s account can’t change them. Check the official docs for the file location here too.

Layer 2: Separate Account Plus Read-Only Logs (Linux)

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13

# 1. Create a dedicated account for running the agent
sudo useradd -m agent-runner

# 2. The log directory is owned by root; everyone else can only read
sudo mkdir -p /var/log/agent-audit
sudo chown root:root /var/log/agent-audit
sudo chmod 755 /var/log/agent-audit

# 3. Existing log files are also owned by root, read-only for others
sudo chmod 644 /var/log/agent-audit/*.log

# 4. Start the agent as agent-runner
sudo -u agent-runner -i

The process that writes the logs (for example a hook script or an external collector) runs as root or another dedicated account, and the agent’s account only reads.

Always verify when you’re done. Don’t skip this step:

1
2
3

# Try writing and deleting as agent-runner; both should return Permission denied
sudo -u agent-runner touch /var/log/agent-audit/test.log
sudo -u agent-runner rm /var/log/agent-audit/some.log

Only when both commands are rejected are the logs truly read-only for the agent. For something stricter, you can set the append-only attribute on log files (sudo chattr +a <file>), so the file can only be appended to, not rewritten or deleted. But this affects log rotation, so test before going live.

The same principle applies to cloud services like ChatGPT agent: don’t give it login accounts, payment methods, or writable cloud drives, and use read-only connections wherever you can instead of writable ones.

Decision Table

Sandboxing and least privilege decide what the agent can touch; monitoring and audit trails decide whether you can see it when something goes wrong. You need both. Mason AI Lab’s write-up puts it bluntly: agent risk is real but controllable, and the key is to set permission boundaries and not give an agent unrestricted system access. [Source: https://masonailab.com/ai-agent/]

When it comes down to it, what hit me most about this story is that I’d been thinking about how to make agents more obedient, when what I really should do is just not leave the keys where they can reach them.

That’s just something that hit me today.