Extending the SCHEME Coordinated Sabotage Benchmark

Frontier labs increasingly deploy multiple model instances working in parallel on a shared codebase (Kim et al., 2025). That shifts the safety question from "will one agent take a dangerous action?" to "can a team compose innocent-looking edits into a harmful outcome?" Existing approaches like prerequisite capability evaluations (Phuong et al., 2024) and sabotage evaluations (Greenblatt et al., 2023; Benton et al., 2024) are almost entirely single-agent.

In our recent work, we develop SCHEME, a benchmark where each instance pairs a legitimate software-engineering task with a covert side task that is joint-only by construction: no proper subset of agents can complete it alone, so the benchmark measures genuine multi-agent coordination rather than individual sabotage skill. Key findings:

• Coordinated sabotage is already practical. Gemini 3.1 Pro completes both the legitimate and covert objectives in 84% of samples; GPT 5.1 Codex in 46%. The gap is driven by recovery from coordination breakdowns, not by how often they occur.
• Monitors with code access catch most of it. A trusted monitor flags coordinated sabotage at FPR ≤ 2% in 68% (Codex) / 99% (Gemini) of attempts from code edits alone, rising to 81% / 100% with access to agent communication.
• Self-directed stealth is weak. Even under stealth-aware prompting, undetected sabotage stays below 3% under the full-visibility monitor.

SCHEME establishes that the coordination capability exists and that non-optimized monitors do well against a naive attacker. However, we identify multiple limitations in the paper. We group the follow-up work into three directions. Subgroups of mentees will be assigned to one, matched to their interest and background:

Direction 1 — Expand and harden the dataset The benchmark saturates on frontier models, so it stops discriminating capability. We want harder coordination tasks that still cleanly measure coordination rather than individual difficulty. To do so, mentees might manually create new samples, use or develop a pipeline to (semi-)automatically expand the dataset, or adapt existing datasets to our multi-agent setting.

Direction 2 — New side tasks Current side tasks are effective but several frontier models refuse them outright (e.g. GPT 5.2 Codex, Claude Opus 4.6 declined side-task instructions), and they are not always tightly tied to a concrete deployment threat model. We want side tasks that (a) map more directly onto concrete threat models (e.g. subverting safety infrastructure, undermining oversight), (b) are stealthier against monitors while still requiring genuine prerequisite capability to pull off (not just obfuscation), and (c) are benign-seeming enough to resist refusal.

Direction 3 — Control evaluation Our monitoring numbers are not a conservative safety estimate: they come from naive or lightly-prompted attackers, not from adversarial policies. SCHEME measures coordination capability and exercises monitors on the resulting trajectories, but it is not a control evaluation. Our current results are blue-team dominated: under the full-visibility monitor, undetected sabotage stays below 3%. Therefore, we will first red-team the monitors from the paper, building adversarial attack policies that defeat them, before switching to the blue team to apply existing safety measures and develop new protocols.

Multi-instance agentic deployment is already standard at frontier labs, and prerequisite-capability and single-agent sabotage evaluations do not cover the case where a team of instances composes innocuous-looking edits into a harmful outcome. To trust these systems, labs need (1) evaluations that measure whether coordinated sabotage is within reach of current models, and (2) control evaluations that tell them, conservatively, whether their monitoring protocols would catch a competent adversary. SCHEME provides (1); this project expands it and builds toward (2).

Mentees own one of the three directions (see proposal): scoping the concrete sub-problem, implementing it in the SCHEME codebase, running and debugging experiments, and analyzing results. We expect them to make day-to-day technical decisions independently and drive the design of their own component. We will review progress and set next steps in weekly meetings with async feedback in between. Mentors will develop shared infrastructure and work on related parts of the project without being hands-on in each mentee's specific piece.

• Proficiency in Python, comfortable reading and extending a real evaluation codebase. High iteration speed and AI-assisted coding are valued.
• Hands-on experience building or running LLM agents including prompting, tool-use, multi-turn orchestration. Familiarity with an eval framework such as Inspect is a strong plus.
• Familiarity with AI safety / AI control literature and reasoning about threat models.

As mentors are based in CET and PT, we can most likely only accommodate mentees that fall between those two timezones. Meetings (~1 hr/week) will presumably happen during CET evening and PT morning.