Commerce Bars Foreign Access to Anthropic Fable 5 and Mythos

What Happened

The US Commerce Department barred all foreign nationals from accessing Anthropic's Fable 5 and Mythos models. In a separate action, it specifically revoked SK Telecom's Claude Mythos access over alleged China ties. This is not a policy whitepaper. A production telco lost a live endpoint.

Model access is now a compliance field, not a capability one. The fallback you didn't write is the one that matters.

What This Means for the Stack

Three questions belong in every architecture doc that touches a frontier model:

1. Which engineers can legally call these endpoints? If the team includes non-US nationals, their access may already violate Commerce rules. Read the citizenship field on the IAM roster.
2. Which customers can receive outputs? If downstream users include foreign entities, the deployment is a conduit for restricted model access.
3. What is the fallback when access is revoked? SK Telecom did not get ninety days notice. The Anthropic SLA does not override a Commerce Department order. It is not in the contract because it cannot be.

The Open-Weight Calculus Shifts

Open-weight models, Llama, Mistral, Qwen, carry no export restrictions. They lag the frontier on benchmarks. That gap used to settle the argument on capability grounds. It is now a procurement, legal, and business-continuity argument. A model you cannot call is worse than a model ten MMLU points behind.

This is not theoretical. If the product serves international customers, or the team includes non-US engineers, closed frontier models now carry regulatory tail risk that open-weight alternatives do not. That is the tradeoff in our context. Yours may differ.

Structural Pattern

This follows the same trajectory as the A100/H100 export controls to China and the chip manufacturing restrictions before them. The mechanism is the same one: AI capabilities are being treated as dual-use technology under the export control frameworks built for defense hardware. The restricted model list grows from here. It does not shrink.

How This Differs from Miasma

Last week's Miasma worm hit npm packages through compromised Microsoft GitHub repos shipping Rust binaries. Shai-Hulud is a different beast with a different vector: it chains vulnerabilities in GitHub's own infrastructure that Deep Specter reported, GitHub's security team reviewed, and explicitly closed as won't-fix. Each bug looked low-severity in isolation. Chained, they are propagating through hundreds of packages and developer accounts.

The same vendor hosts the code and runs the advisory database, and that vendor declined to file advisories against its own infrastructure. That is the single point of failure.

The Structural Problem

If GitHub Security Advisories (GHSA) is your primary supply-chain signal, and for most teams running Dependabot or GitHub-native scanning it is, then the detection pipeline has a blind spot for vulnerabilities GitHub itself declines to acknowledge. This is not a conspiracy. It is incentive misalignment. GHSA will not contain advisories for bugs the platform owner classified as not-a-bug.

What to Do Differently

Short-term action is the same as last week: diff the dependency graph against published IOCs from the Deep Specter research. The structural fix is different from Miasma:

• Add a second advisory feed. OSV.dev, Snyk's database, or a commercial scanner not owned by the code host.
• Check lockfiles for unexpected version bumps in the last 30 days that landed without review.
• Verify package integrity hashes against published checksums from the package registries.
• Add PR-time dependency scanning (Mendral or equivalent) that runs independently of GHSA.

The worm does not care which severity label was attached to the original report. Teams that already keep a "packages added without review" list know their blast radius. The teams that do not are learning it now, on someone else's schedule.