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

Ich habe den Großteil der letzten drei Jahre damit verbracht, KI in die Arbeitsabläufe meiner Teams für die Entwicklung und Bereitstellung von Software zu integrieren. Als diese Woche die Nachricht bekannt wurde, dass die US-Regierung ein KI-Modell praktisch abgeschaltet hatte, war ich ehrlich gesagt schockiert. Nicht für ein Land. Nicht für ein Unternehmen. Sondern für alle Menschen auf der Welt, auf einmal.

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 per Exportkontrolle für eine Liste von Ländern gesperrt. Deaktiviert. Komplett. Für alle Nutzerinnen und Nutzer. Die Anordnung richtete sich technisch gegen den Zugriff ausländischer Staatsangehöriger. Anthropic konnte ausländische Staatsangehörige jedoch nicht in Echtzeit zuverlässig von US-Personen unterscheiden. Um der Anordnung nachzukommen, nahm das Unternehmen deshalb beide Modelle für alle vom Netz. Start war am 9. Juni. Am 12. Juni waren sie bereits wieder verschwunden.

Wenn Sie im Bereich Security arbeiten, sollte das Ihre volle Aufmerksamkeit haben. Nicht wegen der Politik. Sondern wegen dessen, was es über unsere aktuelle Lage und die Richtung aussagt, in die wir uns bewegen.

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 sich damit Fehler finden lassen, die sich seit Jahrzehnten in Codebasen verstecken. Dann entdeckte ein Forscher einen Jailbreak, der diese Fähigkeiten zur Schwachstellenerkennung auf eine Weise freischaltete, die Anthropic nie vorgesehen hatte. Die Regierung sah darin ein Risiko für die nationale Sicherheit. Sie befürchtete, dass Gegner Mythos nutzen könnten, um Zero-Days in großem Umfang zu entdecken und für Angriffe auszunutzen.

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

Anthropic bestreitet, dass die Sache tatsächlich so ernst war. Das Unternehmen sagt, der Jailbreak sei eng begrenzt gewesen und die Reaktion völlig unverhältnismäßig. Darüber lässt sich vernünftig streiten. Mein Kollege Stephen Thoemmes hat den genauen Ablauf ausführlich beschrieben: was genau passiert ist und wie die Security-Branche schon immer mit Dual-Use-Fähigkeiten umgegangen ist. Lesen Sie dort mehr über die technischen Details. In diesem Beitrag geht es darum, was das alles 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 integriert hatte – Code-Reviews, Schwachstellen-Triage, Sicherheitsanalysen oder was auch immer –, sind Sie am 12. Juni aufgewacht und diese Funktion war einfach … weg. Keine Ankündigung der Einstellung. Keine Übergangsfrist. Kein „Wir halten den Betrieb 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-Supply-Chains sind. Wir haben miterlebt, 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 sowie eine ganze Kategorie von Tools, um das Risiko zu beherrschen, dass der Code anderer verschwindet oder sich unter unseren Füßen in Schadsoftware verwandelt.

Meine Frage lautet also: Wie viele von uns gehen beim Zugriff auf KI-Modelle mit derselben Gründlichkeit 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 er auch morgen noch funktioniert. Diese Woche hat diese Annahme erschüttert. Und anders als eine Bibliothek, deren Version Sie fixieren und 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 daran arbeitet mein Team bei Snyk: Security soll Ihre Code- und Agenten-Workflows begleiten und nicht von dem Modell abhängen, in das Sie sie zuerst integriert haben – als würden Sie Sicherheit von diesem Anbieter mieten. Die praktische Schlussfolgerung ist unspektakulär, aber wichtig: Behandeln Sie den Zugriff auf Modelle wie jede andere Abhängigkeit, die Sie nicht kontrollieren. Halten Sie eine Ausweichlösung bereit. Schalten Sie eine Abstraktionsschicht davor. Sorgen Sie für einen Plan für den Morgen, an dem das Modell weg ist.

Problem 2: Abwehrfähigkeiten zu verbieten, hält Angreifer nicht auf

Kommen wir nun zum Thema Cybersicherheit – und damit zu dem Punkt, an dem es wirklich unangenehm wird.

Die Sorge der Regierung ist durchaus nachvollziehbar. Mythos 5 ist so gut darin, Schwachstellen aufzuspüren, dass Gegner Zero-Days entdecken und ausnutzen könnten, schneller als je zuvor, wenn sie Zugriff darauf bekämen. Das ist eine reale Sorge. Ich werde sie nicht einfach beiseiteschieben.

Doch hier ist eine Frage, die meiner Ansicht nach zu selten gestellt wird: Wer leidet tatsächlich darunter, wenn ein Tool zum Auffinden von Schwachstellen verboten wird?

Angreifer, die Schwachstellen finden und ausnutzen wollen, werden nicht erst die nötigen Formulare ausfüllen und sich an eine Exportkontrollanweisung halten. Das haben sie noch nie getan. Genau das macht einen Angreifer aus. Angreifer halten 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 rückgängig machen.

Wer leidet also darunter? Die Verteidiger. Sicherheitsforscherinnen und -forscher. Die Teams in Unternehmen wie Ihrem, die Schwachstellen finden und beheben wollen, bevor die Angreifer ihnen zuvorkommen.

