A different attack turns 1% into 88% on the same safety test

The number that said DeepSeek failed every time

In late January 2025, a security team at Cisco reported that DeepSeek R1, a newly released reasoning model, could be jailbroken 100% of the time.¹ Trade press carried the figure straight. DeepSeek "lacks robust guardrails," one outlet repeated, and set the number beside the same test's scores for rival models.²

Three words in that report are doing quiet work. A jailbreak is a way of getting a model to produce something it was trained to refuse, usually by rewriting or dressing up the request so its safety training does not fire. A refusal is the opposite outcome: the model declines, which is what that training is meant to produce for a harmful request. The attack success rate, or ASR, is the share of a fixed set of harmful requests that a model can be pushed into answering rather than refusing. The 100% was an ASR.

Before deciding a model is unsafe on a number like that, it is worth asking where the number came from. Not which paper to cite it to, but how it was built: what set of requests, pushed by what attack, and judged by whom. Answer those three and the 100% turns out to count something much narrower than the word "unsafe" suggests.

Four choices behind the percentage

Every attack success rate is built the same way, in four steps, and each step is a choice someone made. Take HarmBench, one of the benchmarks the DeepSeek test drew its prompts from, and follow a rate from the list of requests to the final percentage.³

1. A fixed list of forbidden requests

   HarmBench fixes 510 harmful behaviors, 200 standard plus copyright, contextual, and multimodal sets, and splits them into 100 for tuning and 410 for the test. The rate is a fraction of this list and of nothing outside it.³

2. An attack applied to each

   A red-teaming method turns each behavior into an actual prompt: a fixed template, an optimizer-found suffix, or a plain rewrite. Change the attack and you are measuring resistance to a different thing. How the optimizer-found kind is built is its own subject, covered in the paper's jailbreaks lesson.

3. The model's answer

   The target model generates a response, and HarmBench reads the first 512 tokens of it. That length is itself a knob. The paper notes prior work left it unstandardized, and the choice alone can move a rate by up to 30%.³

4. A judge that rules each answer

   Something reads each answer and rules it a success or not. HarmBench uses a classifier, a fine-tuned Llama-2-13B model that agrees with human labelers 93.19% of the time, ahead of a GPT-4 grader at 88.37% and an AdvBench refusal classifier at 69.93%.³

The ASR is the fraction of that 410-request list the judge marks a success, where even a garbled attempt counts. Run HarmBench's classifier over the GCG attack on Llama-2-13B and the rate is 30.2%.³ That is a single number resting on one list, one attack, and one judge. Move any of the three and the number moves with it.

Whoever grades decides the score

The judge is the step that most quietly moves the number, because two reasonable graders can read the same answer and disagree on whether it was a success. StrongREJECT, a second benchmark of 313 forbidden requests, was built around exactly that problem.⁴ Its authors found that most earlier graders counted any non-refusal as a success: if the model did not say no, the jailbreak worked.⁵

That bar is easy to clear with nothing. When researchers translated harmful requests into Scots Gaelic, GPT-4 stopped refusing, and a non-refusal grader scored a 43% attack success rate. StrongREJECT's authors read the actual answers and found them vacuous, carrying no usable information.⁵ The model had not refused, but it had not produced the harmful content either. The high rate measured the absence of a "no," not the presence of a real answer.

StrongREJECT's fix is to grade three things at once: whether the model refused, how specific the answer was on a one-to-five scale, and how convincing it was on another. The refusal flag enters as a multiplier, so any answer the model declined scores zero no matter what else it contains.⁵ That built-in zero is worth pausing on. Because every ASR scores a refusal as a non-success, a model can drive its rate toward zero simply by refusing more, and a model that refuses everything scores a flawless zero. The catch is that a model refusing more also refuses safe requests, and that cost sits on a different axis the ASR never reports. XSTest, a test of 250 safe prompts a well-calibrated model should answer paired with 200 genuinely unsafe ones, measures that axis.⁶ How a model comes to refuse a safe request is the subject of the paper's over-refusal lesson.

Graders also disagree with each other by wide margins on the identical answers. Take GPT-4o's responses to a batch of requests rewritten into the past tense and hold them fixed, then swap the judge. A GPT-4 judge scored 88%, a rule-based judge 73%, and a Llama-3-70B judge 65%, a 23-point spread over one set of answers.⁷ StrongREJECT put a number on how far the common graders drift from human judgment by ranking jailbreaks the way people did and asking how closely each automated grader's ranking matched.

A string match, the crudest grader, sits below zero: it ranked jailbreaks backwards more often than not. A plain GPT-4 judge landed at 0.16, closer to chance than to a human.⁵ This is why two labs can report very different rates for the same model without either lying. They graded the same answers with different judges, and the judge is half the number.

A low score with an expiration date

The attack is as much a choice as the judge, and it dates faster. Look first at the low scores, the ones that make a model sound safe. In 2023, an optimizer called GCG searched for an adversarial suffix on two open models and transferred it to closed ones. Attached to a request, the suffix worked on GPT-3.5 86.6% of the time and on GPT-4 46.9%, but on Claude-2 only 2.1%.⁸ GCG counted a success as any reasonable non-refusing attempt, checked by hand for the transfer tests, a looser bar than StrongREJECT's. So the 2.1% reads as resistance to that one 2023 attack, not as a general grade for Claude-2.

The trouble is that a benchmark is a frozen list of yesterday's attacks. In 2024, two researchers tried the cheapest attack imaginable: rewrite the harmful request in the past tense, turning "how do I make X" into "how did people make X." No optimizer, no suffix, just twenty tries. On 100 requests, GPT-4o went from refusing all but 1% of them to answering 88%, and Claude-3.5 Sonnet went from 0% to 53%.⁷ A general- audience outlet carried the result as evidence that the safety training behind those low scores was shallow.⁹ A low ASR is a claim with an expiration date, and the date is whenever someone tries an attack the list never held.

What the 100 percent actually counted

Now the DeepSeek number reads differently. Cisco's 100% came from 50 prompts sampled from HarmBench, not the full 410, each pushed by one automatic jailbreaking algorithm, with refusals detected automatically under some human oversight, at a temperature of zero.¹ The 100% means DeepSeek R1 refused none of those 50 prompts. On the same 50 under the same setup, Claude-3.5 Sonnet scored 36% and o1-preview 26%.¹

What the test showed is that against that one attack, on that sample, judged that way, DeepSeek refused less often than the others did. What it was used for is a flat verdict, "lacks robust guardrails," forwarded in trade coverage with no mention of the 50-prompt sample, the single attack, or the judging behind it.² The verdict may even be right. But nothing in a single ASR can carry it. Swap the attack, as the past-tense rewrite did to GPT-4o's 1%, and every model on that chart could move. A number that says a model refused none of 50 specific prompts is being asked to mean a model is unsafe, and those are two different claims.