A user asks a legitimate question containing a sensitive word. The base model can answer it, but the defended system refuses. Another user asks an ordinary reasoning question: the system answers, yet the extra safety procedure changes its accuracy. A third request succeeds, but repeated generation makes it slower and more expensive. These are three different failures, and a single safety score cannot distinguish them.
Jailbreak defenses are necessary components of language-model systems. The engineering question is what the defended system becomes after the component is installed. In When LLM Defenses Backfire, we examine the full intervention: safety against unsafe inputs, refusal on safe inputs, downstream capability, and inference cost. Studying them together exposes trade-offs that disappear when a defense is ranked only by the harmful responses it blocks.
Start with what the defense actually does
“Defense” covers very different computations. A filter may inspect the input once. A reflective method may ask a model to reinterpret the request. An output checker may inspect an answer after it has already been generated. A multi-round method may sample several perturbed prompts and aggregate the results. Their costs and failure modes should differ, even when all of them are described as adding safety.
We organize eleven methods into four operational families. The classification follows the mechanism that dominates observable behavior and deployment overhead; it does not claim that every method contains only one idea. A strategy can combine a safety prompt with a checker, but its main intervention still provides a useful way to compare it with alternatives.
| Family | Methods studied | Intervention |
|---|---|---|
| Rule-based check | PPL | Inspect an input using a rule-like signal before answering. |
| Output reflection | LlamaGuard, Self-Exam | Inspect a generated response before releasing it. |
| Input reflection and alignment | Self-Defend, Intention Analysis, PriorityGoal, ICD, Self-Reminder, Self-Paraphrase | Change the instructions, examples, or interpretation that lead into generation. |
| Perturbation and multi-round | SmoothLLM, Retokenization | Modify input representations or perform repeated processing. |
This operational view gives the study a mechanism-level question: when a strategy changes the model’s behavior, where should we look for the secondary effect? Repeated sampling suggests runtime overhead. Aggressive rejection suggests a risk of refusing safe requests. Rewriting a request suggests a risk of disturbing the task itself. The experiments test those possibilities rather than assuming that a stronger safety procedure is free.
Four measurements, one deployed system
The study evaluates eleven defenses over six publicly available models: DeepSeek-V2-Lite-Chat, Llama-3.1-8B, Mistral-7B-Instruct-v0.3, Phi-3.5-Mini-Instruct, Gemma-2-9B-it, and Qwen2-7B. An undefended baseline provides the reference for each model. This matters because a defense is an intervention on an existing model, and its effect depends on the behavior already present in that model.
Safety effectiveness is measured as unsafe-query acceptance: the fraction of unsafe prompts that the system fails to reject. Lower acceptance is better on that workload. Over-refusal asks the complementary question on benign prompts and distinguishes full refusal from partial refusal. The two are not interchangeable. A system can reduce harmful compliance by becoming much less willing to answer anything.
Capability is tested separately on GSM8K, IFEval, and the health, law, and mathematics subsets of MMLU-Pro. These tasks probe mathematical reasoning, verifiable instruction following, and domain reasoning. Finally, token counts, latency, and energy measurements expose the computational consequences of the same defenses. These are measured properties of the evaluated workloads, not a universal cost model for every provider or device.
Unsafe-query acceptance
Refusal of safe requests
Task accuracy and instruction following
Tokens, latency, and energy
Blocking an unsafe request is only the first result
The unsafe-query results identify Self-Defend as a particularly conservative defender, often achieving the lowest or near-lowest acceptance across the evaluated models. The strategy asks the model to scrutinize the request before answering. On this safety measure, that intervention is effective.
Paraphrasing behaves differently. Rewriting a harmful request can preserve the harmful intent, so a fluent reformulation is not itself a safety guarantee. Self-Paraphrase is less reliable at reducing unsafe-query acceptance in this evaluation. The comparison is useful because both methods involve an additional language operation, yet the operation serves a different function.
Cross-model variation is equally important. PriorityGoal’s behavior changes substantially between models. A defense that fits one model’s instruction hierarchy or refusal behavior need not transfer with the same balance to another. The model and the defense must therefore be evaluated as a pair, with the undefended model serving as the local reference.
When caution becomes over-refusal
Now change the workload while keeping the defended system. The request is safe, but its wording sits near a safety boundary. This is where the benefit of caution can turn into lost utility. The study evaluates benign requests from Open Assistant and XSTest and reports both full and partial refusal, rather than reducing every non-answer to a single category.
PPL, Retokenization, Self-Defend, and Self-Exam can produce substantial benign-query refusal. Their profiles differ by model and dataset. The contrast with Self-Paraphrase is revealing: a method that is more tolerant on benign prompts can also be less effective on unsafe prompts. Neither tolerance nor conservatism can be assessed without the other workload.
The practical unit of analysis is the boundary between safe and unsafe intent. A keyword or unusual phrasing can be associated with harm without making the user’s actual task harmful. An evaluation containing only clearly harmless everyday requests would miss this distinction. Boundary-focused benign inputs reveal what ordinary capability benchmarks and unsafe-query tests leave out.
Safety procedures can disturb ordinary reasoning
Refusal is not the only way a defense can hurt a useful task. A system may answer while following an altered instruction, losing the original task constraints, or performing a less successful reasoning process. For this reason, the study measures accuracy on downstream tasks independently of the refusal analysis.
The capability table shows that defense methods rarely provide a broad improvement over the original model. Rule-based checking can preserve task performance well in the evaluated benchmarks, while more invasive input-side reflection and rewriting can change it sharply. The relevant comparison is not whether a defended answer sounds reasonable, but whether the measured task outcome remains correct.
Preserving benchmark capability also does not settle the deployment decision. A method can retain reasoning performance and still reject many benign conversational inputs. Conversely, strong harmful-query rejection can coexist with poorer instruction following or domain accuracy. The point of the joint benchmark is to keep those outcomes separate long enough to see their interaction.
The computation behind an answer
Two defended systems can return a similarly short final answer while doing very different amounts of work internally. Long safety templates increase the input processed by a model. Repeated sampling or reflection adds generations. A checker can introduce an additional model call. Looking only at the final visible answer hides that work.
On the measured Open Assistant workloads, SmoothLLM has the largest output-token overhead. Prompt-heavy and multi-round methods also increase input-token use, while lighter checks generally add less. Token counts explain an important part of the operational story, but input and output work should be distinguished: autoregressive generation and prompt processing do not have identical computational behavior.
The latency and energy measurements connect this token inflation to actual system overhead. Output-heavy defenses occupy more inference time and consume more energy on the measured setup. The deployment consequence depends on workload volume and latency constraints: an intervention that is tolerable for an occasional high-risk request may be costly when inserted into every interaction.
Read the trade-off as a deployment decision
The study’s central contribution is a joint benchmark and an operational explanation of defense side effects. A safety leaderboard alone favors systems that reject harmful requests. A capability leaderboard alone rewards correct answers. A cost table alone rewards cheap inference. A deployed assistant has to satisfy all three, while remaining usable on legitimate requests.
For a concrete model and application, the evaluation should begin with the unsafe behavior that needs to be reduced and the legitimate work that must remain possible. Compare defenses on that model, retain an undefended baseline, include benign boundary cases, and measure task accuracy and runtime on representative requests. The taxonomy then helps interpret why one candidate is preferable: its intervention may preserve useful computation, or it may pay for safety through more refusals and repeated generation.
The results concern the defense implementations, models, and datasets studied here. They do not establish that any family is always preferable or that low unsafe-query acceptance proves robustness against every adaptive attacker. They establish why defense selection needs a fuller experimental object: the model, its safety mechanism, its ordinary tasks, and the resources used to serve them.
The paper and released artifacts provide the method-level comparisons needed to make that object visible. The next useful defense is one whose safety gain can be assessed alongside the useful answers it preserves and the computation it requires.