Cybersicherheit war schon immer ein Wettrüsten. Und zwar seit es diese Branche gibt. Die gesamte Grundlage moderner Application Security ist, dass Verteidigerinnen und Verteidiger mindestens über dieselben Fähigkeiten verfügen müssen wie Angreifer – idealerweise sogar über bessere. Sie scannen Ihren eigenen Code, bevor es jemand anderes tut. Sie führen Penetrationstests auf Ihren eigenen Systemen durch. Sie setzen genau die Tools ein, die auch ein Angreifer verwenden würde, und richten sie auf Ihre eigene Infrastruktur, damit Sie die Lücken zuerst finden.

Nehmen Sie allen, die sich an die Regeln halten, diese Fähigkeit weg – und Sie bremsen Angreifer kein bisschen. Sie schwächen lediglich die Verteidiger. Und fast alles, was in der Security nützlich ist, hat zwei Seiten: Dual-Use steckt im Kern dieser Branche. Stephen geht in seinem Beitrag darauf ein, wie die Branche diesen Zielkonflikt schon immer gehandhabt hat – von koordinierter Offenlegung bis hin zu mehrschichtigen Kontrollen. Meine Kurzfassung: Wird eine Fähigkeit jedes Mal entzogen, wenn sie missbraucht werden könnte, richtet sich der Aus-Schalter am Ende gegen diejenigen, die tatsächlich verteidigen.

Das schafft einen gefährlichen Präzedenzfall

Eines möchte ich klarstellen: Ich verstehe, warum die Regierung gehandelt hat. Nationale Sicherheit ist ein ernstes Thema, und die Vorstellung, dass feindlich gesinnte Staaten über eine KI verfügen, die Zero-Days am Fließband produziert, ist wirklich beängstigend. Das sind keine unbegründeten Bedenken.

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

Wir haben jetzt also festgestellt, dass ein KI-Modell weltweit für alle ohne jede Vorwarnung abgeschaltet werden kann – wegen eines möglichen Missbrauchsszenarios. Nicht wegen eines tatsächlichen Angriffs. Nicht wegen eines bestätigten Sicherheitsvorfalls. Sondern wegen eines Jailbreaks, der theoretisch dazu verwendet werden könnte, Schaden anzurichten.

Denken wir diese Logik einmal weiter. Was passiert, wenn das nächste Modell Anomalien im Netzwerkverkehr hervorragend erkennt und dieselbe Fähigkeit zur Überwachung genutzt werden könnte? Was passiert, wenn ein Modell Sicherheits-Patches besonders gut generiert, sich aber theoretisch auch dazu bringen ließe, Exploit-Code zu schreiben? Nahezu jede wirklich nützliche Fähigkeit im Bereich Security ist von Natur aus Dual-Use. Das ist kein Fehler. So funktioniert diese Branche.

Reagieren wir jedes Mal so, müssen die Verteidiger am Ende mit einer Hand hinter dem Rücken kämpfen. Angreifer hingegen, die sich ohnehin nie an eine Exportkontrolle gehalten hätten, können weiter ungehindert agieren.

Niemand ist dadurch sicherer. Wir haben nur das Gefühl, etwas getan zu haben.

Was die Security-Branche jetzt richtig machen muss

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

Wir brauchen einen echten Rahmen für Dual-Use-KI-Fähigkeiten. „Wir verbieten alles, weil wir keine Zugriffskontrollen hinbekommen“ ist ein grobes Mittel. Seit Jahrzehnten gehen wir mit diesem Zielkonflikt durch verantwortungsvolle Offenlegung, Lizenzierung, rechtliche Rahmenbedingungen und gemeinsame Standards um – nicht, indem wir die Tools selbst verbieten. Dieselbe differenzierte Herangehensweise müssen wir auch auf KI übertragen, statt gleich zum Aus-Schalter zu greifen.

Die Security-Community muss mit am Tisch sitzen. Diese Entscheidung trafen Handelsregulierungsbehörden, nicht die Menschen, die sich tagtäglich damit beschäftigen, wie Software tatsächlich abgesichert wird. Das ist kein Vorwurf an das Handelsministerium. Exportkontrollen fallen in seinen Zuständigkeitsbereich. Doch die Folgen für die defensive Security sind enorm. Die Menschen, die diese Folgen verstehen, müssen 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 vom Netz genommen 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 Risiko so, wie es ist: ein Supply-Chain-Risiko.

Und sehen Sie: Bei Snyk sind wir grundsätzlich davon überzeugt, dass Software sicherer wird, wenn Entwicklerinnen und Entwickler – und mittlerweile auch KI-Agenten – Security-Tools zur Verfügung haben. Je mehr Menschen Schwachstellen finden und beheben können, desto sicherer sind wir alle. Das galt für statische Analyse, für Open-Source-Schwachstellendatenbanken und für jede Security-Fähigkeit, die wir demokratisiert haben. Ich bin überzeugt, dass es auch für KI-gestützte Security gelten wird.

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

Die Zeit drängt

Wir stehen an einem Wendepunkt. Die Fähigkeiten von KI im Bereich Security entwickeln sich rasant, und die politischen Rahmenbedingungen kommen kaum hinterher. 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 ist ein Vorgeschmack auf eine viel größere Debatte, die uns noch jahrelang beschäftigen wird. Unser Umgang mit Dual-Use-KI in der Cybersicherheit entscheidet darüber, ob Verteidiger mit Angreifern Schritt halten oder dauerhaft zurückfallen.

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

Und bis dahin? Prü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 schon nicht mehr verfügbar ist.