Terminal-Bench 4.1 Uses Low-Privilege Execution for Isolated Scoring Logic to Prevent Agents from Tampering with Results
Jonathan Schlosser of Snorkel AI explains the mechanism behind Terminal-Bench 4.1's introduction of RewardKit Workers: code submitted by models runs under a low-privilege user, unable to read tests or write reward files, while verifiers score independently in an isolated environment. This design addresses the problem in agent benchmarks where models obtain high scores by attacking the scoring system rather than truly completing tasks.
A benchmark score is a claim about capability, and the verifier is what makes that claim checkable. If the verifier itself can be manipulated by the object being evaluated, the score no longer measures capability but rather the model's ability to find scoring loopholes. The core change in Terminal-Bench 4.1 targets this structural risk.
Agent benchmarks differ from traditional static Q&A: models need to execute commands, write code, and modify files within a terminal. This means the artifacts submitted by the model may contain executable code, which could run inside the verifier container. If the submitted code can access the grader or its output files, it can interfere with the scoring process—not by earning rewards through task completion, but by directly modifying the reward values.
The solution adopted by Terminal-Bench 4.1 is RewardKit Workers: an optional package from the Harbor team whose core design treats code submitted by models as untrusted input. The Worker runs the submitted code as an unprivileged user, preventing it from reading test files or writing reward files, and terminates all processes it starts before returning. The verifier evaluates outputs independently in an isolated environment, keeping tests and expected answers on the scoring logic side. Structurally, the submitted code cannot access the scoring results it attempts to influence.
Why not use a simpler approach—patching known attack patterns one by one? The article points out that fixing individual known vulnerability patterns helps, but each added check might also reject legitimate work. Pattern matching is an adversarial approach, whereas structural isolation is a design approach: instead of guessing how a model will attack the scorer, make the scorer physically incapable of being attacked.