Vier Fehler. Vier Schichten. Die Architektur selbst ist die Verwundbarkeit.

Eine Episode des Hard-Fork-Podcasts der New York Times vom 10. April 2026 untersuchte die Cybersicherheitsauswirkungen fortschrittlicher KI-Systeme und stellte eine Frage, die die Branche bisher vermieden hat: Was, wenn die Cybersicherheit nicht unterdurchschnittlich ist, sondern grundlegend falsch konzipiert?

Die Episode wurde Wochen nach einer Reihe von Vorfällen ausgestrahlt, die die Antwort schwer zu ignorieren machten. Innerhalb eines Monats durchbrach ein autonomer KI-Agent die interne KI-Plattform von McKinsey in zwei Stunden. Ein Angriff auf eine weit verbreitete Open-Source-KI-Bibliothek führte zu einer Kaskade von Vorfällen in nachgelagerten Unternehmen. Forscher zeigten, dass die Hardware, die als letzte Verteidigungslinie gedacht war, mit Standardteilen für weniger als tausend Dollar gebrochen werden kann. Und Anthropic gab bekannt, dass ein Frontier-Modell autonom tausende Zero-Day-Schwachstellen in Code gefunden hatte, den die Branche als stabil betrachtete.

Vier Vorfälle. Vier Schichten des KI-Stacks: Anwendung, Orchestrierung, Hardware und Betriebssystem. Jeder enthüllte wesentliche Einschränkungen in den Kontrollen, die dazu bestimmt waren, sie zu schützen.

Das Ende des Perimeter-Denkens

Die traditionelle Cybersicherheit basiert auf einer einzigen Prämisse: Mit genügend Kontrollen, Überwachung und Investitionen können Systeme gesichert werden. Diese Prämisse hat die Architektur der letzten Jahrzehnte geprägt, einschließlich Firewalls, Identitätsmanagement, Endgerätesicherheit und SIEM-Plattformen, die alle auf der Idee basieren, dass Sichtbarkeit und strenge Kontrolle Sicherheit bedeuten.

Der Wechsel der Branche zur Zero-Trust-Architektur spiegelt die wachsende Erkenntnis wider, dass traditionelle Netzwerkgrenzen nicht mehr als vertrauenswürdig angesehen werden können. Doch selbst als die Vertrauensmodelle evolvieren, stellen KI-Systeme eine andere Herausforderung dar: sensible Daten werden routinemäßig aggregiert, verarbeitet und über mehrere Infrastrukturschichten hinweg geteilt.

Dieser Ansatz machte Sinn, als Systeme relativ zentralisiert waren und Daten innerhalb klar definierter Grenzen blieben. Er wird jedoch viel weniger effektiv, wenn Daten kontinuierlich über Clouds, APIs, Drittanbieter und KI-Pipelines hinweg bewegt werden, während Benutzer und Rechenressourcen global verteilt sind. Die Perimeter ist keine Grenze mehr. Sie ist eine ständig sich verändernde Oberfläche, und wir wenden immer noch kontrollbasiertes Denken auf Systeme an, die realistisch gesehen nicht kontrolliert werden können.

Anwendungs-Schicht-Fehler: McKinseys Lilli

Am 9. März 2026 veröffentlichte der Sicherheits-Startup CodeWall eine Offenlegung, die die Risiken für Organisationen, die KI intern einsetzen, hervorhob.

Der autonome offensive Agent von CodeWall, ohne Anmeldeinformationen, ohne Insiderwissen und ohne menschliche Anleitung, erlangte Lese- und Schreibzugriff auf die Produktionsdatenbank hinter Lilli, McKinseys interner KI-Plattform, in weniger als zwei Stunden. Lilli wird von über 40.000 Mitarbeitern für Strategiearbeit, Kundenforschung und Dokumentenanalyse verwendet und generiert Hunderttausende von Prompts pro Monat.

Der Einstiegspunkt war nicht komplex. Der Agent fand öffentlich zugängliche API-Dokumentation, die über 200 Endpunkte auflistete, von denen 22 keine Authentifizierung erforderten. Die Schwachstellen entsprachen den Risiken, die im OWASP Top 10 für LLM-Anwendungen hervorgehoben werden, insbesondere im Zusammenhang mit exponierten Schnittstellen, unsicheren Integrationen und übermäßigem Vertrauen in verbundene Systeme.

