The Government Off-Switch

On Friday, June 12, 2026, paying enterprise customers of Anthropic’s Fable 5 model watched it go dark with effectively no notice. They had breached no contract, violated no usage policy, and triggered no service-level penalty. The model was disabled because a letter from the U.S. Commerce Department, issued under export-control authority, left the vendor no compliant alternative. (For the full account of how an AI model became a controlled item overnight, see our anchor analysis: When Washington Switched Off an AI Model.)

The strategic lesson is not about one model or one vendor. It is that model availability has become a regulated, revocable variable that sits entirely outside your commercial agreement. A regulator can now reach past your contract, past the vendor’s safety posture, and past your own controls to turn off a capability you depend on—on a timeline measured in hours.

Most third-party risk programs have no scenario for this. They model outages, breaches, insolvency, and price changes. They do not model “the U.S. government orders our vendor to disable the product for reasons unrelated to us, and the vendor cannot refuse.” This playbook closes that gap.

Why Your Existing Vendor Controls Don’t Cover This

Three assumptions baked into most AI vendor relationships failed on June 12.

Assumption 1: The vendor controls availability. In the Fable 5 case, the vendor was compelled. The decision-maker was not Anthropic’s reliability team; it was the Bureau of Industry and Security. Your SLA is a promise from a party that can be overruled by a third party with no contractual relationship to you.

Assumption 2: “Force majeure” is a tail risk. A government order is a textbook force-majeure event—which means the vendor likely owes you nothing when it happens. Force majeure protects the vendor from liability; it does nothing to keep your business running. The clause you assumed was protection is, in this scenario, the vendor’s shield against you.

Assumption 3: Notice will be reasonable. The window from launch to worldwide shutoff was roughly seventy-two hours; the disablement itself came on a Friday evening. Continuity plans calibrated to weeks of notice are calibrated to the wrong clock.

The Playbook

Step 1: Build a model-dependency inventory

You cannot protect a dependency you have not mapped. Catalog every place a specific frontier model or model version is load-bearing:

Customer-facing product features (chat, summarization, code generation, agents)
Internal automation and decision-support that staff now rely on
Embedded model calls inside other vendors’ products (fourth-party exposure)
Compliance and security controls that themselves use a model (e.g., AI-based content moderation, transaction monitoring, alert triage)

For each, record the exact model and version, the provider, the business criticality, and—critically—the switching cost to an alternative. A dependency you can swap in an hour is a different risk class from one welded to a single model’s specific behavior.

Step 2: Classify by criticality and substitutability

Plot every dependency on two axes: how badly it hurts if the model vanishes, and how quickly you can replace it. The dangerous quadrant is high-criticality, low-substitutability—a core function fused to one model with no tested fallback. Those are your priority remediation targets. Everything in that quadrant needs either an architectural change (Step 4) or a documented, accepted risk decision signed at the right level.

Step 3: Renegotiate the contract terms that actually matter

Standard AI procurement language is not built for compelled disablement. Push for:

Notification obligations — the vendor must notify you of any government or regulatory action affecting model availability as soon as legally permitted, through a named channel, not a status page.
Disablement remedies — distinguish vendor-elected discontinuation (you should get migration assistance, credits, and a sunset window) from legally-compelled disablement (you should at least get data portability and best-efforts transition to a still-available model tier).
Model-substitution rights — the right to fail over to a different, still-available model from the same vendor at comparable terms, without renegotiation.
Exit and portability assistance — prompt libraries, fine-tuning data, and evaluation suites must be exportable so you can stand up an alternative quickly.
Continuity transparency — require the vendor to disclose, at a defensible level of detail, its own regulatory and export-control exposure for the models you depend on.

You will not win all of these. Knowing which ones the vendor refuses is itself risk intelligence.

Step 4: Architect for substitution, not loyalty

The most durable control is technical, not contractual. Where criticality justifies the engineering cost:

Abstract the model behind an internal interface so that swapping providers is a configuration change, not a rewrite.
Maintain a qualified fallback model from a different provider—ideally one with a different regulatory footprint—kept warm with current prompts and evaluations, not discovered in a crisis.
Degrade gracefully. Define what the feature does when the primary model is unavailable: fall back to a smaller model, a cached/templated response, or a clearly-communicated reduced mode. “Hard fail” should never be the only option for a critical path.
Avoid welding to non-portable behavior. The more your product depends on one model’s idiosyncratic outputs, the higher your switching cost and the worse your continuity posture.

Step 5: Set explicit recovery objectives

Treat model loss like any other continuity event. For each critical dependency, define:

RTO (Recovery Time Objective): how fast you must restore the function on an alternative.
RPO-equivalent: what state, context, or fine-tuning you would lose in a switch and how you preserve it.
Acceptable degraded mode during failover.

If your RTO is “four hours” and your only fallback is “evaluate a new vendor from scratch,” you have a finding, not a plan.

Step 6: Run the tabletop

Walk the team through the realistic scenario, on a realistic clock:

It is 5:21pm on a Friday. Your primary model provider emails that, effective immediately, it must disable the model versions powering three of your production features to comply with a federal order. There is no restoration date. What happens in the next four hours? The next four days?

Surface the gaps live: Who is authorized to flip to the fallback? Does the fallback actually work, or has it drifted? Who tells customers, and what do they say? Who tells the regulator, if you are in a regulated sector? What is the financial exposure per hour of outage? A tabletop that produces a list of broken assumptions has done its job.

Step 7: Fold fourth-party model risk into vendor due diligence

Your SaaS vendors increasingly embed frontier models you never selected. Add to your vendor questionnaires:

Which third-party models power the features we rely on?
What is your continuity plan if one of those models is disabled by government order?
Will you notify us, and how fast?

You are now managing risk two layers deep, because a model you never chose can take down a vendor you did.

A Word on Diversification Discipline

The instinct after an event like this is to multi-source everything. Resist the blanket version. Multi-model architecture has real cost—engineering, evaluation, prompt maintenance, and quality variance across providers. Apply it where the dependency inventory says it is justified: high-criticality, low-substitutability functions on the critical path. For everything else, a documented risk acceptance and a known (even if slower) recovery path is the proportionate answer. Resilience is a portfolio decision, not a mandate to duplicate every call.

Conclusion

The Fable 5 shutoff proved that a frontier AI model can be switched off worldwide by force of law, for reasons that have nothing to do with the customer, on the timeline of a single afternoon. That is now a known risk, which means leaving it unmodeled is a choice—and after June 12, a hard one to defend. The organizations that absorb the next event without crisis will be the ones that did the unglamorous work first: inventory the dependencies, classify them honestly, fix the contracts they can, architect substitution where it matters, set recovery objectives, and rehearse the Friday-afternoon call before it comes.

The off-switch is real, it belongs to someone else, and it can be thrown without warning. Plan as if it will be.

This article is provided for informational purposes only and does not constitute legal advice.