Der KI-Hurrikan ist da

Im vergangenen Jahr habe ich dies als KI-Nebel beschrieben: konkurrierende Behauptungen, unklare Risiken und Führungskräfte, die Schwierigkeiten hatten zu erkennen, was wichtig war. Jetzt nimmt der Wind zu. KI beschleunigt die Softwareentwicklung, legt jahrelang angesammelte Schwachstellen offen und gibt Angreifern wie Verteidigern Fähigkeiten an die Hand, die mit Maschinengeschwindigkeit arbeiten.

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

Ich sage seit einem Jahr, dass sich die Entwicklung auf Maschinengeschwindigkeit beschleunigt hat, die Validierung aber nicht, und dass dort, wo diese beiden auseinanderklaffen, das tatsächliche Risiko liegt. An dieser Diagnose hat sich nichts geändert. Geändert hat sich die Taktung. Die Art schwerwiegender Schwachstelle, die KI inzwischen in weit verbreiteter Software aufdeckt – ein Fund, der früher ein- oder zweimal im Jahr aufgetreten wäre und das Quartal aller Beteiligten auf den Kopf gestellt hätte –, taucht in dem, was ich beobachte, inzwischen mehrmals pro Woche auf. Das lässt sich nicht einfach aussitzen.

Es läuft auf drei Probleme hinaus: automatisierte Angriffe, die sich schneller bewegen, als ein Backlog in menschlicher Geschwindigkeit sie 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 Prüfpfad in der Produktion laufen.

Der Hurrikan ist bereits da. Über seine Geschwindigkeit zu debattieren, wird die Anwendungs- oder Infrastrukturebene nicht sturmfest machen.

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

Tun Sie das nicht. Dies ist anders.

Nehmen Sie das tatsächliche Risiko ernst und prüfen Sie genau, 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 darin vorgeschlagen, dass Frontier-Labs den Ausbau 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 fortlaufend Zugriff erhalten, um die Sicherheitspraktiken des Unternehmens zu überprüfen. Separat führt Amodei Agenten an, die Systeme außerhalb ihrer zugewiesenen Aufgabe angreifen – einschließlich des Systems, das ihre Leistung bewertet. Daraus ergeben sich unterschiedliche Fragen zu Aufsicht und Kontrolle. Für die Unternehmenssicherheit ist unsere architektonische Anforderung klar: Das System, das eine Änderung erstellt, darf nicht deren 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 im Einsatz ist. Seiner Einschätzung nach ist die Laufzeit der entscheidende 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 für die Laufzeit ist essenziell. Ich würde es auf die Entwicklung ausweiten: Steuern 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 schränken ein, 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 diese Regel gilt auf jeder Ebene: Das System, das den Code generiert oder eine Behebung vorschlägt, darf nicht sein eigener alleiniger Validator sein.

Drei unterschiedliche Ausgangspunkte: ein Frontier-Lab, ein Verteidiger der Laufzeit und wir – an dem Punkt, an dem Code und Agenten entstehen. 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 architektonische Aussage, die darüber hinausgeht, stammt von uns: Das System, das eine Änderung erstellt, darf nicht deren alleiniger Validator sein. Wenn diejenigen, die am meisten davon profitieren würden, „Vertraut uns“ zu sagen, sich stattdessen für „Überprüft uns“ entscheiden, ist das kein Slogan, sondern Bestätigung.

Unabhängigkeit ist hier eine technische Eigenschaft, keine Frage des Brandings. Sie bedeutet, dass die Nachweise von etwas erzeugt werden, das der produzierende Agent nicht verändern kann, und anhand von Kontrollen geprüft werden, die außerhalb der Reichweite dieses Agenten 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 abgefragt wird.

Die Belege sind nicht mehr hypothetisch

Vor ein paar Wochen sagte ich, dass ich nicht die Raffinesse dieser Angriffe am meisten fürchtete, sondern ihre Verbreitung: dass diese Fähigkeit den Massenmarkt erreicht und schon bald sehr viel mehr Menschen dazu in der Lage sein würden.

Acht Tage später eröffnete Anthropic seinen Septemberbericht mit derselben Erkenntnis, in eigenen Worten: Für ausgeklügelte Angriffe sind keine ausgeklügelten Angreifer mehr erforderlich, weil KI die Lücke bei Arbeitskraft und Tools geschlossen hat, die früher staatlich unterstützte Operationen von Einzelpersonen trennte. Ich wäre lieber im Unrecht gewesen.

