Wenn eine Regierung ein KI-Modell abschaltet: Was die Aussetzung von Fable 5 und Mythos 5 für Sicherheitsteams bedeutet

Am Abend des 12. Juni 2026 deaktivierte Anthropic den Zugriff auf zwei seiner neuesten Modelle, Claude Fable 5 und Claude Mythos 5, für alle Kunden weltweit. Der Grund war weder ein Ausfall noch ein selbst entdeckter Fehler. Anthropic kam damit einer US-Exportkontrollanweisung nach, die das Unternehmen an diesem Tag um 17:21 Uhr ET unter Berufung auf nationale Sicherheitsbefugnisse erhalten hatte.

Für ein Sicherheitspublikum sind die Details wichtiger als die Politik: Was war der mutmaßliche Auslöser, wie lief die Maßnahme ab und was zeigt sie über die Abhängigkeit von fremden Modellen? Diese Fragen können Sicherheitsteams unabhängig davon angehen, wie sie die politische Debatte beurteilen.

Was tatsächlich mit Anthropics Fable 5 und Mythos 5 geschah

Präzision ist wichtig, denn die online kursierende Kurzfassung („Die Regierung hat das Modell für alle verboten“) entspricht nicht ganz dem, was aus den vorliegenden Informationen hervorgeht.

Laut Anthropics Stellungnahme wies die Anordnung das Unternehmen an, „jeglichen Zugriff auf Fable 5 und Mythos 5 durch ausländische Staatsangehörige auszusetzen, unabhängig davon, ob sie sich innerhalb oder außerhalb der Vereinigten Staaten befinden – einschließlich ausländischer Staatsangehöriger unter den Anthropic-Mitarbeitenden“. Dem Wortlaut nach richtete sich die Einschränkung gegen den Zugriff ausländischer Staatsangehöriger, nicht gegen alle Nutzer.

Die weltweite Abschaltung war die praktische Folge. Wie Anthropic erklärte: „Die Anordnung hat unterm Strich zur Folge, dass wir Fable 5 und Mythos 5 für alle unsere Kunden abrupt deaktivieren müssen, um die Vorschriften einzuhalten.“ Bei einer Nutzerbasis von mehreren hundert Millionen Menschen gibt es keine zuverlässige Möglichkeit, ausländische Staatsangehörige in Echtzeit von US-Personen zu unterscheiden – erst recht nicht bei einer Frist von nur einem Tag. Daher schaltete das Unternehmen die Modelle für alle ab. Dieser Unterschied ist wichtig: Die Anordnung zielte auf den Zugriff ausländischer Staatsangehöriger, doch kurzfristig ließ sie sich praktisch nur durch eine pauschale Abschaltung durchsetzen.

Als Begründung wurde ein mutmaßlicher „KI-Jailbreak“ genannt. So beschrieb Anthropic die vorgelegten Belege: „Die Regierung hat uns lediglich mündliche Hinweise auf einen möglichen, eng begrenzten, nicht universellen Jailbreak gegeben. Im Wesentlichen besteht dieser darin, das Modell aufzufordern, eine bestimmte Codebasis zu lesen und darin Softwarefehler zu beheben.“ Das Unternehmen ergänzte, „dass die dort gezeigten Fähigkeiten bei anderen Modellen (einschließlich GPT-5.5 von OpenAI) weithin verfügbar sind und täglich von den Verteidigern eingesetzt werden, die Systeme schützen.“

Die Regierung hat die Anordnung nicht veröffentlicht, und das Schreiben enthielt keine konkrete technische Begründung. Daher stützt sich das öffentliche Bild weitgehend auf Anthropics Darstellung. Die Cyberfähigkeiten von Frontier-Modellen sind ein berechtigter Bereich nationaler Sicherheitsbedenken, und Medienberichten zufolge wurde die Anordnung durch den Jailbreak-Vorwurf eines Dritten ausgelöst. Untersuchen lässt sich hier die Art der Maßnahme und ihr Verhältnis zu etablierten Sicherheitspraktiken – nicht die geheim eingestuften Einzelheiten.

Der mutmaßliche Auslöser: Code-Analyse und Fehlerbehebung

