Papers
arxiv:2610.25060

Policy Is Not Capability: Some Safety Benchmarks Measure Which Definition of "Unsafe" You Trained On

Published on Oct 18
· Submitted by
Vahid Jebraeeli
on Oct 20
Authors:
,
,
,

Abstract

Guardrail benchmark scores primarily reflect labeling policy rather than detection ability, with minor parameter changes shifting results across full ranges and training contamination undermining reported safety metrics.

A guardrail classifier is reported as if unsafe were a property of text. It is not: it is a property of a policy, and the policy enters the model through its labels. We exploit an accident of an industrial deployment in which the same ~53k prompts were labelled twice, under two operational definitions ("is this a request for harmful content?" and "would a moderator block this?"), and used to train ten guardrail arms sharing architecture, codebase and optimiser family, at two model scales. First, the guardrail's own training corpus already contained the benchmarks: JailbreakBench-benign is 88% and OR-Bench-hard 82% present in the training pools, two over-refusal benchmarks, the kind a guardrail reports to argue it does not over-block. Everything below is decontaminated. Second, safety benchmarks stratify sharply by how much of their score is decided by the label definition rather than by the model: with architecture and optimiser fixed, the range across the ten arms is 0.99 on HarmBench-copyright and 0.043 on WildGuard-benign, a 23x spread. Third, a benchmark score can be moved across its entire range by 0.03% of the parameters. Across these arms HarmBench-copyright spans 0-100 and OR-Bench-hard over-refusal 3.4-56.4%, and the four arms whose last supervision signal carries a given policy occupy one extreme of both (exact rank p=0.005, or 0.04-0.14 at worst), at unchanged detection capability. For a distilled student the teacher's soft labels do this even when every hard label carries the other policy, so teacher provenance is an unrecorded confound in any released checkpoint. Fourth, validation accuracy on the one split that grades all twenty arms tracks agreement with the annotator's policy (rho=+0.74), not detection capability (rho=+0.34). We argue that guardrail evaluations should report contamination, a seed floor and the definition they were graded against as first-class variables.

Community

Paper author Paper submitter

A guardrail's safety score depends on which definition of unsafe its training labels encode. Using ten guardrail classifiers trained on the same ~53k prompts labelled under two policies, we find that the training data already contained 88% of JailbreakBench-benign and 82% of OR-Bench-hard, that benchmarks differ 23x in how much the label policy decides their score, that changing 0.03% of the parameters can move a benchmark score across its entire range, and that validation accuracy tracks policy agreement (rho +0.74) rather than detection capability (rho +0.34). Guardrail evaluations should report contamination, a seed floor and the grading definition.

Look, this is the result bank model risk teams NEED to read. A guardrail score without its label policy is NOT evidence. Validation accuracy tracking agreement with the annotator's policy (rho +0.74), not detection capability (rho +0.34), means a held-out split from your own labelling pipeline measures label fit, not capability. And your caveat is the honest one: at n=20 you claim the ordering, not the ratio.

For a regulated go-live record I would make the deployer's own written definition of unsafe a first class variable, scored separately from the public benchmark definition. In a bank, "would a moderator block this?" is a conduct and suitability question, not only a harmful content one.

Question: both pipelines used the same 24 pillars and still disagreed on one prompt in six. Did those disagreements concentrate in a few pillars or spread across Safety, Security, Privacy and Reliability? That tells a deployer whether a policy swap needs a targeted recalibration or a full re-test. Big difference. Huge.

·
Paper author

Hi Ercin, Thanks! This is the question I would have wanted asked. I went back and measured it. The two pipelines almost never argue about which pillar a prompt belongs to. They argue about where safe stops and unsafe starts. Only about one in twenty of the disagreements is a category dispute, and the rest is that line moving. So recalibrating a few pillars would miss almost all of it: a policy swap means re-testing the boundary, not the taxonomy. The category list was never where the policy lived.

Sign up or log in to comment

Get this paper in your agent:

hf papers read 2610.25060
Don't have the latest CLI?
curl -LsSf https://hf.co/cli/install.sh | bash

Models citing this paper 0

No model linking this paper

Cite arxiv.org/abs/2610.25060 in a model README.md to link it from this page.

Datasets citing this paper 0

No dataset linking this paper

Cite arxiv.org/abs/2610.25060 in a dataset README.md to link it from this page.

Spaces citing this paper 0

No Space linking this paper

Cite arxiv.org/abs/2610.25060 in a Space README.md to link it from this page.

Collections including this paper 1