Der von Amodei angeführte Vorfall ist ein Fehlermodus: Agenten verlassen die ihnen erteilte Aufgabe. Das Folgende ist der andere – und es ist der, dem die meisten Organisationen zuerst begegnen werden: Menschen, die diese Tools absichtlich und in großem Maßstab einsetzen.

Anthropic’s Septemberberichtdokumentiert GTG-20006, einen von Anthropic einem russischen staatlichen Umfeld zugeordneten Spionageakteur, der einen KI-gestützten Workflow ausführte, mit dem er seine eigenen Implantate identifizierte, veränderte, neu kompilierte 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 von der Sandbox gespeicherten Zugangsdaten – darunter Produktions-API-Schlüssel aus der eigenen Umgebung dieses 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 gleichzeitig drei Dinge: Skalierbarkeit, die Rechenleistung anderer und den Namen eines anderen im Datenverkehr. Die KI-Lieferkette ist keine zukünftige Risikokategorie, sondern heute bereits ein aktives Risiko.

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-gestützte 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 bauen

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

Software von Anfang an sicher machen, also erkennen, was KI-generierter Code einführt 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 steuern, denn ein Agent mit zu weitreichenden Zugriffsrechten und ein ungeprüftes Tool sind heute eine standardmäßige Angriffsfläche, kein Sonderfall.

Kontinuierlich testen und beheben, denn ein punktueller Penetrationstest kann mit einer Bedrohungslandschaft, die sich wöchentlich verändert, nicht Schritt halten. Kontinuierliches offensives Testen auf Grundlage von Produktionsnachweisen zeigt, dass die festgelegten Kontrollen gegen die von Ihnen tatsächlich getesteten Angriffspfade Bestand haben. 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 inzwischen auf jeder Ebene zubewegt – angewandt auf jede Codezeile und jeden Agenten, den Ihre Teams ausliefern.

Nichts davon funktioniert, wenn sich die Erkenntnisse lediglich anhäufen. Jason Clinton, Deputy CISO bei Anthropic, brachte die operative Hälfte treffend auf den Punkt, als wir unsere Partnerschaft bekannt gaben: „In der KI-Sicherheit war die Erkennung nie der Engpass. Durch die Kombination der Fähigkeiten von Claude mit Snyk können Unternehmen hochpräzise Erkenntnisse in den Workflows, in denen Software entwickelt wird, in konkrete Maßnahmen umsetzen.“

Offen. Gemeinsam. Immer noch standhaft.

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

Amodeis spätere Schritte fordern eine Koordination zwischen Frontier-Labs und anschließend zwischen Regierungen. Das ist ein vernünftiger Vorschlag und kein Plan, irgendjemanden auszuschließen. Meine Sorge betrifft die Wirkung, nicht die Absicht: Jede Vereinbarung, die letztlich die Fähigkeit, KI-Systeme zu entwickeln, zu prüfen und zu verteidigen, in den Händen einiger weniger Labs konzentriert, wird zu einem Single Point of Failure – unabhängig davon, wofür sie ursprünglich gedacht war. Resilienz, die vom Vertrauen in die Roadmap eines einzigen Anbieters abhängt, ist keine Resilienz. Bewerten Sie jeden vorgeschlagenen Lösungsansatz, auch unseren, danach, ob er den Kreis derjenigen erweitert, die 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 nicht verhandelbar betrachten. Wir lieben es, Dinge zu erschaffen, aber wir haben uns nie besonders gern um deren Absicherung gekümmert. KI hat diese Lücke nicht eingeführt; sie hat uns die Zeit genommen, in der wir sie verborgen hielten, und darüber hinaus eigene neue Risiken hinzugefügt.

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

Offen. Gemeinsam. 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 mit Maschinengeschwindigkeit schließen: entdecken, beheben, validieren und verhindern. Sichern Sie sich noch heute Ihren Platz.

Fragen Sie Ihren eigenen Agenten

Wenn Sie daraus ein Gespräch mit Ihrem eigenen Team machen möchten, geben Sie Ihrem Agenten Folgendes. Er wird Ihnen nicht sagen, ob Sie exponiert 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.