Ein Modell aufzufordern, eine Codebasis zu lesen und Fehler darin zu beheben, ist kein exotischer Angriff. Es handelt sich um automatisierte Code-Reviews und die Behebung von Schwachstellen – dieselbe Aufgabe, die statische Analyse, Fuzzer, KI-gestützte Code-Reviews und jede Security-Fachkraft übernehmen, die vor einem Release einen Scan ausführt. Diese Fähigkeit wird routinemäßig von Verteidigern genutzt und ist, wie die meisten Sicherheitsfunktionen, grundsätzlich dual-use.

Die technische Community brachte diesen Punkt schnell zur Sprache. Ein Kommentator auf Hacker News formulierte es so: „Wenn ich das richtig verstehe, besteht der ‚Jailbreak‘ darin, das Modell aufzufordern, die Codebasis zu reparieren, woraufhin es die Schwachstellen offenlegt? Das klingt nach einer Lücke, die sich kaum schließen lässt, ohne die Leistungsfähigkeit stark einzuschränken. Schließlich soll das Modell den eigenen Code reparieren können.“ Es gibt kein leistungsfähiges Coding-Modell, das Schwachstellen beheben, sie aber nicht auch beschreiben kann.

In den Tagen vor der Aussetzung hatten manche Sicherheitsforscher genau die gegenteilige Kritik geäußert: Die Schutzmechanismen von Fable 5 seien für legitime Verteidigungsarbeit zu streng. Valentina Palmiotti von IBM X-Force sagte gegenüber TechCrunch, das Modell „lehne jede Anfrage ab, die auch nur am Rande mit Cyber-Themen zu tun hat“. Innerhalb derselben Woche wurde das Modell einerseits dafür kritisiert, Verteidiger zu stark einzuschränken, und andererseits wegen einer Fähigkeit aus dem Verkehr gezogen, die der Verteidigung dient.

Fähigkeiten sind dual-use – eine in der Sicherheitsbranche vertraute Eigenschaft. Ein Portscanner, ein Paketanalyseprogramm, ein Fuzzer, eine SAST-Engine, ein Debugger und ein Proof of Concept für Speicherbeschädigung sind je nach Anwender und Zweck sowohl „offensive“ als auch „defensive“ Tools. Wir verbieten nmap nicht und stufen Wireshark nicht als Waffe ein. In der Sicherheitsbranche hat sich weitgehend die Erkenntnis durchgesetzt, dass sich die Verteidigung nicht verbessern lässt, wenn man die dafür erforderlichen Tools verbietet.

Wie die Sicherheitsbranche mit Dual-Use-Risiken umgeht

Das grundlegende Problem ist alt: Eine leistungsstarke Fähigkeit ist verfügbar und kann missbraucht werden. Die Sicherheitsbranche hat jahrzehntelang an einer Antwort darauf gearbeitet. Diese bietet hilfreichen Kontext – unabhängig davon, wie man die konkrete Maßnahme beurteilt. Sie beruht auf einigen zentralen Prinzipien.

Koordinierte Offenlegung. Wird eine schwerwiegende Schwachstelle entdeckt, besteht die etablierte Praxis darin, sie der zuständigen Stelle vertraulich zu melden, einen Zeitplan zu vereinbaren und sie zu veröffentlichen, sobald eine Abhilfe verfügbar ist. Ziel der verantwortungsvollen Offenlegung ist es, Schaden zu begrenzen und gleichzeitig das gesamte Ökosystem voranzubringen. Laut Anthropic erhielt das Unternehmen lediglich mündliche Hinweise auf einen möglichen Jailbreak; der konkrete Befund wurde ihm nicht schriftlich mitgeteilt. Die Regierung hat ihr eigenes Vorgehen nicht öffentlich beschrieben.

Mehrschichtige Verteidigung. Keine einzelne Sicherheitskontrolle muss perfekt sein. Stattdessen kombiniert man mehrere Kontrollen und geht davon aus, dass manche versagen werden. Anthropic zufolge wurde Fable 5 genau nach diesem Prinzip entwickelt, wie das Unternehmen zum Start erklärte: „Wir vermuten, dass ein perfekter Schutz vor Jailbreaks derzeit für keinen Modellanbieter möglich ist.“ Daher habe die Strategie darin bestanden, Jailbreaks „entweder eng zu begrenzen … oder sehr teuer in der Durchführung zu machen“ und dies „mit umfassender Überwachung zu kombinieren, um erfolgreiche Angriffe schnell zu erkennen und zu unterbinden“. Dahinter steckt dieselbe Logik wie bei mehrschichtiger Anwendungssicherheit: Scans in der IDE, Prüfungen im Pull Request, Gates in CI und Monitoring in der Produktion. Die Erwartung ist nicht, dass niemals etwas durchkommt, sondern dass die einzelnen Ebenen das Aufgedeckte erkennen und eindämmen.

