On 1 September, Anthropic released Claude Fable 5.1 and Claude Mythos 5.1. The interesting part is a single sentence in the announcement: they are the same model, with different levels of safeguards.
Not a smaller model. Not a distillation. The same weights, gated differently. Fable is the version anyone can use. Mythos is the version you reach through the Cyber Verification Program or the Life Sciences Verification Program, after somebody has established who you are and what you intend to do.
That is not a model release. It is an access control decision, and it has a shape I recognise.
This is the zero-trust argument, applied to capability
Strip the vendor language off zero trust and it says: stop granting access on the basis of where a request came from, and start granting it on the basis of what the requester proved. Capability tiering says the same thing about what a model will do for you. The question stops being "is this prompt allowed" and becomes "is this requester verified for this class of work".
Anyone who has run an identity programme knows what happens next, because the hard parts are the same hard parts:
- Verification is slow, and the people who most need access are rarely the ones best at paperwork.
- Every real environment contains an exception the model cannot accommodate this quarter.
- Access granted in one jurisdiction is not access granted everywhere. In June, Commerce restricted both models for non-US nationals; access was pulled globally and only fully restored at the end of the month.
The timeline is worth having straight. Mythos was disclosed on 7 April and deliberately not released, because it could find vulnerabilities on its own. Instead came Project Glasswing, giving forty-odd large companies access to fix what it found. Fable 5 and Mythos 5 arrived on 9 June. The 5.1 pair landed on 1 September.
The number that matters to defenders is the false positives
Anthropic reports that the new safeguards block 60% fewer false positives on cybersecurity work, and that Fable 5.1 is now permitted to identify software vulnerabilities for defensive purposes. Penetration testing, exploit generation and binary-based vulnerability scanning stay behind the gate.
That 60% is the real product change for anybody doing security work, and for the same reason that a scanner with a high false-positive rate gets ignored. A tool that refuses your legitimate work does not make you safer. It teaches you to route around it, and the route around it has no safeguards at all. Every security control I have ever seen fail in production failed that way first.
What I would take from it
If you are choosing tooling for a security team this year, the question is no longer only how capable the model is. It is which tier you can actually be verified for, how long that takes, what happens to your workflow when the answer is no, and whether the vendor's restrictions are the ones your regulator will ask about.
Capability is becoming a thing you qualify for. That is a defensible design. It is also a new dependency, and dependencies deserve to be written down before you build on them.