AI Security Benchmarks: A Reference to 10 Test Suites

“AI security benchmark” is a label stretched across at least four different measurement problems. A suite that scores how often a model produces harmful text answers nothing about whether an agent can be hijacked through a calendar invite, and a suite that scores agent hijacking answers nothing about whether a detector flags too much benign traffic. Picking the wrong one produces a number that is technically correct and completely irrelevant to the risk you were asked about.

This is a reference to the ten public suites that come up most often, what each actually measures, and the question each one cannot answer.

The suites at a glance

Suite	Family	Scale as published	Measures
AdvBench	Jailbreak / refusal	520 harmful behaviours, 574 harmful strings	Whether an optimised adversarial suffix elicits a harmful completion
HarmBench	Jailbreak / refusal	200 standard, 100 contextual, 100 copyright, 110 multimodal behaviours	Automated red teaming across behaviour types with a standard classifier
JailbreakBench	Jailbreak / refusal	100 curated behaviours (JBB-Behaviors)	Comparable attack and defence artefacts against a fixed small set
AgentDojo	Agent security	97 user tasks, 629 security test cases	Utility under attack and targeted injection success in tool-using agents
AgentHarm	Agent harm	110 base behaviours across 11 harm categories	Whether an agent completes harmful multi-step tasks, plus refusal behaviour
Agent-SafetyBench	Agent safety	349 environments, 2,000 test cases	Unsafe agent behaviour across 8 risk categories and 10 failure modes
SEC-bench	Security engineering	Auto-generated from real vulnerabilities	Whether an agent reproduces a vulnerability and patches it
CyberSecEval	Model cyber capability	Multiple task families across three releases	Insecure code generation, cyberattack helpfulness, injection, offensive capability
PINT	Detector accuracy	4,314 inputs, 3,016 English and 1,298 non-English	Prompt-injection detector accuracy on a neutral corpus
RAID	Detector robustness	Over 6 million generations across 11 models and 8 domains	Machine-generated-text detector robustness under adversarial edits

Scale figures are as reported by each project at publication. Several of these are living repositories and have grown since.

Jailbreak and refusal suites

These measure the model, in isolation, with no tools attached. They answer “will it say the thing”, not “will it do the thing”.

AdvBench originated with the greedy coordinate gradient attack work on universal adversarial suffixes. Its 520 harmful behaviours and 574 harmful strings became the default corpus for optimisation-based attacks, and its ubiquity is now also its weakness: it is thoroughly present in training data and in every subsequent paper’s baseline, so a low success rate against it can reflect memorisation as easily as robustness.

HarmBench was built to fix the evaluation half of the problem rather than the corpus half. It separates standard, contextual, copyright, and multimodal behaviours, and ships a trained classifier so that two teams grading the same completions land on the same verdict. If you care about comparing attacks against each other, the standardised judge matters more than the behaviour count.

JailbreakBench goes the other direction and deliberately keeps the behaviour set small, at 100 curated items drawn partly from AdvBench and the earlier Trojan Detection Challenge set and partly original. The value is the surrounding infrastructure: versioned attack artefacts, defence baselines, and a leaderboard, so a claimed improvement can be checked rather than taken on trust.

The distinctions between these three are load-bearing and routinely ignored, which is why results built on them so often fail to line up. That comparison is worked through in AdvBench, HarmBench, and JailbreakBench compared.

Agent suites

Once the model can call tools, the harmful-text question stops being the interesting one. These three suites split the agent problem into different halves, and none of them substitutes for another.

AgentDojo frames agent security as prompt injection against tool-using agents in realistic environments such as an email client, a banking site, and a travel booking flow. Its structure is the important part: it scores utility under attack alongside targeted attack success, so a defence that blocks every injection by crippling the agent scores badly rather than perfectly. That two-axis framing is the correct way to report agent robustness, and it is expanded on in measuring prompt-injection robustness in tool-using agents.

AgentHarm asks a different question: given an explicitly harmful multi-step task, does the agent carry it out. Its 110 base behaviours span 11 harm categories including fraud, cybercrime, disinformation, and harassment, and it reports refusal behaviour alongside completion, which keeps a model that refuses from being scored the same as a model that tries and fails.

Agent-SafetyBench is the broadest of the three, with 349 interaction environments and 2,000 test cases covering 8 risk categories and 10 recurring failure modes. Its contribution is coverage of unsafe behaviour that nobody attacked into existence: an agent that deletes the wrong records or leaks a credential through ordinary tool use, with no adversary in the loop at all. Assessments that only run adversarial suites systematically miss this class.

For the surrounding methodology, the guide to testing AI agent security covers how these suites fit into a scoped assessment.

Security engineering benchmarks

These score the model as a security practitioner rather than as a target.

