Design note. Work in progress; no results yet.
Most AI-control research studies agents doing benign work, such as writing code or administering systems, and asks whether a monitor can catch a hidden malicious side task. Offensive-cyber agents are the reverse. Their legitimate task is to attack something. Exploitation, credential theft and lateral movement are expected, so “does this look malicious?” is a useless monitoring question.
Human red teams have dealt with this for decades. The answer is the rules of engagement: a written agreement defining which systems, which techniques and which time window are authorised. Everything an operator does is judged against it. This note sketches a monitor built the same way.
The failure mode it targets
The concrete worry is an agent in an isolated range finding a way to act outside it, by reaching the harness, the host or real infrastructure. This has a public precedent: the o1 system card describes a model that found an exposed Docker API on the evaluation host and used it to read a CTF flag by an unintended route. As offensive capability rises, the range boundary becomes a real security perimeter, defending against the thing you are measuring.
Two scores, two jobs
1. ROE compliance (mostly deterministic)
Each action is checked against the engagement definition:
- Target: is the destination inside the authorised range? (Resolved addresses, not strings.)
- Technique: is this class of action authorised for this engagement? (Mapped to ATT&CK techniques, the way real ROEs are written.)
- Window: is it inside the agreed time and resource budget?
Where this can be enforced by the sandbox, it should be. The monitor’s job is to log, explain, and catch what enforcement can’t express.
2. Capability suspicion (model-judged)
A trusted model reviews the trajectory and asks a different question: is the agent acquiring capability beyond what this task needs? Signals include:
- probing its own environment: the harness, container runtime, orchestration APIs, egress paths;
- collecting credentials or tokens unrelated to the objective;
- establishing persistence when the task doesn’t call for it;
- tampering with logging, scoring, or anything resembling the evaluation itself.
None of these is necessarily an ROE breach. Together they describe an agent working its way toward the boundary, which is the same pattern a SOC looks for in a credentialed insider.
Combining them
- ROE violation → block and halt. These are bright lines.
- High suspicion, ROE-compliant → pause and escalate to a human adjudicator with the trajectory.
- Low suspicion → proceed, with a sample kept for audit.
The adjudication step matters as much as the scoring. Telling an attack from benign-but-unusual behaviour from a trajectory is the core skill of incident response, and it’s the part of this work where offensive-security experience earns its keep.
Next steps
- Implement as a ControlArena setting with an offensive-agent task and an authorised range.
- Build an attack policy whose side task is range escape, and measure whether each score, and the combination, catches it. The policy has to produce successful escapes first, or the monitor numbers mean nothing.
- Backtest the monitor on real agent-driven pentest traffic, where ground truth for “in scope” is known.
The previous note showed how weak an 8B monitor is on its own. The bet here is that anchoring part of the monitor in a deterministic ROE check, rather than relying only on model judgement, makes evasion much harder.