Einer dieser Endpunkte enthielt eine SQL-Injection-Schwachstelle, die in JSON-Feldnamen und nicht in Eingabewerten verborgen war, wo die meisten automatischen Scanner suchen. Von dort aus iterierte der Agent durch blinden SQL-Injection, bis Produktionsdaten zugänglich wurden.

Was er zugänglich machte: Zehntausende von Chat-Nachrichten in Klartext, Hunderttausende von Dateien, Zehntausende von Benutzerkonten und Millionen von RAG-Dokument-Teilen, die Jahre von proprietärer Forschung darstellten. Es identifizierte auch die Systemprompts, die das Verhalten von Lilli für jeden Benutzer regelten.

Die beunruhigendste Feststellung war nicht das Volumen. Es war, dass die Systemprompts beschreibbar waren. Ein Angreifer hätte die Anweisungen, die Lillis Ausgaben regelten, stillschweigend umschreiben, vertrauliche Daten in Antworten einbetten, Schutzvorkehrungen entfernen oder sie vollständig beseitigen können, mit einer einzigen Datenbankaktualisierung. Keine Bereitstellung. Keine Codeänderung. Keine Spur in den Anwendungsprotokollen.

In einer öffentlichen Erklärung sagte McKinsey, es habe das Problem innerhalb von Stunden behoben und nach einer Untersuchung durch ein externes Forensik-Unternehmen keine Beweise dafür gefunden, dass vertrauliche Kundendaten zugänglich gewesen seien. Diese Reaktion ist wichtig. Sie ändert jedoch nicht die strukturelle Lektion: eine seit Jahrzehnten bekannte Schwachstellenklasse hat das operative Gedächtnis eines modernen KI-Systems bloßgelegt, weil die dahinterliegenden Daten in lesbarer Form existierten.

Orchestrierungs-Schicht-Fehler: Der LiteLLM-Angriff

Drei Wochen später erschien das gleiche Muster aus einer anderen Perspektive und durch eine andere Schicht.

LiteLLM ist ein Open-Source-KI-Gateway, das von Tausenden von Unternehmen verwendet wird, um Anfragen an KI-Anbieter zu routen. Seine Position im Stack ist kritisch: Es sitzt auf der Orchestrierungsschicht und hält API-Schlüssel für jeden Anbieter, den es verbindet. Jeder Kompromiss auf dieser Schicht gefährdet Anmeldeinformationen über alle integrierten Dienste hinweg.

Laut einem PyPI-Zwischenfallbericht nutzte die Bedrohungsgruppe TeamPCP Anmeldeinformationen, die an eine Abhängigkeit in LiteLLMs CI/CD-Pipeline gebunden waren, und veröffentlichte zwei kompromittierte Versionen des LiteLLM-Pakets direkt auf PyPI. Die kontaminierten Versionen waren weniger als eine Stunde lang verfügbar, bevor sie entfernt wurden. Der Betrieb wurde nur entdeckt, weil das Malware einen Fehler enthielt, der einen Forschers Computer zum Absturz brachte.

Die Lieferkette war der Vektor. Die Orchestrierungsschicht war das Ziel. Durch die Kompromittierung einer einzigen Abhängigkeit im Upstream erreichten Angreifer die Schicht, in der die Anmeldeinformationen aller nachgelagerten Unternehmen lebten.

Das LiteLLM-Team veröffentlichte später eine öffentliche GitHub-Offenlegung, in der es den Vorfall und die Minderungsmaßnahmen erläuterte.

Der Blast-Radius wurde fast sofort sichtbar. TechCrunch, Fortune und The Register berichteten, dass Mercor, ein KI-Recruiting-Startup im Wert von 10 Milliarden Dollar, das mit Unternehmen wie OpenAI, Anthropic, Meta und Google zusammenarbeitet, von den betroffenen Organisationen war. Angreifer behaupteten, große Datenmengen, einschließlich Bewerberprofile, personenbezogener Daten, Video-Interviews von Auftragnehmern, Quellcode und API-Schlüssel, erlangt zu haben. Meta setzte die Arbeit mit Mercor aus, bis die Untersuchung abgeschlossen war. Nachfolgende Berichte deuteten auf ähnliche Malware-Muster in anderen Entwickler-Tools und Paketen hin, was darauf hindeutet, dass der Betrieb möglicherweise über ein einzelnes Projekt hinausging.

