The Day a Frontier Model Got Switched Off. Security Is Now Metric #1.

Your most important dependency has a kill switch, and you don't hold it. Last week, a government pressed it.

On June 12, a US export-control directive ordered Anthropic to cut off all access to Fable 5 and Mythos 5 for any foreign national — not just abroad, but inside the United States, and including Anthropic's own foreign-national employees. The company couldn't segment its users by nationality fast enough to comply, so it did the only thing that satisfied the order on the clock it was given: it turned the models off. Globally. For everyone. Within hours.

That's the event. Here's the claim of this whole post: the shutdown proves that every model you build on is two things at once — an attack surface and a geopolitical kill switch — and that means security, not velocity, is now the metric that decides whether your system survives the year. Most teams wiring frontier models into their critical path have optimized hard for speed and treated resilience as a problem for later. Later just arrived, and it arrived as a press release nobody in engineering got to veto.

I'm not writing this to dunk on Anthropic. I build on these models every day and I'll keep doing it. I'm writing it because the failure mode it exposed is one almost every engineering org is currently exposed to, and most of them don't know it yet.

A hosted frontier model feels like a utility. You call an endpoint, you get tokens back, the bill shows up monthly. Power, water, compute — same mental category. That mental category is wrong, and the directive is the proof.

Utilities don't get switched off by name on a Friday afternoon because of something that happened in a threat briefing you weren't in. This one did. The decision wasn't yours, wasn't your vendor's — Anthropic complied under protest — and wasn't subject to any SLA you signed. There is no line in any commercial agreement that covers "act of government." The capability was there in the morning and gone by dinner, and the only input that mattered came from a party you have no contract with at all.

If your critical path runs through a single hosted model, you have a dependency whose off-switch is held by someone you can't call.

This is the part engineers are trained to see in every other layer of the stack and somehow stopped seeing here. We wouldn't run a payments system on one provider with no fallback. We wouldn't put our whole business on one availability zone and call it resilient. But we'll route every agent, every classifier, every code-gen pipeline through one model from one vendor, hard-coded, and never ask what happens the day it returns a 403 for reasons that have nothing to do with us. We asked that question about databases twenty years ago. We haven't asked it about models.

The official logic of the shutdown is containment: a dangerous capability was discovered, so access to it gets restricted. That logic only works if the capability lives in one place. It doesn't.

By the current measures — an analysis by Håvard Tveit Ihle and colleagues on LessWrong, built on Epoch AI's benchmarking data, is the clearest — open-weight models trail the closed frontier by roughly six months. Six months. That's the lead. That's the entire moat the containment argument depends on.

You cannot switch off a weight file that has already been downloaded ten thousand times. You cannot issue an export-control directive to a model running on someone else's hardware in a jurisdiction that has no reason to honor it. A control that only works inside the borders of the country issuing it, against capability that exists in every other country within months, isn't a defense. It's a structural weakness with a press release attached — it constrains the defenders who comply and does nothing to the adversaries who don't.

Cutting off frontier capability doesn't remove it. It just decides who gets to keep using it, and the answer is rarely the people you'd pick.

Europe read it exactly this way. France's Bruno Retailleau put it bluntly: "a nation that depends on others for its technology is a nation that can be unplugged overnight." The political response there wasn't "let's get access back." It was "let's stop being dependent" — a hard pivot toward Mistral and homegrown capability. Whatever you think of the geopolitics, the engineering instinct underneath it is correct: a dependency you can be denied at someone else's discretion is a liability you have to design around, not a convenience you get to assume.

Here's the strongest version of the case against everything I've just written, and it deserves a real answer, not a strawman.

The trigger wasn't paranoia. The government believed it had found a way to jailbreak Fable 5, and the capability in question had cyber-offensive implications. If a frontier model can be reliably turned into an exploit-generation engine, that is a legitimate national-security concern, and a regulator acting on it is not being hysterical. Anthropic complied for a reason. Steelmanned all the way: the concern was real, the stakes were real, and reasonable people staffed that decision.

Grant all of it. The lesson doesn't move.

