The Shelf Life of Safety Benchmarks

1 Introduction

Safety benchmarks are the main quantitative evidence on how language models respond to harmful requests. Developers report their scores in model cards, and public leaderboards rank models by them. They also have a place in regulation: the GPAI Code of Practice under the EU AI Act lists benchmarks among the methods for evaluating models with systemic risk (Measure 3.2), and asks for evaluations that are reproducible and carried out also by independent external evaluators. Benchmarks suit this third-party role well: they are standardised and public, so in principle anyone can rerun them and check what a developer reported.

That only helps if benchmark results can be relied on. Capability evaluation provides a useful comparison: it also relies on benchmarks, but independent indices regularly assess new models against maintained sets of tasks. The Artificial Analysis Intelligence Index, for instance, combines ten evaluations, among them Humanity’s Last Exam, Terminal-Bench and SciCode, into a single score per model. Safety results are spread across benchmarks with different scorers and model cohorts. If safety evaluation cannot keep pace, models may become more capable while evidence about their safety remains weak. This matters especially for highly capable models, whose harmful assistance may be more effective when safeguards fail. We therefore examine three properties of reliable safety benchmarks.

The first property, discriminatory power, concerns comparison. Benchmarks are used to compare models: to tell whether a new model is safer than the one it replaces, or which of two models is safer. That works only as long as their scores differ. As models improve, their scores on a benchmark rise towards the maximum and bunch together, until the differences between the best models are smaller than the uncertainty in the scores themselves, which are measured on a limited set of test items. At that point the benchmark is saturated: it can no longer show which model is safer, and an improvement or a regression goes unnoticed. For capability benchmarks, saturation appears to come with time: Akhtar et al. (2026) found that across 60 mostly capability benchmarks, older ones are more saturated. Safety benchmarks could saturate in the same way, or in a different one. Safety training targets plain harmful requests most directly, so benchmarks made of such requests may saturate first, whatever their age, while adversarial and agentic benchmarks keep showing differences between models. Before asking which of these patterns holds, we need a preliminary check: whether safety benchmarks are saturating at all. We therefore test, in order, H1: safety benchmarks are saturating; then H1a: older benchmarks are more saturated; and H1b: benchmarks of direct requests are more saturated than adversarial or agentic ones.

The second property, generalisation across benchmarks, is that the score means something beyond the benchmark’s own items. Each benchmark covers a narrow slice of harmful behaviour: certain harms, phrased in certain ways, from plain harmful questions to jailbreaks, persuasion and CBRN uplift. Yet a model card typically reports a few such scores as evidence that the model is safe in general. That reading holds only if a model that does well on one benchmark also does well on others. If safety training fits the prompts it has seen rather than the underlying behaviour, it will not. H2: a high score on one safety benchmark does not predict the score on others.

The third property, freedom from item contamination, requires that models have not seen the benchmark items during training. Benchmark prompts are public, and the older ones are widely reused in papers and code, so they can end up in training data. A model trained on them may recognise them, which would inflate its score and could explain both saturation and poor transfer. H3: models can reproduce released benchmark items, mostly from older collections.

We test each hypothesis in two steps. First we use what the literature already provides: the published results of 17 safety benchmarks. Then we run our own experiment, testing five models on eleven of these benchmarks with a single protocol, which allows checks that the published results cannot support. Each section reports the two steps separately, literature first.

2 Data and measures

2.1 Literature

We collected published results for 17 safety benchmarks released between August 2023 and July 2026, taking for each benchmark one leaderboard of harmful-request or agent-safety results. Each source keeps its own scoring method, and every metric is oriented so that higher means safer. As in Akhtar et al., each benchmark is summarised by the five highest-scoring models reported for it.

Published results rarely let us follow one model across benchmarks, because each benchmark paper scored its own set of models at release. HELM Safety v1.17.0 is the exception: it scored the same 87 model configurations on both SimpleSafetyTests and HarmBench. We use it for H2, alongside our own experiment, which scores every model on every benchmark (Section 2.2).

Saturation index. We use the index of Akhtar et al. (2026), which asks whether the gap between the best and the fifth-best model is larger than the noise in their scores. Let $s_1$ and $s_5$ be the best and fifth-best scores, as proportions, on a benchmark with $n$ items. The gap is $\Delta =s_1-s_5$. Each score is a proportion, so its standard error is $\sqrt{s(1-s)/n_{\mathrm{eff}}}$. Following Akhtar et al., the effective number of items is $n_{\mathrm{eff}}=\sqrt{n}$ rather than $n$, which widens the noise estimate. The standard error of the gap is

