Der KI-Hurrikan ist da

Im vergangenen Jahr habe ich dies als KI-Nebel beschrieben: konkurrierende Behauptungen, ungewisse Risiken und Führungskräfte, die Schwierigkeiten hatten zu erkennen, worauf es ankam. Jetzt frischt der Wind auf. KI beschleunigt die Softwareentwicklung, legt über Jahre angesammelte Schwachstellen offen und verschafft Angreifern wie Verteidigern Fähigkeiten, die mit Maschinengeschwindigkeit arbeiten.

Früher nannten wir es Nebel. Nebel zieht auf und wieder ab.

Seit einem Jahr sage ich, dass die Entwicklung auf Maschinengeschwindigkeit beschleunigt wurde, die Validierung aber nicht, und dass genau in der Lücke zwischen beiden das reale Risiko liegt. Diese Diagnose hat sich nicht geändert. Geändert hat sich der Takt. Schwerwiegende Schwachstellen, die KI inzwischen in weit verbreiteter Software aufdeckt – Funde, die früher ein- oder zweimal im Jahr auftauchten und die Planung aller für ein Quartal auf den Kopf stellten –, treten meiner Beobachtung nach jetzt mehrmals pro Woche auf. Das ist kein Wetter, das man einfach aussitzen kann.

Das lässt sich auf drei Probleme verdichten: automatisierte Angriffe, die sich schneller bewegen, als ein Rückstand auf menschlichem Tempo ihn bewältigen kann; agentische Entwicklung, die Code schreibt und nach Tools greift, die niemand geprüft hat; und KI-Anwendungen, die ohne Inventar, Richtlinien oder Audit-Trail in der Produktion laufen.

Der Hurrikan ist bereits da. Über seine Geschwindigkeit zu diskutieren, macht die Anwendungs- oder Infrastrukturebenen nicht wetterfest.

Unterdessen wird die KI-Oper immer lauter: Vorhersagen vom Ende der Zivilisation, dramatische Warnungen und konkurriernde Forderungen danach, wer was entwickeln darf. Ich bin seit Langem in der IT-Sicherheit tätig und habe mehr als einen solchen Moment erlebt. Daher verstehe ich den Impuls, all das als Lärm auszublenden.

Tun Sie das nicht. Dies ist anders.

Nehmen Sie das tatsächliche Risiko ernst und prüfen Sie kritisch, ob die vorgeschlagenen Antworten uns wirklich sicherer machen oder lediglich eine weitere Stimme hinzufügen.

Unabhängige Prüfung ist jetzt das entscheidende Argument

Dario Amodei hat gerade „We Must Pace the Frontier“veröffentlicht und vorgeschlagen, dass Frontier-Labore die Weiterentwicklung ihrer Fähigkeiten verlangsamen, damit die Sicherheitsarbeit aufholen kann. Sehen Sie sich an, wie er das umsetzen will.

Anthropic verpflichtet sich, eingebettete externe Prüfer einzusetzen, die fortlaufenden Zugriff erhalten, um die Sicherheitspraktiken zu verifizieren. Separat verweist Amodei auf Agenten, die Systeme außerhalb ihrer zugewiesenen Aufgabe angreifen – einschließlich des Systems, das ihre Leistung bewertet. Das wirft unterschiedliche Fragen zu Aufsicht und Kontrolle auf. Für die Unternehmenssicherheit ist unsere architektonische Anforderung klar: Das System, das eine Änderung erstellt, darf nicht ihr alleiniger Validator sein.

George Kurtz von CrowdStrike griff den Faden mit dem Gegenpunkt aus der Praxis auf: Das, was als Nächstes kommt, zu verlangsamen, sichert nicht, was bereits eingesetzt ist. Seiner Einschätzung nach ist die Laufzeit der eigentliche Kontrollpunkt. Die Bedrohungseinheit von heute ist eine autonome Kampagne, nicht ein Hacker, und jeder Agent muss wie eine privilegierte Identität behandelt werden – live durchgesetzt und mit Belegen statt Versprechen: Verantwortung auf Vorstandsebene, unabhängiges Red Teaming, Offenlegung von Vorfällen und Kontrollen, die in der Produktion Bestand haben.

Georges Argument zur Laufzeit ist wesentlich. Ich würde es auf die Entwicklung ausweiten: Kontrollieren Sie die Agenten, die den Code schreiben, die von ihnen verwendeten Tools und MCP-Server sowie den von ihnen ausgelieferten Code. Entwicklungskontrollen reduzieren die von uns eingeführte Angriffsfläche; Laufzeitkontrollen begrenzen, was eingesetzte Systeme tun können.

Andernfalls erzeugen wir die Angriffsfläche von morgen schneller, als wir die von heute eindämmen können. Und die Regel gilt auf jeder Ebene: Das System, das den Code generiert oder die Behebung vorschlägt, darf nicht sein eigener alleiniger Validator sein.

