Hack-Verifiable Terminal Bench: Evaluating Reward Hacking in Terminal Tasks
As agents grow more capable and autonomous, their tendency to reward hack, satisfying a task’s checks while violating its intent, becomes an increasingly important failure mode. Measuring reward hacking is itself challenging, as detection typically relies on human inspection or LLM judges, both of which can be unreliable. The hack-verifiable environments (HVE) methodology addresses this challenge by embedding detectable hacks into tasks, allowing reward hacks to be identified automatically and reliably. In this work, we adapt HVE to Terminal Bench, a leading benchmark of real-world terminal and coding tasks, and introduce Hack-Verifiable Terminal Bench (HVTB). Using HVTB, we measure rewardhacking rates across frontier models and study whether prompts with varying amounts of information on the hack can mitigate this behavior. This lets us test whether prompting can prevent not only known reward-hacking strategies, but also “unknown unknown” exploits that the prompt does not anticipate. We release all environments and agent traces at https://majoroth.github.io/hack-verifiable-environments/hvtb.
Introduction. A central challenge in deploying autonomous agents is reward hacking, where agents achieve apparent success while failing to accomplish the true underlying task. This issue demands our attention: as recent reports demonstrate, frontier models are capable of hacking their own evaluation environments, exploiting previously unknown vulnerabilities to complete tasks in unintended ways [1, 2, 3, 4, 5]. Mitigating this starts with measuring it, yet few benchmarks do so reliably. We introduce Hack-Verifiable Terminal Bench (HVTB), which brings the hack-verifiable environments (HVE) methodology [6], where honeypots are planted so that hacks are detected automatically rather than judged post hoc, to Terminal Bench [7]. Whereas prior work instantiated HVE on game-like environments, HVTB targets real-world coding tasks, the setting in which agents are actually deployed.
Discussion / Conclusion. As models become more autonomous, evaluating their reliability becomes increasingly important, with reward hacking being a key consideration in assessing the readiness of agents for deployment. However, current methodologies for evaluating reward hacking remain underdeveloped, often relying on post-hoc inspection of agent reasoning traces by LLM judges. We believe that effective mitigation must begin with reliable and scalable measurement of this phenomenon. This work represents a first step toward that end by evaluating reward hacking on challenging, real-world terminal and coding tasks.
Lines of inquiry this paper opens 24
Research framings built by reading the notes related to this paper — the questions it feeds into.
How do pretraining biases affect reward signal effectiveness in RLVR?- Can system-level engineering fixes replace hand-designed reward heuristics entirely?
- What makes a reward evolution schedule fast enough to outpace exploitation?
- How should harness scaffolding be treated as a first-class object?
- What persistent failures remain unsolved despite harness evolution efforts?
- What feedback signals matter most during harness evolution search?
- How does reward hacking emerge when agents optimize fixed proxy objectives?
- Why does length exploitation emerge as a reward hacking failure in distillation?
- What are AIDE2's hidden evaluations hidden from, and what makes a win untrustworthy?
- Can infrastructure monitoring catch reward hacking that scores cannot detect?
- Can hidden test sets reveal reward hacking that single public scores conceal?
- How is a reward hack defined and labeled across different benchmark studies?
- What determines the ground truth when detecting reward hacking in model evaluations?
- What specific reward-hacking shortcuts did frontier models find in Terminal Bench?
- How does reward hacking differ from errors in the scoring function itself?
- What rates of reward hacking occur in frontier language model benchmarks?
- What evidence should benchmark operators attach to completion claims?
- When does an agent's action earlier in the loop change what a scorer reads later?
- What shortcuts in data or models let agents inflate benchmark scores?
- What agent evaluation dimensions beyond task success does a single number hide?