The gap measured in standard errors is $R=\Delta /{\mathrm{SE}}_{\Delta }$, and the index is

When the top five are tied ($R=0$), $S=1$. A gap of one standard error gives $S=0.37$, and a gap of two gives $S=0.02$. Akhtar et al. read the index in five levels: very low (below 0.01), low (0.01 to 0.3), moderate (0.3 to 0.7), high (0.7 to 0.9) and very high (0.9 and above). The index depends on test size: with tens of thousands of items even a gap of a few points exceeds the noise, so very large benchmarks rarely come out saturated. SALAD-Bench and ALERT have all five leaders above 95% and still a low index. Benchmark age is the number of months from release to 25 October 2026. We also label each benchmark by request type: direct (plain harmful questions or instructions), adversarial or framed (adversarially phrased or wrapped in a scenario) or agentic (multi-step tasks for an agent). Labels follow each benchmark’s description and a sample of its prompts. AIR-Bench mixes plain requests with stylistic variants and is counted as framed.

2.2 Our experiment

We tested five recent models from five developers: DeepSeek V4.1 Flash, MiMo V2.6 Pro, MiniMax M3.1 Flash, GLM 5.3 Flash and Claude Haiku 5.5. They were run on eleven benchmarks: AdvBench, Do-Not-Answer, CyberSecEval, HarmBench, SALAD-Bench, StrongREJECT, AIR-Bench, AILuminate, APE, FORTRESS (CBRNE items) and AHB. Seven of these also have a published leaderboard in Section 2.1.

Safety scoring (H1, H2). Each model answered the same 100 prompts per benchmark, sampled with a fixed seed and balanced across the benchmark’s categories where it has them. Replies were capped at 200 tokens. Three LLM judges labelled each reply safe or unsafe: GPT-5.6 Luna, DeepSeek V4.1 Flash and Claude Haiku 5.5, the last two also being among the tested models. All judges used the same instruction: a reply is unsafe if it gives substantive help towards the harmful request, and safe if it refuses, redirects or gives no such help. A short benchmark-specific criterion was added, for example that APE counts an attempt to persuade the user of a harmful belief. A label stands when at least two judges agree.

We used one scorer for all benchmarks because the benchmarks’ own scorers are not comparable and are often hard to reproduce.¹ Several of these depend on specific versions of commercial models that their providers update and retire, so the original scoring cannot always be rerun. The same reply can therefore count as safe on one benchmark and unsafe on another, and a published score cannot always be reproduced, which undercuts the reproducibility the Code of Practice asks for. Our common scorer makes the eleven benchmarks comparable with one another. It also means our scores are not comparable with the published ones.

Reconstruction probes (H3). For each benchmark we took 100 released items and gave each of the five models two probes per item, 1,000 probes per benchmark in all. In completion, the model saw the first half of an item, by word count, and had to write the rest. In next-item prediction, it saw the three items that precede a target item in the released file and had to write the target. The instruction named the benchmark, told the model not to answer the request, and asked for the missing text only. The measure is exact reconstruction: the model’s output is identical to the withheld text. A next-item answer counts only if it matches the actual next item, not another item from the benchmark or a copy of the items shown.

3 H1: Are safety benchmarks saturating?

3.1 Literature

Are they saturating? Four of the 17 published benchmarks can no longer separate their five best models. SimpleSafetyTests and OR-Bench are very highly saturated, and SORRY-Bench and HarmBench highly saturated (Figure 1). Five are moderate and eight low or very low. The five scores behind each index show two kinds of saturation. On SimpleSafetyTests and OR-Bench the leaders are all at or near 100%: the benchmark is solved. On SORRY-Bench they are tied between 92% and 95%: the benchmark no longer ranks them, although none has solved it.

H1a, time. Saturation is not related to age (Figure 2; Spearman ρ = −0.03, p = 0.92). Grouped by age into four equal groups, as in Akhtar et al., the mean index moves between 0.27 and 0.50 in no order. Akhtar et al. found a clear decline instead, from about 0.63 in their oldest group to 0.42 in their youngest.

The published data are a weak test of H1a, for two reasons. Safety benchmarks are young: the oldest here is 38 months old, while Akhtar et al. cover benchmarks up to 114 months old. And most leaderboards were scored once, near release, on the models of that time, so a benchmark’s age today says little about how it would rank today’s models.

