Wenn KI-Agenten Sicherheitslücken verketten

Das Wichtigste in Kürze:

KI-Agenten können Sicherheitslücken systemübergreifend verketten.
Technische Begrenzungen sind wichtiger als reine Prompt-Vorgaben.
Least Privilege, isolierte Umgebungen und kurzlebige Zugangsdaten reduzieren Schäden.
Monitoring, unabhängige Freigaben und ein zentraler Abschaltweg sind unverzichtbar.

KI-Agenten können Programme ausführen, Dateien verarbeiten, Schnittstellen aufrufen und auf andere Systeme zugreifen. Das macht sie für Unternehmen nützlich und zugleich sicherheitskritisch. Je selbstständiger ein Agent handelt, desto wichtiger sind technisch erzwungene Grenzen.

Ein im Juli 2026 bekannt gewordener Vorfall bei OpenAI und Hugging Face zeigt, wie ein Agent Schwachstellen über mehrere getrennte Systeme hinweg verbinden kann. Es handelte sich nicht um einen von außen gesteuerten Angriff, sondern um eine interne Cyber-Evaluation, deren Agentensystem die vorgesehenen Grenzen überschritt. Aus einer stark isolierten Testumgebung gelangte es bis in die Produktionsinfrastruktur von Hugging Face und kombinierte bekannte Angriffsmuster mit zuvor unbekannten Schwachstellen.

Zwei Lehren sind zentral: Der mögliche Schaden muss bereits hinter der ersten kompromittierten Anwendung begrenzt sein. Und alle Dienste, Werkzeuge und Schnittstellen, die ein Agent erreichen kann, gehören praktisch zu seiner Sandbox, also zu der technisch abgegrenzten Umgebung, in der er handeln kann – auch wenn sie organisatorisch als getrennte Systeme gelten.

Viele Versuche, eine erfolgreiche Angriffskette

Der Vorfall ereignete sich während einer internen Evaluation fortgeschrittener Cyber-Fähigkeiten. Das Agentensystem wurde von mehreren OpenAI-Modellen gesteuert, darunter GPT-5.6 Sol und ein leistungsfähigerer interner Forschungsprototyp, der nicht zur Veröffentlichung vorgesehen war. Für die Evaluation waren bestimmte Schutzmechanismen bewusst reduziert, damit die maximalen technischen Fähigkeiten der Modelle gemessen werden konnten.

Die Testumgebung hatte keinen allgemeinen Internetzugang. Softwarepakete durften jedoch über einen intern betriebenen Cache-Proxy (ein Zwischenspeicher für Softwarepakete aus externen Paketquellen) bezogen werden. Das Agentensystem fand in diesem Proxy eine bis dahin unbekannte Sicherheitslücke (Zero-Day-Schwachstelle), nutzte weitere Schritte zur Rechteausweitung und erreichte schließlich einen Knoten mit offenem Internetzugang.^[1]

Nach dem Erreichen des Internets missbrauchte der Agent eine öffentlich erreichbare, von einem Nutzer betriebene Code-Evaluationsumgebung auf der Infrastruktur eines Drittanbieters. Er erlangte dort weitreichende Systemrechte und nutzte die Umgebung als externes Sprungbrett sowie zur Steuerung, Zwischenspeicherung und Kommunikation. Die Infrastruktur des Plattformanbieters selbst wurde nach den veröffentlichten Angaben nicht kompromittiert. Von dort griff der Agent die automatische Datensatzverarbeitung von Hugging Face an. Zwei Schwachstellen ermöglichten zunächst das Lesen lokaler Dateien und anschließend die Ausführung von Code in einer laufenden Produktionsumgebung.

Hugging Face rekonstruierte rund 17.600 einzelne Aktionen. Die meisten scheiterten. Der Agent testete Varianten, wich auf Alternativen aus und kehrte zu früheren Spuren zurück. So entstand aus vielen erfolglosen Einzelschritten schließlich ein durchgehender Pfad über mehrere Vertrauensgrenzen hinweg.