Risikobasierte Priorisierung. Ausgereifte Sicherheitsprogramme behandeln nicht jeden Befund wie einen Notfall – das wäre unmöglich und kontraproduktiv. Wird eine kritische CVE in einem beliebten npm-Paket bekannt, legt das Ökosystem nicht den gesamten npm-Betrieb still. Stattdessen werden Schwachstellen nach Ausnutzbarkeit und Erreichbarkeit priorisiert, die tatsächlich relevanten Instanzen behoben und die Korrekturen überprüft. Snyks gesamter Ansatz zur Absicherung von KI-generiertem Code und zur Anwendungssicherheit beruht auf diesem Gedanken: Der Schweregrad ist wichtig, reicht aber nicht aus. Entscheidend ist immer die Frage: „Welches dieser Risiken ist real, erreichbar und muss zuerst angegangen werden?“ Sicherheitsteams stehen selten vor einer einfachen Entscheidung zwischen vollständig aktiv und vollständig abgeschaltet. In der Praxis geht es darum, eine abgestufte Reaktion zu finden, die dem tatsächlichen Risiko entspricht.

Wie sich diese konkrete Maßnahme anhand dieser Praktiken beurteilen lässt, ist angesichts der fehlenden öffentlichen Beschreibung des Regierungsprozesses schwer zu sagen. Die Praktiken bieten jedoch einen gemeinsamen Bezugsrahmen für die anschließende Debatte.

Wie die Reaktionen auf die Aussetzung von Fable 5 auseinandergingen

Die öffentliche Reaktion spaltete sich rasch. Ein Argument lautete, Anthropic habe sich öffentlich für staatliche Befugnisse zur Kontrolle von KI-Einsätzen ausgesprochen und wende sich nun dagegen, dass eine solche Befugnis genutzt werde. In seiner Stellungnahme erklärte Anthropic, Regierungen sollten unsichere Einsätze zwar verhindern können, jedoch nur „im Rahmen eines gesetzlichen Verfahrens, das transparent, fair und klar ist und auf technischen Fakten beruht“. „Diese Maßnahme hält sich nicht an diese Grundsätze“, hieß es weiter. Als Grundlage nannte die Regierung die nationale Sicherheit – ein anerkanntes Anliegen im Zusammenhang mit den Cyberfähigkeiten von Frontier-Modellen. Medienberichten zufolge folgte die Anordnung auf den Jailbreak-Vorwurf eines Dritten. Die konkreten Belege wurden nicht veröffentlicht.

Andere Reaktionen hatten wenig mit einer der beiden Parteien zu tun. Entwicklerinnen und Entwickler, die auf Fable 5 aufgebaut hatten, konzentrierten sich auf die Zuverlässigkeit. Viele sahen den Vorfall als Argument für Open-Weight- oder selbst gehostete Modelle, die sich nicht von außen abschalten lassen. Einige deuteten ihn skeptisch als Öffentlichkeitsarbeit vor einem Börsengang. Simon Willison hielt fest, wann genau der Zugriff ausfiel.

Auch dafür gibt es einen Präzedenzfall. In den 1990er-Jahren behandelten die USA starke Verschlüsselung als kontrollierte Munition und schränkten ihren Export ein. US-Gerichte stellten schließlich fest, dass die Veröffentlichung von Sicherheitscode eine geschützte Ausdrucksform ist. Diese Kontrollen beschränkten den Export; sie zwangen jedoch kein bereits eingesetztes Produkt dazu, für Nutzer im Inland offline zu gehen – ein Unterschied zu diesem Fall.

Der Zuverlässigkeitsaspekt, den Sicherheitsteams nicht ignorieren können

Lassen wir die Rechtsfragen beiseite: Es gibt eine operative Lehre, die unabhängig davon gilt, wie die politische Debatte ausgeht.

