Die Regierung hat gerade ein KI-Modell verboten. Die Perspektive eines Ingenieurs.

Seit fast drei Jahren integriere ich KI in die Art und Weise, wie meine Teams Software entwickeln und bereitstellen. Als diese Woche die Nachricht bekannt wurde, dass die US-Regierung ein KI-Modell praktisch abgeschaltet hatte, war ich deshalb wirklich schockiert. Nicht für ein Land. Nicht für ein Unternehmen. Sondern für alle Menschen auf der Welt, gleichzeitig.

Drei Tage. So lange waren die Modelle Fable 5 und Mythos 5 von Anthropic verfügbar, bevor die Regierung ihre Abschaltung für alle anordnete.

Nicht eingeschränkt. Nicht für eine Liste von Ländern mit Exportkontrollen belegt. Deaktiviert. Vollständig. Für alle Nutzer. Die Anordnung richtete sich zwar formal gegen den Zugriff durch ausländische Staatsangehörige, doch Anthropic konnte ausländische Staatsangehörige nicht in Echtzeit zuverlässig von US-Personen unterscheiden. Um der Anordnung nachzukommen, nahm das Unternehmen daher beide Modelle für alle vom Netz. Sie wurden am 9. Juni gestartet. Am 12. Juni waren sie wieder verschwunden.

Wenn Sie im Sicherheitsbereich arbeiten, sollte das Ihre volle Aufmerksamkeit haben. Nicht wegen der Politik. Sondern wegen dessen, was es uns darüber sagt, wo wir gerade stehen und wohin die Reise geht.

Was passiert ist

Hier die Kurzfassung.

Mythos 5 erwies sich als außergewöhnlich gut darin, Software-Schwachstellen aufzuspüren. Wirklich sehr gut. So gut, dass es Fehler aufdecken kann, die sich jahrzehntelang in Codebasen versteckt haben. Dann fand ein Forscher einen Jailbreak, der diese Fähigkeiten zur Schwachstellenerkennung auf eine Weise freisetzte, die Anthropic nie beabsichtigt hatte. Die Regierung stufte das als Risiko für die nationale Sicherheit ein. Sie befürchtete, dass Gegner Mythos nutzen könnten, um Zero-Day-Schwachstellen in großem Maßstab zu entdecken und als Angriffswaffe einzusetzen.

Daraufhin erließ die Regierung eine Exportkontrollanordnung. Da Anthropic US-Personen nicht zuverlässig von allen anderen unterscheiden konnte, blieb dem Unternehmen praktisch keine Wahl. Es deaktivierte Fable 5 und Mythos 5 für alle.

Anthropic bestreitet, dass die Sache tatsächlich so gravierend war. Das Unternehmen sagt, der Jailbreak sei eng begrenzt gewesen und die Reaktion völlig unverhältnismäßig. Darüber lässt sich durchaus streiten. Mein Kollege Stephen Thoemmes hat den Ablauf ausführlich beschrieben: was genau passiert ist und wie die Sicherheitsbranche schon immer mit Dual-Use-Fähigkeiten umgegangen ist. Lesen Sie dort die Details. In diesem Beitrag geht es darum, was das bedeutet.

Problem 1: Ihr KI-Anbieter ist jetzt ein Supply-Chain-Risiko

Sprechen wir über das, worüber niemand sprechen möchte.

Wenn Ihr Engineering-Team Fable 5 oder Mythos 5 in irgendeinen Workflow eingebaut hatte – etwa in Code-Reviews, die Schwachstellen-Triage oder Sicherheitsanalysen –, wachten Sie am 12. Juni auf und diese Fähigkeit war einfach … weg. Keine Abkündigung. Kein Zeitfenster für die Migration. Kein „Wir halten den Betrieb noch 90 Tage aufrecht, während Sie eine Alternative finden“. Einfach weg.

Das ist ein Supply-Chain-Vorfall.

Als Branche haben wir jahrelang – manchmal auf schmerzhafte Weise – gelernt, wie anfällig unsere Software-Lieferketten sind. Wir haben erlebt, wie ein einzelner Maintainer massenhaft npm-Pakete löschte und das halbe Internet lahmlegte. Wir haben SolarWinds erlebt. Log4Shell. Wir haben SBOMs und Dependency-Scanning entwickelt und eine ganze Tool-Kategorie aufgebaut, um das Risiko zu beherrschen, dass der Code anderer plötzlich verschwindet oder sich unbemerkt in etwas Bösartiges verwandelt.

Deshalb meine Frage: Wie viele von uns gehen beim Zugriff auf KI-Modelle mit derselben Sorgfalt vor?

