ENDASV · soonNO · soon

JOURNAL

Anthropic just published what Fable 5 blocks on cybersecurity. Here is how to turn it into a policy that survives an audit

Fable 5 came back, developers hit blocks on ordinary coding work, and Anthropic responded with a detailed list of what the model stops and what it does not. Here is what it means for your company.

3 July 2026·17 min read·claude · anthropic · fable 5 · cybersecurity · jailbreak · gdpr compliant ai consulting · ai governance · claude for business · claude news

When Claude Fable 5 came back globally on 1 July, it did not take long before a group of developers noticed something odd. Completely legitimate coding tasks were being blocked. Secure coding, debugging, ordinary work that has nothing to do with attacks. The criticism came fast, and Anthropic answered just as fast. On 2 July they published a detailed walkthrough of what Fable 5's cybersecurity safeguards are, and are not, built to stop, along with a first draft of a shared yardstick for how serious a jailbreak is. A jailbreak is a technique that tricks an AI model into bypassing its built-in safeguards.

For a Nordic company the interesting part is not the model itself. It is that an AI vendor is publishing its blocking logic and a proposed severity scale for the first time. That is exactly the kind of documentation you can build a usage policy on, and exactly the kind an audit asks for. That makes this more than a cybersecurity news item. It is a governance document you can use.

Anthropic: More details on Fable 5's cyber safeguards and our jailbreak framework (2 July 2026)

Anthropic's own starting point is that almost every security capability can be used both ways, for defense and for attack. As they put it:

All security capabilities are dual use, that is, they can under certain circumstances be helpful to both attackers and defenders.
Anthropic, More details on Fable 5's cyber safeguards and our jailbreak framework, 2 July 2026

Key takeaways

  • Fable 5 came back, and legitimate coding tasks were soon blocked. Anthropic responded by publishing exactly what the model blocks and what it does not.
  • Cyber work is split into four categories, from prohibited to benign. Secure coding and debugging are benign and pass. If they get rejected, it is a false alarm.
  • They propose a shared severity scale for jailbreaks, called CJS. It does for jailbreaks what CVSS has long done for software vulnerabilities.
  • The value for you is not in the document, that is free. It is in turning it into a usage policy that survives an audit.
  • AI literacy is no longer optional. It is a legal duty under EU AI Act Article 4.

The four categories of cyber use

Cybersecurity is hard for safeguards because most capabilities are dual use, meaning they can be used both for defense and for attack. A model that can scan your codebase for vulnerabilities can, in the wrong hands, also be the first step in an attack. That is why Anthropic does not block all cyber work. They train their safety classifiers, the smaller AI systems that monitor a conversation and block dangerous responses, to tell four categories apart.

Prohibited use. Activities with high potential for harm and little defensive value. Anthropic lists ransomware and other extortion software, programs that wipe data, malware development and delivery, command-and-control servers, exfiltration of data out of the owner's systems, attacks on the internet backbone such as BGP hijacking and DNS attacks, and direct sabotage of physical processes like power, water, oil and gas, transport and medical devices. That is blocked.

High-risk dual use. Activities that are widely used by attackers but are also the daily work of security professionals. Penetration testing, red teaming, privilege escalation, lateral movement across a network, and exploit development. It is blocked for now, because Anthropic does not yet have a reliable way to limit access to known, approved actors.

There is an important nuance here. Anthropic does not want to block all vulnerability finding, because it is a core part of defensive work. They aim to block what they call high-uplift vulnerability finding, the ability to find vulnerabilities that other freely available models cannot, and they block the automatic generation of exploits. If many other models can already find a given vulnerability, it is instead a benefit to let Fable find and fix it.

Low-risk dual use. Activities that lean toward defense but can also help an attacker. Open source intelligence, identifying vulnerabilities that other tools can already find, testing cryptographic protocols. A lot gets through, but a portion is still blocked as a deliberate safety margin.

Benign use. Core defensive and IT work with little room for abuse. Secure coding, debugging, translating code into more secure languages, log analysis, threat hunting, incident response, patch management, malware reverse engineering and security training. This is not meant to be blocked.

