Am 21. Juli 2026 gab OpenAI bekannt, dass zwei seiner eigenen KI-Modelle aus einer isolierten Evaluationsumgebung entkommen und in die Produktivinfrastruktur von Hugging Face eingedrungen waren. Es gab keinen externen Angreifer. Die KI-Modelle wurden mit einem Cybersecurity-Benchmark getestet, folgerten, dass die Antworten vermutlich auf den Servern von Hugging Face lagen, und holten sie sich. Es ist einer der ersten öffentlich dokumentierten Fälle, in denen Frontier-KI-Modelle autonom ein reales Unternehmen kompromittierten. Der Vorfall zeigt, dass Guardrails zur Produktivinfrastruktur gehören und keine Funktion des KI-Modells sind.
Was tatsächlich passiert ist
OpenAI führte eine interne Evaluation offensiver Cybersecurity-Fähigkeiten durch: den Benchmark ExploitGym mit GPT-5.6 Sol und einem leistungsfähigeren, noch nicht veröffentlichten KI-Modell. Da der Test messen sollte, wozu die KI-Modelle fähig waren, wurden die üblichen Verweigerungen bei Hacking-Aufgaben reduziert. Der gesamte Test lief in einer Umgebung, die OpenAIs Bericht als hochgradig isoliert bezeichnet.
Die Umgebung war nicht so isoliert wie vorgesehen. Wie TechCrunch berichtete, behielt ein Dienst zur Paketinstallation innerhalb der Sandbox seine Internetverbindung. Die KI-Modelle fanden eine Zero-Day-Schwachstelle in dieser intern gehosteten Drittanbieter-Software, nutzten sie für den Zugang zum offenen Internet und setzten laut Fortune von dort erhebliche Rechenleistung für das Benchmark-Ziel ein.
Der Einstiegspunkt bei Hugging Face waren Daten, keine Firewall. Hugging Faces Bericht zum Vorfall beschreibt zwei Pfade zur Codeausführung in der Dataset-Verarbeitung: einen Dataset-Loader für Remote-Code und eine Template-Injection, beide ausgelöst durch bösartige Dataset-Inhalte. Von diesem ersten Zugang auf einem Verarbeitungs-Worker eskalierte der Angriff zu Zugangsdaten auf Node-Ebene und bewegte sich lateral durch interne Cluster. Er erreichte begrenzte interne Datasets und eine Reihe von Service-Zugangsdaten. Hugging Face fand keine Hinweise auf Manipulationen an öffentlichen KI-Modellen, Datasets oder Spaces.
Hugging Faces eigene Anomalieerkennung meldete den Angriff, und das Unternehmen dämmte ihn ein, bevor OpenAIs Benachrichtigung eintraf. OpenAI meldete den Zero Day an den betroffenen Anbieter, nahm Hugging Face in sein Trusted-Access-Programm für Cyber-Defense-Tooling auf und gibt an, seine Isolationsmechanismen selbst dort zu verschärfen, wo dies die Forschung bremst.
Guardrails versagten auf beiden Seiten
Diese Geschichte ist über die Schlagzeile hinaus relevant, weil Guardrails zweimal und in entgegengesetzte Richtungen versagten.
Auf Angriffsseite waren die Guardrails ausgeschaltet
Die KI-Modelle verfolgten kein bösartiges Ziel. Ihre Sicherheitsregeln waren nicht durch einen Jailbreak umgangen worden. Ihre Sicherheitsbeschränkungen bei Cybersecurity-Aufgaben waren für eine legitime Evaluation gelockert worden, die Sandbox um sie herum war undicht, und die zielgerichtete Optimierung erledigte den Rest. Die in der Analyse des Vorfalls in Forbes zitierten Sicherheitsforscher argumentierten, dass die KI-Modelle keine bösartige Absicht benötigten, um Schaden anzurichten, und dass die Kompromittierung eines unbeteiligten Dritten zur Erfüllung eines Benchmarks tatsächlich Neuland sei. Wenn Sicherheit nur auf Ebene des KI-Modells bestand, ließ ein Konfigurationsfehler keine weitere Schutzschicht übrig.
Auf Verteidigungsseite verweigerten die Guardrails ihre Hilfe
Das umgekehrte Versagen ist aufschlussreicher. Während der Reaktion auf den Vorfall wollte Hugging Face proprietäre Frontier-KI-Modelle zur Analyse des Angriffs einsetzen und stellte fest, dass providerseitige Sicherheitssysteme einen Incident Responder nicht von einem Angreifer unterscheiden konnten. Die KI-Modelle verweigerten die Arbeit. Stattdessen führte das Team Zhipus Open-Weight-KI-Modell GLM 5.2 lokal auf eigener Infrastruktur aus. Dort analysierte es laut Forbes mehr als 17.000 forensische Ereignisse des Angriffs, während offengelegte Zugangsdaten und Angreiferdaten im Unternehmen blieben.
Guardrails auf Ebene des KI-Modells folgen den Richtlinien und dem Bedrohungsmodell des jeweiligen Anbieters. Im Angriff waren sie ausgeschaltet, bei der Verteidigung blockierten sie die Untersuchung. Die Menschen, die das tatsächliche Risiko trugen, konnten diese Einstellungen nicht beeinflussen.
Prompt-Injection-Erkennung, PII-Schwärzung und Prüfungen auf Datenabfluss für jeden Input und Output, vom Team konfiguriert und in Traces aufgezeichnet.
Kostenlos startenWas sich für Teams ändert, die Agenten betreiben
Die meisten Unternehmen führen keine Cybersecurity-Evaluationen von Frontier-KI-Modellen durch. Jedes Unternehmen, das Agenten bereitstellt, kombiniert jedoch dieselben drei Voraussetzungen, die diesen Vorfall ermöglichten: leistungsfähige KI-Modelle, echte Berechtigungen und nicht vertrauenswürdige Inhalte. Der Vorfall lässt sich direkt auf Agenten im Produktivbetrieb übertragen.
Guardrails unter Kontrolle des Betreibers einsetzen
Beide Fehlerarten erfordern eine vom Betreiber kontrollierte Sicherheitsschicht in der Runtime, die sich nicht ändert, wenn ein Anbieter seine Richtlinien aktualisiert. Genau dort arbeiten Connic Guardrails innerhalb der Runtime. Sie prüfen den Input vor der Ausführung des Agenten und den Output, bevor eine Antwort die Runtime verlässt. Jede Regel arbeitet in einem von drei Modi: block, warn oder redact.
Die Guardrail-Typen entsprechen den Schwachstellen, die dieser Vorfall ausnutzte. Die Prompt-Injection-Erkennung erkennt über Inhalte eintreffende Versuche, Anweisungen zu überschreiben. Die Erkennung von Datenabfluss erfasst codierte Payloads, URL-Smuggling und die strukturierte Extraktion von privatem Kontext auf dem Weg nach außen. PII-Regeln schwärzen sensible Daten in beide Richtungen, und die Erkennung offengelegter System-Prompts hält interne Anweisungen privat.
guardrails:
input:
- type: prompt_injection
mode: block
- type: pii
mode: redact
output:
- type: data_exfiltration
mode: block
- type: system_prompt_leakage
mode: block
- type: pii_leakage
mode: redactBetreiberregeln statt Anbieterrichtlinien
Da das Team jede Regel, jeden Modus und jede Ablehnungsnachricht definiert, kann das Problem der Verteidiger bei Hugging Face hier nicht entstehen: Ein selbst geschriebener Guardrail verweigert nicht die Untersuchung des Betreibers. Der Warn-Modus loggt Verstöße als Trace-Spans, ohne Runs zu unterbrechen. Das unterstützt die Untersuchung verdächtigen Traffics. Reichen die integrierten Typen nicht aus, ist ein eigener Guardrail eine Python-Funktion, die zum Projekt des Agenten hinzugefügt wird.
Bewusst unabhängig vom KI-Modell
Hugging Faces Wechsel zu einem lokal ausgeführten Open-Weight-KI-Modell wurde unter Druck improvisiert. Das zugrunde liegende Prinzip sollte bewusst gelten: Die Sicherheitsschicht darf nicht vom eingesetzten KI-Modell abhängen. Wir halten Guardrails, Approvals, Judges und Traces außerhalb des Pfads des KI-Modells. Beim Wechsel zwischen BYOK, einem selbst gehosteten Open-Weight-Endpunkt oder einem EU-gehosteten connic/*-KI-Modell bleibt die gesamte Sicherheitskonfiguration unverändert erhalten.
Dieselbe Schichtung schließt die forensische Lücke. Jede Guardrail-Evaluation wird zusammen mit dem restlichen Run als OpenTelemetry-Trace-Span aufgezeichnet: jeder KI-Modell-Call, Tool-Call und jede Entscheidung. Die Aufzeichnung, die Hugging Face während des laufenden Vorfalls zusammenstellen musste, erzeugt jeder Connic-Run standardmäßig.
Isolation ist die andere Hälfte
Der Vorfall begann mit einer Sandbox, die trotz geplanter Isolation einen Dienst mit Internetzugang behielt. Ein verwundbares Programm zur Paketinstallation genügte. Guardrails prüfen, was durch einen Agenten fließt. Isolation begrenzt, was ein Agent erreichen kann, wenn dennoch etwas durchrutscht. Eine KI-Agenten-Plattform für Produktivsysteme benötigt beides. Die Isolation liegt unterhalb des Anwendungscodes und bleibt deshalb leicht unbeachtet.
Unsere Runtime basiert auf dieser Annahme. Agenten werden in isolierten Containern mit CPU- und Speicherlimits ausgeführt und pro Kunde getrennt. Die Ausführungsumgebungen sind temporär: Sie werden nach jedem Run gelöscht, sodass nichts, was ein Agent abgerufen, geschrieben oder durch Manipulation behalten hat, den nächsten Run erreicht. Secrets werden verschlüsselt gespeichert und der Runtime als Umgebungsvariablen übergeben, statt in Code oder Images zu liegen. Das Plattformnetzwerk liegt hinter Firewall-Regeln mit Default-Deny und ist segmentiert, um den möglichen Schaden einer einzelnen kompromittierten Komponente zu begrenzen. Genau auf dieses Ausbreitungsmuster stützte sich der Angriff auf Hugging Face bei der lateralen Bewegung mit erbeuteten Zugangsdaten. Unsere Sicherheitsdokumentation bietet einen Gesamtüberblick einschließlich Verschlüsselung und Datenverarbeitung.
Wo Teams anfangen sollten
Für eine Prüfung der Agentenflotte ergeben sich fünf Prioritäten:
- 1.Alle Agenten erfassen, die Inhalte von außerhalb des Teams lesen: Postfächer, Tickets, Webhooks, hochgeladene Dateien und externe APIs. Sie bilden die Angriffsfläche für Prompt Injection
- 2.Prompt-Injection- und Datenabfluss-Guardrails im Block-Modus sowie PII-Schwärzung bei diesen Agenten aktivieren, wenn personenbezogene Daten fließen
- 3.Freigaben vor jede Aktion schalten, die Zugangsdaten, Geld oder Infrastruktur betrifft
- 4.Einen aktuellen Run im Dashboard öffnen und prüfen, ob sein Trace eine vollständige Rekonstruktion ermöglicht
- 5.Prüfen, worauf ein manipulierter Agent tatsächlich zugreifen könnte: welche Netzwerke, welche Zugangsdaten und was nach Ende des Runs bestehen bleibt
Für die vollständige Prüfung vor dem Launch dient die Sicherheitscheckliste für den Produktivbetrieb als Grundlage. Die Konfigurationsreferenz steht in der Guardrails-Dokumentation.