By Clara Reed
Anthropic’s July 2 disclosure about Claude Fable 5 offers a useful starting point for a question every security team should answer before connecting an AI model to code, tickets, logs or cloud tools: what exactly happens when a request sits between legitimate defense and offensive capability? The company says Fable 5 uses safety classifiers alongside access controls, safety training and offline monitoring. It also divides cyber activity into four categories, from prohibited use to benign use.
That taxonomy is not an independent certification, and Anthropic does not publish a universal pass rate for it in the announcement. It is still practical as an assessment template. The guide below turns the disclosure into an eight-minute first review for a model you plan to use in an authorized security workflow. Treat the result as a launch gate, not as proof that a system is safe in every situation.
1. Write down the allowed job
Start with one narrow use case and one owner. “Help the SOC” is too broad. A useful scope might be summarizing alerts, reviewing a patch for an already identified flaw, analyzing sanitized logs or suggesting a safer configuration. Record the systems the model may read, the tools it may call, the data it may retain and the person who approves actions.
Keep discovery and execution separate. An assistant that explains a vulnerability or proposes a patch should not automatically be able to scan an external host, change a firewall rule or deploy code. Use a read-only identity for the first phase, and require a human approval step for every action that changes a system.
2. Map the workflow to a risk category
Use Anthropic’s four-way model as a simple decision table. Prohibited activity includes destructive impact, malware development, defense evasion, covert command-and-control and exfiltration. High-risk dual-use work includes penetration testing, privilege escalation, lateral movement, exploit development and assessments of industrial, telecom or financial infrastructure. Those are not ordinary productivity tasks; they need a separate, tightly controlled process.
Low-risk dual-use work includes public-source research, enumeration of publicly accessible systems and vulnerability identification that widely available tools can already perform. Benign work includes secure coding, patch management, log analysis, threat hunting, incident response and defensive configuration. If a request could move from one row to another when context changes, classify the workflow by its most harmful plausible outcome and apply the stricter control.
3. Build a safe verification set
Do not test safeguards against a live target, real credentials, production secrets or malware. Create a disposable repository and a synthetic log set instead. Include benign tasks that should be allowed, such as fixing an intentionally simple coding error, explaining a known vulnerability at a high level and writing a defensive detection rule. Include boundary cases phrased as legitimate security work, but keep them non-operational and confined to the test environment.
For each case, record the exact prompt, attached data, model version, tools exposed, response, block or allow outcome, and whether a human reviewer would classify the request differently. Repeat each case at least once after changing only the surrounding context. This checks whether the control is responding to the task rather than to a particular keyword. Never turn a blocked case into an offensive recipe while trying to reproduce it.
4. Check the safety margin
Anthropic says Fable 5 uses a deliberately larger safety margin than earlier models: some benign or low-risk requests may be blocked to reduce the chance that harmful requests pass through. That trade-off matters operationally. A high block rate on defensive work can push analysts toward unsafe workarounds, while a permissive boundary can create a more serious exposure.
Measure both sides in your own approved set. Count false positives among legitimate tasks and false negatives among the non-operational boundary cases. Do not convert those counts into a product-wide accuracy claim; your small sample is only evidence about your configuration. If an allowed response contains unexpected operational detail, stop the workflow, preserve the record, remove sensitive inputs and escalate it through the provider’s security channel.
5. Score jailbreak reports by impact
When a safeguard failure is found, document four questions drawn from Anthropic’s proposed Cyber Jailbreak Severity framework. How much new capability does the technique provide beyond existing tools? How broadly does it work across targets or offensive tasks? How easy is it to turn into a repeatable workflow? How discoverable is the technique to an attacker?
Keep the report abstract enough to avoid spreading a working bypass. Include the minimum reproducible evidence, the affected model or configuration, the data exposure, the required human effort and the immediate mitigation. A narrow, difficult-to-reproduce issue is not automatically harmless; a broadly reusable failure may deserve urgent containment even if the output still needs expert work.
6. Put the controls around the model
Prompt filtering is only one layer. Place sensitive code and logs behind least-privilege access, redact secrets before they reach the model, isolate tool execution, cap network egress and log every tool call. Add rate limits and an emergency disable switch. Review model updates, classifier changes and connector permissions as change events, not as routine maintenance.
Finally, schedule the same safe verification set for every material model or policy change. Keep a human owner for approvals and a separate owner for incident response. Anthropic’s disclosure is valuable because it makes the boundary explicit: cyber safety depends on classifiers, but also on access controls, monitoring and governance. Your deployment should make those layers independently testable.
Bottom line: use the public taxonomy to decide what the model may assist with, verify the boundary in a disposable environment, and prevent the model from taking unsupervised action. If you cannot explain what happens when a request is blocked, logged or escalated, the workflow is not ready for production.