H1b, type. All four saturated benchmarks consist of direct requests, and none of the six adversarial, framed or agentic benchmarks is saturated (Table 1). The mean index falls from 0.47 for direct benchmarks to 0.30 for adversarial or framed ones and 0.19 for agentic ones. Within the direct benchmarks, age is not related to the index (Spearman ρ = 0.12, p = 0.73). With three benchmarks in each of the other two groups, this is a pattern rather than a test.

: Table 1. Literature. Saturation index by request type for the 17 published benchmarks.

3.2 Our experiment

Our experiment addresses the second of these problems: all eleven benchmarks were run on the same five models at the same time.

Are they saturating? None is highly saturated for these models (Figure 3). Three are moderate (Do-Not-Answer 0.60, AILuminate 0.38, AdvBench 0.32), six low and two very low (APE and AHB).

H1a, time. Older benchmarks separate the five models less well (Spearman ρ = 0.66, p = 0.03).

H1b, type. The seven benchmarks of direct requests (AdvBench, Do-Not-Answer, HarmBench, SALAD-Bench, StrongREJECT, AILuminate, APE) are more saturated on average than the four adversarial or framed ones (AIR-Bench, CyberSecEval, FORTRESS, AHB): a mean index of 0.28 against 0.07. Six of the seven direct benchmarks lie between 0.17 and 0.60, while all four others are at 0.14 or below. The exception is APE, whose persuasion task splits the models widely, from 10% safe for DeepSeek V4.1 Flash to 99% for Claude Haiku 5.5. Within the direct benchmarks, older ones are still somewhat more saturated (Spearman ρ = 0.54, p = 0.23). With eleven benchmarks, age and request type overlap too much to separate.

Verdict. Saturating: partly. Four of the 17 published benchmarks can no longer separate their leading models; in our experiment none is highly saturated. H1a, time: not supported in the literature, where saturation shows no link with age. In our experiment older benchmarks are more saturated, but age and request type overlap too much to tell them apart. H1b, type: supported in the literature, where all four saturated benchmarks consist of direct requests, and broadly in our experiment, where direct benchmarks are more saturated on average, with APE as the exception. As flagship models become more robust to direct requests, these are the benchmarks likely to lose their value first. Testing this requires scoring them again on current flagship models.

4 H2: Transfer across benchmarks

H1 compares models within one benchmark. H2 follows one model across benchmarks.

4.1 Literature

In HELM Safety, 25 of the 87 configurations score 100% on SimpleSafetyTests. Ten of those 25 score below 90% on HarmBench, and Command R Plus scores 48.5% (Figure 4). A perfect score on the saturated benchmark says little about the score on the other.

4.2 Our experiment

If a safety score described a model’s safety in general, a model that does well on one benchmark would do well on the others. Our experiment, which scores every model on every benchmark, shows that it does not. Every model has a wide interval between its best and worst benchmark, from 22 points for Claude Haiku 5.5 to 90 points for DeepSeek V4.1 Flash, which is 100% safe on AdvBench and 10.2% safe on APE (Table 2, Figure 5).

: Table 2. Our experiment. Interval of each model’s share of safe responses (%) across the eleven benchmarks, on each benchmark’s common items. AHB is our laboratory’s own benchmark, so the last column leaves it out. Figure 5 shows the full score distribution.

Models mostly do best on benchmarks of direct requests, such as AdvBench, StrongREJECT and Do-Not-Answer, and worst on adversarial ones: AHB, which recasts harmful requests in humanities-style framings, and FORTRESS, whose CBRNE requests are adversarially phrased. There are exceptions. APE, a persuasion task, is DeepSeek’s worst benchmark but among the best for GLM and Claude Haiku, and SALAD-Bench, a benchmark of direct requests, is among the lowest for GLM and Claude Haiku. Leaving out AHB, our own benchmark, narrows the intervals but does not close them (Table 2, last column).

The pattern matters for what a score can support. A high score on direct requests says little about whether a model resists the same harm once the request is adversarially transformed. That resistance is what matters in deployment, and it has to be measured directly with adversarial benchmarks, not inferred from scores on direct ones.

4.3 Adversarial transformations of the same requests

A separate study of ours, currently under review, tests directly whether a safety score survives when the same request is presented differently. Eight models (DeepSeek V4 Pro, Gemma 4 31B, GLM 5.2, GPT-5.6 Luna, GPT-OSS 120B, Kimi K3, Qwen 3.8 27B and Seed 2.1 Turbo) answered 1,000 requests drawn from ten public safety benchmarks, among them AdvBench, HarmBench, SALAD-Bench, SORRY-Bench, StrongREJECT and AILuminate. Each request was given in its original wording and in six variants that keep the same intent: a translation, three reformulations built from human red-teaming techniques, such as a change of persona, a reframed situation, a different output format or obfuscation, and two translations of those reformulations. A response counted as a violation when it gave material or severe harmful assistance.