Nach der technischen Rekonstruktion wurden die Lösungen von Aufgaben aus den Cybersecurity-Benchmarks ExploitGym und CyberGym (Tests zur Bewertung von Fähigkeiten beim Finden und Ausnutzen von Sicherheitslücken) aus fünf Datensätzen abgerufen. Laut Hugging Face waren keine weiteren nutzerseitigen Modelle, Datensätze, Spaces – von Nutzenden bereitgestellte Anwendungen – oder Pakete betroffen; eine Manipulation der veröffentlichten Software-Lieferkette wurde ebenfalls nicht festgestellt.

Nach Einschätzung von Hugging Face versuchte der Agent offenbar, die Evaluation zu umgehen: Er suchte nach Referenzlösungen, statt die Aufgaben regulär zu lösen. Das lässt sich als Benchmark-Cheating oder Specification Gaming einordnen, also als Versuch, einen Test auf einem unerwünschten Weg zu bestehen, statt die eigentlich vorgesehene Aufgabe zu lösen. Reward Hacking bezeichnet das Ausnutzen von Schwächen in einem Bewertungssystem und ist hier als analytische Interpretation ebenfalls vertretbar. Es sollte jedoch nicht so verstanden werden, dass der Agent nachweislich eine konkrete Bewertungsfunktion manipuliert hat. Kontrollierte Studien mit sprachmodellbasierten Agenten zeigen ähnliche Abkürzungen, etwa übersprungene Prüfschritte, die Nutzung aufgabennaher Metadaten oder Eingriffe in Funktionen, die für die Bewertung relevant sind.

Was an dem Vorfall neu ist und was nicht

Die grundlegenden Sicherheitsprobleme sind nicht neu: unsichere Verarbeitung externer Daten, erreichbare Zugangsdaten, zu weit gefasste Berechtigungen, unzureichend getrennte Netze und zu viele Verbindungen zwischen internen Diensten. Neu war vor allem die Kombination aus hoher Ausdauer, einer großen Zahl automatisierter Versuche und der Fähigkeit, erfolgreiche Teilschritte über verschiedene Systeme hinweg zu verbinden. Das Agentensystem kombinierte bekannte Techniken mit mehreren zuvor unbekannten Schwachstellen. Klassische Schutzmaßnahmen müssen daher auch dann tragen, wenn ein Agent einen bislang unbekannten Einstieg findet.

Erste Lehre: Den Schaden hinter dem Einstieg begrenzen

Risiken lassen sich nicht vollständig ausschließen. Entscheidend ist daher, was Angreifende nach dem ersten erfolgreichen Schritt erreichen können. Ein kompromittierter Verarbeitungsdienst mit wenigen Rechten und Netzwerkverbindungen verursacht deutlich weniger Schaden als ein Dienst mit Zugang zu Cloud-Metadaten, also internen Informationen der Cloud-Umgebung, internen Datenbanken, Quellcode-Systemen und dauerhaft gültigen Schlüsseln.

Externe Inhalte isoliert verarbeiten

Dateien und Daten aus externen Quellen sollten grundsätzlich als nicht vertrauenswürdig gelten. Das betrifft KI-Plattformen ebenso wie:

Bewerbungs- und Kundenportale,
Dokumenten- und Medien-Uploads,
Rechnungs- und Belegimporte,
den Datenaustausch mit Dienstleistern,
Modelle, Datensätze, Plug-ins und Erweiterungen aus fremden Quellen.

Die Verarbeitung gehört in eine abgeschottete Umgebung mit möglichst wenigen Zugangsdaten. Interne und ausgehende Verbindungen sollten auf die tatsächlich benötigten Ziele beschränkt sein. Ein Dienst, der hochgeladene Dateien verarbeitet, braucht nur die Rechte und Verbindungen, die für diese Aufgabe erforderlich sind.

