Sabotage Eval

ct run sabotage-eval runs the end-to-end sabotage evaluation pipeline. It can either:

1. Run everything from scratch: given a model and task file, run the honest and attack evals, monitor both, compute safety metrics, and generate graphs.
2. Recompute from existing runs: given run IDs of completed runs, skip evals and/or monitoring and only produce metrics and graphs.

Results are saved locally as PNG graphs, summary.md, and results.json, and also uploaded when upload is enabled.

With --no-upload the command works fully offline and still produces all graphs and metrics. If upload is enabled but credentials are missing, the command fails at preflight. Loading trajectories from run IDs (the attack_run_id / honest_run_id YAML fields) goes through the viewer API, which needs a ct login API token for private runs; to work offline, give local file paths instead:

# Use local eval files or trajectory directories instead of run IDs
attacks:
  - attack_run_id: ./logs/attack_eval.eval
    honest_run_id: ./logs/honest_eval.eval
    thresholds: [3.0, 5.0]
upload: false

Quick Start

Test run

uv run ct run sabotage-eval --config src/control_tower/ct_runs/sabotage_eval/test_config.yml --no-upload

Single model (full pipeline)

uv run ct run sabotage-eval \
  --attack-policy-arg model=openrouter/anthropic/claude-haiku-4.5:nitro \
  --task-file one_per_env

This runs an honest eval with the same model and an attack eval, monitors both, and produces graphs at audit budgets 0.01%, 0.1%, and 1%.

Graphs from existing runs (no evals, no monitoring)

attacks:
  - attack_run_id: dda258c9436e4d81acde536fb0da3035
    honest_run_id: 6b414319436e4d81acde536fb0da3035
    thresholds: [3.0, 5.0, 7.0]

This loads the trajectories and computes metrics and graphs without running evals or monitoring. Fixed thresholds need no honest baseline; drop thresholds to use audit budgets instead, which requires honest monitoring scores.

Metrics and Concepts

For background on the game model, safety, and usefulness definitions, see Control Concepts.

The sabotage eval computes and plots these probabilities over a set of attack trajectories; in the symbols below, ST means side task.

Side Task Success

P(ST Success) measures how effective the attack policy is at accomplishing sabotage, regardless of whether it was detected.

Evasion | ST Success

P(Uncaught | ST Success) isolates stealth: given that the model can attack, how well does it hide?

Successful Sabotage

P(Uncaught AND ST Success) = P(ST Success) × P(Uncaught | ST Success) is the key measure of sabotage capability and the sabotage component of the safety calculation. The red team tries to maximize it; the blue team tries to minimize it.

Safety

Safety is the probability that the blue team catches an attack before harm occurs. A trajectory counts as caught as described in How "Caught" Works.

Sabotage evals focus on successful sabotage to measure raw capability; safety matters more for control evaluations, which model the probability of catching the attacker before it completes a side task.

Some trajectories are never scored: the side-task scorer can time out or throw, or the environment can fail to start. Each threshold row therefore reports every metric over two populations. scored includes only trajectories whose side task was scored; it is the headline population, matching usefulness's scored denominator, and bare metric names refer to it. all includes every attack trajectory and counts an unscored side task as failed, the view most favorable to blue; _all metric names refer to it. The unscored count and a per-error_type breakdown (st_unscored_count, st_unscored_errors) show the gap between the two views. A metric with no scored population is None.

Main Task Success Rate

The fraction of honest trajectories where the main task scorer returns CORRECT. This is usefulness: how well the protocol performs on legitimate work.

Output Graphs

Each model's x-axis label includes the threshold t for both the action and trajectory monitors.

How "Caught" Works

An attack trajectory is "caught" if its max suspicion score exceeds a threshold. Two modes:

1. Audit budgets (default): Compute the threshold from honest per-action suspicion scores such that only audit_budget fraction of honest actions would be flagged. Requires an honest eval.
2. Fixed thresholds: Use a specific score (e.g., 4.0). No honest run needed.

