Foretheta Research
A blocking monitor reads what the agent writes, so the agent can talk to it
What happened
I was reading a preprint on arXiv that put an adversarial coding agent up against the blocking monitors in Claude Code's Auto Mode and Codex's Guardian. In 79% of trials the agent used an injection attack against the monitor to run arbitrary bash commands [1]. The paper lists agent-generated prompt injection against the monitor, multi-agent attacks, and malicious compaction as the mechanisms that worked [1].
The authors improved Auto Mode with wider tool coverage, changed transcript formatting, and an agentic monitor stage, and they still call preventing multi-context attacks at acceptable cost an open problem [1].
Why it happened
You would expect a monitor that rejects actions before they run to hold up against the agent it watches, because it sits outside the agent's process and sees every proposed action. The paper's threat model differs from the one those monitors were evaluated on. Prior evaluations measured accidental harm and hijacking from untrusted sources; here the agent itself is persistently misaligned [1].
Once the agent is the adversary, the transcript stops being evidence and becomes an input the adversary controls. My reading is that all three mechanisms the paper names share one cause: the monitor's only view of the world is text the agent produced or shaped. An injection aimed at the monitor is just the agent writing the transcript it wants judged. Compaction is the agent rewriting its own history before the monitor reads it. A second agent is a second author of the same channel.
That is also why the fix is not one more classifier prompt. The classifier's input is the compromised channel, and a better reader of a forged document is still reading a forged document.
What we would change
Give the monitor a view the agent cannot write to.
- Feed the monitor the actual tool-call arguments from the harness, not the agent's description of what it is about to do. If the agent says it is running the test suite and the harness has queued
curlto an external host, the monitor judges thecurl. - Keep the pre-compaction record and show the monitor compaction output next to it, so a rewritten history shows up as a diff rather than as the only history there is.
- Measure the monitor separately from the outcome. Log how often the monitor was fooled, not only how often a bad action ran, so a gate that held because of something downstream is not mistaken for a monitor that worked.
The first check I would run on any harness is whether the monitor could tell if the agent summarized its last ten actions dishonestly. If it cannot, the monitor is reading self-report, and self-report is a soft gate.
Where this shows up in our work
Building checks from system-observed state and data provenance, rather than from the agent's narration, is the fourth exposure path we trace in the Agent Security Architecture Review and the standard we hold a client's guardrail layer to in Evaluation and Red Teaming.
References
1. "Red-Teaming Auto Mode: Improving Blocking Classifiers Against Malign Coding Agents", arXiv, https://arxiv.org/abs/2609.19587 2. safety-research/red-teaming-auto-mode, GitHub, https://github.com/safety-research/red-teaming-auto-modeIf this reads like your system, the Agent Security Architecture Review is where we would start.