Abstract
Benchmark numbers about AI offensive capability drive headlines, procurement, and policy — and they are unusually easy to misread. The gap between “an agent exploited 87% of vulnerabilities” and what that sentence actually means is where most public reasoning goes wrong.
This closing publication is a reading guide. We explain what the major benchmarks measure, name four traps that inflate perceived capability, re-read the headline numbers with their fine print restored, and argue that the evaluation environment itself must be treated as a security boundary [5]. The goal is calibration: neither dismissal nor panic.
01Numbers drive policy — so read them like an adversary would
A benchmark result is a measurement under specific conditions. Strip the conditions and you get a slogan; keep them and you get intelligence.
The incidents in this series — especially GTG-1002 — make capability assessment operationally important: how much you invest in containment depends on how capable you believe autonomous attackers are. That belief should come from the literature read precisely, not from the most quotable number in it.
02What these benchmarks measure
Three complementary families, measuring different things:
- Exploitation-given-knowledge. Can an agent exploit a vulnerability it has been told about? (one-day work) [1]
- End-to-end real-world exploitation. Can an agent exploit real application CVEs under realistic conditions with reliable success criteria? (CVE-Bench) [3]
- Defense/attack evaluation for agents themselves. How exploitable are tool-using agents, and do defenses hold with utility intact? (AgentDojo) [4]
Conflating these is the primary error. “87% exploitation” and “≤13% resolution” are not contradictory — they measure different tasks under different conditions. The first is exploitation given the CVE description; the second is end-to-end resolution of real-world vulnerabilities. Both are true; only together are they informative.
03Four measurement traps
The most important distinction. Handing an agent a CVE description and asking it to exploit the flaw measures execution, not discovery. The one-day study makes this explicit: 87% with the description collapses to ~7% without it [1]. Headlines quote the 87%; the 7% is the number that describes autonomous discovery.
Models trained on internet-scale data may have seen the benchmark’s vulnerabilities, write-ups, or exploits. A high score can reflect memorization rather than reasoning — which is precisely why fresh, real-world-grounded benchmarks like CVE-Bench were built [3].
Agents are stochastic. A result reported as “best of many attempts” (pass@k) overstates the capability of a single autonomous run, while a single-attempt result may understate a determined attacker who simply retries. Always ask how many attempts a number represents.
What counted as success — a proof-of-concept, or full impact? How much human-built scaffolding (tools, prompts, orchestration) surrounded the model? Multi-agent coordination alone improved results up to 4.3× [2], so “the model’s capability” is inseparable from the harness around it.
04Reading the headline numbers
LLM Agents can Autonomously Exploit One-day Vulnerabilities
R. Fang, R. Bindu, A. Gupta, D. Kang — submitted 2024-04-11 · revised 2024-04-17
- Question
- Can an LLM agent exploit real one-day vulnerabilities, with and without the CVE description?
- Method
- A single agent with tools against ~15 real one-day vulnerabilities; the CVE description is the key ablation.
- Key finding
- 87% exploited with the description; ~7% without — an order-of-magnitude gap that pins the difference between execution and discovery.
- Reported metric
- 87% (given CVE) → 7% (without)
- Limitations
- Small set; older frontier model; success contingent on provided knowledge — not a discovery measurement.
- Why it matters
- The canonical example of trap #1. Cite the 7% when discussing autonomous discovery; cite the 87% when discussing execution of known exploits.
CVE-Bench: A Benchmark for AI Agents' Ability to Exploit Real-World Web Application Vulnerabilities
Y. Zhu, A. Kellermann, D. Bowman, P. Li, A. Gupta, et al. — submitted 2025-03-21 · revised 2025-06-24
- Question
- How well do agents resolve real-world web application CVEs under realistic, contamination-resistant conditions?
- Method
- A sandboxed benchmark grounded in critical-severity real CVEs with reliable success criteria, built to avoid CTF abstraction and memorization.
- Key finding
- State-of-the-art frameworks resolved up to 13% — capability is real but far from saturation on realistic targets.
- Reported metric
- ≤13% resolved end-to-end
- Limitations
- Benchmarks trail frontier models; a snapshot ceiling, not a permanent one.
- Why it matters
- The realistic-conditions counterweight to given-the-answer numbers; the ≤13% is the figure to quote for end-to-end autonomous exploitation today.
05The evaluation environment is itself a boundary
Cyber-Capable AI Agents: Vulnerabilities, Evaluation Containment, and Defensive Response
A. B. Siddik — submitted 2026-07-28 · revised 2026-08-01
- Question
- When AI agents run multi-step offensive-security tasks during evaluation, where do the security risks concentrate?
- Method
- An analysis of cyber-capable agent behavior that identifies vulnerability classes at the evaluation boundary and argues the evaluation environment must be integrated with containment controls.
- Key finding
- Names five recurring concern classes — multi-step offensive chains, objectives conflicting with sandbox boundaries, supply-chain/credential exposure, persistent command-and-control, and the speed of automated action — and argues the evaluation environment is part of the security boundary.
- Reported metric
- Qualitative synthesis (single-author preprint)
- Limitations
- A recent single-author preprint referencing incidents we could not independently corroborate from primary sources; we cite its framing, not any specific incident claim it makes.
- Why it matters
- Useful reframing: measuring offensive capability means running dangerous agents somewhere, and that somewhere must be contained. Evaluation is not a safe space by default.
We flag this source explicitly as a recent preprint whose incident references we did not verify against primary disclosures; we adopt only its structural argument — that testing a cyber-capable agent is itself a containment problem — which is sound regardless of the specific cases it cites. This is exactly the kind of provenance discipline the rest of this series demands of itself.
06Read the trend, not the point
The single most useful mental move is to stop treating any benchmark number as a fixed fact about “AI capability” and start reading the slope. Benchmarks are snapshots that models routinely surpass within quarters; CVE-Bench’s ≤13% is a statement about today’s frameworks on today’s models, not a ceiling [3]. The responsible planning posture is to assume the slope is upward and to build containment with headroom, while quoting today’s numbers accurately when describing today.
07How to use a benchmark number responsibly
| When someone cites a number, ask | Because |
|---|---|
| Given the answer, or discovered it? | Separates execution from discovery — the 87%/7% gap [1] |
| Single attempt or pass@k? | k-of-many overstates a single autonomous run |
| Could the model have memorized it? | Contamination inflates scores vs. real reasoning [3] |
| What was the success criterion? | PoC vs. full impact are very different claims |
| How much human scaffolding? | Harness/coordination can dominate the result [2] |
| What is the date and model? | Numbers are snapshots on a rising curve [3] |
Never quote an offensive-capability number without its conditions. For public or executive communication, pair the highest and most-realistic figures (e.g. “87% when handed the exploit; ~7% discovering it unaided; ≤13% end-to-end on realistic CVEs”) so the audience gets calibration rather than a slogan. For planning, assume the curve rises and size containment accordingly.
08Open questions
How much of the autonomous-capability signal is real reasoning versus information handed to the benchmark or memorized from training remains only partially answered — the 87%/7% gap is the clearest quantification we have [1]. Equally open: how to build contamination-proof, discovery-measuring benchmarks that stay valid as models train on the benchmarks themselves, and how to measure long-horizon, real-world capability of the kind GTG-1002 implied without running genuinely dangerous experiments.
09Limitations
- The headline numbers cited [1][3] come from specific models and dates and are already partially historical; treat them as trend anchors, not current ceilings.
- Multi-agent and scaffolding gains [2] mean "model capability" and "system capability" are conflated in most reporting; disentangling them is rarely done.
- The evaluation-boundary framing draws on a recent single-author preprint [5] whose incident references we did not independently verify; we use only its structural argument.
- Benchmark contamination is difficult to rule out and hard to quantify, so even careful numbers carry irreducible uncertainty.
10Where this leads
Calibrated capability estimates are the input to every design decision in this series: they justify containment architecture, egress control, and least privilege, and they put the GTG-1002 incident in proportion. For the full argument, return to the pillar: autonomous AI agent security.
—References
- R. Fang, R. Bindu, A. Gupta, D. Kang. LLM Agents can Autonomously Exploit One-day Vulnerabilities. arXiv:2404.08144 [cs.CR], 2024. https://arxiv.org/abs/2404.08144
- Y. Zhu, A. Kellermann, A. Gupta, P. Li, R. Fang, R. Bindu, D. Kang. Teams of LLM Agents can Exploit Zero-Day Vulnerabilities. arXiv:2406.01637 [cs.MA], 2024. https://arxiv.org/abs/2406.01637
- Y. Zhu, A. Kellermann, D. Bowman, P. Li, A. Gupta, et al.. CVE-Bench: A Benchmark for AI Agents' Ability to Exploit Real-World Web Application Vulnerabilities. arXiv:2503.17332 [cs.CR], 2025. https://arxiv.org/abs/2503.17332
- E. Debenedetti, J. Zhang, M. Balunović, L. Beurer-Kellner, M. Fischer, F. Tramèr. AgentDojo: A Dynamic Environment to Evaluate Prompt Injection Attacks and Defenses for LLM Agents. arXiv:2406.13352 [cs.CR], 2024. https://arxiv.org/abs/2406.13352
- A. B. Siddik. Cyber-Capable AI Agents: Vulnerabilities, Evaluation Containment, and Defensive Response. arXiv:2607.25379 [cs.AI], 2026. https://arxiv.org/abs/2607.25379
Engineering assistance
ProxyTech works with engineers and teams building production AI, cloud, security, data and distributed systems. If this analysis maps to a system you are designing or operating, we provide hands-on support and interview preparation for these domains.