SEC-bench is the one people are usually looking for when they search the name. Published in 2025 and appearing at NeurIPS, it is an automated framework that builds reproducible artefacts from real-world software vulnerabilities, using a multi-agent scaffold to construct repositories with build harnesses, reproduce the vulnerability in an isolated environment, and generate a gold patch. It then scores agents on two tasks: proof-of-concept generation and vulnerability patching. The headline figures are the useful part: the paper reports best-in-class success rates of 18.0 percent on PoC generation and 34.0 percent on patching, at a construction cost the authors put at $0.87 per instance. The gap between those two numbers is the finding worth carrying around, because patching a known, localised defect is a far easier task than demonstrating one from scratch.

Two naming collisions make this suite easy to cite wrongly. SecBench (arXiv:2412.20787), one hyphen away, is not an agent benchmark at all: it is 44,823 multiple-choice and 3,087 short-answer cybersecurity questions in Chinese and English, measuring what a model knows rather than what an agent can do. And SEC-bench Pro (arXiv:2605.26548) is the long-horizon successor to SEC-bench proper, covering 344 validated vulnerabilities in V8, SpiderMonkey, and the Linux kernel, with a top reported proof-of-concept reproduction rate of 58 percent. That figure is not comparable to SEC-bench’s 18.0 percent: different corpus, different task definition. Three papers, three unrelated numbers, near-identical names. Cite the arXiv identifier, not the name.

CyberSecEval, from Meta’s Purple Llama project, is the longest-running suite in this family, released across three papers between December 2023 and August 2024. The first release measured insecure code generation and helpfulness to cyberattackers; later releases added textual and visual prompt-injection evaluations, code-interpreter abuse, and offensive-capability assessments covering automated social engineering and autonomous operations. It is the right suite when the question is “does this model make attackers more effective”, and the wrong one when the question is “is my application safe”.

Detector benchmarks

Both of these evaluate a classifier rather than a generator, which means the false-positive rate is not optional.

PINT, Lakera’s Prompt Injection Test, exists because vendor detection claims were unfalsifiable. Its corpus of 4,314 inputs, split 3,016 English and 1,298 non-English, deliberately includes benign prompts and hard negatives so that a detector cannot score well by flagging everything. The multilingual share matters: detectors trained on English injection patterns commonly collapse on translated payloads, and a single-language benchmark hides that entirely.

RAID targets machine-generated-text detection, published at ACL 2024 with over 6 million generations spanning 11 models, 8 domains, 11 adversarial attacks, and 4 decoding strategies. Its contribution is the adversarial axis: detectors that look strong on clean text degrade sharply under paraphrase, homoglyph substitution, and whitespace perturbation. If a detector’s published accuracy has no adversarial condition attached, RAID is the benchmark that will embarrass it.

Building a corpus for a detector evaluation of your own, rather than consuming one of these, is covered in how to benchmark a prompt-injection detector honestly.

Choosing by the question you were actually asked

The question	The suite that answers it
Will this model produce harmful content under attack?	HarmBench, or JailbreakBench for comparability
Is my attack better than the published state of the art?	JailbreakBench, for its versioned artefacts
Can my agent be hijacked through the content it reads?	AgentDojo
Will my agent carry out an overtly harmful task?	AgentHarm
Will my agent do damage without anyone attacking it?	Agent-SafetyBench
Can this model find and fix real vulnerabilities?	SEC-bench
Does this model raise attacker capability?	CyberSecEval
Is my injection detector accurate enough to deploy?	PINT
Does my text detector survive evasion?	RAID

The comparability trap

Numbers from these suites travel badly. Four things break comparison, and all four are routinely omitted from published results.

• Corpus version. Every one of these repositories has changed since its paper. A score against an unnamed revision cannot be reproduced.
• The judge. HarmBench’s classifier, an LLM-as-judge, and a refusal-keyword matcher will assign three different success rates to the same completions. The judge is part of the measurement, not a detail.
• Attempt count. A rate computed over one attempt per behaviour and a rate computed over twenty-five are different quantities wearing the same label. Both belong in the report.
• Target configuration. System prompt, temperature, and any guardrail sitting in front of the model change the result more than most attack refinements do. The pinning discipline that fixes this is set out in reproducible LLM scanner benchmarks, and the arithmetic of a comparable success rate in benchmarking jailbreak resistance.

What none of them measure

No suite here evaluates your system. They evaluate models and agents against generic corpora, which is exactly what makes them comparable and exactly what makes them incomplete. None of them knows your tool schema, your tenant boundaries, your document formats, or your business rules, and those are where the findings with real consequences tend to sit.

The correct use is as a baseline layer: run a public suite for comparability, then run a bespoke corpus built from your own trust boundaries for relevance, and report the two separately rather than averaging them into a single score. How to construct that second half is covered in AI security testing: a method for LLM and agent systems, and the wider caution about benchmark scores predicting production behaviour is in why MMLU will not predict production quality.

For tooling that runs these corpora rather than defining them, see the open source LLM security scanner field guide and the 2026 red teaming tool comparison.