Eine einzige Anordnung brachte ein allgemein verfügbares Produkt innerhalb weniger Stunden für seine gesamte globale Nutzerbasis offline. Wer Fable 5 in einen Arbeitsablauf integriert hatte, musste feststellen, dass der Zugriff auf das Modell durch Kräfte außerhalb der eigenen Kontrolle und der des Anbieters widerrufen werden konnte. Die unmittelbar reagierenden Entwicklerinnen und Entwickler kamen zu einer naheliegenden Schlussfolgerung: Redundanz bei Modellen ist jetzt eine Resilienzanforderung – nicht nur eine Frage von Kosten oder Leistung. Ein einzelnes gehostetes Modell als feste Abhängigkeit zu behandeln, schafft einen Single Point of Failure. Und solche Single Points of Failure sind ein Sicherheitsproblem, ganz gleich, ob der Ausfall durch eine Störung, ein Abrechnungsereignis, eine Richtlinienänderung oder ein Schreiben der Regierung ausgelöst wird.

Dieselbe Disziplin wendet Snyk auch auf die übrige Software-Supply-Chain an. Was Sie nicht sehen, können Sie nicht verwalten. Deshalb wird es zum Mindeststandard, Ihre KI-Angriffsfläche zu kennen, mithilfe der Asset-Erkennung zu erfassen, wo sich KI-Komponenten und Abhängigkeiten tatsächlich in Ihren Systemen befinden, und auf den Ausfall jeder einzelnen davon vorbereitet zu sein. Die Aussetzung von Fable 5 zeigt eindrücklich, warum.

Gemeinsam stärker: die Rolle von Security-Tools

Unabhängig vom Ausgang der politischen Debatte müssen Sicherheitsteams ihren Betrieb aufrechterhalten. Die praktische Frage ist, wie sich KI-Fähigkeiten mit Dual-Use-Potenzial im Alltag verwalten lassen – und dafür gibt es in der Sicherheitsbranche bewährte Praktiken. Bei Snyk erleben wir bereits, wie sich das direkt in KI-Tools auswirkt: Unsere ToxicSkills-Forschung untersuchte fast 4.000 KI-Agenten-Skills und stellte fest, dass mehr als ein Drittel mindestens eine Sicherheitslücke aufwies – von Prompt-Injection über offengelegte Geheimnisse bis hin zu regelrechter Malware.

Koordinierte Offenlegung, mehrschichtige Kontrollen, kontinuierliches Monitoring und risikobasierte Priorisierung sind keine abstrakten Konzepte. Sie gehören zum Alltag und ermöglichen es, weiterhin Software auszuliefern, obwohl ständig neue Schwachstellen entdeckt werden. Diese Praktiken lassen sich direkt auf die Entwicklung und den Betrieb mit KI übertragen:

• Sichern Sie den Code, den diese Modelle erzeugen – kontinuierlich. KI schreibt schneller mehr Code, doch nicht jeder davon ist sicher. Wenn Sie KI-generierten Code bereits bei seiner Erstellung und im Pull Request scannen und nach Möglichkeit automatisch korrigieren, lassen sich Geschwindigkeit und Sicherheit miteinander verbinden, statt sie gegeneinander auszuspielen. Das ist der Kern von Snyks Empfehlungen zur sicheren Entwicklung mit KI und zu Ansätzen auf Type-Ebene für eine sichere KI-Codegenerierung.

• Setzen Sie der KI Grenzen. Die sinnvollste Kontrolleinheit ist in der Regel die Aktion, nicht das gesamte Modell. Snyks Arbeit zu Leitplanken für KI-Coding-Assistenten und zur Zukunft der Sicherheit von KI-Agenten folgt diesem Ansatz: Beschränken Sie, was ein Agent tun kann, überwachen Sie ihn und greifen Sie gezielt ein.

• Betrachten Sie KI-Systeme als Teil der Angriffsfläche, die Sie bereits verwalten. Prompt-Injection, Offenlegung sensibler Informationen und die weiteren Einträge in den OWASP Top 10 für LLMs sind Anwendungsrisiken, denen sich mit den Prinzipien der Anwendungssicherheit begegnen lässt. Die oben beschriebenen ToxicSkills-Erkenntnisse sind genau solche Risiken: real, messbar und mit den Tools und Prozessen beherrschbar, über die Sicherheitsteams bereits verfügen.

