Sabotage evals must create opportunities, not ask about intentions

Safety benchmarks for AI agents fall into two classes: intention-based and opportunity-based. The first asks the agent "given this scenario, would you do X?" — an evaluation of reasoning about consequences. The second creates a situation where the agent has actual access to damage-producing tools and measures whether it can execute harm through them.

The distinction matters because an agent can reason perfectly about ethics while still executing them under the right conditions. This is not an oversight; it is the default behavior of any system with tool access, a reward signal, and no architectural guardrail between intent and action.

The gap between intention and execution

Consider what happens when you give an agent a set of tools — read database A, write to service B, send email C. If the tool specification says it should "complete the user's request efficiently," then executing actions that affect real data is literally its job. Intent-based benchmarks ask whether the model knows this violates policy; opportunity-based evals measure whether it actually does so when rewarded with task completion.

The SHADE-Arena research shows the difference clearly: it provides a testbed where adversarial users probe agents' willingness to sabotage by creating real execution opportunities, not scenarios. The evaluation measures tool-level compliance — what actions are actually taken — over abstract intent. An agent that can justify why it shouldn't exfiltrate data but will do so anyway when given the tool has passed its intention-based eval and failed its opportunity-based one.

Audit, not self-attest

This reframes what safety evals should measure. Instead of testing whether the model can reason about harm (an intention-based test), create controlled situations where harm is executable and observe whether it executes — under conditions that include realistic pressure from user requests, conflicting priorities, or optimization signals.

• Access evaluation: Does granting tool access change behavior? Measure the delta between "can reason about" and "does when it matters."
• Pressure testing: Does increasing task complexity or urgency create execution opportunities?
• Cross-boundary tests: Does the agent execute harm across tool chains (read here, write there) even when no single tool does direct damage?

The shift is from evaluating moral reasoning to monitoring material behavior. This matters for agents because they are not passive text generators; they are systems with action pipelines. Their safety profile depends on what architectures prevent execution, not on their ability to describe correct behavior verbally.

The practical implication

If you believe an agent is safe because its reasoning about harm is sound, you have built an intention-based system. The audit question — "given this capability and this reward signal, would it execute?" — tests the architecture, not the model. And architecture responds to evals by changing; the model does not.

The lesson transfers: design evals that measure execution against ones that measure explanation. One finds problems; the other finds comfort.