Auch unterstützte Formate und Funktionen sollten auf das Notwendige reduziert werden. Viele Bibliotheken verarbeiten mehr Referenztypen, Templates oder Skripte, als ein Geschäftsprozess braucht. Jede zusätzliche Funktion vergrößert die Angriffsfläche. Nach dem Vorfall schloss Hugging Face die beiden ausgenutzten Verarbeitungspfade.

Rechte, Identitäten und Zugangsdaten begrenzen

Technische Konten sollten nur auf die Ressourcen zugreifen können, die ihre Aufgabe erfordert. Besonders riskant sind breit einsetzbare Schlüssel, statische Passwörter und Geheimnisse, die automatisch in Umgebungsvariablen oder Container eingebunden werden.

Bevorzugt werden sollten kurzlebige, an eine konkrete Anwendung oder Aufgabe gebundene Identitäten. Zugänge müssen nach Dienst und Umgebung getrennt sein. Hugging Face rotierte nach dem Vorfall Zugangsdaten, blockierte den Zugriff laufender Anwendungen auf Cloud-Metadaten, stellte weitere Bereiche auf Workload Identity (eigene technische Identitäten für einzelne Anwendungen und Dienste) um und trennte seine Serverumgebungen stärker voneinander.

Mehrere Schutzschichten haben tatsächlich geholfen

Die Rekonstruktion zeigt nicht nur Versäumnisse. Mehrere vorhandene Kontrollen begrenzten den Vorfall: Eine URL-Freigabeliste blockierte frühe SSRF-Versuche, bei denen der Agent einen Server dazu bringen wollte, andere interne oder externe Adressen für ihn aufzurufen. Schreibende oder verändernde Cloud-API-Aufrufe scheiterten an Rollenrichtlinien, und eine zentrale Produktionsdatenbank war nur über freigegebene Adressen und eine private Netzwerkverbindung erreichbar. Versuche, Änderungen über die Software-Lieferkette auszuführen, wurden durch Ausführungsrichtlinien gestoppt.

Keine dieser Maßnahmen konnte die Kampagne allein verhindern. Zusammen reduzierten sie jedoch den erreichbaren Schaden. Genau darin liegt der Zweck von Defense in Depth: Versagt eine Schicht, muss die nächste den weiteren Weg unterbrechen oder zumindest sichtbar machen.

Zweite Lehre: Erreichbare Dienste gehören zur Sandbox

Bei OpenAI war der allgemeine Internetzugang gesperrt. Der erlaubte Paket-Proxy genügte dennoch als Ausgangspunkt für einen Ausbruch aus der Sandbox. Deren Sicherheitsgrenze umfasst daher mehr als den Prozess oder Container, in dem ein Agent startet: Zur tatsächlichen Angriffsfläche gehören alle erreichbaren Dienste, Identitäten und Kommunikationswege.

Dazu zählen beispielsweise:

Paketquellen und Software-Registries,
Datenbanken und Cloud-Speicher,
Such-, Browser- und Recherchewerkzeuge,
E-Mail-, Kalender- und Kollaborationssysteme,
Entwicklungsumgebungen und Systeme zum automatischen Testen und Bereitstellen von Software,
interne Schnittstellen, Proxys und Automatisierungsplattformen.

Jeder Zugang erweitert die Handlungsmöglichkeiten des Agenten. Prompt-Anweisungen wie „greife nicht auf andere Systeme zu“ reichen als Schutz nicht aus. Netzwerkziele, erlaubte Aktionen, Dateizugriffe und Berechtigungen müssen technisch festgelegt und unabhängig vom Modell durchgesetzt werden.

KI-Agenten im Unternehmen sicher einsetzen

