Robots Atlas>ROBOTS ATLAS
Evaluation

Offensive Cyber Eval

2023ActivePublished: 20 September 2026Updated: 20 September 2026Published
Key innovation
Turned the vague question "can this model help with a cyberattack?" into a repeatable, quantitative measurement of offensive capability on real tasks (CTFs, vulnerability exploitation, autonomous operations), used as a decision threshold in frontier-model safety policies.
Category
Evaluation
Abstraction level
Pattern
Operation level
Evaluation (runtime)System
Use cases
Frontier-model assessment before deployment (release gating)Setting capability thresholds in safety frameworks (Preparedness, RSP, FSF)Public comparative model benchmarks (Cybench, CyberSecEval)Human-uplift studies estimating attacker enhancementRed-teaming and autonomous cyber-operation testingRegulatory oversight and evaluations by AI safety institutes

How it works

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.

Problem solved

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.

Components

Task suite (CTF / exploitation tasks)Defines the measured capabilities and difficulty level

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.

Agent scaffoldLets the model actually act on the environment

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.

Isolated execution environmentEnsures safety and reproducibility of the test

A controlled sandbox (container/VM/CTF range) cut off from real systems, where the model performs offensive actions without risk of real-world harm.

Scoring & uplift measurementTranslates model behavior into comparable numbers and thresholds

The scoring mechanism: task solve rate, attempts, time, cost, offensive compliance, False Refusal Rate, and human-subject studies measuring attacker uplift.

Implementation

Implementation pitfalls
Sensitivity to agent scaffoldHigh

The same model's scores can differ dramatically depending on the scaffold and toolset, making cross-study comparison hard.

Fix:Report scaffold, attempt budget, and environment version; test multiple scaffolds.
Training-data contaminationHigh

Public CTF tasks may appear in a model's training data, inflating scores relative to real, novel targets.

Fix:Use fresh, private tasks and check for memorization.
False refusals (False Refusal Rate)Medium

Overly aggressive safeguards cause refusals on benign cyber requests, understating both measured capability and utility.

Fix:Measure FRR in parallel and separate lack-of-capability from refusal.
Dual-use and leakage riskHigh

The OCE tooling and results can themselves serve as an offensive playbook; they require controlled disclosure.

Fix:Restrict access, redact exploit details, and follow responsible disclosure.

Evolution

Original paper · 2023 · Meta AI / arXiv 2023 · Manish Bhatt
Purple Llama CyberSecEval: A Secure Coding Benchmark for Language Models
Manish Bhatt, Sahana Chennabasappa, Cyrus Nikolaidis, Shengye Wan, Ivan Evtimov
2023
CyberSecEval (Purple Llama) — first broad cyber benchmark
Inflection point

Meta releases CyberSecEval measuring insecure code generation and "offensive compliance" — whether a model fulfills explicitly malicious requests.

2024
CyberSecEval 2 — prompt injection, exploitation, FRR

Extended with prompt injection, code-interpreter abuse, exploit generation, and the False Refusal Rate metric.

2024
CyberSecEval 3 — autonomous operations and social engineering

Adds evaluation of automated social engineering, scaling manual offensive operations, and autonomous cyber operations on Llama 3 models.

2024
Cybench — professional CTF as an agent benchmark
Inflection point

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.

2024
Cyber in frontier-model safety frameworks
Inflection point

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.

Hyperparameters (configurable axes)

Agent scaffoldCritical

The kind of agent loop and toolset (structured bash, action-only, pseudoterminal, web search). Strongly affects the result.

Attempts / pass@kHigh

Number of allowed attempts per task (pass@1 vs pass@k) and token/time budget — changes reported success rate.

Subtask decompositionMedium

Whether tasks are broken into guiding intermediate steps — affects measured difficulty.

Execution paradigm

Primary mode
Conditional

OCE is not a model architecture but an evaluation process run conditionally (pre-deployment / when a capability threshold is crossed).

Activation pattern
Input dependent

Parallelism

Parallelism level
Fully parallel

Individual tasks/CTFs can be evaluated in parallel across independent sandboxes; cost and API rate limits are the constraint.

Scope
Inference

Hardware requirements

Primary

OCE is an evaluation process around model inference and sandbox execution — independent of any specific accelerator; scale depends on model access and sandbox infrastructure.