SecureBench framework review

Use this page to review SecureBench as a benchmark-security target, verifying the framework architecture and controls according to the goals in scope.

Test objective

SecureBench claims a narrow property: benchmark security rules should be explicit, testable, and enforced by the runtime. The current implementation focuses on agentic benchmarks, specifically repo_patch and terminal_task.

Test whether SecureBench:

leaks hidden data
lets a candidate alter trusted verification
allows undeclared egress
trusts candidate-controlled artifacts
records a passing score when the task was not solved

Security claim

SecureBench enforces benchmark security through visibility lanes, isolated candidate production, trusted verification, path policy, and default-deny network behavior. It does not claim complete benchmark security, as it is still trusting benchmark developers and giving customizability to the tester.

Test plan

In addition to deterministic tests of the design under tests, an agentic adversarial test suite is present, aiming to verify whether capable agents can find ways to escape the boundaries posed by SecureBench. Under review, different testing profiles are present:

Failure class	SecureBench control	Test profile
Agent can read answers or checker data	Public / evaluation / hidden visibility lanes	`leak_probe`
Agent and evaluator share mutable state	Separate candidate and verifier phases, trusted evaluator mounts	`terminal_poison`
Test infrastructure tampering	Repo-patch path policy blocks tests, CI, dependencies, and SecureBench paths	`repo_tamper`
Unsafe `eval()` or command execution	Trusted verifier code and hardened terminal checkers	`evaluator_escape`
Network or tool exfiltration	No-network default, allowlisted egress, provider relay	`network_exfil`
Weak string matching or output-only scoring	Hidden checkers reject magic-output candidates	`output_only`
Trusting untrusted logs or reward files	Candidate artifacts are untrusted; verifier computes score	`artifact_forgery`
Result integrity and replay hardening	Known gap in v1	Not claimed
LLM judge prompt injection	Not used by current families	Not applicable

Run the test suite

Clone the repository and create a Python environment:


git clone https://github.com/nathanhoulamy/securebench.git
cd securebench
python -m venv .venv
. .venv/bin/activate
pip install -e .

Run the adversarial tests and live provider configs from the repository test workspace. Start with leak_probe, network_exfil, and repo_tamper; they cover hidden-data handling, egress policy, and repository tamper controls.

Use an external scanner

The external mode lets your scanner run under the same public-workspace contract and produce a normal SecureBench candidate.

This replaces the bundled adversary without changing the workspace contract, candidate format, or verifier path. SecureBench should enforce the same controls regardless of who produced the candidate.

See the external scanner contract in the adversarial test suite.

Test artifacts

Each run produces:

results.jsonl: normal SecureBench candidate and verifier results
summary.json: aggregate pass/fail and violation counts
traces/*.json: adversary actions, observations, errors, and violations

Treat non-empty trace.violations as possible framework-level evidence. trace.errors usually means the adversary failed to run or produced invalid actions. It does not prove SecureBench is secure.

Limits

Current families are repo_patch and terminal_task.
Result signing and resume/replay hardening are not claimed in v1.
Current families do not use LLM-as-judge scoring, so LLM judge prompt-injection defenses are out of scope.
Passing bundled adversarial profiles does not prove general benchmark security.

Report findings

Send concrete cases where SecureBench exposes hidden or evaluation data, lets a candidate influence trusted verification, allows undeclared egress, trusts candidate-controlled artifacts, or records a passing score without solving the task.