What a "jailbreak severity rubric" actually is, and why four labs just proposed one

Anthropic, Amazon, Microsoft and Google announced yesterday that they are working on a shared way to score how bad a jailbreak is. That sentence sounds like industry housekeeping. It isn't. It's an attempt to give regulators a ruler before regulators reach for one of their own.

Here is what a jailbreak-severity rubric is, how one would actually work, and why the timing tells you more than the announcement does.

The thing being classified

A jailbreak is a prompt or technique that gets a model to produce output its safety training was supposed to block: instructions for making a weapon, working exploit code, sexual content involving minors, and so on. Every frontier lab deals with them constantly. What no lab has done, until now, is agree with the other labs on how to grade them.

Right now, if a researcher finds a jailbreak against Claude and reports it to Anthropic, Anthropic decides internally whether it is minor (a workaround that produces mildly off-policy text) or catastrophic (reliable uplift for a bioweapon attacker). The same jailbreak, ported to a different model and reported to a different lab, gets a different label. There is no shared vocabulary. There is no shared threshold. There is definitely no shared trigger for "this is bad enough that we should tell the government."

That vacuum is what the new framework is trying to fill.

The mechanism, step by step

A severity rubric is a pipeline that turns a jailbreak report into a tier. Every rubric I've seen — for software vulnerabilities, for biosecurity incidents, for aviation near-misses — has the same four stages, and this one will too.

Stage one: describe the input. What is the prompt or technique? Is it a single clever sentence, a multi-turn conversation, a fine-tuned adversarial suffix, an image with hidden text? Different attack shapes have different reproducibility, and reproducibility feeds into severity.

Stage two: describe the model behaviour. Does the model comply once out of a hundred tries, or every time? Does compliance require a specific system prompt, or does it work from a cold start? A jailbreak that works 1% of the time on one model version is a very different object from one that works 95% of the time across a whole family.

Stage three: classify the output harm. This is the hard stage. You need agreed categories (CBRN uplift, cyber-offensive capability, CSAM, targeted harassment, financial fraud) and, within each category, agreed thresholds for what counts as meaningful uplift over what a determined person could already find on the open web. The phrase "uplift over baseline" is doing enormous work here, and every lab currently measures it differently.

Stage four: assign a tier. Low, medium, high, critical, with the tier boundaries defined by the combination of reproducibility and harm class. This is the number that ends up in the model card, and eventually, if this framework does what its authors want, on a regulator's desk.

The closest existing analogy, and where it breaks

The obvious model is CVE, Common Vulnerabilities and Exposures, the system that gives every publicly known software bug a unique ID and a severity score (CVSS, currently version 4.0). CVE has been running since 1999. It is imperfect, contested, and indispensable. It's what lets a security team at a bank and a security team at a hospital talk about the same bug using the same words.

The analogy holds in useful places. Both systems assign identifiers. Both use tiered severity. Both depend on a disclosure norm: you tell the vendor, the vendor patches, then the vulnerability goes public with a score. A jailbreak rubric could plausibly inherit that whole shape.

Where the analogy breaks is the nature of the thing being scored. A software vulnerability is a discrete defect in deterministic code. You patch it, and it is gone; the same input no longer produces the same output. A model jailbreak is a behaviour of a probabilistic system. You can fine-tune the model to refuse the specific prompt, and the underlying weakness, whatever generalisation in the training made it comply, is often still there, waiting for a slightly reworded attack. "Patched" is not a clean state for a model the way it is for a library.

That is why the severity tier for a jailbreak has to encode something CVE doesn't: how transferable is this? Does the same technique work against the next model version? Against other labs' models? A jailbreak that transfers across the whole frontier is a categorically different threat from one that dies with a single checkpoint, and the rubric has to say so.

Why this is being announced now

The trigger is not technical. It is the Fable/Mythos episode last month, when the Commerce Department invoked export controls to suspend two Anthropic deployments after a jailbreak research disclosure. Anthropic's own restoration note says the episode "made clear the industry needs a consistent way to assess and fix potential jailbreaks."

Read that sentence carefully. The industry does not currently have a consistent way. Commerce, faced with a jailbreak report and no rubric, improvised. A rubric offered to Commerce next time is a rubric Commerce might use instead of improvising again. That is the deal being proposed.

The four signatories are the four Western labs most exposed to that kind of intervention. The labs not at the table, xAI, Meta, and every Chinese frontier lab, are the ones whose models the rubric will not cover. A severity scale that classifies Claude, Gemini, and the models Amazon and Microsoft host, but not Llama, Grok, or Qwen, is a scale with a hole in the middle of the threat surface. Jailbreaks transfer across models more often than not. A rubric that four labs agree on is not the same as a rubric the field agrees on.

What to actually take away

A jailbreak-severity rubric is a good idea. Software security is measurably better for having CVE, even with all of CVE's problems, and model safety will be better for having something like it. The mechanism, describe input, describe behaviour, classify harm, assign tier, is sound, and the four labs proposing it have the technical capacity to build it well.

The open question is whether the rubric ends up being the industry's shared language or the industry's shared shield. Those are not the same document, and you can tell which one is being written by watching who has to comply with it, and who gets to write the next version.

Footnotes and links

Further reading

• FIRST, the CVSS v4.0 specification: https://www.first.org/cvss/v4-0/
• Anthropic on constitutional classifiers and universal jailbreaks: https://www.anthropic.com/research/constitutional-classifiers
• MITRE ATLAS, the adversarial-ML analogue to ATT&CK: https://atlas.mitre.org/

¶