The Legible Boundary
Anthropic proposed a Cyber Jailbreak Severity scale on July 1 as a shared industry standard, developed with Amazon, Microsoft, and Google. A common vocabulary for how far a jailbreak reaches is overdue, and the applause is earned. What the applause skips past is smaller and harder.
A score and a control are different objects, and only one of them becomes an attack surface the moment it is exposed. Severity scoring describes a jailbreak. It grades how far a prompt reaches past the model's classifier and how much of the harmful task space it opens. That is an assessment. It is useful for procurement, for board conversations, for comparing one lab's posture against another. It is the reference point that vendor self-assessment never gave buyers. None of that is in question.
The confusion starts when a severity tier becomes a threshold, and a threshold becomes a configurable control. At that point the framework has been used to build something the assessment never was. A boundary now exists that someone operates. And a boundary its operator can see is a boundary its adversary can eventually see too.
Governance has made this mistake before
For thirty years, enterprise data governance measured everything and governed almost nothing. Catalogs, lineage graphs, quality scores, stewardship dashboards. An enormous apparatus for describing the state of data, sitting next to systems that made their decisions at runtime without consulting any of it. Measurement was mistaken for control. The score on the dashboard was not in the path of the transaction, so it governed nothing.
Security learned the opposite lesson earlier and better. CVSS normalized how the industry talks about vulnerabilities, and it worked because a vulnerability is a fixed artifact. A CVE does not adapt to its score. It does not read the threshold and move. The severity of a jailbreak against a deployed agent is not a fixed artifact. It is a moving adversarial target, and the attacker is in the room.
Agents change where the boundary lives
The severity of a jailbreak is no longer a property of the model alone. It is coupled to what the agent is authorized to do once the prompt gets through. The same tier of jailbreak is a non-event against a read-only agent and a breach against an agent wired into payment rails or identity infrastructure. The boundary that determines real damage has moved off the model and onto the authorization layer, where the decision to execute an action is actually made.
This is where the exposed-control question turns serious. If the operative threshold is a single number, and that number is observable, even indirectly, then a competent adversary can probe until they find its edge and tune attacks to sit just underneath it. Legibility to the defender is legibility to the attacker. You cannot publish the location of the fence and still expect it to hold.
The principle: a legible boundary is a targetable boundary
Assessment vocabulary should be public. Publish the severity scale, argue about it, let CISOs benchmark against it, let researchers submit against it. The shared language is the point.
The operative boundary is the opposite kind of object. It should not be a single published threshold that an attacker can reverse-engineer, and it should not live where the model lives. Containment belongs at execution, as an authorization decision on each action, one that a jailbroken prompt has to defeat separately from the classifier. Two independent gates, not one. The first gate assesses the prompt. The second decides whether this action, by this agent, against this system, should proceed at all. A jailbreak that defeats the first has accomplished nothing if the second never trusted the model to begin with.
What to do with a version 1.0
The CJS framework is version one, and it will move. The tiers will be recut, the boundaries redrawn, the thresholds retuned as attacks evolve. Anthropic has said as much, describing this as an early draft to be improved with partners into a practical, agreed-upon standard. Anyone deploying against it should build for that assumption rather than against it. Treat the severity scale as shared language and keep it current. Treat any deployed threshold as an operational secret, and better still, do not concentrate containment in a threshold at all. Put the real gate at the authorization layer, per action, revocable, and version every part of it so the boundary can move without a rebuild.
The uncomfortable version of the same point is worth stating plainly. No serious buyer should be willing to put a frontier model into production today on the strength of a severity threshold alone. The framework is fine. The problem is that a threshold is an assessment wearing the costume of a control, and the audience that has to sign off on it will each bring a different acceptable line drawn from their own use case. The CISO, the regulator, and the board do not share a threshold. No single number satisfies all of them, and the number that tries to becomes the map an attacker follows.
A boundary you can publish is a boundary an adversary can walk around. Real containment is decided at execution, one action at a time.
Cross-link: this piece continues the runtime-authorization arc opened by N° 020 (The Authorization Gap) and extended by N° 022 (The Decision Moved to the Edge). Where N° 020 argued that observation is not authorization at the agent-action surface and N° 022 argued the same at the model-selection surface, this essay argues that a published assessment threshold is not a control at the prompt-classifier surface. The pattern is the same shape at three different surfaces: containment lives at execution, not at the artifact that describes what might have to be contained. Cyber Jailbreak Severity framework details from anthropic.com/news/fable-safeguards-jailbreak-framework (July 1, 2026).