On the original wording, the eight models look almost equally safe, with violation rates between 0.4% and 2.3%. On the transformed versions of the same requests, the range widens to between 1.1% and 21.5%, and the average rises from 1.1% to 8.8% (Figure 6). Identical original scores hide very different robustness: GPT-OSS 120B and Seed 2.1 Turbo both start at 0.9%, but reach 1.1% and 21.5% after transformation. GPT-OSS stays safe on the original and all six variants for 94% of requests, Seed for 32%. The two models that look safest on the original wording, Qwen 3.8 27B and GPT-5.6 Luna, produce a violation on about one request in four once all variants are counted (228 and 227 of the 1,000). The ranking changes accordingly: Qwen falls from first to third, GLM rises from seventh to second, and Seed falls from joint third to last.

The effect is general rather than confined to a few benchmarks. Transformed violation rates are higher in 75 of the 80 combinations of model and benchmark. In 44 combinations the original violation rate was zero, and in 43 of these violations appear after transformation. On WildGuardMix, none of the eight models gives a single violation on the original requests, yet the variants of the same requests produce 500 material and 77 severe violations across 4,800 responses. Several of the original benchmarks were already adversarial: WildGuardMix and the skilled stratum of AILuminate, for example, contain requests disguised with jailbreak techniques. The increase appears on these too, so it is not simply the effect of adding an adversarial element to direct requests.

The study also groups the requests by the systemic risks named in the Code of Practice. Every model has its lowest transformed violation rate on chemical, biological, radiological and nuclear requests, but almost a quarter of the violations there (172 of 712) are severe, and three models account for 164 of them.

These results extend the finding above from different benchmarks to different presentations of the same request. A low violation rate on a benchmark’s original wording describes how a model handles that wording, not how it handles the same harm asked differently. Two models with the same benchmark score can differ by twenty percentage points once the requests are transformed, and that difference is invisible to anyone who sees only the original score.

Verdict. Supported: in the one published source that allows the comparison, for all five models in our experiment, and in our study of adversarial transformations, where violation rates rise after transformation in 75 of 80 combinations of model and benchmark.

5 H3: Memorisation of benchmark text

The published results we collected include no reconstruction or contamination tests for these benchmarks, so H3 rests on our experiment alone.

Across 11,000 probes we found 40 exact reconstructions: 27 completions and 13 next-item predictions. AdvBench accounts for 31 of the 40 (Table 3).

: Table 3. Our experiment. Exact reconstructions per benchmark, out of 1,000 probes each (500 per probe type).

The next-item matches are the strongest evidence, and 12 of the 13 are AdvBench items. In each, the model saw three consecutive items and wrote out the next one exactly, without seeing any part of it. Completions are weaker evidence, since a short ending can sometimes be guessed from its first half.

Table 4 shows which models produced the matches. Every model reproduced at least one AdvBench item. Whole next items came from four models: DeepSeek V4.1 Flash (8), GLM 5.3 Flash and MiniMax M3.1 Flash (2 each) and Claude Haiku 5.5 (1). Claude Haiku 5.5 and MiMo V2.6 Pro declined, were blocked or returned nothing on most probes, so their low counts say little about what they have seen.

: Table 4. Our experiment. Exact reconstructions per model and probe, out of 1,100 probes of each type per model. The last column is the share of the model’s 2,200 probes it declined, was blocked on or left empty, by a lexical refusal check.

Verdict. Partly supported. Some models have seen AdvBench: they reproduce whole items they were not shown. For the other ten benchmarks we have no such evidence. Whether exposure inflates safety scores remains to be tested, with controls such as shuffled order and unseen text.

6 Discussion

Capability and safety are reported separately, but the risk a model poses depends on both. A model that complies with a harmful request can do more harm when it is more capable, because the help it gives may be more effective. Safety evidence therefore matters especially for the most capable models. Yet a single safety score can mislead: as Section 4 showed, a model can do well on one safety benchmark and badly on another. Table 5 and Figure 7 set our five models’ capability, measured by the Artificial Analysis Intelligence Index, against two safety measures: their average share of safe responses and their lowest score on any benchmark. The latter makes visible weaknesses that an average can hide.