Die meisten Teams behandeln den Zugriff auf KI-Modelle wie eine Versorgungsleistung. Sie melden sich an, erhalten einen API-Schlüssel, integrieren ihn in ihren Workflow und gehen stillschweigend davon aus, dass alles auch morgen noch verfügbar sein wird. Diese Woche hat ein Loch in diese Annahme gerissen. Und anders als eine Bibliothek, deren Version Sie fixieren und die Sie in Ihr Repository übernehmen können, lässt sich ein Modell, das auf den Servern eines anderen läuft, nicht zwischenspeichern. Wenn es weg ist, ist es weg.

Genau mit diesem Problem beschäftigt sich mein Team bei Snyk jeden Tag: Sicherheit soll Ihren Code und Ihre Agenten begleiten, damit Sie nicht faktisch von dem Modell abhängig sind, das Sie zuerst eingebunden haben. Die praktische Empfehlung ist unspektakulär, aber wichtig: Behandeln Sie den Modellzugriff wie jede andere Abhängigkeit, die Sie nicht kontrollieren. Halten Sie eine Ausweichlösung bereit. Schalten Sie eine Abstraktionsschicht davor. Und sorgen Sie für einen Plan für den Fall, dass es plötzlich weg ist.

Problem 2: Wer defensive Fähigkeiten verbietet, hält Angreifer nicht auf

Kommen wir nun zur Cybersicherheit – hier wird es wirklich unangenehm.

Die Sorge der Regierung ist leicht nachvollziehbar. Mythos 5 ist so gut darin, Schwachstellen zu finden, dass Gegner, wenn sie Zugriff darauf bekämen, Zero-Days schneller entdecken und ausnutzen könnten als je zuvor. Das ist eine berechtigte Sorge. Ich werde sie nicht einfach abtun.

Doch hier ist die Frage, die meiner Meinung nach nicht oft genug gestellt wird: Wer wird tatsächlich geschädigt, wenn man ein Tool verbietet, das Schwachstellen aufspürt?

Angreifer, die Schwachstellen finden und ausnutzen wollen, werden nicht erst Formulare einreichen und eine Exportkontrollanordnung befolgen. Das haben sie noch nie getan. Genau das macht einen Angreifer aus: Er hält sich nicht an Regeln. Wenn ein gejailbreaktes Mythos Zero-Days finden kann, ist diese Fähigkeit bereits verfügbar. Der Jailbreak wurde veröffentlicht. Das lässt sich nicht mehr rückgängig machen.

Wer wird also geschädigt? Die Verteidiger. Sicherheitsforscher. Die Teams in Unternehmen wie Ihrem, die versuchen, Schwachstellen zu finden und zu beheben, bevor die Angreifer ihnen zuvorkommen.

In der Cybersicherheit herrscht seit jeher ein Wettrüsten. Schon so lange, wie es die Branche gibt. Die gesamte Grundlage moderner Anwendungssicherheit ist, dass Verteidiger mindestens über dieselben Fähigkeiten wie Angreifer verfügen müssen – idealerweise über bessere. Sie scannen Ihren eigenen Code, bevor es jemand anderes tut. Sie testen Ihre eigenen Systeme mit Penetrationstests. Sie setzen dieselben Tools ein wie ein Angreifer und richten sie auf Ihre eigene Infrastruktur, damit Sie die Schwachstellen zuerst finden.

Nimmt man allen, die sich an die Regeln halten, diese Fähigkeit, bremst man Angreifer überhaupt nicht aus. Man verschlechtert lediglich die Lage der Verteidiger. Und fast alles, was in der Sicherheit von Nutzen ist, kann in beide Richtungen eingesetzt werden – es ist seinem Wesen nach Dual Use. Stephens Beitrag beleuchtet, wie die Branche mit diesem Spannungsfeld umgegangen ist: von der koordinierten Offenlegung bis hin zu mehrschichtigen Kontrollen. Meine Kurzfassung: Wird eine Fähigkeit jedes Mal entzogen, sobald sie missbraucht werden könnte, richtet sich der Ausschalter am Ende gegen genau die Menschen, die tatsächlich verteidigen.

Das schafft einen gefährlichen Präzedenzfall

Eines möchte ich klarstellen: Ich verstehe, warum die Regierung gehandelt hat. Die nationale Sicherheit ist eine ernste Angelegenheit, und die Vorstellung, dass feindliche Staaten über eine KI verfügen, die Zero-Days am Fließband produziert, ist tatsächlich beängstigend. Diese Bedenken sind nicht unbegründet.

Doch der Präzedenzfall beunruhigt mich mehr als der konkrete Vorfall.

Wir haben nun etabliert, dass ein KI-Modell weltweit und ohne jede Vorwarnung für alle abgeschaltet werden kann – wegen eines Szenarios mit möglichem Missbrauch. Nicht wegen eines tatsächlichen Angriffs. Nicht wegen eines bestätigten Sicherheitsvorfalls. Sondern wegen eines Jailbreaks, der theoretisch für schädliche Zwecke eingesetzt werden könnte.