One last detail IT people will notice: techniques that get Claude to reveal its own system prompt are not treated as a cybersecurity risk and are not something they try to block. Fraud and social engineering without malware, game cheating and web scraping also sit outside these specific cyber classifiers, even if some of it is caught by other safeguards.

The four categories of cyber use: prohibited, high-risk dual use, low-risk dual use and benign use, with what Fable 5 blocks and allows.
Fable 5's safeguards tell four categories of cyber work apart.

The safety margin, and why coding got blocked

The safety margin explains the whole episode. Anthropic deliberately sets the classifier to also block a share of requests that are probably harmless. A request has to look very clearly safe to get through. For Fable 5 they made the margin larger than for earlier models, precisely to have more confidence they catch the dangerous requests. The cost is more false rejections, and that is exactly what the developers ran into: harmless coding work that got refused. The gain from the wide margin is that fewer genuinely dangerous responses get out. With this post Anthropic makes it clear that coding work belongs in the benign category, and that rejections there are false alarms, not a decision to shut down coding. Classifiers are only one layer. They also use access controls, safety training of the model itself, and monitoring after the fact.

The proposed severity scale for jailbreaks

Today there is no shared standard for how serious a jailbreak is. That makes it hard for both developers and governments to know when to react. Anthropic now proposes a scale it calls Cyber Jailbreak Severity, or CJS. It runs from CJS-0, purely informational, through CJS-1 low, CJS-2 medium and CJS-3 high, to CJS-4 critical. The scale is meant to be exponential, so each step is several times more serious than the one before.

A jailbreak is scored on four axes. Capability gain: how much further it takes the attacker than the tools that already exist. If weaker, freely available models can do the same, the score is zero and the assessment stops there. Breadth: how many different attack tasks the same technique works on. Ease of weaponization: how much human effort and expertise it takes. And discoverability: whether the technique is freely available online, or takes months of specialist work to find.

The four scores are added into a number between 0 and 10. CJS-0 is 0, CJS-1 is 1 to 3.5, CJS-2 is 4 to 6.5, CJS-3 is 7 to 8.5, and CJS-4 is 9 to 10. The calculated number is a floor. The final severity can be raised if the real risk is greater, for example if a jailbreak hits a power grid or a banking system, but never lowered below the calculated score.

The Cyber Jailbreak Severity scale from CJS-0 informational to CJS-4 critical with the four scoring axes.
Anthropic's proposed severity scale for jailbreaks. An early draft.

Three examples of how a jailbreak is scored

Anthropic gives its own examples, and they make the scale concrete.

The worst case is a universal system-prompt override: a single public, reusable text string that switches safety off across every category of attack and is widely posted on social media. It scores CJS-4, a 10, the maximum on every axis.

The most instructive example is that severity depends on timing. Imagine a jailbreak that gets the model to find the well-known Log4Shell vulnerability. If it had happened in December 2021, before the vulnerability was public and no other tool could find it, it would score as high as CJS-4, because the model handed an attacker something no one else could. The same jailbreak today, where Log4Shell is public knowledge and every scanner finds it, scores CJS-0. Capability gain is always measured against the tools that exist at the time of assessment. The model's behavior is the same, but the baseline has moved.

Anthropic has opened a HackerOne program where security researchers can submit jailbreaks found in Fable 5, and it takes feedback on the framework itself at [email protected]. The work is done together with its Glasswing partners, which it says include Amazon, Microsoft and Google. That partner list is Anthropic's own statement and is not independently verified here.

A shared language for severity, borrowed from vulnerabilities

If the idea sounds familiar, there is a good reason. The security industry has had CVSS, the Common Vulnerability Scoring System, for years. It is a standard from the organization FIRST. It gives every software vulnerability a score from 0 to 10 and translates it into low, medium, high or critical, where critical is 9.0 to 10.0, high is 7.0 to 8.9, medium is 4.0 to 6.9 and low is 0.1 to 3.9. It is used across the industry, including by the US National Vulnerability Database (NVD), run by NIST. The point of CVSS is not that the number is perfect. The point is that everyone speaks the same language, so a vendor, a customer and a regulator mean the same thing when they say critical.

CJS tries to do the same for jailbreaks. It is worth understanding, because it tells you something about how mature this part of AI security is becoming. We have gone from no shared yardstick to a first draft in a short time. That is good for you as a buyer, because the more the industry speaks one language about risk, the easier it is to set requirements and judge the answers.

