On Friday, June 12, the same model class covered by our previous blog post went dark. Anthropic suspended Fable 5 and Mythos 5 worldwide after a US Commerce Department issued an export-control directive which led to requests from prominent cybersecurity pros requests to undo the action.

The bypass that triggered the export controls, per Katie Moussouris, was a request to “fix this code” that required a multi-step and manual process. This occurred after a request to “review this code for security issues” failed and triggered the guardrails.

Our original launch analysis still holds, but the revocation adds a risk vector that isn’t about the model’s capabilities at all. It’s about who can switch them off, how little warning you’ll get, and the business risk implications for organizations. Once model access is restored, this post will remain relevant in case it happens again.

Here’s the “good news” (if there is any about this episode). Fable 5 (and its brother model Mythos 5) just released. While plenty of organizations had internal access for testing purposes, most enterprises had yet to build any meaningful integrations into existing products and services. Consumer subscribers had access to Fable 5 as well, but only with significant utilization premiums attached to it.

The reality is that the revocation of access to these models came so quickly that it’s unlikely it resulted in substantial impact to enterprise teams. That’s the bright side.

The downside, however, is that the next suspension may not come as quickly as this one. We dive into the details of what this means below.

What The Revocation Means

1. It does not mean “go buy a non-US model”, but it does mean single-sourcing any frontier model is now a concentration and continuity risk.

The instinct to flee to a non-US provider is understandable and wrong. A European or Chinese model carries its own export-control exposure, its own government-control story, and in the China case a far more direct state-access concern for US enterprises. Swapping one sovereign dependency for another simply relocates risk under the guise of taking action. AI sovereignty is also not a “plug and play” choice of AI model alone. It also depends on factors like compute infrastructure, data sovereignty, and energy sources and non-technical inputs like operational, legal, and compliance risk when working in other jurisdictions.

What the revocation actually argues for is model portability as a control objective: abstraction layers that let you reroute workloads across providers, fallback models tested before you need them, and an inventory of every workflow that hardcodes a single model string. Single sourcing is the issue, not US government oversight.

However, the action itself should spur two discrete actions from organizations:

  1. Continue to explore running models locally to avoid external control (and costs)
  2. Explore model providers in other regions as “back up” or complimentary to US-based model providers.

2. It does signal an era of direct government involvement in model releases.

The June 2nd executive order established a voluntary framework for pre-release government access to frontier models. Ten days later, the US government  pulled Fable 5 and Mythos 5 with an export control directive. That makes the “voluntary” part of the framework seem mandatory. Whatever the merits of this specific case, frontier models are being treated as objects of national-security policy, and “generally available” is now conditional.

For US enterprises, this distinction can’t be ignored: a line now exists between your AI vendor’s product roadmap and US national security policy. Model availability is no longer purely a commercial SLA question. Since the US cited an available jailbreak for Fable 5 as the reason for the export control directive (which Forrester predicted would be developed in our first blog), this also means that model availability is now at the mercy of AI safety protocols and knowledge from users and security practitioners of available ways to bypass controls. Since AI models are probabilistic, not logical, jailbreaks are always possible which could keep them in crosshairs of political and national security policies.

3. “Available in the cloud” is no longer the same as “available to you.”

Every assumption your teams hold about SaaS and API availability has changed. It’s now true that a frontier model can disappear from your stack for reasons that have nothing to do with the vendor’s competence or your contract, and the vendor may be legally barred from giving you notice. Add that to your risk register.

The revocation also adds the inverse exposure: any vendor that already built on a model can have it pulled out from under them. Your third-party risk assessments need to capture not just which vendors use frontier models, but which models are embedded in each tool, automation, chatbot, or development workflow and whether those vendors have tested fallbacks of their own. A vendor with no Plan B for a model suspension now carries a continuity risk. Multi-model routing plans require engineering, architectural, and design revisions as model differences result in behavioral differences.

Having a software inventory is the only way to take control of this. You need to know which third-party software incorporates AI models from AI coding agents and open-source build tools as well as what models AI-powered business applications and SaaS platforms use. This requires reviewing your vendor contract language today. Ask suppliers for a Software Bill of Materials (SBOM) that includes detailed information about the AI models they use. They may also include an AI-BOM. Talk to your suppliers about how they choose their models, when changes occur, and how you’ll be notified. If you don’t know what AI is embedded in the tools you buy, download, or use, you’re exposing your organization to governance challenges that span security, IT, and the business.

4. Export-control now reaches inside your customer base.

The directive reportedly restricts access for foreign nationals, including a vendor’s own foreign-national employees, under “deemed export” logic. This could usher in the era of “know your customer” for AI access across enterprise and commercial subscriptions. This would mirror the KYC requirements originally issued in Executive Order 13984 that forced IaaS providers to verify the identities of foreign customers.

Frontier model providers would need to collect citizenship details of employees and subscribers across their customer base to meet the export control requirements mandated by governments. For example, if Anthropic had this capability already, it would not have needed to suspend all access, merely prove that it could bar access to non-US citizens only and that its customers could do the same. That’s a loaded sentence because assuring this happens is far more difficult than saying it’s possible.

Ensuring that Anthropic partners that host or resell the model along with their customers abided by the restriction is a bigger challenge. That has enormous impact on customer identity and access management (CIAM) and workforce identity. While controlling this at the workforce level is far easier and well understood, if frontier model access for customers starts depending on nationality, legal, privacy, HR, security, and IAM teams will have to agree on what data can be collected, who can see it, and how it’s used.

Connect With Us

Forrester clients with questions related to this can connect with us through an inquiry or guidance session.