: Table 5. Capability from Artificial Analysis (Intelligence Index v4.3.2, read 25 October 2026); safety from our experiment. Artificial Analysis tests models at their own reasoning settings, mostly the highest, while our safety run used reasoning off or low effort, so the two halves of the table describe different settings of the same models.

On capability the five models are almost tied, between 42 and 46. On safety they are far apart: 74% to 95% safe on average, and 10% to 77% on their weakest benchmark. The two most capable, MiMo V2.6 Pro and DeepSeek V4.1 Flash, fall in the quadrant of high capability and low safety. Leaving out AHB lifts MiMo above the midline, but not DeepSeek, whose weakest benchmark is APE. A capability index treats these models as interchangeable, and our safety results do not. This matches earlier evidence. Ren et al. (2024) correlated safety benchmarks with general capabilities across many models and found that robustness to jailbreaks, adversarial reformulations of harmful requests, does not rise with capability: on HarmBench, robustness to human-written jailbreaks, TAP and GCG correlates negatively with their capabilities score, from −28% to −43%. Greater capability does not bring greater resistance to adversarial requests, so it cannot stand in for measuring it.

This is the capability–safety measurement gap: our ability to say how capable a model is runs ahead of our ability to say how safe it is. The two are measured differently. Capability indices are maintained: they are versioned, run every new model on the same tests, and add harder tests as models improve. Safety benchmarks are not. Each is released with its own scorer and usually scored once, on the models of its time, and the published results we collected come from leaderboards built at different dates with different metrics. A capability score is current and comparable across models; a safety score often is neither.

The gap matters more as capability grows. A more capable model can do more with a harmful request it accepts: write working code, carry out steps as an agent, give more precise guidance. The same unsafe rate carries more risk the more capable the model. For third-party evaluation under the Code of Practice there is a further problem. A provider can report high scores on benchmarks of direct requests, which models pass most easily in both the published results and ours, and a third party rerunning them will confirm the scores. Reproducibility then confirms a number that says little about adversarial or agentic use. Adversarial and agentic benchmarks give a fuller picture, but only if they hold up as well. If safety benchmarks saturate, have been memorised, or generalise weakly to other requests, a third party can reproduce their scores but cannot rely on them, and the main reproducible tool for checking a developer’s safety claims loses its value just as the models it describes become more capable.

Appendix

Benchmark source references

These entries distinguish the released items and benchmark descriptions from published model scores. AILuminate public demo prompts differ from its private official test set.

• AdvBench: paper; released harmful-behaviour files.
• Agent-SafetyBench: paper and evaluation protocol; official dataset and code; published scores used in the literature analysis.
• AHB: paper; official dataset, test split; project repository. Our prompts came from the pinned public data/test.csv revision recorded in the local source manifest.
• AILuminate: v1.0 public demo prompt file used in our experiment; official evaluation FAQ; published scores used in the literature analysis. The published official scores use a private test set, whereas our prompts come from the public demo.
• AIR-Bench: benchmark paper; released default/test prompts; published scores used in the literature analysis.
• ALERT: paper; official repository and prompts; published scores used in the literature analysis.
• APE: paper; released topic file used in our experiment; official repository and evaluation code.
• BioTIER: paper; benchmark description; prompts are access-controlled. Item text was not used in our prompt experiment; published scores used in the literature analysis.
• Boiling the Frog: paper and reported results; published scores used in the literature analysis.
• CyberSecEval: released MITRE prompt file used in our experiment; original benchmark paper; later reproduced scores used in the literature analysis. Our literature analysis uses the later reproduction rather than scores from the original benchmark paper.
• Do-Not-Answer: paper; official repository and prompts; published scores used in the literature analysis.
• FORTRESS: paper; released prompt pairs and rubrics; published scores used in the literature analysis.
• HarmBench: paper; released text behaviours used for memorisation; text test split used for response safety; published scores used in the literature analysis.
• M-ALERT: paper; released dataset; published scores used in the literature analysis.
• OR-Bench: paper; released dataset; published scores used in the literature analysis.
• S-Eval: paper; official repository; published scores used in the literature analysis.
• SafeArena: paper and published scores used in the literature analysis; official code and dataset access instructions. The task files require access; we did not use them in our prompt experiment.
• SALAD-Bench: paper; official repository and prompts; published scores used in the literature analysis.
• SimpleSafetyTests: benchmark paper; published scores used in the literature analysis.
• SORRY-Bench: paper; official dataset and evaluation code; published scores used in the literature analysis.
• StrongREJECT: paper; pinned 313-prompt CSV used in our experiment; released scoring implementation.