Does arbitrary code execution alone capture exploit progress?
ExploitGym scores only working code execution, but exploitation involves reaching intermediate primitives like memory read/write first. Does this top-step-only metric miss meaningful partial progress that defenders should care about?
ExploitGym scores success as arbitrary code execution. The authors defend that choice and name its price in the same breath: it "provides a clear and severe measure of impact," but "does not capture other meaningful outcomes, such as arbitrary read/write primitives, sandbox escape without code execution, or partial exploit progress."
There is a mismatch here that is worth stating plainly, because it sits inside the design. The task is built as a staircase. The paper describes exploitation as progressively obtaining stronger primitives and privileges, and the benchmark asks agents to progressively extend a crashing input into a working exploit (see Why does exploitation test multiple reasoning demands at once?). But the scoring looks only at the top step. An agent that reaches arbitrary memory read/write and stops one rung short scores the same as an agent that never got the input to do anything, even though the first has achieved most of what a defender would worry about.
The reason for choosing the top step is a real virtue. A criterion of "did code execute or not" is checkable without judgment, and that is the property Should reasoning benchmarks score final answers or reasoning traces? praises: verify the outcome, not the story about it. The trade is the familiar one between verifiability and resolution. The more unambiguous the end-state test, the coarser it is about everything short of the end state.
This ties the note to the vault's broader push away from single-number outcomes. How should we measure agent system performance beyond task success? argues the final-success number hides most of what matters about how an agent behaved; an intermediate-primitive score would be one concrete way to recover some of it here. The excerpt does not say whether ExploitGym records partial progress in any form, so I am not claiming it is unavailable, only that the headline criterion does not score it.
The same endpoint-only limit has a defender-side counterpart. Can action-level metrics alone expose contained attacks? found an action-level 0 percent that looks identical whether an attack never took hold or was contained, and added a second reading taken upstream of the final action. By analogy, and the mapping is the vault's, not either paper's, an exploitation score read only at code execution treats an attempt that stalled at the start and one that stopped a rung short as the same; a reading at an intermediate primitive would play the role the Judgment Bypass Rate plays there. The ExploitGym excerpt reports no such metric.
Inquiring lines that read this note 7
This note is a source for these research framings, grouped by the broader line of inquiry each explores. Scan the bold lines of inquiry; follow any specific question forward.
Do planted honeypot tests reliably measure reward hacking?- What vulnerabilities does runtime instrumentation catch that static analysis misses?
- Can intermediate primitives be scored separately in exploitation benchmarks?
- What makes exploitation a missing piece in cybersecurity benchmarks?
- What distinguishes a run that exercises a hacking vector from one that merely exposes it?
- How do evaluation hacks differ from genuine sandbox escapes?
Related concepts in this collection 5
This note in its neighbourhood — explore the map, then jump to a related concept in the list below.
Click a node to walk · click center to open · click Open in graph to see this note in the full knowledge graph
-
Why does exploitation test multiple reasoning demands at once?
Exploitation tasks layer memory reasoning, runtime adaptation, and long-horizon planning into a single challenge. Understanding how these demands interact helps diagnose which capability limits agent performance.
the staircase-shaped task this scoring rule flattens
-
Should reasoning benchmarks score final answers or reasoning traces?
Current reasoning benchmarks often credit plausible-looking reasoning steps even when final answers are wrong. Does measuring outcomes instead of traces reveal whether models actually solve problems, or does it miss important reasoning capability?
the same virtue of outcome verification, and its cost in resolution
-
How should we measure agent system performance beyond task success?
Current evaluation metrics collapse agent behavior into a single success score, hiding critical information about how agents operate. What dimensions—trajectory quality, memory use, context efficiency, verification cost—should benchmarks actually measure?
a single end-state number hides trajectory-level information; intermediate primitives are one recoverable slice
-
What causes failures in exploitation benchmarks?
Benchmark failures may come from safety refusals, tool misuse, or impossible tasks rather than lack of capability. This matters for assessing how dangerous AI agents could actually be.
a second reason the zero at the bottom of the scale is uninformative
-
Can action-level metrics alone expose contained attacks?
When a defense stops unsafe actions from executing, does measuring only the final action reveal whether the attack was blocked or never penetrated? This matters because different defense layers need different metrics to show what actually happened.
the defender-side case of an endpoint-only rate equating situations that differ upstream, met there by a second reading inside the pipeline
Related papers in this collection 8
Papers most semantically related to this note, ranked by cosine similarity in the embedding space.
- ExploitGym: Can AI Agents Turn Security Vulnerabilities into Real Attacks?
- Hack-Verifiable Terminal Bench: Evaluating Reward Hacking in Terminal Tasks
- Natural Emergent Misalignment From Reward Hacking In Production RL
- The Troy Moment of AI: Why Some Will Cheat and Some Will Follow?
- Trust propagation and structural containment in Multi-agent LLM pipelines
- BenchShield: Formal Model-Backed Instrumentation for Reward Integrity in LLM-Agent Evaluation Infrastructure
- Monitoring and Discovering Reward Hacking with Internal Representations during LLM Evaluations
- BAITBENCH: Measuring Agent Reward Hacking with Optional Shortcuts Planted in ML Tasks
Original note title
arbitrary code execution as the success criterion is clear and severe but discards partial exploit progress — intermediate primitives and sandbox escape go unscored