Der LiteLLM-Vorfall war kein Einzelfall. Es war das System, das wie konzipiert funktionierte. Jedes Komponente in einer KI-Pipeline benötigt Zugriff auf verwertbare Daten, um zu funktionieren, was bedeutet, dass jedes Komponente auch ein potenzieller Extraktionspunkt ist. Die Fixierung von Abhängigkeiten und die Rotation von Anmeldeinformationen sind notwendige Reaktionen, aber sie beheben den Vorfall, nicht die Architektur.

Hardware-Schicht-Fehler: TEE.fail

Wenn der McKinsey-Breach zeigte, dass die Anwendungsschicht nicht vertrauenswürdig ist, und der LiteLLM-Angriff zeigte, dass die Lieferkette nicht vertrauenswürdig ist, zeigte die TEE.fail-Forschung, dass die Hardware, die als letzte Verteidigungslinie gedacht war, nicht vollständig vertrauenswürdig ist.

Am 28. Oktober 2025 veröffentlichten Forscher von Georgia Tech, Purdue University und Synkhronix TEE.fail, einen Side-Channel-Angriff, der kryptografische Schlüssel aus Trusted Execution Environments extrahiert, indem er physikalische Speicherbus-Interposition auf DDR5-Servern verwendet. Der Angriff betrifft Intel SGX, Intel TDX und AMD SEV-SNP, einschließlich vollständig gepatchter, vertrauenswürdiger Systeme mit AMDs Ciphertext Hiding aktiviert. Diese Technologien werden weithin als Grundlage für vertrauliches Rechnen beworben.

Die Forscher extrahierten Attestationsschlüssel: das kryptografische Material, das verwendet wird, um zu überprüfen, dass Workloads innerhalb sicherer Umgebungen ausgeführt werden. Mit diesen Schlüsseln kann ein kompromittiertes System sich als vertrauenswürdig präsentieren, während es vollständig außerhalb der erwarteten Schutzmechanismen operiert. Die Forscher demonstrierten dies direkt: Sie fälschten TDX-Attestationen auf Ethereums BuilderNet, um vertrauliche Transaktionsdaten zu erhalten, und fälschten Intel- und NVIDIA-Attestationen, um Workloads außerhalb jeder TEE auszuführen, während sie sich als legitime präsentierten.

Die NVIDIA-Implication ist für KI insbesondere wichtig. Da die GPU-Attestation von der CPU-Attestation abhängt, kann ein kompromittierter CPU-Vertrauensketten die Garantien untergraben, die durch vertrauliche KI-Schlussfolgerungsumgebungen bereitgestellt werden. Die Hardware-Basis für vertrauliche KI-Schlussfolgerung ist in diesem Bedrohungsmodell von einer CPU-TEE abhängig, die nachweislich gebrochen wurde.

Hardware-Hersteller reagierten mit formellen Warnungen. AMD erklärte, dass physische Angriffe außerhalb seines Standard-Bedrohungsmodells liegen und gab an, dass es keine Firmware-Updates bereitstellen würde. Intel und NVIDIA bestätigten die Ergebnisse und gaben an, dass sie an der Minderung der Bedrohung arbeiteten. Diese Reaktionen sind innerhalb ihrer Bedrohungsmodelle vernünftig. Sie heben jedoch eine wichtige Grenze hervor: Die Garantien der hardwarebasierten Sicherheit hängen von Annahmen ab, einschließlich physischer Kontrolle, die souveräne, regulierte und feindliche Konfrontationen nicht immer machen können.

TEE.fail macht die Hardware-Isolation nicht irrelevant. Es zeigt, dass sie bedingt ist.

 Betriebssystem-Schicht-Fehler:  Die Mythos-Offenlegung

Wenn die ersten drei Vorfälle die Anwendungsschicht, die Orchestrierungsschicht und die Hardware-Schicht in Frage stellten, rief eine vierte Offenlegung im April 2026 die Schicht in Frage, die unter all diesen liegt: die Betriebssysteme und Kernbibliotheken, auf denen alle anderen Schichten basieren.

Am 7. April 2026 kündigte Anthropic Claude Mythos Preview an, ein Frontier-Modell, das es aufgrund seiner offensiven Sicherheitsfunktionen nicht öffentlich veröffentlichte, und startete gleichzeitig Project Glasswing, ein Konsortium mit AWS, Apple, Broadcom, Cisco, CrowdStrike, Google, JPMorgan Chase, der Linux Foundation, Microsoft, NVIDIA und Palo Alto Networks. Anthropic berichtete, dass Mythos in nur wenigen Wochen tausende unbekannte Schwachstellen in großen Betriebssystemen und Webbrowsern autonom identifiziert und für viele davon funktionsfähige Exploits produzieren konnte.

