A model came back this week, and it did not come back alone.
On 30 June 2026 the United States Department of Commerce lifted the export controls it had imposed three weeks earlier, and from 1 July Anthropic began restoring Claude Fable 5 globally, on the Claude Platform, Claude.ai, Claude Code and Claude Cowork. For Australian users that ends a short, strange outage. If your organisation relies on a frontier model for real work, the reinstated access is the least interesting part. The framework that arrived with it, and the way the model was let back out, are the parts worth filing.
What actually happened
Rewind to 12 June. Anthropic received a legal directive from the US government at 5:21pm Eastern time to suspend access to Fable 5 and its restricted sibling Mythos 5 for "any foreign national, whether inside or outside the United States". In practice the company suspended both models for all users. Its stated understanding was that the government believed it had found a way to bypass, or "jailbreak", Fable 5 to unlock cybersecurity capability. Anthropic complied. Australians, as foreign nationals, were squarely inside the group that lost access.
Three weeks later the controls came off. In its 30 June post, "Redeploying Claude Fable 5", Anthropic said researchers from the Department of Commerce's Center for AI Standards and Innovation, known as CAISI, had tested both its prior and new safeguards, the controls were lifted, and the model would return globally the next day.
Two things came back with it. First, a new cybersecurity classifier. Anthropic says it blocks the behaviour described in the report, the jailbreak itself, in more than 99% of cases. It is candid about the cost: the classifier "comes at the cost of flagging benign requests more often during routine coding and debugging tasks". Second, and more significant, a proposed framework. Together with Amazon, Microsoft, Google and other partners in its Glasswing program, Anthropic has started building a shared way to rate how serious an AI jailbreak actually is.
What it actually means
The headline is "access restored". The substance is a governance artefact taking shape in public.
Until now, "this model was jailbroken" has been a binary, largely rhetorical claim. One lab's serious breach is another's minor curiosity, with no common scale to say which is which. The proposed framework tries to fix that by rating a jailbreak on four dimensions: how much capability an attacker actually gains beyond tools already available to them; how broad that gain is across different offensive tasks; how easy the technique is to weaponise; and how discoverable or widely known the technique already is.
That is what a safety standard looks like when it is being written rather than announced. Not a page of principles, but a severity scale that turns a scare word into something you can measure and compare. Anthropic calls it something the group has "started to develop", so it is early. The direction is the point: the industry is inching from "trust us, it is safe" toward "here is how we score the risk".
Scoring a jailbreak in practice
The four dimensions only earn their keep if you can run something through them, so here is a worked example. Picture a widely shared prompt that coaxes a general assistant into writing a phishing email a little more convincing than the user could manage alone. Score it.
Capability gain: low. A motivated person can already write a passable phishing email, and templates are everywhere, so the model adds polish rather than a new power. Breadth: narrow. The trick helps with one task, social-engineering text, not a spread of offensive work. Ease of weaponisation: high, because it is a copy-and-paste prompt that needs no skill. Discoverability: high, because it is already circulating publicly.
Now score a different case: a technique that reliably walks the model through producing working exploit code for a class of software vulnerabilities the user could not have written unaided. Capability gain: high, because it hands over something the attacker did not have. Breadth: wide, because it generalises across targets. Ease of weaponisation and discoverability might both be low if the method is fiddly and privately held, but the first two dimensions already mark it as serious.
The value is in the disagreement the scale resolves. The phishing case feels alarming and scores mild. The exploit case can look academic and scores severe. A shared rubric moves the conversation off vibes and onto the two questions that matter most for misuse: how much new capability, and how broadly it reaches. That is the difference between a scare word and a risk rating.
The safety-utility trade-off you inherit
Here is the part that lands on your desk directly. The fix that made the return possible is not free. By Anthropic's own account, the new classifier flags benign requests more often during routine coding and debugging. A legitimate developer will now hit more false alarms on ordinary work, because the model is more cautious to close a specific hole.
That is the general lesson in this week's specifics. When you depend on a model for real work, a safety patch can quietly change its behaviour on your legitimate tasks. The model you assessed at procurement is not always the model you are running a fortnight later. The patch is the responsible move; the point is to treat vendor safety updates as change events, not silent background maintenance.
Who is building it, and why release is now gated
Two structural signals sit underneath the news, and both matter more than the model itself.
The first is who is holding the pen. This is not Anthropic alone publishing a policy. The severity work is running through its Glasswing program with Amazon, Microsoft, Google and other partners, which is what makes it a candidate industry standard rather than one vendor's house rules. A scale only one lab uses is marketing. A scale several competitors agree to use is the beginning of a benchmark, the kind of thing a regulator or a procurement team can eventually point at.
The second is how the model came back. It returned only after CAISI, a government standards body, tested both the old and the new safeguards. Release was no longer purely the vendor's call. A capable model was pulled, patched, tested by a public authority, and only then let back out. That is a preview of how frontier releases may increasingly work: gated on a demonstrated safety control that an external body has checked, not simply shipped on a launch date the vendor chose. For anyone whose risk register treats "the vendor decides when to ship" as a given, that assumption is loosening.
Map it to your controls
None of this is abstract for regulated Australian teams. It maps onto obligations you already carry.
Under the Voluntary AI Safety Standard, the expectation to understand and manage your AI supply chain now has a concrete hook. A shared jailbreak-severity scale is exactly the kind of artefact a third-party assessment can lean on: instead of accepting "our model is safe", you can ask a provider how they rate the misuse severity of their model and how they respond to a serious finding. That same question sits comfortably inside an APRA CPS 234 information-security review of a material technology provider, where you are already expected to assess the security capability of third parties commensurate with the threat they face.
CPS 230 supplies the change-management half. It frames a material AI provider as a service relationship with a service provider, and a behaviour-altering safety patch is a change within that relationship. The standard's discipline, know your material service providers, understand the impact of disruption, and manage change, applies cleanly to a classifier update that shifts how a model handles your legitimate work. The move is to fold three questions into your existing register: where does this provider sit on the emerging severity scale, what is their process when a serious jailbreak is found, and how will we know when a safety update has changed the model's behaviour on our workflows.
Questions to put to your AI vendor
You do not need to wait for the framework to mature to use its logic. Lift these into your next third-party AI assessment.
- How do you rate the severity of a jailbreak or misuse finding, and do you use a scale with defined dimensions such as capability gain, breadth, ease of weaponisation and discoverability?
- What is your process when a serious finding lands: who is notified, on what timeline, and what interim control applies while a fix is built?
- When you ship a safety or classifier update, how do you tell customers, and what changes on our side of the interface, including any increase in false positives on legitimate work?
- Can access to the model be restricted by government or export action, and if so, what is your continuity commitment and our notice period?
- Which external or public bodies, if any, review your safeguards before a significant release, and can we see the result?
None of these needs a mature standard behind it. They turn a vague "is it safe" into answerable questions, and a vendor who cannot answer them has told you something useful.
The Australian angle, and the wider one
For regulated work here, two threads matter. Due diligence gets a common language: a severity scale, once it matures, gives your third-party assessment a shared way to ask about misuse rather than accepting a vague assurance. Change management gets a trigger: if a model's behaviour on your legitimate tasks can shift with a safety update, your controls need to notice, re-test the key workflows, and log what changed.
The wider thread is that none of this is really about one model. For the second time in a month a frontier model's availability moved on government action, and this time it moved back. The safety-patch lesson is not Anthropic-specific either: any major vendor can, and will, change a model's behaviour under you to close a risk. Read the specifics as a template. Access is a live variable, not a settled fact, whether the logo on the model is Anthropic, OpenAI or Google. Keep a named fallback in your AI plan, and treat a behaviour-altering update from any of them the way you would treat a change to any material service.
Hype check
The framework is proposed, not adopted. Four dimensions is a start, not a standard, and a group of vendors agreeing on a scale is not a regulator mandating one. Do not overstate it. Equally, do not read the return as an all-clear that drops the caution the past month earned. The honest version is smaller than either headline: the labs are starting to standardise how they measure model misuse, and a safety fix arrived with a real cost attached.
What to do this week
- If your team uses Fable 5 through Claude.ai, Claude Code or Cowork, expect it back from 1 July and re-test your legitimate workflows. The new classifier may flag more routine coding and debugging requests. Log any new false positives so you can tell your people what changed and why.
- Add jailbreak and misuse severity to your AI vendor questions. Use the five above, and watch the four-dimension framework as it develops. Fold it into your next third-party AI assessment under the Voluntary AI Safety Standard and CPS 234.
- Treat vendor safety updates as change events. For any AI supporting real work, re-test after a safety patch, record what shifted, and keep the evidence. The model you signed off is not always the model you are running.
The loud version of this week is that a model came back. The lasting version is that it came back measured, tested by a public authority, and carrying the first draft of a shared way to score its own risk. That is the development to watch.
TheAICommand. Intelligence, At Your Command.
