A cyber capability evaluation tries to answer one narrow, measurable question: given a security task an attacker would actually face, how often can a model — or a human helped by the model — complete it? Not ‘does the model know about SQL injection’ but ‘can it find the injectable parameter, build a working payload, and exfiltrate the flag, end to end, in a real shell.’ That shift from knowledge to execution is what makes cyber evals hard to build and easy to get wrong. This piece stays at the measurement level: the task taxonomy, how a task is decomposed into scorable steps, the agentic harness that lets a chat model touch a terminal, the scoring math (flags, partial credit, pass@k), and the quantity that matters most for policy — the uplift a model gives a human over a no-model baseline — before closing on the pitfalls that silently corrupt every number: contamination, under-elicitation, brittleness.
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.
Mapping scores to thresholds and threat models
Numbers only inform decisions once they are tied to a threat model. The methodology works backward from a harm scenario — say, an intermediate actor autonomously discovering and exploiting a novel vulnerability — to the capabilities it requires, then to eval tasks that proxy each. A score matters insofar as its task proxies a real step in that chain.
This is the logic behind capability thresholds in responsible-scaling and preparedness frameworks: a pre-registered eval result — a solve rate or uplift crossing a defined line — triggers a specified response, such as heightened safeguards or a deployment hold. For the threshold to mean anything it must be set before the model is tested and justified against the threat model, not reverse-engineered to whatever the model scores. The eval, in this view, is not a report card; it is a tripwire, and its value depends on the wire being placed at a level that corresponds to real-world danger, not benchmark convenience.
Contamination: the silent score inflator
The gravest threat to a cyber-eval number is contamination — the tasks, or their published solutions, sitting in the model’s training data. Public CTF archives, competition write-ups, and CVE proof-of-concepts are exactly the kind of material scraped at scale, so a model may be recalling a walkthrough rather than reasoning to a solution. The measured capability is then an illusion that will not transfer to a genuinely novel target.
Mitigations stack rather than substitute. Author novel challenges that have never been published. Use held-out or post-cutoff tasks whose solutions could not have been in training. Probe for memorization directly by perturbing a known challenge (rename variables, change the flag, alter the offset) and watching whether performance collapses, which betrays recall over skill. And treat any suspiciously high score on a well-known public benchmark as a contamination hypothesis until ruled out. Because contamination inflates in one direction only, an uncorrected suite systematically overstates frontier capability — the most dangerous error direction for a safety measurement to make.
Brittleness, variance, and honest reporting
Agentic cyber runs are high-variance. Success can hinge on a single tool call, a lucky command ordering, or whether the harness happened to retry after a transient error, so two runs of the same model on the same task diverge. A responsible eval reports this: multiple seeds per task, confidence intervals on solve rates, and the raw n behind every percentage, so readers are not misled by a point estimate drawn from three runs.
Brittleness cuts both ways for interpretation. A capability that appears only under one exotic scaffold, once in twenty tries, is real but weak; one that shows up robustly across seeds, harnesses, and task variants is the one to take seriously. The discipline that keeps cyber evals honest is therefore to publish the whole apparatus — harness, tools, budgets, sample counts, elicitation effort, contamination controls, variance — alongside the number. A solve rate without that context is not a measurement; it is a claim, and in a domain this dual-use the difference is the entire point of doing the eval at all.