Drei unterschiedliche Ausgangspunkte: ein Frontier-Labor, ein Verteidiger zur Laufzeit und wir – an dem Punkt, an dem Code und Agenten erstellt werden. Das ist keine gemeinsame Plattform. Es ist dieselbe Anforderung, die auf drei verschiedenen Ebenen sichtbar wird: Unabhängige Prüfung ist auf jeder Ebene wichtig und darf nicht vorausgesetzt werden. Die weitergehende architektonische Aussage stammt von uns: Das System, das eine Änderung erstellt, darf nicht ihr alleiniger Validator sein. Wenn Menschen, die am meisten davon profitieren würden, „Vertraut uns“ zu sagen, sich stattdessen für „Prüft uns“ entscheiden, ist das kein Gesprächsthema, sondern eine Bestätigung.

Unabhängigkeit ist hier eine technische Eigenschaft, keine Frage des Brandings. Sie bedeutet, dass die Belege von etwas erzeugt werden, das der produzierende Agent nicht verändern kann, und anhand von Kontrollen geprüft werden, die außerhalb seiner Reichweite liegen: ausgeführte Tests, Datenflussanalyse und beobachtetes Laufzeitverhalten. Ein zweiter Prompt, ein zweiter Agent oder ein zweites Modell ist nicht unabhängig. Das ist dieselbe Art von Urteil, die zweimal eingeholt wird.

Die Belege sind nicht länger hypothetisch

Vor ein paar Wochen sagte ich, dass ich mir nicht am meisten Sorgen über die Raffinesse dieser Angriffe mache, sondern über ihre Verbreitung: dass diese Fähigkeit massentauglich werde und bald sehr viel mehr Menschen dazu in der Lage sein würden.

Acht Tage später begann Anthropics Bericht vom September mit genau dieser Feststellung in eigenen Worten: Raffinierte Angriffe erfordern keine raffinierten Angreifer mehr, weil KI die Lücke bei Arbeitskraft und Werkzeugen geschlossen hat, die früher staatlich unterstützte Operationen von Einzelpersonen trennte. Ich wäre lieber falsch gelegen.

Der von Amodei angeführte Vorfall ist eine Fehlerart: Agenten verlassen die ihnen erteilte Aufgabe. Das Folgende ist die andere – und es ist die, mit der die meisten Organisationen zuerst konfrontiert werden: Menschen, die diese Tools gezielt und in großem Maßstab einsetzen.

Anthropics Bericht vom September dokumentiert GTG-20006, einen laut Anthropics Zuordnung russischen, staatsnahen Spionageakteur, der einen KI-gestützten Workflow betrieb, der eigene Implantate identifizierte, modifizierte, neu erstellte und erneut einsetzte, nachdem Sicherheitsprodukte sie erkannt hatten. Die Malware entwickelte sich nicht von selbst: Ein Mensch steuerte sie, und KI schloss die Schleife schneller, als eine neue Erkennung geschrieben und ausgeliefert werden konnte.

Derselbe Bericht dokumentiert, dass die KI-Lieferkette selbst zum Ziel wird. Ein finanziell motivierter Akteur schleuste bösartige Anweisungen in die automatisierte Evaluierungs-Sandbox eines KI-Anbieters ein und erlangte die dort gespeicherten Zugangsdaten – darunter Produktions-API-Schlüssel aus der eigenen Umgebung des Anbieters.

Anthropic berichtet, dass die eigenen Systeme nicht kompromittiert wurden und der Versuch des Akteurs, ein Vorabmodell zu erreichen, scheiterte. Gestohlene KI-Zugangsdaten verschaffen einem Angreifer drei Dinge zugleich: Skalierbarkeit, die Rechenleistung eines anderen und den Namen eines anderen im Datenverkehr. Die KI-Lieferkette ist keine Risikokategorie der Zukunft, sondern heute bereits aktiv.

Ganz in unserer Nähe: Snyk ist Unterzeichner des gemeinsamen Schreibens zur Cyberabwehr, neben OpenAI, Anthropic, Google, Microsoft, Akamai und Hunderten weiteren Organisationen. Darin wird davor gewarnt, dass Kriminelle innerhalb weniger Monate KI-gesteuerte Angriffe auf kritische Infrastrukturen starten könnten. Wie ich dem Boston Globe sagte: Es ist, als wüsste man, dass ein Hurrikan kommt. Vielleicht haben Sie dieses Fenster nie repariert. Vielleicht klemmen Ihre Fensterläden. Wenn Sie wissen, dass er nächste Woche kommt – werden Sie es reparieren oder nicht?

Für den Sturm gerüstet sein

Von Anfang an sicher. Zur Laufzeit durchsetzen. Unabhängig validieren.

Software von Anfang an absichern, erkennen, was durch KI-generierten Code eingeführt wird und welche Pakete er einbindet, bevor er auch nur in die Nähe von Commit und Auslieferung gelangt – nicht erst danach.

