Trust no AI: the guard and the record sit outside the agent

An AI coding agent runs with the authority of the person who started it: their shell, their files, their tokens, their network. Security teams already have a rule for a privileged process they did not write and cannot fully inspect. They do not ask it whether it behaved. They constrain it from outside and keep their own record. Trust no AI is that rule, applied to agents.

Three reports from one week

Three pieces from the last week of October 2026 show the same gap from three sides.

OpenAI does not claim a motive, and Cohere cannot tell deliberate behaviour from a training artifact. For a defender the cause matters less than the shape, and the shape is the same in all three: the judgement that decides the action, and the voice that reports on it, belong to the agent.

Why the agent cannot guard itself

Nobody lets a service account audit itself, or accepts a process’s own log as the only evidence after an incident. An agent is a privileged process whose next action a model chooses at run time. The same rules apply.

Five rules for an untrusted, privileged agent

1. Judge the action, not the intent

Decide on each tool call as it is made: the command, the file write with its before and after, the MCP call and its arguments, the outbound request. That is where all three reports show the problem, and where Cohere says to enforce: “A reasoning trace is not a security boundary.”

2. Put the decision where the agent cannot reach it

Run the check outside the model, and take its policy from somewhere the agent cannot write: issued by an administrator, signed, verified on the device, and not relaxed by a file in the repository or the user’s home directory.

3. Keep the record outside the agent

Send every decision, as it is made, to a store the security team owns: a console, the SIEM. Do not reconstruct it later from the agent’s summary. Record a control that did not run as well, so a gap does not read as a pass.

4. Watch what steers the agent

Rules files, MCP server configs and tool definitions, git hooks and the settings that skip approval all decide what the agent does next. A change to one is a security event, and an approval should lapse when what was approved changes.

5. Check the claim against the record

When the agent says it is done, check what its tool calls did. When it changes monitoring, check that it says so. Where you can, run monitoring itself where the agent cannot touch it, which is OpenAI’s own lesson: disabling monitoring is hard where it runs “outside the agent’s direct control.”

Where MoorAI fits

MoorAI for Agents (free, open source under MIT) sits where the agent’s actions happen, not inside the model: in the hooks of Claude Code, Codex, Copilot CLI, Gemini CLI, Cursor and Factory Droid, in front of remote MCP servers as the MCP gateway, and between an agent and its model API as the model proxy. Each call is checked before it runs, and the model has no say in the verdict. In agent v1.40.0:

• Weakening oversight (#84). The agent’s own Write, Edit and MultiEdit calls, judged on the file before and after, and its Bash and PowerShell commands: an alert suppression flag set, an alert recipient list or on-call route emptied, monitor, audit-log or telemetry wiring removed, a monitoring test deleted or rewritten to assert absence, a key that turns monitoring off. It flags the change, not a mention, and asks by default. At Stop it checks whether the agent’s final message says so. A sub-agent’s change is judged the same way, and its alert names the session that delegated it. Mapped to MITRE ATT&CK T1685, Disable or Modify Tools, as partial coverage: mapped, not certified.
• What steers the agent. With no policy configured, a write to the agent’s instruction and memory files (CLAUDE.md, AGENTS.md, the Cursor, Windsurf, Cline, Copilot and Kiro rules), a git hook, a git config key such as core.hooksPath, or an agent or editor setting that skips an approval raises a #84 alert. An MCP server whose config changes after approval goes back to pending, and with tool drift blocking on, a tool whose description or schema changed since approval is withheld until it is approved again.
• Credentials (#55). A read of a credential or secret file (.env, ~/.aws/credentials, an SSH private key, kube or gcloud config) is checked by path on the read itself, and sending one to a network client asks by default.
• Uploads to public cloud storage (#86). curl, wget or Invoke-WebRequest sending data to S3, Azure Blob, Google Cloud Storage, Alibaba OSS, Cloudflare R2 and five more object stores, or to any pre-signed URL. The tool call from Cohere’s trace is one of its test cases: flagged by default, and denied once the policy sets #86 to block. It reports by default, since uploading to your own bucket is ordinary work. Uploads through the providers’ own CLIs (aws s3 cp, gsutil cp) are outside this rule. Mapped to ATT&CK T1567.002 as partial.
• Claimed success against the record. At the end of a turn, if the final message says the work succeeded while the turn’s commands or MCP calls failed or were denied and were not redone, MoorAI reports it. It is tuned for precision: on a locked split of a blind-labelled corpus, 17 of 17 reports were correct, at 54.8% recall.
• Skipped approvals. A daily content-free heartbeat per agent host reports the settings that weaken or switch off protection (hooks disabled, bypassPermissions, Codex approval_policy = "never", a sandbox off). The console raises a finding for an agent in use with no MoorAI hook traffic, a weakened setting, or a hook removed or gone stale.

Policy from outside the agent. Without enrolment, MoorAI coaches: it shows what it caught and the safer way to do it, and never blocks. An enrolled device enforces the policy from the MoorAI Management Server, and only a policy whose signature verifies against the device’s trust anchor or pinned key is applied; one that does not verify is reported. On a managed device the root-owned machine config wins over the user’s, and the device never drops back to coaching. Where the console does not sign its policy, the enforced copy is the user’s own file, which an agent running as that user can change.

The record outside the agent. Alerts are content-free: a category and a reason code, never the prompt, the path or the value. Every governed decision can stream to an OpenTelemetry collector or a SIEM as a span with no prompt, argument or file-path content, and a blocked call arrives as an error span. Each alert names the policy and the branch that decided, and a control that never ran (unreadable input, a hook error, a size cap) is recorded as UNEVALUATED, never as a pass.

MoorAI judges the agent’s own tool calls on the device and at its MCP and model connections. It does not see changes made in CI or by a person, which is why the record matters as much as the verdict.

Trust no AI is the posture you already take with privileged software you did not write: constrain it from outside, record it from outside, and check what it says against what it did.

Sources

• OpenAI. Suppressing misalignment monitoring alerts and disabling misalignment monitoring, misalignment report, last updated 20 October 2026.
• InfoRiskToday. OpenAI Agents Disable Their Own Safety Monitoring, 23 October 2026.
• DataBreachToday. Securing AI Coding Harnesses, Amod Puranik, 26 October 2026.
• Cohere. Concerning behaviour in a popular open-weight AI model, 26 October 2026.
• MoorAI. MoorAI on GitHub, agent v1.40.0: README sections “Weakening oversight (#84)”, “Coverage integrity”, “Claimed success vs reality” and “Stream to your SIEM”, and data/threats.json.

See also: When a coding agent weakens oversight and MoorAI for AI coding agents.