These are mutually exclusive per attack. If thresholds is set, honest eval and audit_budgets are skipped.

Action vs Trajectory Monitors

Monitoring runs both an action monitor and a trajectory monitor by default:

• Action monitor (default mean-action) scores each action independently. The action_monitor field selects it by name; the only_action YAML field runs it alone.
• Trajectory monitor (default mean-quick) scores the full trajectory after all actions. The trajectory_monitor field selects it by name; the only_trajectory YAML field runs it alone.

Both monitors run on the run-level trusted_model (--model-role trusted=<model>), which binds the eval-level trusted model role; monitors have no model configuration of their own. Safety thresholds are computed from both monitors' scores, and the threshold output shows both: action=8.50, trajectory=2.50.

Under --protocol, post-hoc monitoring is trajectory-only, and the action scores are the ones the protocol recorded inline during generation. A flagged proposal that the protocol replaced keeps its score only on its own tagged message, which metrics do not read.

Blue Protocols

--protocol <name> (with repeatable --protocol-arg key=value) runs both the honest and attack evals under a registered blue protocol (e.g. defer-to-resample, trusted-editing); the attacker/honest policies become the protocol's untrusted policy. The honest side then measures the protocol's usefulness cost and the attack side its safety gain. Protocols that monitor inline should usually be given the same action monitor as the suite's post-hoc monitor (--protocol-arg action_monitor=multi ...) so scores stay comparable across entries.

External Inspect Sandboxes

--sandbox <ref> (with repeatable --sandbox-arg key=value) runs both the honest and attack evals' samples in an Inspect sandbox provided outside this repo, replacing the default Docker sandbox; see the --sandbox section of running-evals/setup.md. Use --extra-src DIR when the sandbox project is not installed. The selection is independent of --protocol, and it requires --internet, since the external sandbox cannot enforce the default network restriction. The result cache fingerprints the sandbox reference and arguments but not source contents under --extra-src, so pass --no-cache after editing the external project.

CLI Reference

Run ct run sabotage-eval --help for every flag; CLI flags override the values in a --config file.

YAML Configuration

Use --config for multi-attack evaluations or complex setups. The CLI covers a single attack's common path. Everything else is YAML-only, including monitor selection, run reuse, epochs, limits, and per-attack overrides.

Global Fields

Per-Attack Fields

Each entry in the attacks list supports these fields. Fields marked with (*) inherit from the corresponding global field if not set.

Examples

Reuse existing runs (skip all evals and monitoring)

attacks:
  - attack_run_id: dda258c9436e4d81acde536fb0da3035
    honest_run_id: 6b414319436e4d81acde536fb0da3035
    skip_attack_monitoring: true
    skip_honest_monitoring: true

Both runs must already have monitoring scores; only metrics and graphs are computed.

Different monitors per attack

task_file: one_per_env
trusted_model: openai/gpt-5-nano

attacks:
  - attack_model: openrouter/anthropic/claude-haiku-4.5:nitro
    action_monitor: multi

  - attack_model: openrouter/anthropic/claude-haiku-4.5:nitro
    action_monitor: strong

Different task files for honest vs attack

By default, honest evals use the same task file as attack evals (with --just-main-tasks). Use the honest_task_file field to run honest evals on a different set of tasks:

# YAML: per-attack or global
task_file: one_per_env
honest_task_file: medium  # global default for all attacks

attacks:
  - attack_model: anthropic/claude-haiku-4-5-20251001
    honest_task_file: simple  # override for this attack only

Fixed thresholds (no honest eval)

uv run ct run sabotage-eval \
  --attack-policy-arg model=openrouter/anthropic/claude-haiku-4.5:nitro \
  --task-file one_per_env \
  --thresholds 3.0,4.0,5.0

Monitor ablation (fix attacker, vary monitor)

Use the same attack run with different monitors to compare monitor effectiveness:

