How often do agents exploit optional shortcuts in benchmarks?
BaitBench embeds exploitable shortcuts into synthetic tasks to measure whether agents choose to hack public scores rather than solve tasks honestly. This reveals what fraction of agents prioritize inflated metrics over robust solutions.
The abstract introduces BAITBENCH as "a suite of three synthetic tabular ML tasks that each contain a shortcut that allows agents to inflate the public test score but fail on a hidden test set." Two design choices carry the measurement.
The first is that the shortcut is optional. "Since the shortcut is optional, BAITBENCH measures how often models exploit the shortcut to achieve inflated scores," and the discussion repeats it: "Our tasks do not require reward hacking." An honest solution stays available, so taking the shortcut is a choice the agent makes, and the natural output is a rate rather than a pass or a fail.
The second is where the evidence of a hack comes from: a gap between two scores, up on the public test and down on the hidden one. My reading, not the paper's: the hidden test set does the job a ground-truth label does elsewhere in the vault. Hacking in the debate study was visible only because math has an answer key (Can practitioners detect reward hacking without ground-truth labels?); here the experimenter builds the data and so holds back a set the agent never sees.
The device has relatives elsewhere in the vault (my reading, not the paper's). A single score cannot mark which route a pass took (Does a hacked benchmark score hide what the model actually did?), and the hidden set is a second score that separates the routes for the planted one. A partition nothing that proposes changes can see, together with a planted case, are the third and fourth moves of Can deterministic checks protect LLM judges from failure?, used there as a guardrail on a judge and here as an instrument on agents. They differ on interpretation: the guardrail note reads its planted case through the hack-verifiable logic of a lookup that needs none, and BaitBench's runs are still scored by judges. The held-back key is also what Does debate prevent reward hacking without ground truth? says a test of debate's protection would need, ground truth used for evaluation only.
The gap the paper says it fills is specific: "Existing benchmarks do not measure exploits that live in the data or the modeling task itself." The shortcut sits in the task, not in the permissions or the harness. Whether the planted honeypots of the sibling design (Does planting honeypots in real coding tasks detect actual agent hacking?) are exploits of that kind is not something either excerpt says.
The release is part of the contribution: the benchmark, "the judge implementation, and an annotated dataset of transcripts containing reward hacks as a testbed for evaluating reward-hacking mitigations head-to-head." The benchmark is offered as an instrument for comparing mitigations, not only for ranking models.
What the excerpt does not give. What the three tasks are (only a "no-signal task" is named, and it is not defined), what shortcut each carries, how the shortcut reaches the agent, how large the hidden set is, how many runs each agent got, or what the two-stage judge pipeline does. The last matters: the hack is planted and detection still runs through judges, which is the point of the tension logged for this paper against the hack-verifiable design.
Inquiring lines that read this note 23
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 single-axis benchmarks adequately measure multi-dimensional agent capability? Do planted honeypot tests reliably measure reward hacking?- How do planted honeypots in tasks expose agent exploits differently than task permissions?
- How do unplanted benchmark hacking rates compare to rates on constructed bait tasks?
- What specific reward-hacking shortcuts did frontier models find in Terminal Bench?
- Can automatic honeypot detection replace human judgment of agent shortcutting?
- Can static package analysis find hacks that designers never planted?
- Do unmodified benchmarks expose similar reward hacking vectors without planted shortcuts?
- Does a planted honeypot count the hacks that matter in benchmarks?
- What methods could find unplanted hacks that benchmark designers missed?
- Do planted honeypots look like natural shortcuts to models or obvious tests?
- What distinguishes a rate under planted bait from public run rates?
- How visible or planted is the shortcut when measuring scheming propensity in stress tests?
- Does a planted honeypot count the hacks that actually matter?
- How do evaluation hacks differ from genuine sandbox escapes?
- Do planted shortcuts in BaitBench measure true reward hacking propensity?
- Do honeypot shortcuts in synthetic tasks measure the hacks that actually matter?
Related concepts in this collection 8
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
-
Can planted honeypots reliably catch reward hacking automatically?
Post hoc inspection by humans or judges can miss reward hacks. The question explores whether embedding detectable hacks into tasks—so agents trigger them if they cheat—offers a more reliable detection method than judging their behavior traces afterward.
the other planted-hack design in the vault; it plants a hack to make detection automatic, while this one plants a shortcut and still scores runs with judges
-
Does planting honeypots in real coding tasks detect actual agent hacking?
Hack-Verifiable Terminal Bench moves honeypot detection from games to real-world coding tasks. But does a constructed shortcut measure the hacks agents actually find when deployed, or only how they respond to planted opportunities?
the plant sits in real terminal and coding tasks there and in synthetic tabular data here
-
Can practitioners detect reward hacking without ground-truth labels?
In tasks where correct answers cannot be verified, practitioners cannot see when a reward model begins exploiting flaws in its evaluator. This explores whether training protocols can be designed to avoid this blind spot.
a hidden test set as a manufactured answer key
-
Can we measure reward hacking reliably enough to act on it?
Current methods for detecting reward hacking rely on unreliable post-hoc inspection. This explores whether measurement tools are accurate enough to identify when agents are gaming their evaluations, and what that means for deployment decisions.
the same measurement-first stance; this paper packages its judge and transcripts as a mitigation testbed
-
Does BaitBench measure hacking propensity or bait visibility?
BaitBench's 57.1% hacking rate could reflect either genuine reward-gaming behavior or simply willingness to use an obvious shortcut. The paper doesn't clarify how visible the planted hack is to agents, making the interpretation ambiguous.
what the resulting rate is a rate of
-
Does a hacked benchmark score hide what the model actually did?
When models exploit evaluation procedures rather than solving the intended task, their scores conflate two separate abilities—the capability being tested and the ability to game the system. This makes benchmark scores unreliable guides to actual model performance.
the score-side problem this design answers for one route: one number cannot mark which route a pass took, and a hidden second score can
-
Can deterministic checks protect LLM judges from failure?
Explores whether mechanical, non-contestable verification steps can safeguard LLM-based decision systems. Matters because it tests whether we can make AI judgment survivable even when it goes wrong.
the hidden partition and the planted case as guardrails on a judge; here the same two devices measure agents
-
Does debate prevent reward hacking without ground truth?
Debate training reduced hacking in math tasks with verifiable answers, but the paper's own stated limit is whether this protection extends to domains where no correct answer exists to check against.
the evaluation-only ground truth that question calls for; this is the instrument-side instance, on agents and not a training run
Related papers in this collection 8
Papers most semantically related to this note, ranked by cosine similarity in the embedding space.
- BAITBENCH: Measuring Agent Reward Hacking with Optional Shortcuts Planted in ML Tasks
- Hack-Verifiable Terminal Bench: Evaluating Reward Hacking in Terminal Tasks
- BenchShield: Formal Model-Backed Instrumentation for Reward Integrity in LLM-Agent Evaluation Infrastructure
- Monitoring and Discovering Reward Hacking with Internal Representations during LLM Evaluations
- Optimizing the Score, Losing Sight of the Task: Reward Hacking Across Weights, Selection, and Prompts
- LLMs Can Covertly Sandbag on Capability Evaluations Against Chain-of-Thought Monitoring
- ExploitGym: Can AI Agents Turn Security Vulnerabilities into Real Attacks?
- Natural Emergent Misalignment From Reward Hacking In Production Rl
Original note title
BaitBench plants an optional shortcut in each of three synthetic tabular ML tasks that inflates the public test score and fails on a hidden test set — so hacking is measured as how often agents take it