Die Absicherung von KI-generiertem Code ist für die meisten Teams der erste Schritt. Dieser kurze Snyk-Walkthrough zeigt, wie das in der Praxis aussieht:

Play Video: The Secret to Secure AI Code

Das Geheimnis sicheren KI-generierten Codes (So bleibt KI-generierter Code sicher, wenn Umfang und Geschwindigkeit zunehmen)

Sie müssen sich deshalb nicht zwischen „KI ist sicher“ und „KI ist gefährlich“ entscheiden. Die Sicherheitsbranche geht mit jeder leistungsstarken Technologie gleich um: Sie gehen von bestehenden Risiken aus, schaffen mehrere Schutzebenen, um sie zu beherrschen, legen Sicherheitslücken offen und beheben sie in koordinierter Zusammenarbeit und sorgen dafür, dass Sicherheitsteams gut gerüstet sind.

Was Sicherheitsteams und Entwickler daraus mitnehmen sollten

1. Machen Sie kein einzelnes gehostetes Modell zu einer kritischen Abhängigkeit. Sorgen Sie bei allem, worauf es ankommt, für Modellredundanz und reibungslose Ausweichlösungen. Wenn Sie die Verfügbarkeit nicht kontrollieren, müssen Sie das entsprechende Risiko einplanen.

2. Erfassen Sie, wo KI in Ihrem Stack zum Einsatz kommt. Ohne eine Erfassung Ihrer Assets lässt sich der mögliche Schadensradius nicht einschätzen. Wissen Sie, welche Services, Pipelines und Produkte von welchen Modellen und KI-Komponenten abhängen.

3. Scannen Sie KI-generierten Code standardmäßig und nicht erst im Nachhinein. Angesichts des Umfangs und der Geschwindigkeit KI-generierten Codes ist es nur mit Scans bei der Erstellung und in Pull Requests sowie automatisierter Behebung praktikabel, Schritt zu halten.

4. Setzen Sie eher auf Leitplanken und Monitoring als auf Notausschalter. Beschränken Sie Aktionen, beobachten Sie das Verhalten und greifen Sie gezielt ein. Entfernen Sie ein Modell vollständig nur in Fällen, in denen dies wirklich gerechtfertigt ist, und legen Sie im Voraus fest, welche das sind.

5. Praktizieren Sie koordinierte Offenlegung und erwarten Sie das auch von anderen. Eine Sicherheitslücke, die Sie nicht kennen, können Sie nicht beheben. Bestehen Sie auf Belegen und einem Weg zur Behebung – und bieten Sie anderen dasselbe.

Fazit

Die Aussetzung von Fable 5 und Mythos 5 wird noch eine Weile aus rechtlicher und politischer Sicht diskutiert werden. Vernünftige Menschen werden unterschiedlicher Meinung darüber sein, ob Regierungen ein bereits eingesetztes Modell offline nehmen dürfen sollten. Für Sicherheitsteams hängen die dauerhaften Erkenntnisse nicht davon ab, wer recht hat. Die Fähigkeit, um die es bei dem Streit geht, nutzen Sicherheitsteams routinemäßig. Das praktische Ergebnis – eine weltweit verfügbare Abhängigkeit, die innerhalb weniger Stunden entfernt wurde – ist ein konkretes Argument für Redundanz und Transparenz.

Leistungsstarke, vielseitig einsetzbare Fähigkeiten sind kein neues Problem, und die Sicherheitsbranche kennt bereits die passende Vorgehensweise: Sorgen Sie für ausreichend Modellredundanz, damit kein einzelner Anbieter zu einer kritischen Abhängigkeit wird. Wissen Sie, wo KI in Ihrem Stack zum Einsatz kommt. Scannen Sie KI-generierten Code direkt bei seiner Bereitstellung. Schränken Sie die Möglichkeiten von KI mit Leitplanken ein, statt zu Notausschaltern zu greifen, und praktizieren Sie koordinierte Offenlegung in beide Richtungen. Wenn Teams diese Maßnahmen kontinuierlich umsetzen, können sie trotz der Risiken vielseitig einsetzbarer Technologien weiterentwickeln und ausliefern. Hier kommen Sicherheitstools wie Snyk ins Spiel. So gelingt ein besseres Zusammenspiel.