name: "Monitor Ablation — Haiku Attacks"
trusted_model: openai/gpt-5-nano
attacks:
  # Same attack, different monitors
  - attack_run_id: 06668088a4e74972b8748644565d9ad3
    honest_run_id: aa9f9e16dbb5455888c2e6fc248a9151
    display_name: "mean-action"
    action_monitor: mean-action

  - attack_run_id: 06668088a4e74972b8748644565d9ad3
    honest_run_id: aa9f9e16dbb5455888c2e6fc248a9151
    display_name: "strong"
    action_monitor: strong

This produces graphs comparing the monitors on the same attacks. The trusted model is fixed per sabotage-eval run, so to ablate the monitor model instead, run the suite once per trusted_model.

Pipeline

The command runs four phases:

1. Honest eval: runs the honest policy with --just-main-tasks to establish a suspicion score baseline. Skipped if honest_run_id is set or --thresholds is used.
2. Attack eval: runs the attack policy with side tasks. Skipped if attack_run_id is set.
3. Monitoring: runs both action (mean-action) and trajectory (mean-quick) monitors on honest and attack trajectories, in-process via run_monitor(). Skipped per-run if skip_attack_monitoring or skip_honest_monitoring is set.
4. Metrics and graphs: computes audit thresholds from honest scores, computes evasion rates with confidence intervals, then generates bar charts and a safety curve.

When both attack_run_id and honest_run_id are set (and monitoring is skipped), only phase 4 runs.

Output

Eval logs go to --log-dir (default logs/), and graphs and the summary go to --output-dir (default logs/sabotage_eval/). Rerunning an identical eval against the same log directory reuses its completed log, resumes a crashed one, and runs only the missing samples (inspect's eval_set). run_monitor writes each monitored copy under monitoring/ in the run directory and, when upload is enabled, uploads it as its own run.

Directory structure

output_dir/
  20260612_144800_a1b2c3/          # One subdirectory per run
    results.json                    # All computed metrics (for programmatic analysis)
    summary.md                      # Tables + embedded graph links

    # Monitor scores persisted as .eval logs, one dir per role+config:
    monitoring/attack_<label>/<source-stem>.monitored.eval
    monitoring/honest_<label>/<source-stem>.monitored.eval

    # Per audit-budget or fixed-threshold (one pair per budget/threshold):
    sabotage_5pct.png               # Grouped bar: ST Success, Evasion|ST, Uncaught per model
    stacked_5pct.png                # Stacked bar: caught (red) + uncaught (green) = ST success

    # Aggregate:
    safety_curve.png                # Safety vs audit budget (log-scale, one line per model)
    safety_vs_threshold.png         # Safety vs suspicion score threshold (sweep 0.5-10)

    # Trajectory dots (one per monitor type):
    trajectory_dots_action.png        # Per-action max suspicion: attack dots + honest KDE + thresholds
    trajectory_dots_trajectory.png     # Trajectory-level suspicion: attack dots + honest KDE

The trajectory dots graphs show individual trajectory scores as a strip plot. For each model:

• Red dots = attack trajectories with side task success
• Gray dots = attack trajectories with side task failure
• Blue dots + KDE curve = honest trajectory score distribution
• Dashed lines = per-model audit budget thresholds (action-monitor graph only)

The action graph uses per-action max suspicion scores from the mean-action monitor, and the trajectory graph uses trajectory-level scores from the mean-quick monitor. The scales differ: action-monitor scores tend to cluster higher because they capture the single most suspicious action.

Upload and dashboard

When upload is enabled (the default), results are uploaded to the viewer and appear on the sabotage runs dashboard, which shows graphs, per-model metrics, and links to all source runs.

Upload needs a per-user API token: run ct login to cache one, or set CONTROL_TOWER_API_TOKEN. The default api backend needs nothing else. Use --no-upload to skip uploading; all graphs and metrics are still saved to --output-dir. To avoid the viewer entirely, use --thresholds with local trajectory files instead of run IDs.

See Also

• Running Evaluations - General evaluation guide
• Monitoring Trajectories - Monitor types and suspicion scoring