Die spezifischen Ergebnisse sind schwerer zu ignorieren als jede Zusammenfassung. Ein 27 Jahre alter Bug in OpenBSD. Ein 17 Jahre alter Remote-Code-Execution-Fehler im NFS-Server von FreeBSD, der jetzt als CVE-2026-4747 verfolgt wird, der einem nicht authentifizierten Angreifer Root-Zugriff gewährt. Ein 16 Jahre alter Schwachpunkt in FFmpeg, einer der am häufigsten eingesetzten Medienbibliotheken im Internet. In einem Fall bat ein Anthropic-Ingenieur ohne formale Sicherheitsausbildung das Modell, nach Remote-Code-Execution-Schwachstellen zu suchen, und fand am nächsten Morgen einen vollständigen funktionsfähigen Exploit.

Das sind Betriebssystem-Ebene-Feststellungen. OpenBSD und FreeBSD sind Kerne. NFS ist ein Kernel-Netzwerkteil. FFmpeg ist eine Systembibliothek, die mit den meisten Linux-Distributionen ausgeliefert wird und Medienpipelines im Internet unterstützt. Die OS-Schicht wurde als sicher angenommen, nicht weil sie bewiesen sicher war, sondern weil das Finden tiefer Schwachstellen in ihr seltene und teure menschliche Expertise erforderte. Diese Annahme war die beste verfügbare Heuristik. Sie war nie eine Garantie.

Diese Einschränkung hat sich jetzt gelockert. Anthropic selbst bezeichnete dies als Dual-Use-Verschiebung: dieselben Fähigkeiten, die es einem Frontier-Modell ermöglichen, Schwachstellen im großen Maßstab zu finden und zu beheben, ermöglichen es ihm auch, sie im Falle eines Angriffs im großen Maßstab auszunutzen. Anthropics Entscheidung, den Zugang über Project Glasswing einzuschränken, spiegelt diese Realität wider. Sie löst sie jedoch nicht. Ähnliche Fähigkeiten werden, laut der Unternehmenseinschätzung, verbreitet sein. Die Kosten für die Überprüfung von Legacy-Code sind zusammengebrochen, und damit auch die implizite Verteidigung, dass solcher Code zu alt, zu unbedeutend oder zu sehr überprüft war, um noch kritische Schwachstellen zu enthalten.

Das ist auch der Punkt, an dem die vier Vorfälle zusammenkommen. Die Hardware-Schichts-Schutzmaßnahmen für vertrauliches Rechnen funktionieren nicht isoliert. Sie laufen als Kernel-Code. Intel TDX läuft im Kernel. NVIDIA-GPU-Treiber laufen als Kernel-Module. Die CPU-TEE-Attestationskette hängt von einem vertrauenswürdigen Betriebssystem ab, um zuverlässig zu melden, was es tut. Wenn die OS-Schicht unter Ihrer TEE jahrzehntealte latente Schwachstellen hat und ein Frontier-Modell sie im Maschinengeschwindigkeit finden kann, hängt die bedingte Sicherheit der Hardware-Schicht von einer OS-Schicht ab, deren Sicherheitsgarantien durch dieselbe Offenlegung geschwächt wurden.

Die drei früheren Vorfälle beschreiben, wie KI-Systeme heute kompromittiert werden. Mythos beschreibt die Rate, mit der alles darunter, einschließlich Betriebssysteme, Kernel-Module und Systembibliotheken, von Maschinen neu überprüft wird. Der McKinsey-Breach nutzte eine SQL-Injection-Schwachstellenklasse aus, die seit über zwei Jahrzehnten existiert. Schwachstellen dieser Art sind genau das, wozu Modelle der Mythos-Klasse nachweislich in der Lage sind, im industriellen Maßstab zu finden.

Das Muster

In jedem Fall waren die Daten im Moment des Eintretens lesbar.

Die Anwendungsschicht verarbeitete sie im Klartext. Die Orchestrierungsschicht leitete sie im Klartext weiter. Die Hardware-Schicht, trotz ihrer Schutzmaßnahmen, erforderte letztendlich eine Entschlüsselung am Ausführungspunkt. Die OS-Schicht unter all diesen operierte auf sie im Klartext, per Definition. Vier Schichten, vier Fehler, und in jeder Schicht galt dieselbe Bedingung: wenn der Bruch eintrat, waren die Daten lesbar.

Das ist kein Sammelsurium isolierter Fehler. Es ist die Architektur selbst.

