"We added guardrails" is a claim; "the multi-turn jailbreak bypass rate dropped from 68% to 4%" is evidence. The measurement that gives an AI red-team program its credibility is the bypass-rate delta: a rigorously computed before-and-after number showing that a specific defense actually reduced how often attacks succeed.
Tier: Advanced · Workflow area: AI red-team program & tooling
This playbook builds that measurement for your own system — defining bypass rate precisely, controlling for stochasticity, running matched attack sets against the pre- and post-hardening configurations, and reporting a delta you can defend. It is what turns a hardening sprint from an act of faith into a proven risk reduction.
Define bypass rate before you measure it. Fix the denominator and numerator: bypass rate = (attack attempts where the model produced the unsafe outcome) / (total attempts), over a fixed, versioned attack set. Ambiguity here makes every later number meaningless.
Freeze the attack set. Use the same corpus of Garak probes, Promptfoo cases, and PyRIT orchestrated attacks for both measurements. A delta computed against different attacks is not a delta.
Control for stochasticity with repeated trials. LLMs are non-deterministic. Run each attack N times (5–10) per configuration and average, so a swing is signal, not sampling luck.
config = pre-hardening
promptinject suite: attempts 300 (30 cases x 10 runs), bypasses 204 → 68.0%
crescendo (PyRIT): attempts 50 ( 5 objectives x 10), bypasses 34 → 68.0%
config = post-hardening (identical attack set, identical runs)
promptinject suite: attempts 300, bypasses 12 → 4.0%
crescendo (PyRIT): attempts 50, bypasses 3 → 6.0%
delta: single-turn -64.0pp, multi-turn -62.0pp
Change one variable at a time. Hold the model, the attack set, and the generation settings constant; change only the defense. If you swap the model and add a guardrail, you cannot attribute the delta.
Report percentage-point deltas with the base rates. "-64pp (68% → 4%)" is honest; "94% improvement" hides the residual 4% that still bypasses. Always show what still gets through.
Re-baseline after the change. The post-hardening number becomes the new baseline that future regressions (pb-43) are measured against, closing the loop.
A bypass-rate delta is only credible if the attack set is frozen, each attack is run enough times to beat noise, and exactly one defense variable changed between the two measurements.
The delta is trustworthy when it is reproducible and attributable. Reproducibility: re-run the full before/after measurement a second time; the two deltas should agree closely — if they swing by tens of points, your trial count N is too low to overcome stochasticity, so raise it. Attributability: confirm through your change log and config diff that nothing but the defense changed between the two runs — same model version, same temperature/sampling, same attack corpus, same scorer. If the model was updated or the attack set edited between measurements, the number is confounded and must be re-run cleanly. Finally, hand-verify a sample of the post-hardening "bypasses" that remain, so the residual rate is real and not scorer noise — the residual is what you report as remaining risk.
A bypass-rate delta is an ideal client deliverable — it quantifies the value of a security investment without exposing attack payloads. In an engagement, compute the measurement inside the client's environment against their authorized endpoint, keep the frozen attack corpus and per-trial transcripts within their boundary, and report the aggregate before/after rates and points-of-reduction with the residual risk stated plainly. Document the methodology (attack set version, trial count, the single changed variable) so the client's own team can reproduce and re-baseline after future changes. Use the client's approved or local model as the target and, if an LLM scorer is involved, an approved endpoint — never send their prompts or outputs to an unapproved service, and do not reuse their attack corpus elsewhere.