Where it fits in the bigger picture

Jailbreaks are not a standalone phenomenon. In the well-known OWASP Top 10 for LLM Applications from 2025, the security organization OWASP's list of the biggest risks in language models, a jailbreak sits under prompt injection, which ranks as risk number one on the list. Prompt injection means using text to make a model ignore its original instructions. Another item on the list is system prompt leakage, getting the model to reveal its own system prompt. Here is a detail many people miss: Anthropic says directly that this type sits outside their cyber classifiers and is not something they try to block. They publish that kind of thing themselves. It is a healthy sign that they separate real cyber risk from noise, instead of blocking everything that sounds technical.

Here is my take

Here is my take, and it is an opinion, not a fact. The most important thing about this post is not the security itself. It is that the value sits in the implementation, not in access to the model.

Anyone can get access to Fable 5. It took two days from the criticism to the clarification, and the clarification is public and free. What is hard, and what actually protects your company, is translating the four categories and the safety margin into a concrete usage policy that your employees understand and an auditor can read. That is work, not a download. It is exactly what I do for companies: Claude put directly into the business, under your own data and security rules, with your team able to keep building after I leave.

And an honest counterweight, because I will not sell this as more than it is. The framework is Anthropic's own early draft, not a finished third-party standard. The numbers and categories are their own account. It is well considered and well documented, but it is not an independent audit. Use it as a strong basis, not a norm set in stone.

This is now also a legal question

Here is the part many companies have not caught yet. With the EU AI Act, having your AI in order is no longer just good practice, it is law. Article 4 on AI literacy requires that anyone who provides or deploys AI ensures a sufficient level of AI literacy among their staff and among others who use the systems on the company's behalf. That obligation entered into application on 2 February 2025, and supervision and enforcement apply from 2 August 2026. It applies to everyone, whether your AI is high-risk or not. A softening of Article 4 has been proposed, so the duty would be to support the development of AI literacy rather than guarantee a specific level, but that is a proposal, not law yet.

This ties directly to this post. A usage policy built on the vendor's own categories is a concrete way to meet the requirement, and so is recognized AI training like Anthropic's AI Fluency certification through Anthropic Academy, Anthropic's own education track. And if you are working toward ISO 42001, the new standard for AI management systems, it expects exactly that vendor documentation and vendor assessment feed into your own system. Anthropic just handed you a piece of that material for free.

For the record: I hold that AI Fluency certification myself through Anthropic Academy. So this is not theory for me.

Four steps from vendor document to audit-ready AI usage policy: read the categories, write the policy, train the team, host in the EU.
Four steps turn Anthropic's documentation into a policy that survives an audit.

Red flags when you write an AI usage policy

This episode exposes some classic mistakes I see again and again. Avoid them.

Thinking access is the same as having it under control. Having the model is easy. Having a policy your people follow is the work.

Forgetting the false rejections. If you do not write down that legitimate work is sometimes blocked, an employee thinks it is a bug and may start looking for workarounds.

Treating a draft as a standard. The CJS scale is an early draft. Do not build your compliance argument on it being a finished norm.

Skipping EU hosting. If you run personal data through the model without deciding on a region, you have a gap an audit will find.

Not training the team. Under EU AI Act Article 4, that is no longer a choice.

What it means for Nordic B2B SaaS

For a Nordic B2B SaaS company this is directly relevant, because you both build software and sell trust. The four categories tell you exactly what Claude will help your developers with, and where you might hit a false rejection. Secure coding and debugging get through. That is good to know before you put Claude into your development flow. At the same time you can use the vendor's published security approach in your own customer communication. When a customer asks about the security behind your product, it is strong to be able to point out that the model behind it has a considered, public blocking logic. That is a concrete sales argument, not just a compliance checkbox.

What it means for telemarketing and sales teams

For a telemarketing or sales team, cybersecurity is rarely the core task, but trust is. If you use Claude to research prospects, write follow-ups or run a customer-facing agent, the practical message is that ordinary sales work sits far from the blocked categories and passes cleanly. What you can take away is reassurance: the model behind your work has a public and considered security profile. If a customer or a compliance officer asks what sits behind your AI, you now have a concrete answer to give, instead of a shrug.