Because look at what the triggering capability actually was. By the reporting — Snyk's security write-up is the clearest — it was a "narrow jailbreak" around getting the model to read code and fix its vulnerabilities. That's not an exotic weapon. That's automated code review. That's the single most useful defensive thing these models do, the thing your security team wants them doing all day long. You cannot ban "read this codebase and find the flaws" without banning the exact workflow defenders depend on, because attackers and defenders run the identical query — the only difference is what they do with the answer.

So the concern can be entirely valid and the response still indicts the architecture. A safety control whose only available implementation was "make the model go dark for everyone, including every defender and the vendor's own staff" is not a precise instrument. It's a blast radius. And the thing about a blast radius is that the people standing closest to the explosion are usually the ones who were doing legitimate work.

A control that can only protect you by turning the lights off for everyone is not a control. It's a single point of failure wearing a safety vest.

Put the two failure modes side by side. The model can be jailbroken — that's the attack surface. The model can be revoked by policy — that's the kill switch. Same asset, two ways to lose it, and neither one is in your roadmap. The only discipline that addresses both is the one most teams have been treating as a phase-four nice-to-have: security, designed in from the start.

Concretely, treating it as metric #1 changes three things.

You build for model redundancy the way you already build for region redundancy. More than one provider, an abstraction layer over the model call, the ability to fail over to an open-weight model you host yourself — not because the open model is as good, but because a degraded model you control beats a better model you can be denied. The parity gap above is exactly why this is feasible now: your fallback is about six months behind, not two or three years.

You treat AI as part of your existing attack surface instead of a magic box bolted to the side of it. Every model output that reaches a sensitive sink gets the same scrutiny as any other untrusted input, because a jailbroken model is an untrusted input. The defensive disciplines for this already exist — it's the same resilience thinking we apply to any distributed system. A model provider is just another dependency that can fail, partition, or lie, and we already know how to engineer around dependencies that do.

And you stop shipping AI-generated code you never threat-modeled. The velocity these models give you is borrowed against a security debt that comes due the first time generated code hits production with a flaw nobody reviewed. Speed that you can't secure isn't an asset. It's leverage pointed at your own foot.

None of this is exotic. It's the resilience engineering we already do for every other critical dependency, finally applied to the one we've been pretending is a utility.

The teams most exposed right now are the ones for whom last week was a non-event — the ones who felt the headlines, noted that their region still had access, and moved on. Their dependency didn't get switched off this time. The architecture that left them one directive away from an outage is completely intact, and the next trigger doesn't have to be a jailbreak. It can be an export rule, a sanctions list, a licensing dispute, a model deprecation, a provider that simply decides your use case isn't worth the liability.

The cost of the conventional wisdom — one model, no fallback, security as a checklist you get to at the end — is an outage you cannot engineer your way out of after it lands, because the time to build the fallback was before you needed it. The shutdown didn't create that risk. It just sent everyone an invoice for it, and most teams are going to file it under "interesting" and pay it later at a much worse exchange rate.

Velocity got us here. It won't get us through what's next. The metric that does is the one we've been deferring.

Am I wrong about this? If you've already built real model redundancy — actual failover to a second provider or a self-hosted open-weight model, not a config flag you've never tested — I want to hear how it's holding up, and what it cost you to build before you needed it. And if you think I'm over-rotating on one directive, tell me why. I'm reading every comment.

If this named something you've been feeling but hadn't put words to, subscribe below — I write up what building resilient agentic systems teaches me, usually by going wrong in production first.

Subscribe on Substack

— Glenn Eggleton builds agentic engineering systems and writes about what survives contact with production.

<details>

<summary>SEO meta</summary>

Title (≤60 chars): A Government Switched Off an AI Model. Now What?

Meta description (≤155 chars): A government just switched off a frontier AI model overnight. Why that makes security — not velocity — your top engineering metric.

URL slug: ai-model-kill-switch-security

Primary keyword: AI model dependency risk

Secondary keywords: frontier model export controls, AI supply chain security

Search intent: informational

</details>