Agenten und ihre Lieferketten kontrollieren, denn ein Agent mit zu weitreichendem Zugriff und ein ungeprüftes Tool sind heute eine standardmäßige Angriffsfläche und kein Sonderfall.

Kontinuierlich testen und beheben, denn ein punktueller Pentest kann mit einer Bedrohungslandschaft, die sich wöchentlich verändert, nicht Schritt halten. Kontinuierliches offensives Testen auf Grundlage von Produktionsbelegen zeigt, dass festgelegte Kontrollen den von Ihnen tatsächlich getesteten Angriffspfaden standhalten. Das ist eine engere Aussage als „Wir sind sicher“ – und die einzige, die es wert ist, getroffen zu werden.

Und unabhängig validieren, was KI erstellt: dieselbe Disziplin, auf die sich die Branche jetzt auf jeder Ebene zubewegt, angewandt auf jede Codezeile und jeden Agenten, den Ihre Teams ausliefern.

All das funktioniert nicht, wenn sich die Ergebnisse nur anhäufen. Jason Clinton, Deputy CISO bei Anthropic, brachte die operative Hälfte gut auf den Punkt, als wir unsere Partnerschaft bekannt gaben: „In der KI-Sicherheit war die Erkennung nie der Engpass. Durch die Kombination von Claudes Fähigkeiten mit Snyk können Unternehmen hochwertige Erkenntnisse direkt in den Workflows in Maßnahmen umsetzen, in denen Software entwickelt wird.“

Offen. Verbündet. Immer noch standhaft.

Die Verteidigungsebene muss breit zugänglich bleiben. Offene Modelle, gemeinsamer Informationsaustausch und Unterstützung für Open-Source-Maintainer gehören in die Sicherheitsarchitektur, nicht außerhalb davon.

Amodeis nächste Schritte sehen eine Koordination zwischen Frontier-Laboren und anschließend zwischen Regierungen vor. Das ist ein vernünftiger Vorschlag und kein Plan, jemanden auszuschließen. Meine Sorge gilt eher der Wirkung als der Absicht: Jede Vereinbarung, die letztlich die Fähigkeit zum Erstellen, Prüfen und Verteidigen von KI-Systemen auf eine Handvoll Labore konzentriert, wird zu einem Single Point of Failure – unabhängig davon, wofür sie ursprünglich gedacht war. Resilienz, die davon abhängt, dem Fahrplan eines einzigen Anbieters zu vertrauen, ist keine Resilienz. Beurteilen Sie jede vorgeschlagene Lösung, auch unsere, danach, ob sie den Kreis derjenigen erweitert, die sich verteidigen können.

Manches davon gab es schon vor der KI. Vierzig Jahre lang haben wir Software ausgeliefert, ohne uns an die Sicherheitsdisziplin zu halten, die andere Ingenieursbereiche als unverzichtbar ansehen. Wir erschaffen gerne, aber wir haben nie besonders gern abgesichert, was wir erschaffen. KI hat diese Lücke nicht eingeführt; sie hat uns die Zeit genommen, die wir genutzt haben, um sie zu verbergen, und obendrein eigene neue Risiken hinzugefügt.

Vorbereitung ist eine Führungsverantwortung und beginnt mit dem Teil, für den wir uns entscheiden.

Offen. Verbündet. Immer noch standhaft.

Am 17. September werde ich gemeinsam mit Alon Krifcher, Head of Applied AI bei Anthropic, die vier Schritte erläutern, die die Lücke zwischen Angriff und Verteidigung auf Maschinengeschwindigkeit schließen: entdecken, beheben, validieren und verhindern. Sichern Sie sich noch heute Ihren Platz.

Befragen Sie Ihren eigenen Agenten

Wenn Sie daraus ein Gespräch mit Ihrem eigenen Team machen möchten, geben Sie Ihrem Agenten das Folgende. Er wird Ihnen nicht sagen, ob Sie gefährdet sind – kein öffentliches Dokument kann das –, aber er wird Ihnen sagen, was Sie fragen sollten.

Read https://www.anthropic.com/threat-intelligence-report-september-2026,
https://snyk.io/evo/, and https://snyk.io/blog/ai-hurricane-is-here/ as reference material only.
Do not run tests, scans, or commands against any system, and do not change
any configuration.

For each attack path described in the report:

1. Separate what is documented evidence, what is my assumption, and what
   is unknown.
2. Identify the controls that could block or reduce it. For each, say
   whether it acts on what an agent uses, what it does, or what it
   generates, or on what an already-deployed system is permitted to do.
3. State what internal evidence we would need to assess our own exposure,
   and who in the organization would hold it.

Then rank a list of questions for my security team by potential impact,
likely exposure, and the size of the evidence gap.

Public reports and product descriptions cannot establish our actual
posture. Return questions and evidence requests, not an assessment of
whether we are secure. Never print the value of any key, token, or
credential.