What it means for professional services firms

For lawyers, accountants, advisors and other professional services firms, this may be the most valuable news of all. Your business is built on confidentiality and documentable order. A vendor document that describes exactly what the model blocks, and how severity is assessed, is gold for your own risk management. You can reference it in your vendor assessment, and you can base what your people may use Claude for on the four categories. That makes it easier to say yes to AI without compromising the documentation your field requires. And because you often advise your own clients on exactly this kind of thing, it is an approach you can learn to use and pass on.

What it means for founders and scale-ups

For founders and scale-ups there are two concrete things. One, if you build anything that touches cybersecurity, read the four categories carefully, because they tell you exactly where you might hit a block on otherwise legitimate work. Two, the safety margin is set tight on Fable 5, so expect more false rejections in coding and security tasks than on lighter models like Opus. Build your flow so a blocked request does not stop the whole workflow, for example by having a clear path to escalate or switch model. It is a small design decision now that saves you a lot of frustration later.

GDPR, the EU, and what applies to Nordic companies

This post is more a governance document than a news item, and that is exactly why it is useful before an audit. A SOC 2, ISO 27001 or ISO 42001 audit asks how you manage the risk of the tools you use. The vendor publishing what the model blocks, and how they assess severity, is documentation you can point to. Save the link, and write the four categories into your own usage policy for Claude.

The false rejections are also an operational fact that should be written down. The wide safety margin means legitimate work is sometimes blocked. It is not a data breach and not a bug, but an employee needs to know it in advance. If data rules mean you run on a specific cloud, you can host Claude in the EU through AWS Bedrock or Google Vertex AI, so the processing stays in the region. The security story is Anthropic's own and a stated early draft. Use it as a good basis, not a finished norm.

If you want that kind of vendor documentation translated into a usage policy that survives an audit, that is exactly what I do. I put Claude into your business under your own data and security rules and make your team able to run with it themselves. See how I work with internal AI tools, or write to me and we will talk through your situation.

In short

Anthropic did something unusual: it showed the engine room. The four categories tell you what Claude blocks, the CJS scale gives the industry a shared language for severity, and the system-prompt exception shows they draw the line with care. The value for you is not in the public documentation, that is free. It is in turning it into a usage policy that meets the EU AI Act and survives an audit. That is work, and it is exactly the work I do.

Sources

Primary sources (Anthropic)

Third-party sources for background and verification

The categories, the severity scale (CJS) and the Glasswing partner list (Amazon, Microsoft, Google) are Anthropic's own account and a stated early draft. They are not independently verified here.

Division of the work between AI and Kim, phase by phase. In total AI 70 percent, Kim 30 percent.
How the work behind this article was divided. An informed estimate, not a measured log.

This work was produced in collaboration with AI. Overall: AI about 70 percent, Kim about 30 percent. Production only: AI about 89 percent, Kim about 11 percent. The human sets the direction, AI produces the volume. An informed estimate, not a measured log.

FAQ

Frequently asked questions

A jailbreak is a technique that tricks an AI model into bypassing its built-in safeguards, so it does something it is otherwise set to refuse. Anthropic now proposes a shared scale, Cyber Jailbreak Severity, to measure how serious a given jailbreak is.

No. Anthropic places secure coding, debugging and log analysis in the benign use category, which is not meant to be blocked. Because Fable 5 has a wide safety margin, legitimate work can sometimes be rejected anyway, but that is a false alarm, not a decision to shut down coding.

Article 4 requires that you ensure a sufficient level of AI literacy among your staff. The obligation entered into application on 2 February 2025, and enforcement applies from 2 August 2026. A usage policy and training built on the vendor's own categories is a concrete way to meet it.

Write a usage policy based on the vendor's categories, host in the EU via AWS Bedrock or Google Vertex AI if data rules require it, train the team, and document what counts as permitted use. That is exactly the kind of GDPR compliant AI consulting Brinvik helps companies with.

Get new essays by email.

Roughly twice a month. Same voice. No list rental, no retargeting.

Sign up for the Brinvik journal. Unsubscribe anytime. See our privacy policy.

Protected by Cloudflare Turnstile. No challenge, no CAPTCHA. Brinvik never shares your address.