On 1 September, Anthropic shipped two models it describes as strictly identical: "Claude Fable 5.1 and Claude Mythos 5.1 are the same model, but with different levels of safeguards." The first is generally available and can now identify vulnerabilities in source code, but will not produce working exploits; penetration testing, exploit generation and binary analysis remain refused. The second lifts those limits, but only through a vetted access programme reserved for security professionals. Two days later, OpenAI placed its new model at the "critical" tier of its own cyber capability scale, with the same arrangement: wider access granted after identity verification.
Two competing labs, forty-eight hours apart, the same call. That is not scheduling luck. It is a shared doctrine taking shape.
The line drawn between finding and exploiting is easy to state and leaky in practice. During an audit, a working proof of concept is often the only way to separate a genuine vulnerability from a theoretical one. An overflow in a function your traffic never reaches does not warrant a maintenance window; the same overflow reachable from an exposed interface warrants one that evening. Only an exploitation attempt settles the question.
So the restriction constrains the defender first. The attacker enrols in no verification programme: they run an open-weights model, or they work around the guardrails. Anthropic documents this itself — researchers had already extracted exploit code from the previous version simply by asking it to identify a vulnerability.
Finding flaws has never been the bottleneck in an audit. Putting them back in context is: which version is genuinely running in production, which code path is reachable from outside, what compensating control already exists. A model flagging a weakness in an isolated file answers none of those three questions.
What is new is a question worth adding to your tenders: is your provider a member of a vetted access programme? The answer is verifiable, and it says something real about their capability.
It also raises another point. Joining one means sending code, and sometimes binaries, to a model hosted by a third party. On a scope covered by a confidentiality agreement or a sovereignty requirement, that question belongs before the engagement, not during it.
Your exposure window is shrinking. The unspoken assumption that an obscure flaw in a rarely inspected component would stay unnoticed for months no longer holds.
Three questions for your next steering committee: how long, in your organisation, separates a patch being published from it being applied; which embedded third-party components are covered by no monitoring at all; and under which legal framework your source code would leave the building if your auditor routes it through an external model.
Picking a “sovereign” model does not make a use case compliant. What can actually be controlled is which data leaves, what the provider does with it, and what trace you keep.
The standard has been published since 2024. What stalls enterprises is not picking an algorithm — it is knowing where cryptography actually sits, and how long already-deployed equipment will live.
CyberIA Labs