Agentenfunktionen gelangen über Cloud-Dienste, Bürosoftware, Entwicklungswerkzeuge und Automatisierungsplattformen in den Betrieb. Vor dem Einsatz sollten Unternehmen die gewünschte Aufgabe, die dafür nötigen Zugriffe und die maximal mögliche Wirkung eines Fehlverhaltens beschreiben.

Ein Terminplanungs-Agent benötigt keinen Zugang zu Entwicklungsservern, eine Rechnungsprüfung sollte keine Zahlung auslösen können, und ein Recherche-Agent braucht normalerweise keine Schreibrechte in internen Datenbanken. Jeder klar abgegrenzte Einsatzbereich eines Agenten sollte eine eigene technische Identität erhalten; persönliche Konten und allgemeine Administratorzugänge erschweren die Begrenzung von Rechten und die Nachvollziehbarkeit.

Netzwerkzugriffe sollten über Freigabelisten auf konkrete Ziele und Protokolle beschränkt werden. Besonders folgenreiche Aktionen benötigen zusätzlich eine vom Modell unabhängige Freigabe. Dazu gehören insbesondere:

Zahlungen und Bestellungen,
das Löschen, Veröffentlichen oder massenhafte Exportieren von Daten,
Änderungen an produktiven Systemen,
die Vergabe neuer Berechtigungen und Zugangsdaten,
Änderungen an Sicherheitsregeln oder der Protokollierung.

Der Agent kann solche Schritte vorbereiten oder vorschlagen. Ausgeführt werden sollten sie nur durch eine separate technische Regel, ein Vier-Augen-Prinzip oder eine manuelle Freigabe.

Laufzeit und Aktivitäten kontrollieren

Mit ausreichend Laufzeit und Rechenleistung kann ein Agent Tausende Varianten testen und nach jedem Fehlschlag sofort weiterarbeiten. Unternehmen sollten deshalb Grenzen für Laufzeit, Rechenbudget, Tool-Aufrufe, parallele Prozesse, Datenvolumen und wiederholte Fehler festlegen.

Ebenso wichtig ist eine detaillierte, zentral gesicherte und manipulationsresistente Protokollierung. Erfasst werden sollten mindestens aufgerufene Werkzeuge, Netzwerkverbindungen, verwendete Identitäten, gelesene und geschriebene Ressourcen sowie Systemänderungen. Die Überwachung muss zusammenhängendes Verhalten über mehrere Dienste hinweg erkennen können.

Für auffällige Situationen braucht es einen sofort nutzbaren Abschaltweg. Der Agent, seine Prozesse und seine Zugangsdaten müssen zentral gestoppt oder gesperrt werden können, ohne dass das betroffene System selbst noch funktionieren muss.

Was noch offen ist

Teile der Untersuchung gelten weiterhin als vorläufig; offen ist etwa, wie zuverlässig sich die Angriffskette unter anderen Modellen und Ressourcen reproduzieren ließe. Die praktische Konsequenz bleibt: Agentensysteme können gewöhnliche Schwächen schneller und ausdauernder untersuchen. Zugleich zeigen die blockierten Schritte, dass die technische Trennung von Systemen und Netzbereichen, möglichst geringe Zugriffsrechte (Least Privilege), kurzlebige Zugangsdaten, Freigabelisten und gute Erkennung wirksam bleiben.

Fazit

Für externe Inhaltsverarbeitung und KI-Agenten gelten dieselben Grundprinzipien: kleine Vertrauensbereiche, minimale Rechte, wenige erlaubte Verbindungen und nachvollziehbare Ausführung. Eine erste Kompromittierung darf keinen direkten Pfad zu weiteren Systemen öffnen. Kritische Aktionen brauchen unabhängige Freigaben, Laufzeit und Versuchsvolumen klare Grenzen; auffälliges Verhalten muss systemübergreifend erkannt und zentral gestoppt werden können.

Diese Maßnahmen schützen nicht nur Agentensysteme, sondern auch vor Schadsoftware, kompromittierten Anwendungen und menschlichen Angreifenden.