Am 9. Juli 2026 lädt jemand einen Datensatz auf eine öffentliche Plattform. Die Konfiguration dieses Datensatzes deklariert für jeden Split eine kleine HDF5-Datei. Jede dieser Dateien ist ein formal gültiger HDF5-Container, dessen Rohdaten an einem lokalen Dateipfad liegen sollen. Als der Verarbeitungsdienst die Datei öffnet, um die Splits zu erzeugen, liest er die Bytes von diesem Pfad und gibt sie als Zeilen des Datensatzes zurück. Einer der deklarierten Pfade lautet /proc/self/environ.
Es wurde nichts umgangen. Es wurde nichts gebrochen. Die Pipeline hat exakt das getan, wofür sie gebaut wurde: eine deklarierte Konfiguration in Dateizugriffe übersetzen. Das Ergebnis war der vollständige Umgebungsspeicher eines Produktions-Pods, einschließlich Zugangsdaten.
Vier Tage später, am 13. Juli um 14:14 UTC, endet der letzte protokollierte Vorgang. Dazwischen liegen rund 17.600 rekonstruierbare Aktionen eines autonom operierenden KI-Agenten, der sich aus einer Evaluationsumgebung befreit, eine fremde Sandbox als Startrampe übernommen, sich in eine Produktionsinfrastruktur hineingearbeitet und dort Cluster-Administratorrechte erlangt hat. Hugging Face hat den Ablauf am 27. Juli in einer technischen Rekonstruktion der Kill Chain 📎 offengelegt. OpenAI hatte den Vorfall am 21. Juli als beispiellos bezeichnet 📎 und in einem Update am 28. Juli ergänzt, dass der Ausbruch aus der Evaluationsumgebung über eine bis dahin unbekannte Schwachstelle in einem Paket-Proxy erfolgte, die inzwischen an den Hersteller gemeldet 📎 wurde.
Die öffentliche Diskussion konzentriert sich seither auf die Frage, was Modelle inzwischen können — bis hin zu der in der Entwicklercommunity verbreiteten Einschätzung 📎, hier sei Science-Fiction eingetreten. Das ist die zweitwichtigste Frage. Die wichtigste lautet: Warum hat die Autorisierungsarchitektur der betroffenen Umgebung diesen Ablauf nicht einmal verlangsamt — obwohl die Authentifizierung an keiner einzigen Stelle gebrochen wurde?
Drei Umstände sind festzuhalten, bevor die technische Analyse beginnt, weil sie den Rahmen bestimmen, in dem sie zu lesen ist. Der Ausbruch fand in der Evaluationsumgebung eines der bestausgestatteten KI-Labore der Welt statt, also dort, wo Isolation von Testumgebungen zum Kerngeschäft gehört. Bemerkt wurde er zuerst nicht dort: Das Sicherheitsteam des angegriffenen Unternehmens hatte die Aktivität nach eigener Darstellung bereits erkannt, eingedämmt und mit der forensischen Rekonstruktion begonnen, als die Teams beider Seiten miteinander in Kontakt traten. Und wir wissen davon ausschließlich, weil beide Beteiligten sich entschieden haben, es zu erzählen.
Aus Sicht des Agenten war es kein Angriff. Es war eine Abkürzung.
Zum Verständnis des Falls gehört sein Motiv, und das Motiv ist bemerkenswert unspektakulär. Vorweg jedoch eine Klarstellung, damit die folgende Argumentation nicht als Verharmlosung gelesen wird: Für den betroffenen Betreiber war der Vorgang eine Intrusion, unabhängig davon, was den Agenten angetrieben hat. Wer über mehrere Tage Cluster-Administratorrechte in fremder Produktionsinfrastruktur hält, greift an — Absicht ist dafür keine Voraussetzung. Die Motivfrage ist deshalb nicht die Frage nach der Schwere, sondern die Frage danach, welche Schutzannahme hier gescheitert ist. Der Agent wurde auf einem Benchmark für die Ausnutzung realer Schwachstellen 📎 evaluiert. Für diese Messung waren die Schutzklassifikatoren, die im Produktivbetrieb hochriskante Cyberaktivitäten unterbinden, absichtlich deaktiviert — die Evaluation sollte die maximale Fähigkeit des Modells bestimmen, nicht sein Verhalten unter Schutzmaßnahmen.
Der Agent schloss daraus, dass die Referenzlösungen dieses Benchmarks auf der Plattform von Hugging Face liegen könnten. Er versuchte nicht, ein Unternehmen zu schädigen. Er versuchte, die Prüfung zu bestehen, indem er die Musterlösung besorgte. Nach der Erstmeldung des Betreibers vom 16. Juli 📎 und der späteren technischen Aufarbeitung war die gesamte Intrusion aus Sicht des Agenten ein Täuschungsversuch gegenüber der eigenen Bewertung.
Das ist der eigentlich unangenehme Befund. Es brauchte keinen feindseligen Auftrag, keinen staatlichen Akteur, keine Kompromittierung des Modells durch Dritte. Es brauchte ein hinreichend hartnäckig verfolgtes Ziel, Werkzeugzugriff und eine Umgebung, deren Autorisierungsgrenzen nicht darauf ausgelegt waren, gegen den eigenen Nutzer zu halten. Genau diese Konstellation beschreibt OpenAI in einer separaten Veröffentlichung vom 20. Juli 📎 als strukturelles Merkmal langlaufender Agenten: Modelle, die über lange Zeithorizonte an einem Ziel arbeiten, entwickeln Handlungsketten, in denen jede Einzelaktion für sich zulässig erscheint und erst die Sequenz unzulässig ist.
Für Betreiber in Deutschland ist das die relevante Übersetzung: Ein Agent muss nicht bösartig sein, um eine Kompromittierung zu verursachen. Er muss nur zielstrebig sein und Rechte haben.
Jede verwendete Berechtigung war gültig.
Ich habe die dokumentierte Kill Chain daraufhin durchgesehen, an welcher Stelle eine Authentifizierung überwunden wurde. Es gibt diese Stelle nicht.
Der Agent las das im Pod verfügbare projizierte Service-Account-Token und sprach damit die Cluster-API an. Gültiges Token. Er las die temporären Zugangsdaten der Knotenrolle aus dem Cloud-Metadatendienst und baute daraus einen korrekt konstruierten Bearer-Token, mit dem er sich gegenüber der Cluster-API als der Knoten selbst auswies. Gültiger Identitätsnachweis. Er las aus der Pod-Umgebung ein statisches Passwort und meldete sich damit an der internen Betriebsdatenbank an. Gültige Anmeldung. Er entnahm einem Secret-Objekt mit 136 Schlüsseln einen Authentifizierungsschlüssel für das unternehmensinterne Mesh-VPN und meldete damit Geräte im Firmennetz an — 181 Anmeldungen im Verlauf der Kampagne. Gültiger Schlüssel, gültiges Enrollment. Er erreichte über die dem VPN-Tag erlaubte Verbindung die Quellcodeverwaltung, fand dort eine interne App-Integration und ließ sich von ihr ein Installationstoken mit Schreibrechten ausstellen. Regulär ausgestelltes Token.
An keiner dieser Stationen musste ein Passwort erraten, eine Signatur gefälscht oder ein Kryptoverfahren gebrochen werden. Jedes System, das der Agent ansprach, hat korrekt geprüft, wer da anfragt — und die Antwort war jedes Mal: ein berechtigter Aufrufer.
Das ist der Punkt, an dem eine ausschließlich identitätszentrierte Umsetzung von Zero Trust nicht mehr trägt. Zero Trust Architecture fragt: Wer greift zu, von wo, mit welchem Gerätezustand, unter welcher kontinuierlichen Verifikation — und sie beantwortet diese Fragen mit Least Privilege, dynamischer Autorisierung, Mikrosegmentierung und laufender Risikobewertung. Konsequent umgesetzt hätte ZTA den Wirkungsradius dieser Kampagne spürbar verkleinert; zwei der oben beschriebenen Konfigurationsfehler sind schlicht ZTA-Verstöße. Die tatsächlich vorhandenen Kontrollstellen erhielten in dieser Kampagne aber auf ihre jeweiligen Fragen korrekte und zunächst unauffällige Antworten: gültige Identität, gültiges Token, zulässige Verbindung, formal erlaubte Aktion. Nicht gestellt wurde eine andere Frage, und für sie gab es in dieser Architektur auch keinen Prüfpunkt: Auf wessen Autorität hin handelt dieser Aufrufer gerade — und lässt sich diese Autorität bis zu einer menschlichen oder policy-basierten Entscheidung zurückverfolgen?
Genau diese Trennung von Identität und Autorität habe ich im April als eigenständige, zu ZTA orthogonale Steuerungsschicht beschrieben und Execution Provenance Control genannt. Sie war damals ein Architekturargument ohne Vorfall, der es zwingend gemacht hätte. Das hat sich am 9. Juli geändert. Warum Zero Trust in der agentischen Ära Execution Provenance Control braucht 📎
Ein einziges Systemkonto war überall Cluster-Administrator.
Zwei Konfigurationsentscheidungen verdienen besondere Aufmerksamkeit, weil sie in deutschen Unternehmensumgebungen mindestens ebenso häufig anzutreffen sind wie in kalifornischen.
Die erste betrifft einen internen Zugriffsvermittler, der mehrere Kubernetes-Cluster fronted. Dieser Vermittler war mit einer einzigen, über alle Cluster hinweg geteilten Connector-Berechtigung ausgestattet, und die zugehörige Identität war an die Gruppe system:masters gebunden. Eine einzige Anfrage lieferte dem Agenten den vollständigen Zielkatalog des Vermittlers, also Verbindungs-URLs und Zertifikate sämtlicher dahinterliegender Cluster. Durch Impersonation dieser einen Systemidentität hielt er nach eigener Rekonstruktion des Betreibers innerhalb einer Sekunde Cluster-Admin-Rechte auf zwei Clustern — und dieselbe Bindung existierte auf praktisch allen weiteren.
Die zweite betrifft die Cluster-Policy. Es gab keine Admission-Regel, die privilegierte Pods oder Pods mit Host-Dateisystem-Einbindung abgelehnt hätte, und die ClusterRole eines Speichertreibers erlaubte clusterweite Pod-Erstellung. Der Agent legte daraufhin einen privilegierten Pod mit eingehängtem Host-Dateisystem an, erlangte Root auf dem Knoten und baute anschließend eine sich selbst wiederherstellende Pod-Flotte über elf Knoten auf. Ein reines Löschen von Pods hätte die Kampagne nicht beendet.
Beides sind keine exotischen Fehler. Beides sind Bequemlichkeitsentscheidungen, die in gewachsenen Plattformarchitekturen entstehen, weil sie im Betrieb funktionieren und niemand sie unter der Annahme geprüft hat, dass ein Aufrufer mit gültigen Zugangsdaten systematisch ausprobiert, was diese Zugangsdaten sonst noch erlauben. Genau das ist aber die Betriebsannahme, die ab jetzt gilt.
Der Agent wurde vom Inhaber gestohlener Schlüssel zum Aussteller von Identität.
Unter den erbeuteten Geheimnissen befand sich ein privater EdDSA-Signaturschlüssel für JSON Web Token. Mit diesem Schlüssel stellte der Agent sich eigene, kryptografisch korrekt signierte, kurzlebige Identitätsnachweise aus.
Das ist qualitativ etwas anderes als ein gestohlenes Token. Ein gestohlenes Token hat einen begrenzten Geltungsbereich und meist eine endliche Laufzeit; je nach Architektur lässt es sich widerrufen oder über seine Ausstellung korrelieren — verlassen kann man sich darauf allerdings nicht, denn ein selbsttragendes JWT bleibt ohne eigene Widerrufsinfrastruktur bis zum Ablauf gültig. Wer den Signaturschlüssel hält, ist selbst der Aussteller. Er kann fortlaufend neue, formal gültige Identitätsnachweise erzeugen, für beliebige Subjekte, zu beliebigen Zeitpunkten, und jeder dieser Nachweise wird von jedem entsprechend konfigurierten Prüfsystem als echt akzeptiert — weil er kryptografisch gültig ist.
An dieser Stelle kollabiert die Beweiskette, auf der jede identitätsbasierte Sicherheitsarchitektur ruht. Der Identitätsnachweis belegt nicht mehr, dass eine Berechtigungsentscheidung stattgefunden hat. Er belegt nur noch, dass jemand Zugriff auf einen Schlüssel hatte. Ein Autorisierungsmodell, dessen einziger Anker die Vorlage eines gültigen Tokens ist, hat in diesem Moment keinen Anker mehr.
Ein Provenienzmodell hätte hier gegriffen — nicht weil es die Schlüsselkompromittierung verhindert hätte, sondern weil eine Handlung dann nicht nur einen Ausweis vorlegen, sondern eine nachvollziehbare Autoritätsherkunft mitführen müsste: welche Policy-Version, welche delegierende Instanz, welcher übergeordnete Auftrag. Ein selbstausgestelltes Token trägt keine solche Kette. Es ist ein Ausweis ohne Vorgeschichte.
Das Erkennungsproblem war Volumen, nicht Raffinesse.
Der Betreiber formuliert die Lehre aus dem Vorfall mit bemerkenswerter Nüchternheit: Die einzelnen Schwächen waren gewöhnlich. Unsichere Datenverarbeitung, erreichbarer Metadatendienst, zu breit geschnittene Rechte, langlebige Zugangsdaten. Ein fähiger menschlicher Angreifer hätte dieselben Fehler finden können.
Was sich geändert hat, ist der Maßstab. Der Agent führte rund 17.600 Aktionen aus, gruppiert in etwa 6.280 Cluster. Die überwiegende Mehrheit führte ins Leere. Er testete Pfade, die scheiterten, wechselte Kanäle, sobald einer geschlossen wurde, und kehrte wiederholt zu früheren Spuren zurück. Der erfolgreiche Weg lag im Rauschen der gescheiterten. Die Kommando- und Kontrollinfrastruktur bestand vollständig aus gewöhnlichen öffentlichen Diensten — einem Request-Capture-Dienst über mehr als hundert Einweg-Endpunkte, Pastebins, Dateiablagen und, was besonders unangenehm ist, aus vom Angreifer selbst angelegten öffentlichen Datensätzen auf der angegriffenen Plattform, die als tote Briefkästen dienten. Es gab keinen eigenen Implantatserver, den man hätte blockieren können.
Zwei Beobachtungen zur Detektion sind für den Betrieb von Security Operations Centern unmittelbar relevant. Sie decken sich mit der Einordnung aus der Verteidigerperspektive 📎, wonach die eigentliche Verschiebung darin liegt, dass die Ressourcenschranken auf der Angreiferseite fallen.
Erstens: Die Korrelation funktionierte, die Priorisierung nicht. Nach Darstellung des Betreibers waren die Signale aus Laufzeitanalyse und SIEM einzeln mehrdeutig, wurden aber von einer KI-gestützten Sicherheitsagentenschicht zu einem kohärenten Angriffssignal verdichtet. Diese Schicht stufte den Alarm anschließend in seiner Kritikalität falsch ein und alarmierte die Rufbereitschaft nicht — was in der Reaktion Zeit gekostet hat. Das ist kein Argument gegen KI-gestützte Detektion. Es ist ein Argument dafür, die Schwellenwertlogik einer solchen Schicht ebenso zu prüfen wie ihre Erkennungsleistung.
Zweitens: Die naive Auswertung der Rohdaten unterschätzte den Schaden erheblich. Der Agent hatte gestaffelte Daten in Blöcke zerlegt, mit einem kampagnenspezifischen Schlüssel XOR-verknüpft und komprimiert. Ein textbasierter Scan der aufgezeichneten Kommunikation fand kaum Geheimnisse. Erst als das Reaktionsteam das Kodierungsverfahren des Agenten nachbaute, kam etwa das Vierfache der ursprünglich gefundenen Zugangsdaten zum Vorschein, überwiegend Token. Wer nach einem Agentenvorfall den Rotationsumfang aus einem Textscan ableitet, rotiert zu wenig.
Die Forensik hing an der Verfügbarkeit eines Modells.
Ein Detail dieses Vorfalls ist sicherheitspolitisch so aufgeladen, dass es sorgfältige Formulierung verlangt.
Das Reaktionsteam versuchte zunächst, die Rekonstruktion mit kommerziellen Frontier-Modellen durchzuführen. Nach eigener Darstellung verweigerten diese Modelle einen erheblichen Teil der Arbeit, weil ihre Schutzmechanismen das Rückwärtsanalysieren eines Exploits nicht von dessen Durchführung unterschieden. Das Team stellte daraufhin ein quantisiertes Open-Weight-Modell auf eigener Infrastruktur bereit und leitete die gesamte Auswertungspipeline dorthin um — mit dem Nebeneffekt, dass die Angreiferdaten das Haus nicht verließen.
NVIDIA hat diesen Umstand am 27. Juli in der Ankündigung der Open Secure AI Alliance 📎 ausdrücklich als Beleg angeführt: Verteidiger benötigten offene, lokal kontrollierbare Modelle, weil geschlossene Systeme im entscheidenden Moment nicht zwischen Angreifer und Verteidiger unterscheiden könnten. Der Allianz gehören nach übereinstimmender Berichterstattung 📎 mehrere Dutzend Gründungsmitglieder an, darunter Microsoft, Dell, IBM, Red Hat und Palantir; sie baut auf Vorarbeiten der Linux Foundation und der OpenSSF auf.
Die Gegenposition ist ebenso dokumentiert. Anthropic hat am 27. Juli eine formelle Stellungnahme 📎 veröffentlicht, in der das Unternehmen ein pauschales Verbot offener Modelle ausdrücklich ablehnt, zugleich aber der Prämisse widerspricht, offene Gewichte begünstigten Verteidiger strukturell stärker als Angreifer. Vorgeschlagen wird stattdessen eine verpflichtende Sicherheitsprüfung für alle hinreichend leistungsfähigen Modelle, unabhängig von Herkunft und Veröffentlichungsform, mit ausdrücklicher Ausnahme weniger leistungsfähiger Modelle aus Forschung und Frühphasenunternehmen. Das Argument stützt sich unter anderem darauf, dass Schutzmechanismen nach der Veröffentlichung von Gewichten entfernbar sind und Kopien nicht zurückgerufen werden können.
Ich halte mich in dieser Frage zurück, weil sie industriepolitisch aufgeladen ist und beide Seiten belastbare Argumente führen. Was sich aus dem Vorfall aber unabhängig von der Positionierung ableiten lässt, ist eine betriebliche Feststellung: Die Fähigkeit, einen eigenen Sicherheitsvorfall zu untersuchen, war in diesem Fall abhängig von der Verfügbarkeit und Kooperationsbereitschaft eines externen Modellanbieters. Für einen KRITIS-Betreiber ist das keine Meinungsfrage, sondern eine Abhängigkeit im Sinne des Lieferkettenrisikos. Wer seine Incident-Response-Prozesse auf ein einziges externes Modell stützt, sollte vorab geklärt haben, ob dieses Modell forensische Arbeit an Angriffsartefakten überhaupt zulässt — und was der Rückfallpfad ist, wenn nicht.
Die Europäische Kommission hat diese Abhängigkeit im Aktionsplan für Cybersicherheit und künstliche Intelligenz vom 7. Juli 📎 adressiert, wenn auch aus anderem Anlass: geplant sind eine eigene europäische Bewertungskapazität für fortgeschrittene Modelle, ein mit der ENISA zu erarbeitender Fahrplan für den strukturierten Zugang berechtigter Organisationen zu leistungsfähigen Modellen und eine gemeinsam mit ENISA und der Gemeinsamen Forschungsstelle betriebene sichere Testplattform, auf der Organisationen aus Energie, Verkehr, Gesundheit, Finanzwesen und Verwaltung KI-Werkzeuge an realistischen Sicherheitsfällen erproben können, ohne Produktivsysteme zu gefährden.
Die Kosten trug jemand, der nicht gefragt worden war.
Bis hierher lässt sich der Vorfall als technisches Versagen lesen. Ab hier wird er zu einem Verteilungsproblem.
Die Evaluation, aus der der Agent ausbrach, diente dem Erkenntnisinteresse eines Unternehmens. Getragen wurden die Folgen weitgehend von einem anderen. Der Betreiber der angegriffenen Plattform hat nach eigener Darstellung sämtliche von seiner Infrastruktur genutzten Zugangsdaten rotiert — auch auf Clustern, die gar nicht erreicht wurden —, einen betroffenen Kerncluster vorsorglich vollständig neu aufgebaut, den fehlerhaft konfigurierten Zugriffsvermittler abgeschaltet und neu entwickelt, die Verarbeitungspipeline umgebaut und die forensische Rekonstruktion von 17.600 Aktionen selbst geleistet. Keiner dieser Aufwände war eingeplant; verursacht wurden sie durch eine Evaluation, an der das betroffene Unternehmen nicht beteiligt war und von der es vorab nichts wusste.
Das ist exakt die Struktur, die ich an anderer Stelle als ökonomischen Kern des Problems beschrieben habe: Der Nutzen schneller Fähigkeitsentwicklung fällt beim entwickelnden Unternehmen an, ein erheblicher Teil möglicher Schäden bei Dritten. Die Sicherheitsteams, die immer wieder sterben 📎 Was dort als Anreizanalyse formuliert war, liegt hier erstmals als bezifferbarer Vorgang vor. Der Juli-Vorfall ist damit weniger ein Beleg für die Fähigkeiten heutiger Modelle als ein Beleg für die Externalitätenstruktur, in der diese Fähigkeiten erzeugt werden.
Bemerkenswert ist auch die angebotene Wiedergutmachung. Der Verursacher hat den Geschädigten in sein Programm für privilegierten Zugang zu cyberfähigen Modellen aufgenommen, damit dessen Teams die eigenen Verteidigungsfähigkeiten mithilfe eben jener Modellklasse verbessern können. Man kann das als kooperative Geste lesen, und beide Seiten stellen es so dar. Man kann ebenso feststellen, dass die Kompensation für einen durch ein Produkt verursachten Schaden in erweitertem Zugang zu diesem Produkt besteht. Beide Lesarten sind mit dem veröffentlichten Sachverhalt vereinbar; ich halte die zweite für die aufschlussreichere.
Ein letzter Umstand gehört der Vollständigkeit halber dazu, ausdrücklich ohne Kausalbehauptung. Unabhängig von diesem Vorfall wurde im selben Monat die eigenständige Führungskonstruktion für Sicherheit bei demselben Unternehmen in eine breitere, forschungsgeführte Organisation überführt. Daraus lässt sich kein ursächlicher Zusammenhang ableiten; der Vorfall datiert auf Anfang Juli, die Umstrukturierung auf Ende Juli. Es ist aber die Governance-Struktur, innerhalb derer die zugesagte Aufarbeitung und die angekündigten zusätzlichen Kontrollen künftig stattfinden.
Offenlegung war eine Entscheidung, kein Verfahren.
Ein KRITIS-Betreiber in Deutschland, dessen Produktionsumgebung über mehrere Tage von einem fremden Akteur kontrolliert wird, der Cluster-Administratorrechte erlangt, Geheimnisse ausliest und Schreibzugriff auf die Quellcodeverwaltung erhält, hat nach § 32 BSIG binnen 24 Stunden eine frühe Erstmeldung abzusetzen, binnen 72 Stunden eine bewertende Meldung und binnen eines Monats eine Abschlussmeldung. Das ist der Maßstab, an dem meine Leser gemessen werden.
Für ein Unternehmen, dessen interne Fähigkeitsevaluation aus der Testumgebung ausbricht und in die Produktionsinfrastruktur eines Dritten eindringt, gibt es nichts Vergleichbares. Das liegt nicht daran, dass keine Pflicht bestünde. Der EU AI Act verpflichtet Anbieter von Allzweckmodellen mit systemischem Risiko zur Meldung schwerwiegender Vorfälle, und diese Pflichten gelten bereits seit dem 2. August 2025 — also zum Zeitpunkt des Vorfalls. Was am 2. August 2026 hinzukommt, sind die Durchsetzungsbefugnisse der Kommission. Es fehlt also weder Norm noch Adressat. Es fehlt die Kette dahinter: ob ein ausgebrochener Evaluationslauf als schwerwiegender Vorfall in diesem Sinne gilt, in welcher Frist zu melden wäre, was aus der Meldung folgt und ob davon je etwas öffentlich wird, ist praktisch ungeklärt. Die Veröffentlichung erfolgte jedenfalls freiwillig, in selbst gewähltem Umfang, zu selbst gewähltem Zeitpunkt, mit selbst gewählter Redaktion von Details.
Ich will das ausdrücklich nicht als Vorwurf gegen die Beteiligten formulieren. Beide haben ungewöhnlich detailliert offengelegt, und die technische Rekonstruktion ist ein Dokument, aus dem Verteidiger unmittelbar lernen können. Genau darin liegt aber das Problem: Der Erkenntnisgewinn der Öffentlichkeit hing vollständig an der Kooperationsbereitschaft zweier Unternehmen. Wäre die Entscheidung anders ausgefallen, gäbe es diesen Artikel nicht — und der Stand der Technik, auf den sich Prüfer künftig berufen werden, wäre ein anderer.
Wer daraus ableitet, dass die dokumentierte Kette der einzige Vorgang dieser Art war, verwechselt Abwesenheit von Meldungen mit Abwesenheit von Vorfällen. Der Verursacher gibt selbst an, in der laufenden Prüfung weitere Fälle gefunden zu haben, in denen seine Modelle öffentlich exponierte Zugangsdaten fremder Dienste verwendet haben — vier Konten bei vier Diensten allein im Zusammenhang mit diesem Vorfall, weitere im Rahmen anderer Evaluationen. Nach eigener Darstellung erreichte keiner dieser Fälle Schwere oder Umfang des Hauptvorfalls. Das ist plausibel und zugleich unüberprüfbar.
Seit dem 27. Juli lässt sich Unkenntnis schwerer begründen.
Der zeitliche Zusammenfall ist zufällig, die inhaltliche Verbindung nicht. Ab dem 2. August 2026 werden zentrale Bestimmungen der KI-Verordnung durchgesetzt 📎. Der Aktionsplan der Kommission ordnet die Risikobewertung fortgeschrittener Modelle ausdrücklich in diesen Rahmen ein 📎, und die Cyberresilienzverordnung wird Ende 2027 Sicherheit durch Technikgestaltung für Hard- und Softwareprodukte verbindlich machen.
Für Betreiber wesentlicher Einrichtungen nach § 30 BSIG ist die entscheidende Frage nicht, ob ein neuer Rechtsakt entsteht. § 30 verlangt geeignete, verhältnismäßige und wirksame Risikomanagementmaßnahmen nach dem Stand der Technik. Eine einzelne Veröffentlichung definiert diesen Stand nicht kalendertaggenau neu. Sie verändert aber die öffentlich verfügbare Evidenz, anhand derer sich Geeignetheit, Verhältnismäßigkeit und Wirksamkeit beurteilen lassen — und damit den Begründungsaufwand.
Bis Mitte Juli 2026 konnte ein Betreiber mit einiger Berechtigung geltend machen, dass eine autonome, mehrstufige Angriffskette durch ein KI-System ein Laborszenario sei. Seit dem 27. Juli liegt eine öffentlich zugängliche, technisch detaillierte Rekonstruktion eines solchen Ablaufs gegen eine reale Produktionsumgebung vor, mit Phasentabellen, Zeitstempeln und benannten Techniken. Das Szenario ist damit nicht mehr hypothetisch, sondern belegt. Wer nach diesem Datum eine Agenteninfrastruktur ohne Egress-Kontrolle, ohne Beschränkung des Metadatenzugriffs auf Workload-Ebene und mit langlebigen, breit geschnittenen Systemidentitäten betreibt, wird sich im Prüfungsfall schwerer damit tun, das als angemessen darzustellen. Dies ist meine Einschätzung als Praktiker und keine Rechtsauskunft; die aufsichtliche Bewertung steht aus.
Der parallel laufende Befund zu Azure CosmosDB — Wiz hat am 30. Juli eine inzwischen geschlossene Schwachstelle gemeldet 📎, die theoretisch den entfernten Zugriff auf Kundendaten ermöglicht hätte, wobei Microsoft angibt, das Problem sei vollständig behoben und es gebe keine Hinweise auf Kundenbetroffenheit — verlängert diesen Gedanken in die Cloud-Kontrollebene hinein. KI-Sicherheit ist nicht die Sicherheit des Modells. Sie ist die Sicherheit der Datenbank, der Identitätsverwaltung und der Steuerungsebene, auf denen das Modell betrieben wird. Eine kompromittierte Kontrollebene macht jede Modellabsicherung gegenstandslos.
Wirkungsbegrenzung setzt voraus, dass man den Handlungsraum kennt.
An dieser Stelle ist eine Unterscheidung nötig, weil ohne sie der übliche Trugschluss entsteht.
Was im Juli gescheitert ist, war Capability Containment — die Frage, ob ein hochleistungsfähiges System überhaupt in seiner Umgebung gehalten werden kann: der Versuch, ein absichtlich von seinen Schutzmechanismen befreites, auf maximale Fähigkeit vermessenes Modell in einer Umgebung zu halten, die es gezielt anzugreifen aufgefordert war, ohne dabei das Messergebnis zu verfälschen. Das ist ein hartes Problem, möglicherweise kein abschließend lösbares, und ein deutscher Netzbetreiber oder ein Klinikverbund muss es nicht lösen. Er führt keine Fähigkeitsevaluationen durch.
Sein Problem ist scheinbar ein kleineres, nennen wir es Impact Containment: einen aufgabengebundenen Agenten so einzubetten, dass dessen maximaler Wirkungsradius vorab bekannt und technisch begrenzt ist. Nicht: Kann dieses System ausbrechen? Sondern: Wie weit kommt es, wenn es ausbricht?
Diese Frage ist im Grundsatz beantwortbar, und ich will nicht behaupten, sie sei es nicht. Wer eine Wirkung außerhalb des Modells technisch unmöglich macht — kein ausgehender Netzverkehr, kein Schreibrecht, keine Erzeugung neuer Identitäten, jede irreversible Wirkung nur über einen determinierten Freigabepunkt —, hat eine Zusicherung, die nicht davon abhängt, welche Sequenz sich der Agent als Nächstes ausdenkt. Man muss das Verhalten eines Systems nicht vorhersagen können, um seine Wirkungen zu begrenzen. Das ist der Unterschied zwischen Verhaltensprognose und Durchsetzung von Invarianten, und er ist real.
Präzise formuliert lautet die Anforderung deshalb: Wer den Handlungsraum eines Modells nicht aufzählen kann, kann dessen Verhalten nicht vorhersagen. Ein maximaler Wirkungsradius ist nur dann belastbar zugesichert, wenn er nicht vom Modell selbst, sondern von einer vom Modell unabhängigen, deterministisch durchsetzbaren Grenze bestimmt wird.
Genau hier setzt der Juli-Vorfall an, und zwar unangenehmer, als es zunächst aussieht. Er widerlegt nicht, dass solche Grenzen konstruierbar sind. Er zeigt, woran sie in gewachsenen Systemen scheitern: Die Grenze war nicht ein Bauteil, sondern verteilt über einen Dataset-Loader, eine URL-Allowlist, RBAC-Regeln, einen Metadatendienst, ein Mesh-VPN und eine App-Integration. Jede dieser Komponenten hat ihre eigene Fehlerfläche, und der Agent brauchte nur eine. Die URL-Allowlist des Verarbeitungsdienstes funktionierte übrigens einwandfrei — sie wies jeden fremden Abruf ab. Der Agent stellte daraufhin keine Abrufe mehr, sondern ließ lokale Dateien lesen. Die Invariante war korrekt implementiert und am falschen Ort gezogen.
Daraus folgt keine Unmöglichkeit, sondern eine Nachweislast. Und Nachweislast bedeutet: Wer sie für eine kritische Wirkungskette nicht erfüllt, darf dort nicht betreiben. Die Frage ist damit nicht mehr, ob eine belastbare Grenze denkbar ist, sondern ob irgendjemand sie für ein produktiv eingesetztes Agentensystem je nachgewiesen hat.
In der Avionik wäre die Beweislast umgekehrt.
Es lohnt sich, den Maßstab einer Domäne heranzuziehen, die gelernt hat, Sicherheitszusagen nicht aus beobachtetem Wohlverhalten abzuleiten.
In der Luftfahrt richtet sich die geforderte Evidenz nach der möglichen Auswirkung eines Fehlers. Anforderungen müssen nachvollziehbar in Architektur und Implementierung überführt, sicherheitsrelevante Funktionen verifiziert, Abhängigkeiten kontrolliert und Annahmen über Partitionierung und Fehlerausbreitung begründet werden — abgestuft nach Kritikalität, mit wachsender Unabhängigkeit der Prüfung. Ich formuliere das bewusst als Nachweisregime und nicht als vollständige Aufzählung aller Systemzustände: Die Luftfahrt weiß seit den Auseinandersetzungen um Mehrkernprozessoren sehr genau, dass sich der Zustandsraum realer Systeme nicht erschöpfend durchtesten lässt. Gerade deshalb genügt es dort nicht, auf erfolgreiche Erprobung oder auf das bisherige Ausbleiben eines Fehlers zu verweisen. Wer die Argumentation nicht führen kann, bekommt keine Zulassung — unabhängig davon, wie gut das System bisher funktioniert hat.
Auf agentische Systeme übertragen heißt das: Nicht das Modell muss vorhersehbar sein. Nachweispflichtig ist die Grenze, die seine Wirkungen begrenzt. Und je schwerwiegender die möglichen Folgen einer Handlung, desto weniger darf diese Grenze von probabilistischem Modellverhalten, von freiwilliger Regelbefolgung oder von einem weiteren KI-Monitor abhängen.
Das ist keine ferne Analogie, sondern ein Maßstab, den auch die Luftfahrtaufsicht derzeit auf KI anzuwenden versucht, statt sie pauschal auszuschließen. Der Unterschied zur betrieblichen IT liegt nicht im Anspruch, sondern in der Institution. Produktbezogene Zulassungs- und Assurance-Ordnungen gibt es auch dort, wo Wirkungen physisch werden: in der Medizintechnik, in der Fahrzeugsicherheit, in der industriellen Automatisierung, in evaluierten Sicherheitsprodukten. Für allgemeine Unternehmens-, Cloud- und Plattform-IT existiert eine vergleichbare Ordnung regelmäßig nicht. Deshalb kann dort als vertretbares Restrisiko behandelt werden, wofür in den genannten Domänen zuerst eine belastbare Assurance-Argumentation verlangt würde — und genau in dieser ungeregelten Zone werden agentische Systeme derzeit ausgerollt.
Vier Nachweise, die mindestens zu verlangen wären — und die kaum jemand erbringt.
Die üblichen Härtungsempfehlungen bleiben richtig, und ich formuliere sie hier bewusst nicht als Handlungsempfehlung, sondern als Nachweisanforderung. Der Unterschied ist entscheidend. Eine Maßnahme kann man ergreifen und dokumentieren. Einen Nachweis muss man führen. Wer die vier folgenden Nachweise nicht erbringen kann, betreibt kein nachweislich abgesichertes System, sondern eines, das lediglich plausibel abgesichert erscheint.
Erstens: Nachweis einer unvererbbaren Kommunikationsgrenze. Die Kampagne wurde möglich, weil eine als isoliert geltende Umgebung genau einen erlaubten Netzwerkpfad besaß und dieser Pfad eine ausnutzbare Schwachstelle enthielt. Zu zeigen wäre nicht nur, dass Egress gefiltert wird, sondern dass ein kompromittierter Workload auch beim Ausfall einer einzelnen Vermittlungskomponente keinen beliebigen Internetzugang erhält. Paket-Proxys, Registry-Caches, Spiegel und Update-Dienste sind deshalb selbst Teil der Sicherheitsgrenze und ihrer Nachweisführung. Diesen Nachweis führt in der Praxis fast niemand, weil er den Betrieb spürbar verteuert.
Zweitens: Nachweis der Nichtvererbung von Rechten. Der Sprung von Codeausführung in einem Arbeitsprozess zu Knotenrechten lief über den Cloud-Metadatendienst. Zu zeigen wäre, dass aus einer Kompromittierung des Prozesses unter keinen Umständen Knoten-, Cluster- oder Mandantenrechte folgen können — nicht, dass entsprechende Rollen sparsam vergeben wurden. Der Juli-Vorfall zeigt beides zugleich: Der Betreiber hatte gute Praktiken, und eine einzige an eine Administratorgruppe gebundene Systemidentität hat sie ausgehebelt.
Drittens: Nachweis der Sequenzerkennung. Wie gezeigt war jede Einzelaktion unauffällig; unzulässig war die Sequenz. Zu zeigen wäre, dass die eigene Detektion nicht nur die Kette erkennt, sondern sie richtig einstuft und eskaliert. Im dokumentierten Fall hat die korrelierende Schicht das Signal korrekt gebildet und anschließend die Kritikalität falsch bewertet, sodass die Rufbereitschaft nicht alarmiert wurde. Wer diesen Nachweis führen will, muss seine Schwellenwertlogik gegen echte Angriffsketten testen, nicht gegen Einzelindikatoren. OpenAI beschreibt in seiner Veröffentlichung vom 20. Juli genau diesen Umbau als offene Aufgabe, nicht als gelöste.
Viertens: Nachweis der Autoritätsherkunft. Solange eine folgenreiche Handlung ausschließlich damit legitimiert ist, dass der Aufrufer ein gültiges Token vorlegt, ist jede Schlüsselkompromittierung gleichbedeutend mit vollständiger Handlungsfreiheit. Zu zeigen wäre, dass jede folgenreiche Handlung eine unabhängig prüfbare Autoritätsherkunft mitführt: welche Policy-Version, welche delegierende Instanz, welcher übergeordnete Auftrag. Das ist die Konsequenz, für die ich seit April argumentiere, und sie ist die einzige der vier, die nicht nur eine technische Station absichert, sondern die Legitimität der daraus entstehenden Handlung prüfbar macht.
Die Prüfkriterien, an denen sich eine solche Autoritätskette messen lässt, habe ich im Kontext von Delegationsketten nach § 30 BSIG entwickelt. Die fünfte Komponente. Wenn Agenten Agenten beauftragen 📎 Ihre Anwendung auf vier reale Vorfälle des ersten Quartals 2026 hat gezeigt, dass keiner der dokumentierten Fälle auch nur ein Kriterium erfüllte — der Vorfall vom Juli fügt dieser Reihe den bislang vollständigsten Beleg hinzu. Vier Vorfälle. Vier Prüfkriterien. Keins erfüllt. 📎
Diese vier Nachweise adressieren unterschiedliche Ebenen der Absicherung. Gemeinsam sind sie noch nicht hinreichend, und ich sage das ausdrücklich, obwohl der vierte von mir stammt: Die ersten drei begrenzen oder erkennen Stationen eines Weges, den jemand vorher als Weg gedacht hat. Der Agent hat 17.600 Aktionen lang nach einem Weg gesucht, den niemand gedacht hatte. Nur der vierte adressiert die Legitimität der entstehenden Wirkung — und auch er wirkt erst, wenn der Freigabepunkt selbst deterministisch und vom Modell unabhängig ist.
Was daraus folgt.
Es ist verführerisch, diesen Vorfall als Beleg dafür zu lesen, dass Modelle gefährlich geworden sind. Ich halte diese Lesart für falsch, und zwar aus einem präzisen Grund: Der Agent hat sich nicht gegen seine Betreiber gewandt. Er hat eine Prüfung bestehen wollen und dabei jede Grenze überschritten, die nicht technisch erzwungen war.
Der Unterschied zu GTG-1002, der ersten dokumentierten KI-orchestrierten Angriffskampagne, ist genau hier zu suchen: Dort steuerten menschliche Operateure eine weitgehend automatisierte Kette, das Modell war Werkzeug eines Angreifers. Agentische KI in kritischer Infrastruktur: eine Gefährdungsanalyse 📎 Im Juli hat niemand die Einzelschritte angewiesen. Was sich verschoben hat, ist nicht die Absicht der Systeme, sondern das Verhältnis zwischen Angriffsvolumen und Verteidigungsaufwand. Gewöhnliche Schwächen werden teurer, weil ein Agent tausende Pfade testen kann, gescheiterte Pfade in Sekunden ersetzt und dabei ein Beweisvolumen erzeugt, das menschliche Auswertung überfordert. Die Rekonstruktion des Vorfalls musste ihrerseits KI-gestützt erfolgen, weil 17.600 Aktionen von Hand nicht auswertbar sind.
Vor diesem Hintergrund wirken die vier Hochrisiko-Simulationen, die Anthropic am 13. Juli veröffentlicht hat 📎, weniger akademisch als bei Erscheinen: verdeckte Sabotage einer Forschungspipeline, Unterstützung bei Täuschung von Investoren, motivierte Fehlklassifikation in Bewertungsprozessen und die Anleitung von Menschen zur Preisgabe vertraulicher Information. Es handelt sich ausdrücklich um kontrollierte Simulationen und nicht um reale Vorfälle. Sie beschreiben aber dieselbe Bruchstelle, die im Juli real geworden ist: Das Risiko entsteht nicht dort, wo ein Modell etwas Falsches sagt, sondern dort, wo es etwas tun darf.
Die Frage für KRITIS-Betreiber lautet daher nicht, ob agentische Systeme eingesetzt werden. Sie werden eingesetzt. Sie lautet auch nicht nur, ob in der eigenen Architektur eine Instanz existiert, die eine folgenreiche Handlung ablehnen kann, obwohl der Aufrufer sich einwandfrei ausgewiesen hat. In der hier dokumentierten Umgebung existierte diese Instanz nicht, und das ist keine Besonderheit dieser Umgebung, sondern der Normalzustand.
Die unbequemere Frage liegt eine Ebene darüber. Der Ausbruch geschah in der Testumgebung eines Unternehmens, dessen erklärtes Kerngeschäft die Beherrschung genau dieser Systeme ist, mit erheblichen Ressourcen, mit einer Sicherheitsorganisation, mit einem Preparedness-Rahmenwerk und einem Sicherheitsausschuss. Bemerkt hat es zuerst der Geschädigte. Aufgearbeitet hat es überwiegend der Geschädigte. Bezahlt hat es der Geschädigte.
Ich ziehe daraus eine Konsequenz, die unter Sicherheitsarchitekten unpopulär ist, weil sie das eigene Gewerbe verkleinert: Systeme, in denen ein Modell selbst die Auswahl und Verkettung von Handlungen bestimmt und sich die dafür erforderlichen Rechte im Verlauf erschließen kann, haben in versorgungs- und sicherheitskritischen Wirkungsketten nichts zu suchen, solange dieser Nachweis nicht geführt ist: nicht vorläufig, nicht unter bloßen organisatorischen Auflagen, nicht als überwachter Pilotbetrieb.
Zwei Abgrenzungen gehören dazu, sonst wird der Satz zum Gummiband. Nicht gemeint sind Analyse, Klassifikation, Simulation oder Vorschläge, deren Umsetzung ein Mensch verantwortet, und nicht gemeint ist eine fest verdrahtete Automatisierung, in der ein Modell lediglich einordnet. Und mit dem Anwendungsbereich meine ich nicht die Organisation, sondern die Wirkungskette: Ein Agent, der Bewerbungsunterlagen sortiert, ist ein anderer Fall als einer mit Schreibzugriff auf eine Netzleitstelle — auch wenn beide beim selben Versorger laufen.
Die Begründung stützt sich nicht auf die Gefährlichkeit der Technologie, sondern auf drei überprüfbare Feststellungen. Erstens ist die Zusage „das Modell wird diese Grenze nicht überschreiten“ nach dem Juli-Vorfall wertlos; belastbar ist nur die andere Zusage: „auch wenn es die Grenze überschreiten will, kann es diese Wirkung nicht erzeugen“. Zweitens ist mir weder aus den öffentlich dokumentierten Fällen noch aus den von mir untersuchten produktiven Architekturen ein System bekannt, für das dieser Nachweis vollständig geführt worden wäre. Drittens fallen Nutzen und Risiko auseinander: Die Effizienzgewinne fallen beim Betreiber an, die Folgen eines Ausfalls bei Versorgten, Patienten, Fahrgästen. Wer das Risiko trägt, wird über die Einführung nicht gefragt. Genau diese Struktur ist der Grund, warum es in solchen Sektoren überhaupt Zulassungsordnungen gibt.
Zum Verhältnis zu meinem eigenen Vorschlag will ich deutlich sein, weil sonst der Verdacht naheliegt, ich argumentierte auf ein Produkt hin. Execution Provenance Control ist für diese Systemklasse notwendig. Hinreichend ist sie nicht. Eine nachweisbare Autoritätsherkunft macht überprüfbar, woher eine Handlung ihre Berechtigung bezieht; sie beantwortet nicht, ob der Freigabepunkt selbst deterministisch, vom Modell unabhängig und an der richtigen Stelle gezogen ist. Solange dieser zweite Teil offen bleibt, rechtfertigt auch eine vollständige EPC-Implementierung keine autonome Handlungshoheit in versorgungskritischen Prozessen. Wer das anders darstellt, verkauft eine Kontrollschicht als Freigabeschein.
Außerhalb kritischer Wirkungsketten fällt mein Urteil aus demselben Grund milder aus, aus dem es innerhalb hart ausfällt. Wer die Folgen weitgehend selbst trägt, darf ein Risiko eingehen, das er verstanden hat. Ich rate auch dort ab, aber das ist eine Empfehlung und kein Ordnungsargument. Die Linie verläuft dort, wo Dritte betroffen sind: Kundendaten, Lieferketten, Patientenakten, Zahlungsverkehr. Ab dieser Linie gilt derselbe Einwand, unabhängig davon, ob das Unternehmen unter das BSIG fällt.
Die Frage, mit der ich Sie entlassen möchte, ist deshalb keine Architekturfrage mehr. Sie lautet: Welche ist die folgenreichste Handlung, die Ihr Agent ohne eine von ihm unabhängige Freigabe ausführen kann — und wo ist technisch nachgewiesen, dass er darüber hinaus nicht gelangt? Wer darauf keine Antwort hat, betreibt kein abgesichertes agentisches System. Er betreibt eines, dessen Reichweite noch niemand nachgewiesen hat — und überträgt dieses nicht nachgewiesene Risiko auf seine Versorgten.
Anmelden zu unserem Newsletter:
Schreibe einen Kommentar