Do We Need a CVSS for AI Jailbreaks?
What two decades of CVSS, EPSS, and SSVC can teach the AI safety community about scoring jailbreaks
On June 30, 2026, Anthropic published likely one of the more consequential AI safety blog posts of the year. Not necessarily due to technical details but due to the broader societal context and how big of a deal the entire export ban situation proved to be for the AI industry, leading to conversations around open source, AI sovereignty, model security and much more.
That said, buried inside the announcement that Fable 5 was being redeployed after its brief export-control-driven suspension was something practitioners should pay close attention to. Anthropic proposed a consensus industry framework for scoring the severity of AI jailbreaks, explicitly modeled on the Common Vulnerability Scoring System (CVSS) used in traditional software security. They are drafting it alongside Amazon, Microsoft, Google, and other partners in the Glasswing program.
This is a significant development, but not because the idea is new, but because it signals that the frontier labs have reached the same conclusion the vulnerability management community reached years ago, even if it took an export ban and societal shit storm to get there.
When you have a class of security problem that will never be fully solved, you need a standardized way to talk about severity so that organizations can prioritize their response. The cybersecurity industry spent two decades learning that lesson with software vulnerabilities. The AI safety community is now compressing that same realization into months.
What Jailbreaks Actually Are
For practitioners coming from traditional security, jailbreaks are best understood as the AI equivalent of vulnerability exploitation. Every frontier AI model ships with safety training and behavioral constraints designed to prevent it from producing harmful outputs. A jailbreak is any technique that bypasses those constraints and gets the model to do something it was designed to refuse.
The techniques range from simple to sophisticated.
For example, some involve creative prompt engineering, rewording a dangerous request in language that slips past the model’s safety training. Others use multi-turn conversations that gradually shift the model’s context until it complies with requests it would have initially refused. More advanced methods involve encoding harmful instructions in ways the model processes but its safety systems do not catch, or byspass built in safeguard to try and prevent malicious usage.
It can also occur via exploiting the gap between what the model was trained to refuse and what it actually refuses in practice. Some of these methods are direct, with users directly entering text/inputs to the LLM, while others leverage indirect methodologies, via all sorts of content that makes its way into the models context. A great resource on the latter is Google DeepMind’s “AI Agent Traps” paper.
Industry organizations such as OWASP recognized this threat early.
Prompt injection, which encompasses jailbreaking as a technique, has held the number one position in the OWASP Top 10 for Large Language Model Applications in both the 2023 and 2025 editions.
That is not a ranking driven by theoretical concern. It reflects the assessment of hundreds of security professionals that manipulating LLMs into bypassing their intended constraints is the single most significant risk facing AI deployments today. The fact that it has held the top spot across two editions, despite significant investment in mitigations by every frontier lab, tells you something about the persistence of the problem.
Jailbreaks matter because they are what triggered the export controls on Fable 5 in the first place. Amazon researchers allegedly found a method to bypass Fable 5’s safeguards, prompting it to identify software vulnerabilities and produce exploitation code.
The government’s concern was straightforward. If a frontier model can be jailbroken into producing offensive cyber capabilities, that capability in the wrong hands represents a national security risk. The result was immediate export controls on both Fable 5 and Mythos 5 on June 12, with Anthropic forced to suspend global access because they had no reliable way to verify user nationality in real time.
What made the situation more complicated was Anthropic’s own testing, which showed the behavior that triggered the ban was not unique to Fable 5. Many less capable models, including Claude Opus 4.8, GPT-5.5, Kimi K2.7, and even Claude Haiku 4.5, could reproduce the same vulnerability identification and exploitation demonstrations.
The reported bypass was what Anthropic characterized as a borderline case involving routine defensive cybersecurity work, not a unique offensive capability. This is something others such as Katie Moussouris on the Anthropic Export-Control Mess in an episode of the Three Buddy Problem podcast I listen to, where she discussed reviewing aspects of the report that made its way out of AWS to the Government.
Ironically, I was listening to the playlist from the recent Real World AI Security Conference and one of the presenters was Jerry Wei from Anthropic, and he walked through how they create, test and implement their classifiers, including training, refusals, activations and more. It was a great opportunity to hear directly from Anthropic themselves on this topic at depth:
How Classifiers Work
The primary defense against jailbreaks in production AI systems is a set of mechanisms called classifiers. These are smaller automated AI systems that run alongside the main model during interactions, monitoring for potentially harmful requests or outputs. When a classifier detects that a conversation is heading toward dangerous territory, it intervenes and blocks the model from responding. Anthropic has a good image in their Fable 5 blog, where they discuss applying even more rigorous classifiers to their Fabel 5 model to try and mitigate risk/abuse, as well as alleviate concerns. (It’s worth noting many cyber practitioners and researchers have voiced frustration with the classifiers, arguing it is preventing them from doing legitimate defensive and research work.)
Anthropic describes their approach as defense in depth. Multiple safety mechanisms are layered together. Some involve training the model itself to decline dangerous requests. Others involve retroactive pattern analysis of misuse across conversations. The classifiers operate on a safety margin principle, deliberately set to trigger on requests that might be benign but carry some probability of being harmful. A request must look very clearly safe to avoid triggering the classifier.
For Fable 5 specifically, Anthropic made the safety margin much larger than any prior launch. This was a deliberate tradeoff. More benign requests would be incorrectly blocked, creating frustration for legitimate users, but fewer harmful requests would slip through. After the Amazon report, they trained an improved classifier that blocks the specific reported technique in over 99% of cases, which CAISI independently verified.
The important thing for practitioners to understand is that classifiers are not perfect and never will be. They reduce the probability of successful jailbreaks but cannot eliminate it. This is not an engineering limitation that better classifiers will eventually overcome. It is a structural property of the problem itself.
I have written about this quite a bit, especially in the context of agentic AI and the fact that probabilistic controls, often referred to as soft guardrails are imperfect and ultimately we need hard boundaries, especially in the age agents, where rather than just inputs and outputs such as with LLMs, agents take actions and introduce significantly more risk to the enterprise as a result.
Jailbreaks Will Never Be Fully Solved
Anthropic states this explicitly in their announcement. It is probably impossible to make any AI model fully robust to jailbreaks. They are not alone in that assessment. OpenAI has made similar acknowledgments, and NIST recently put mathematical rigor behind the claim.
In June 2026, NIST senior scientist Apostol Vassilev published a peer-reviewed proof in IEEE Security and Privacy that formally extends Gödel’s incompleteness theorems to AI guardrail systems. The CSA published a research note analyzing the implications, and the conclusion is stark. No finite set of AI guardrails can be universally robust against adversarial prompts. This is not a gap that better engineering can close, it is a mathematical property.
The fundamental problem is simple. There are infinite ways to ask for the same thing in natural language. You can rephrase, use analogies, speak in hypotheticals, encode instructions, or bury the real request inside something that looks harmless. AI safety filters are built from finite rule sets, and finite rules cannot cover infinite variations. Vassilev's proof at NIST confirmed what practitioners already suspected. No matter how many rules you add, there will always be some way to phrase a request that slips through. The rules can get better, but they cannot become complete.
To see a concrete example against a model with robust safeguards, you can see the alleged jailbreak of Fable 5 itself by the popular “Pliny the Liberator”, who had claimed to jailbreak Fable 5 using unicode, homoglyphs, fiction narratives and more.
The empirical evidence supports the theory. One of the best resources if you want to dig into it is a paper titled “SoK: Evaluating Jailbreak Guardrails for LLM’s”. The paper has a good synthesis on the current knowledge and research on the topic, as well as a common taxonomy for discussing LLM jailbreaks.
Funnily enough, as I was looking for the most recent literature on the topic for this article, Claude, which I’m a big user of, and in this case using Fable 5, actually ran into the classifier when I asked about LLM jailbreaks and reverted me back to Opus 4.8.
You can see how even trivial genuine research and requests can easily bump into the classifiers and guardrails and frustrate cyber defenders and researchers leveraging LLM’s.
The OWASP Top 10 for LLM Applications reinforces this from the practitioner side. Prompt injection has held the number one position across both editions, and OWASP’s own guidance notes that it is unclear if there are foolproof methods of prevention due to the stochastic nature of generative AI.
For anyone who has worked in application security, that language should sound familiar. It is the same conclusion the industry reached about SQL injection, cross-site scripting, and every other injection class before it. You can reduce the attack surface dramatically. You can make exploitation harder, but you cannot always eliminate the category entirely. The difference with prompt injection is that the input language is natural language itself, which makes the boundary between legitimate use and adversarial manipulation fundamentally harder to define than it is for structured query languages or markup.
For practitioners, the parallel to traditional security is direct. We long ago accepted that software will always have vulnerabilities, however we did not throw up our hands. We built systems for discovering, scoring, prioritizing, and remediating them. The AI safety community is now reaching the same inflection point with jailbreaks, and that is where the CVSS comparison becomes relevant.
The CVSS Parallel, and Its Limitations
CVSS has been the standard language for communicating software vulnerability severity for nearly two decades. It gives every vulnerability a numerical score from 0 to 10, providing a common reference point for vendors, security teams, and regulators to discuss how bad a given flaw is.
Anthropic’s proposed jailbreak scoring framework borrows this concept directly, even citing it in the footnotes of their blog. Their system evaluates a jailbreak on four criteria, which I will directly share below:
Capability gain. How far beyond existing tools does the jailbreak take the user? If existing widely available tools (including other, weaker AI models) can reach the same capability as the jailbroken model, the score here will be low; if the jailbreak unblocks model capabilities that can significantly accelerate even domain experts, the score will be high.
Breadth of capability gain. For how many distinct offensive tasks does the same jailbreak technique work? Cases where the jailbreak only allows the model to pursue narrow targets will score low; cases where the same jailbreak technique works for multiple different targets or techniques will score high.
Ease of weaponization. How much human effort does it take to turn the jailbreak into an attack? Where the jailbreak involves a great deal of skilled prompting and many retries, the score will be low; where the jailbreak works on a single prompt or on the first or second try, the score will be high.
Discoverability. How easy is it for someone to obtain the technique? If it requires specialist knowledge it will score low; if it is already widely known and available online it will score high.
The first two describe what the jailbreak provides to an attacker, while the latter two describe how quickly it can become a real-world problem. Anthropic also provided insights into how jailbreaks interact with their safety classifiers and what a spectrum from minor, narrow and universal jailbreaks looks like.
This is a reasonable starting framework, but practitioners who have lived through the evolution of vulnerability management know that CVSS, while valuable as a common language, has significant limitations when used as the primary driver of remediation decisions, and it’s misuse are among the leading reasons trends such as “shift left” in AppSec experienced so much heartache and pushback.
As I covered in The Death of CVSS as Federal Policy, CISA’s BOD 26-04 formally replaced CVSS-driven remediation mandates with the Stakeholder-Specific Vulnerability Categorization (SSVC) framework. The directive recognized what practitioners had been saying for years. CVSS measures theoretical severity in a vacuum. It does not account for whether a vulnerability is actually being exploited, whether the affected asset is publicly exposed, whether the vulnerability is reachable, the business context, or whether exploitation can be automated at scale.
ACM research demonstrated that using CVSS severity alone to measure risk is equivalent to picking random vulnerabilities to fix. Yet for years, the entire federal government, and by extension much of the private sector, used CVSS base scores as the primary input for remediation timelines. It’s a topic I’ve been ranting about for years, in blogs, and even my book Effective Vulnerability Management.
As I covered in A Look at the Exploit Prediction Scoring System, EPSS emerged to fill the exploitation probability gap that CVSS ignores. EPSS provides a numerical score representing the probability that a given CVE will be exploited in the wild over the next 30 days, using over 1,400 features and data from sources like Fortiguard, AlienVault, Shadow Server, and GreyNoise.
EPSS 3.0 demonstrated an 82% performance improvement over previous versions and can help organizations achieve the same risk coverage with one-eighth the remediation effort of CVSS-based strategies. While dated now, the below image is helpful to demonstrate how much more effective it is to prioritize vulnerability remediation based on exploitation probability over CVSS base severity scores:
But EPSS has its own limitations. For example, it measures threat probability without accounting for organization-specific context like asset criticality or business impact, a flaw that CVSS base scores have as well.
The lesson from two decades of vulnerability management is that no single scoring system is sufficient alone. CVSS lacks exploitation context, EPSS lacks organizational context (although organizations such as Empirical who are involved with EPSS have been working on local/organizational-specific models), KEV only covers confirmed exploitation and even then has gaps compared to sources such as the commercial VulnCheck KEV.
SSVC provides a decision framework but depends on enrichment data that remains incomplete. The most effective approach combines all of these with reachability analysis and business-context scoring.
Any jailbreak severity framework will face the same challenge. Anthropic’s four criteria are a solid foundation, but they will need to evolve to incorporate contextual factors like what systems the jailbroken model has access to, what actions it can take autonomously, what data it can reach, and what the downstream consequences of a successful jailbreak would be in a specific deployment.
A jailbreak against a model powering a customer service chatbot and a jailbreak against a model with autonomous access to production infrastructure are categorically different risk events, even if the jailbreak technique itself is identical.
This is where some of the heavy lifting will be left to organizations, much as it was with moving beyond CVSS base scores to account for organizational-specific factors, and as we saw with CVSS, most organizations won’t do that lifting.
This Is Not the First Attempt
It is worth noting that Anthropic’s proposal is not the first attempt to build a structured scoring system for AI security risks. OWASP’s AI Vulnerability Scoring System (AIVSS) has been in development and is currently at version 0.8, an effort that has been championed by my friend Ken Huang. AIVSS is building a standardized, quantifiable framework for assessing security vulnerabilities specific to AI systems, with an initial focus on scoring the OWASP Agentic AI Core Security Risks.
AIVSS covers AI vulnerabilities broadly, not just jailbreaks. Its scope includes model manipulation, data poisoning, agent misalignment, and other AI-specific risk categories. The project’s structure, with a numerical scoring system, severity assessment, exploitability factors, and an interactive calculator tool, is clearly inspired by CVSS but adapted for AI-specific risk vectors.
The project has also integrated with SSVC decision-tree methodology, suggesting the team is learning from the vulnerability management community’s evolution beyond pure severity scoring. There’s also open source efforts, such as interactive AIVSS calculators and dashboards:
The OWASP LLM Top 10 and AIVSS represent complementary efforts from the same organization. The Top 10 identifies and ranks the most critical risks, with prompt injection at the top. AIVSS provides the scoring methodology to quantify the severity of specific instances of those risks. Together they form the beginning of a governance stack for AI security that mirrors what OWASP built for web application security over the past two decades with the original Top 10 and its associated testing guides.
The AIVSS founding membership is notable, but I’m bias, as I’m among them. It also includes representatives from NIST, NSA, Google, Microsoft, Anthropic, AWS, JP Morgan, MIT, CISA, Gartner, MITRE, and Scale AI. Apostol Vassilev, the NIST scientist who proved that jailbreaks can never be fully eliminated, sits on both the founding membership and the Distinguished Review Board. The framework is being built by people who understand both the AI safety problem and the mathematical limits of any solution.
Where This Framework Should Live
One of the most important questions about a jailbreak severity framework is governance. Anthropic is drafting theirs with other frontier labs, which makes sense as a starting point. But a framework that is owned and maintained by the companies whose models are being evaluated will face the same credibility questions that would arise if software vendors maintained their own vulnerability scoring systems (and some do).
The most effective path would be for this work to converge with existing industry efforts at organizations like OWASP, the Cloud Security Alliance, or the Coalition for Secure AI (CoSAI). These organizations have the governance structures, the multi-stakeholder participation, and the credibility to maintain a framework that the broader practitioner community will trust and adopt. OWASP’s AIVSS is the most natural home given its existing scope and the caliber of its membership, but the CSA’s work connecting the Vassilev proof to practical monitoring guidance and CoSAI’s focus on AI security standards both represent viable paths.
The worst outcome would be fragmentation, where every frontier lab maintains its own severity taxonomy, every regulator invents their own assessment criteria, and practitioners are left translating between incompatible frameworks.
The vulnerability management community lived through exactly this before CVSS emerged as a common standard, and the wasted effort and inconsistent prioritization that resulted should serve as a cautionary tale.
What This Means for Practitioners
The practical takeaway is that jailbreaks are entering the same lifecycle that software vulnerabilities went through over the past two decades. They started as novel, surprising events. They are becoming routine, expected, and manageable through structured processes. The industry is building the scoring, classification, and response frameworks that will define how organizations handle jailbreaks at scale.
For practitioners deploying AI systems today, this means several things. First, accept that jailbreaks are a permanent feature of AI systems, not a bug that will be patched away. NIST has proven this mathematically and Anthropic, OpenAI, and OWASP have all acknowledged it publicly.
Any vendor telling you their model is fully jailbreak-proof is selling something that cannot exist.
Second, start thinking about jailbreak response the same way you think about vulnerability management. Not every jailbreak is equally severe. Anthropic’s five-tier taxonomy, ranging from minor intrusions into the safety margin all the way to universal jailbreaks that unblock entire classes of harmful behavior, provides a useful starting framework. The severity of a jailbreak depends on what capability it unlocks, how broadly it applies, how easy it is to weaponize, and how widely the technique is known. Organizations need triage processes for jailbreaks the same way they have triage processes for CVEs.
Third, watch the framework convergence carefully. Whether the industry coalesces around Anthropic’s four-criteria model, OWASP’s AIVSS, or something that combines elements of both will determine how practitioners communicate about AI risk for years to come. Engage with these efforts now rather than waiting for a standard to be imposed.
The cybersecurity industry spent twenty years learning that vulnerability severity scoring is necessary, imperfect, and only useful when combined with exploitation evidence, organizational context, and asset criticality.
The AI safety community has the opportunity to compress that learning curve dramatically. The question is whether it will, or whether it will repeat the same progression of oversimplified severity scores driving compliance-oriented responses while the actual risk distribution goes unaddressed.
Given what I have watched happen with CVSS, I am cautiously optimistic but realistic about the odds.