What a cyber-capability eval actually measures
The object of measurement is task completion under realistic conditions, not recited knowledge. A multiple-choice quiz on CVE trivia measures memorization; a cyber-capability eval hands the model a live target and asks it to do something — recover a hidden flag, locate an exploitable bug. The unit of credit is a verifiable outcome, usually a secret string (a ‘flag’) that only appears if the objective was met.
This framing forces three design commitments. Tasks must be objectively gradable — a flag either matches or it does not, with no human judgment in the loop. They must be executable: the model needs a real environment (a container, a network, a shell) to act in, because reasoning about an exploit and landing it are different skills. And they must span a difficulty range, so a single number is not reported when the reality is ‘solves the trivial ones, fails the ones that matter.’
The task taxonomy: CTF, vuln discovery, exploit dev
Cyber tasks cluster into three families, each probing a different rung of the offensive chain. Capture-the-flag (CTF) challenges are the workhorse: self-contained puzzles across categories — web, binary exploitation (pwn), reverse engineering, cryptography, forensics — each with a hidden flag that proves success — already objective, already graded, and already difficulty-tiered by the competitive-security community.
Vulnerability discovery asks a narrower question: given a codebase or binary, can the model locate a real, exploitable flaw? Here the ground truth is a known bug (often a patched CVE), and success is identifying it — ideally with a proof-of-concept trigger, not just a line number. Exploit development is the hardest rung: turn a known vulnerability into reliable code execution, chaining primitives (a leak, a write, control-flow hijack) into a working exploit. Measured together, the three families let you say where on the offensive chain a model is strong and where it collapses — a far more useful signal than one blended score.
Decomposing a task into scorable sub-steps
A single pass/fail on a hard challenge wastes information: a model that gets 90% of the way to a flag scores identically to one that does nothing. Decomposition fixes this by splitting each task into an ordered chain of milestones, each independently checkable. A web-exploitation task might decompose into: reconnaissance identifies the vulnerable endpoint → the injection type is correctly classified → a payload bypasses the filter → the flag is exfiltrated.
Milestone scoring turns a binary into a progress curve. If a task has m milestones and a run reaches milestone k, partial credit is k / m — the deepest milestone reached, since later milestones presuppose earlier ones. Aggregated across a suite, this exposes systematic walls: models that reliably find bugs but fail to weaponize them pile up at the exploitation milestone. That pattern is invisible to a flag-only score, and it is exactly the structure a threat model cares about.
The agentic harness: from chat model to operator
A language model on its own emits text; a cyber task requires actions in a world. The bridge is an agentic harness — a scaffold that exposes tools (run a shell command, read a file, send an HTTP request), feeds the tool output back into the context, and loops until the model declares done or a budget is hit — turning next-token prediction into an observe–act cycle.
The harness is not neutral apparatus — it is part of the capability being measured, and this is the most under-appreciated point in cyber evals. The same weights score wildly differently under a bare one-shot prompt versus a harness offering a Python interpreter, a persistent shell, retry-on-error, and a planning scratchpad. So a result is only interpretable if the harness is reported with it: tools, step limit, token budget, and whether the model can recover from failed commands. Two labs quoting different solve rates on ‘the same benchmark’ are often just quoting different harnesses.
Flag-based scoring and why it is trusted
The atomic measurement is flag verification. Each challenge hides a string — say flag{...} — hard to guess and only recoverable by completing the objective. The grader does an exact match against the submission; no rubric, no LLM judge, no partial-string leniency at this layer.
This is what gives CTF-derived evals their unusual credibility. Most capability benchmarks lean on a model or a human to judge free-form answers, injecting noise and bias. A flag either matches or it does not, so the false-positive rate is essentially the probability of guessing a high-entropy secret — negligible. The cost is that flag matching is all-or-nothing at the task level, which is why milestone decomposition is layered on top: flags give an incorruptible signal of full success, milestones recover the graded signal of partial progress. Good cyber evals use both, at different granularities.
Pass@k, sampling, and the elicitation problem
Capability is a distribution, not a point. A model that solves a task on 1 run in 10 still can solve it, and for a security threat that intermittent success is what counts — an attacker simply retries. The standard estimator is pass@k: the probability that at least one of k independent attempts succeeds. From n sampled runs of which c succeed, the unbiased estimator is pass@k = 1 − C(n−c, k) / C(n, k), avoiding the high-variance trap of sampling just k and checking.
Reporting pass@1 alone understates a persistent adversary; a large pass@k alone overstates a one-shot user. Both belong in the table. The deeper issue is elicitation: a ‘fail’ may mean the capability is absent, or merely that the prompt, tools, or budget failed to surface it. Because evals set a lower bound — you can prove a model can do something, never that it truly cannot — serious cyber evals invest in strong elicitation (better scaffolds, fine-tuning, more attempts) before concluding a capability is missing.
Uplift: the quantity that actually matters
For risk assessment, absolute solve rate is the wrong number. The question policymakers ask is marginal: how much more dangerous does this model make a given human? That is uplift — the difference in task success between people working with the model and a matched control group working without it. Formally, for a cohort at skill level L, uplift(L) = P(success | model, L) − P(success | baseline, L).
Uplift is measured with a controlled human study, because the threat is a human–model team, not the model alone. Two details decide whether the number means anything. First, the baseline: uplift over ‘a blank page’ is meaningless; the honest control is a human with ordinary tools — a search engine, public write-ups, standard software. Second, the cohort: uplift is typically largest for intermediate practitioners (who can act on guidance they could not generate) and smallest for both novices and experts, so a single averaged uplift hides the shape that matters. Reporting uplift(L) as a curve against a realistic baseline is the difference between a defensible finding and a headline.