Übertragen wir diese Logik auf die Zukunft. Was passiert, wenn das nächste Modell Anomalien im Netzwerkverkehr hervorragend erkennt und sich dieselbe Fähigkeit auch zur Überwachung einsetzen ließe? Was passiert, wenn ein Modell großartige Sicherheitspatches erstellt, sich aber theoretisch auch dazu bringen ließe, Exploit-Code zu generieren? Fast jede wirklich nützliche Fähigkeit im Sicherheitsbereich ist von Natur aus Dual Use. Das ist kein Fehler. So funktioniert dieser Bereich.

Reagieren wir jedes Mal so, müssen die Verteidiger am Ende mit einer Hand auf dem Rücken kämpfen, während Angreifer – die sich ohnehin nie an Exportkontrollen gehalten hätten – beide Hände frei haben.

Damit wird niemand sicherer. Wir haben lediglich das Gefühl, etwas unternommen zu haben.

Was die Sicherheitsbranche jetzt richtig machen muss

Wie geht es also weiter? Ich behaupte nicht, alle Antworten zu haben, aber ein paar Dinge sollten wir offen aussprechen.

Wir brauchen einen tragfähigen Rahmen für KI-Fähigkeiten mit Dual-Use-Potenzial. „Wir verbieten das einfach vollständig, weil wir keine Zugriffskontrollen hinbekommen“ ist eine grobe Maßnahme. Seit Jahrzehnten gehen wir mit diesem Spannungsfeld durch verantwortungsvolle Offenlegung, Lizenzierung, gesetzliche Rahmenbedingungen und gemeinsame Normen um – nicht, indem wir die Tools selbst verbieten. Diese Differenziertheit müssen wir auch auf KI übertragen, statt reflexartig zum Ausschalter zu greifen.

Die Sicherheits-Community muss mit am Tisch sitzen. Diese Entscheidung wurde von Handelsregulierungsbehörden getroffen, nicht von den Menschen, die sich täglich damit beschäftigen, wie Software tatsächlich abgesichert wird. Das ist keine Kritik am Handelsministerium. Exportkontrollen fallen in seinen Zuständigkeitsbereich. Doch die Auswirkungen auf die defensive Sicherheit sind enorm. Deshalb müssen die Menschen, die diese Folgen verstehen, vor der nächsten Entscheidung mitreden können – nicht erst danach.

Unternehmen müssen ihre KI-Strategie jetzt widerstandsfähig aufstellen. Warten Sie nicht, bis das nächste Modell abgeschaltet wird. Wenn Sie kritische Workflows auf KI aufbauen, die Sie nicht kontrollieren, brauchen Sie schon heute Notfallpläne: Strategien mit mehreren Anbietern, Abstraktionsschichten und Ausweichlösungen. Behandeln Sie das als das Supply-Chain-Risiko, das es tatsächlich ist.

Und sehen Sie: Bei Snyk beruht unsere gesamte Philosophie darauf, dass Software sicherer wird, wenn Entwickler und inzwischen auch KI-Agenten Sicherheits-Tools zur Verfügung haben – nicht unsicherer. Je mehr Menschen Schwachstellen finden und beheben können, desto sicherer sind wir alle. Das hat sich bei statischer Analyse, bei Open-Source-Schwachstellendatenbanken und bei jeder Sicherheitsfähigkeit bewährt, die wir jemals demokratisiert haben. Ich bin überzeugt, dass das auch für KI-gestützte Sicherheit gilt.

Auf „Dieses Tool ist leistungsstark“ sollte die Antwort lauten: „Sorgen wir dafür, dass die richtigen Menschen es verantwortungsvoll nutzen können.“ Nicht: „Sorgen wir dafür, dass es überhaupt niemand nutzen kann.“

Die Zeit drängt

Wir stehen an einem Wendepunkt. Die KI-Fähigkeiten im Sicherheitsbereich entwickeln sich rasant weiter, während die politischen Rahmenbedingungen kaum hinterherkommen. In dieser Lücke zwischen dem, was die Technologie kann, und dem, was die Regeln erlauben, liegt das eigentliche Risiko.

Das Verbot von Fable 5 und Mythos 5 in dieser Woche gibt einen Vorgeschmack auf eine viel größere Debatte, die uns noch jahrelang beschäftigen wird. Wie wir mit Dual-Use-KI in der Cybersicherheit umgehen, entscheidet darüber, ob Verteidiger mit Angreifern Schritt halten oder dauerhaft zurückfallen.

Mir wäre lieber, wir machen es richtig, als schnell. Aber wir müssen die Debatte jetzt beginnen, denn die Entscheidungen, die wir heute treffen, werden die Sicherheitslandschaft noch lange prägen.

Und bis dahin? Überprüfen Sie Ihre KI-Abhängigkeiten. Im Ernst. Am besten sofort. Denn wenn uns diese Woche eines gezeigt hat, dann, dass das Modell, auf das Sie sich heute verlassen, morgen vielleicht nicht mehr verfügbar ist.