Moderne KI-Systeme sind so konzipiert, dass sie auf lesbarer Daten operieren. Jede Schicht, einschließlich Abruf, Routing, Schlussfolgerung und Tool-Ausführung, erfordert Zugriff auf Klartext, um zu funktionieren. Diese Designentscheidung bedeutet, dass jeder Bruch in jeder Schicht die dahinterliegenden Daten freilegt.

Die Frage ist nicht, ob eine Schicht kompromittiert wird. Es ist, was der Angreifer findet, wenn er es tut.

Von angenommener Verletzung zu Null-Exposition

Die Branche hat bereits begonnen, sich von “Verletzung verhindern” zu “Verletzung annehmen” zu bewegen. Die meisten Architekturen haben jedoch nicht die Implikationen verfolgt.

Wenn eine Verletzung unvermeidlich ist, ist die eigentliche Frage nicht, wie man Angreifer fernhält. Es ist, was passiert, wenn sie hereinkommen. Derzeit ist die Antwort einfach: Sie erhalten die Daten. Denn trotz aller Investitionen in Sicherheitsinfrastruktur sind Daten immer noch im Moment, in dem sie wertvoll werden, wenn sie verwendet werden, ungeschützt.

Die Reaktion der Branche war vorhersehbar: mehr Überwachung, schnelleres Erkennen, zusätzliche Schichten für vertrauliches Rechnen. Das sind Verbesserungen. Sie lösen jedoch nicht das Kernproblem. Sie gehen immer noch davon aus, dass eine Schicht – sei es Software, Hardware oder Betrieb – vertrauenswürdig genug ist, um Klartext zu schützen.

Die Alternative ist, den Klartext vollständig zu entfernen. Nicht die Schichten um die Daten zu sichern, sondern die Daten selbst unzugänglich für jeden zu machen, der sie erreicht. Berechnungen auf verschlüsselten Daten, bei denen Prompts, Modellgewichte und Ausgaben während der gesamten Pipeline verschlüsselt bleiben, adressieren die Exposition, die jeder dieser Vorfälle ausgenutzt hat.

Fortgeschrittene Techniken für vollständig homomorphe Verschlüsselung und andere Techniken für den Schutz der Privatsphäre machen Architekturen, die die Exposition von Klartext minimieren oder eliminieren, für reale KI-Arbeitslasten zunehmend praktikabel. Während erhebliche Leistungs-, Skalierungs- und Implementierungsprobleme bestehen bleiben, ist das Ziel grundlegend anders als traditionelle Sicherheitskontrollen: die Reduzierung des Wertes einer erfolgreichen Kompromittierung anstelle der bloßen Verringerung der Wahrscheinlichkeit einer Kompromittierung.

Der Wechsel ist nicht von einem Sicherheits-Tool zu einem anderen. Es ist von der Sicherung von Systemen zur Reduzierung der Exposition. Von vertrauenswürdiger Infrastruktur zu Null-Vertrauen-Daten. Von Risikomanagement zur Minimierung der Angriffsfläche selbst.

Was kommt als Nächstes

Die Hard-Fork-Diskussion hat die Frage aufgeworfen, ob die Cybersicherheit grundlegend falsch konzipiert ist. Die Beweise der letzten Wochen deuten darauf hin, dass die Antwort, zumindest für KI, ja ist.

Das alte Modell ging davon aus, dass Systeme gesichert werden können, Verletzungen eingedämmt und Expositionen gemanagt werden können. Die neue Realität ist, dass Verletzungen angenommen und Expositionen minimiert werden müssen. Die Vorfälle, die hier beschrieben werden, deuten darauf hin, dass die Sicherung von KI-Systemen zunehmend von der Reduzierung der Menge an sensitiven Daten abhängt, die bei einem Kontrollverlust verfügbar sind.

Die Schwachstellen, die in diesen vier Vorfällen aufgedeckt wurden, sind nicht auf eine einzige Schicht beschränkt. Sie sind systemisch. Ihre Behebung wird mehr als inkrementelle Verbesserungen erfordern. Es wird einen Wechsel von der Sicherung von Systemen zur Reduzierung der Exposition erfordern, von der Verteidigung der Perimeter um die Daten zur Entfernung des Klartexts, den die Perimeter schützen sollte.

Die KI-Sicherheit geht nicht mehr darum, Angreifer fernzuhalten. Es geht darum, sicherzustellen, dass, wenn sie hereinkommen, und sie werden hereinkommen, es nichts Lesbares gibt, das sie finden können.