u/usually_guilty99

Anthropic proposed a Cyber Jailbreak Severity framework for Fable this week, scoring jailbreaks by capability gain and how easily they're found. Genuine step, and it walks up to a trap this field fell into once already.

Governance spent a decade producing scores that sat next to the workflow instead of inside it. A severity framework is better, because it's meant to feed a control. That's also where the risk starts.

A score is an assessment. A control is a decision in the execution path. They get conflated the moment a severity tier hardens into a single configurable threshold that decides what ships. Once that threshold exists and is observable, it's a target. A competent adversary probes until they find its edge and tunes attacks to land just under it. A boundary you can publish is a boundary someone can walk around.

CVSS survived being public because a software vuln is a fixed artifact. A jailbreak against a deployed agent isn't fixed. It moves the instant you describe how you're measuring it.

Agents make it sharper. The same jailbreak tier is a non-event against a read-only agent and a breach against one wired into payment rails or identity. Severity is coupled to what the agent is authorized to do once the prompt gets through. So the operative boundary can't live where the model lives. It has to live at the authorization layer: a decision per action, revocable, versioned, that never trusted the model in the first place.

For a 1.0 the rule is clean: keep the severity scale public as shared language, treat any deployed threshold as an operational secret, and put the real containment at execution. No serious buyer should put a frontier model into production on the strength of a severity threshold alone.

Curious where people here land on the assessment-versus-control line, especially for agents with write access to systems that matter.

First comment: Long version: fixgovernance.ai/essays/the-legible-boundary. No signup, no pitch.

Watching the Fable 5 saga, one detail stuck with me. What changed between the version that got pulled and the one coming back isn't the model, it's a classifier at the output boundary that decides per request whether to answer or fall back. Same weights, different gate.

Which made me realize the governance asymmetry in my own pipeline. The generation step now has a per-request gate. The merge step, where that generated code actually enters production, has a human skim and a green CI run. CI tells me the code passes tests. It doesn't tell me the blast radius, whether this path has a history of incidents, or whether it touches a regulated service.

For teams shipping meaningful volumes of AI-generated code: are you doing anything structured at the merge boundary specifically, or is it still tests-plus-review like everything else? Curious whether anyone's scoring PRs on anything beyond test pass/fail before they land.

Watching the Fable 5 saga, one detail stuck with me. What changed between the version that got pulled and the one coming back isn't the model, it's a classifier at the output boundary that decides per request whether to answer or fall back. Same weights, different gate.

Which made me realize the governance asymmetry in my own pipeline. The generation step now has a per-request gate. The merge step, where that generated code actually enters production, has a human skim and a green CI run. CI tells me the code passes tests. It doesn't tell me the blast radius, whether this path has a history of incidents, or whether it touches a regulated service.

For teams shipping meaningful volumes of AI-generated code: are you doing anything structured at the merge boundary specifically, or is it still tests-plus-review like everything else? Curious whether anyone's scoring PRs on anything beyond test pass/fail before they land.

Watching the Fable 5 saga, one detail stuck with me. What changed between the version that got pulled and the one coming back isn't the model, it's a classifier at the output boundary that decides per request whether to answer or fall back. Same weights, different gate.

Which made me realize the governance asymmetry in my own pipeline. The generation step now has a per-request gate. The merge step, where that generated code actually enters production, has a human skim and a green CI run. CI tells me the code passes tests. It doesn't tell me the blast radius, whether this path has a history of incidents, or whether it touches a regulated service.

For teams shipping meaningful volumes of AI-generated code: are you doing anything structured at the merge boundary specifically, or is it still tests-plus-review like everything else? Curious whether anyone's scoring PRs on anything beyond test pass/fail before they land.

Every regulated team I talk to still points to the same control when something ships wrong: a human approved it. There's a name in the approval field. Someone signed.

Look closer at what that signature now means. An agent generates the change. The diff is large, fast, and one of dozens that day. A reviewer clicks approve. The name gets recorded. But the thing that signature used to certify, that a human read this, understood it, and stands behind it, didn't happen. It couldn't have. Nobody absorbs thousands of lines of agent output at agent cadence. The approval is collected. The reading behind it is gone.

That's the gap, and it's worth being precise about. This is not a slowness problem you fix by adding reviewers or helping them read faster. Accountability used to be a real artifact: a person who could answer "why did this ship" because they actually decided it. At agent velocity that artifact quietly stopped existing, even though the approval field is still populated. The signature outlived the thing it was signing.

Which makes the populated field worse than an empty one. An empty one tells the truth: nobody vetted this. A signed one manufactures accountability that isn't there, and an examiner or an incident review will eventually pull that thread and find nothing behind the name.

The fix isn't a faster human. It's producing the artifact the human used to be: a durable, independent record of what was actually checked, by what, against what, so accountability attaches to something real instead of a click. A signature has to point at evidence, not at a person who couldn't have read what they signed.

So the question for anyone running AI-assisted delivery in a regulated environment: when the wrong thing ships, and it will, what does your approval record actually prove? A decision, or a keystroke?

Mapping an initiative to the EU AI Act, NIST RMF, and ISO 42001 is real work and worth doing. But a framework you fill in is a snapshot, and governance risk isn't a snapshot problem. The score you record in January describes a system that no longer exists in February, the moment the model is retrained, the owner leaves, the policy is reworded, or the data scope expands. Nothing in the checklist tells you it went stale. You end up defending a green tier against a system it stopped describing.

The harder questions sit in the gaps the standards can't see. Is this approval still valid today, or just stored? Is this agent acting on the right entity, or one the policy technically allows but the source event never referred to? What governs the change between two audits?

Governance has to resolve to a decision at two control points, computed live. The merge gate, where AI-generated code lands before it ships. And the agent runtime, where an agent executes an action. At both the question is the same: should this proceed, against the current state of the system it is about to touch. Not should it have proceeded last quarter.

I've been working this out in the open at fixgovernance.ai.

About twenty essays so far, no signup, no pitch. If you're coming at it from the standards side, I'd be glad to compare where the checklist ends and the runtime decision has to begin.

A governance score you store is a fact about the past. The only score that counts is the one you can recompute right now.