A typical evaluation proceeds in steps: (1) define a task set — realistic CTF challenges, vulnerable applications, exploitation tasks, or multi-stage operation scenarios; (2) wrap the model in an agent scaffold that grants tool access (shell, code interpreter, browser) and a reasoning–action–observation loop; (3) run it inside an isolated environment (container/VM) cut off from real systems; (4) measure outcomes — task completion rate, number of attempts, wall-clock time, token cost, and qualitative analysis of the attack chain; (5) run human-uplift studies comparing participants with vs. without model access; (6) map results onto capability thresholds in a safety policy and decide on mitigations or holding the deployment. Additionally, "offensive compliance" (whether the model fulfills explicitly malicious requests) and the False Refusal Rate (rate of wrongful refusals on benign requests) are measured.
Before OCE, judging whether an AI model posed a real cyber threat relied on intuition and isolated red-team anecdotes, making cross-model comparison and deployment decisions impossible. OCE provides objective, repeatable metrics (CTF solve rate, exploitation success, degree of autonomy) that let teams compare models, track capability growth over time, and set risk thresholds.
A set of realistic offensive tasks: CTF challenges (web, pwn, crypto, reversing, forensics), vulnerable applications and exploitation scenarios, often with intermediate subtasks to grade difficulty.
A layer wrapping the model in an agent loop (reasoning–action–observation) with tool access: bash shell, code interpreter, browser. Scaffold choice materially affects the result.
A controlled sandbox (container/VM/CTF range) cut off from real systems, where the model performs offensive actions without risk of real-world harm.
The scoring mechanism: task solve rate, attempts, time, cost, offensive compliance, False Refusal Rate, and human-subject studies measuring attacker uplift.
The same model's scores can differ dramatically depending on the scaffold and toolset, making cross-study comparison hard.
Public CTF tasks may appear in a model's training data, inflating scores relative to real, novel targets.
Overly aggressive safeguards cause refusals on benign cyber requests, understating both measured capability and utility.
The OCE tooling and results can themselves serve as an offensive playbook; they require controlled disclosure.
Meta releases CyberSecEval measuring insecure code generation and "offensive compliance" — whether a model fulfills explicitly malicious requests.
Extended with prompt injection, code-interpreter abuse, exploit generation, and the False Refusal Rate metric.
Adds evaluation of automated social engineering, scaling manual offensive operations, and autonomous cyber operations on Llama 3 models.
A Stanford-led team (Andy K. Zhang et al.) releases Cybench: 40 professional CTF tasks from 4 competitions, with subtasks and a standardized agent scaffold. Accepted as an ICLR 2025 Oral.
OpenAI's Preparedness Framework, Anthropic's Responsible Scaling Policy, and Google DeepMind's Frontier Safety Framework incorporate cyber evaluations as capability thresholds gating deployments; AI safety institutes (UK/US) run independent tests.
The kind of agent loop and toolset (structured bash, action-only, pseudoterminal, web search). Strongly affects the result.
Number of allowed attempts per task (pass@1 vs pass@k) and token/time budget — changes reported success rate.
Whether tasks are broken into guiding intermediate steps — affects measured difficulty.
OCE is not a model architecture but an evaluation process run conditionally (pre-deployment / when a capability threshold is crossed).
Individual tasks/CTFs can be evaluated in parallel across independent sandboxes; cost and API rate limits are the constraint.
OCE is an evaluation process around model inference and sandbox execution — independent of any specific accelerator; scale depends on model access and sandbox infrastructure.
