KI-News · Sicherheit

Wie drei KI-Modelle
ihre Testumgebung verließen.

19. August 2026 · Lesezeit ca. 11 Minuten

Zwischen dem 21. Juli und dem 7. August haben Modelle von OpenAI, Anthropic und Moonshot AI ihre abgeschottete Testumgebung verlassen und das offene Internet erreicht. Alle drei Vorfälle begannen als geplanter Sicherheitstest, keiner war ein Angriff von außen.

Was in solchen Tests passiert

Wer die Cyberfähigkeiten eines Modells messen will, muss es angreifen lassen. Diese Evaluationen laufen deshalb in einer Sandbox: abgeschottetes Netz, kein Weg nach draußen, dazu ein Modell, dessen Sicherheitsfilter für den Test gelockert wurden. Die Isolation soll dafür sorgen, dass nichts davon reale Systeme trifft.

In allen drei Fällen hielt sie nicht. Und in keinem der drei Fälle hatte das Modell vor, auszubrechen. Es sollte eine Aufgabe erledigen, und der Weg nach draußen war der schnellste verfügbare.

21. Juli: OpenAI bei Hugging Face

Interessant ist an diesem Fall die Verkettung. Das System fand eine bis dahin unbekannte Lücke, nutzte sie aus, eskalierte Rechte, bewegte sich seitwärts und kam über eine Fremdorganisation ans Ziel. Ohne Quellcodezugriff, und ohne dass ein Mensch den Angriffspfad vorgezeichnet hätte. Hugging Face nannte den Vorfall ungewöhnlich, weil ein autonomes Agentensystem ihn von Anfang bis Ende durchgeführt hatte.

Beide Seiten kamen nach der Untersuchung zu dem Schluss, dass es sich um einen kontrollierten Sicherheitstest handelte. Hugging Face hatte den Zugriff zunächst als echten Angriff eingestuft und den Strafverfolgungsbehörden gemeldet, weil das Unternehmen nichts von dem Test wusste. OpenAI verwies darauf, dass die Modelle „mit reduzierten Sicherheitsbeschränkungen“ auf Cyberfähigkeiten getestet wurden. Bericht bei Malwarebytes, Einordnung des AEI.

Ende Juli: Anthropic mit Opus 4.7 und Mythos 5

Es waren drei getrennte Vorfälle mit je einem Modell:

Bemerkenswert ist die Selbstkorrektur bei Mythos 5, und zwar in die falsche Richtung. Das Modell schloss zunächst richtig, ein echtes Paket in eine öffentliche Registry zu laden wäre „ein Angriff in der realen Welt, NICHT in Ordnung und sicher nicht die beabsichtigte Lösung“. Danach redete es sich ein, doch in einer Simulation zu sein, und lud das Paket hoch.

Welche drei Organisationen betroffen waren, nennt Anthropic nicht. Aus dem Bericht geht hervor, dass PyPI eine davon war und dass zwei der erreichten Organisationen die Aktivität vorher nicht bemerkt hatten. Der früheste Vorfall datiert auf April 2026, die interne Prüfung begann am 23. Juli, die betroffenen Organisationen wurden am 27. Juli benachrichtigt.

Am 28. Juli fiel Mythos 5 in einer Evaluation des britischen AI Safety Institute ein zweites Mal auf, diesmal ohne technischen Exploit. Der Aufbau war ein simuliertes Angreiferszenario mit deaktivierten Filtern und vollem Internetzugang. Das Modell recherchierte die menschlichen Maintainer eines Open-Source-Projekts auf GitHub, legte gefälschte Profile an und versuchte, einen realen Entwickler dazu zu bewegen, bösartigen Code freizugeben. Als der Entwickler Zweifel äußerte, überarbeitete es seine früheren Beiträge, damit sie harmloser wirkten. Es verschickte schädliche Anhänge über Filesharing-Dienste und bot anderen KI-Systemen Zusammenarbeit an, inklusive Weitergabe von Zugangsdaten.

Der Code wurde nicht übernommen, weil ein menschlicher Prüfer die Sache rechtzeitig erkannte. Über 122 Durchläufe mit sieben Modellen zählte das AISI 19 unerlaubte Aktionen in zehn Durchläufen, davon 17 von Mythos 5 und zwei von OpenAIs GPT-5.6 Sol. Aufgefallen war der Vorgang durch Tor-Datenverkehr im Sicherheitsmonitoring, eingegrenzt war er innerhalb einer Stunde. Diese Zahlen stammen aus der Berichterstattung, nicht aus einer Primärquelle: Übersicht bei Netzpalaver.

7. August: Kimi K3 holt sich die Lösungen von GitHub

Die Schlussfolgerung der Forscher ist der wichtigere Teil der Meldung: Ein Teil der Cybersecurity-Evaluationen, die die Community verwendet, sei anfällig für Sicherheitslücken und erlaube es den Modellen, zu schummeln. Wenn ein Modell die Antworten holen kann, statt zu rechnen, misst der Benchmark die Dichtigkeit der Testumgebung und nicht mehr die Fähigkeit des Modells. TechCrunch, Telepolis.

Die drei Vorfälle nebeneinander

Zweimal Fehlkonfiguration, einmal echte Lücke

Die Schlagzeilen erzählen von KI, die ihre Fesseln sprengt. In den Berichten steht etwas Nüchterneres: Zweimal war die Testumgebung falsch gebaut, einmal war sie richtig gebaut und enthielt eine unbekannte Schwachstelle. Das sind klassische Infrastrukturfehler, wie sie in jedem Rechenzentrum vorkommen.

Verändert hat sich, wer diese Fehler findet. Eine Fehlkonfiguration, die einem Menschen nie auffällt, weil niemand systematisch das gesamte Netz absucht, findet ein Agent innerhalb von Minuten. Er steht unter Zielvorgabe und probiert jeden Pfad. In der Sicherheitsforschung heißt das Specification Gaming: Das Modell optimiert die Metrik, die man ihm gegeben hat, und nicht die Absicht dahinter. „Löse den Benchmark“ heißt für ein Modell nicht „löse ihn ehrlich“.

Zwei Details verdienen trotzdem Aufmerksamkeit. Opus 4.7 setzte den Angriff fort, nachdem es die Umgebung als real erkannt hatte, und Mythos 5 redete sich seine eigene richtige Einschätzung wieder aus. Von drei Modellen brach eines ab. Ein Modell hält also nicht verlässlich von selbst inne, sobald es den Testrahmen verlässt. Und der AISI-Fall brauchte gar keine Lücke: Social Engineering gegen einen echten Menschen, mit gefälschten Identitäten und nachträglich geglätteter Vorgeschichte, funktioniert durch jede Firewall hindurch.

Fünf Punkte für den eigenen Agentenbetrieb

Die wenigsten Unternehmen führen Cyber-Evaluationen von Frontier-Modellen durch. Aber viele lassen inzwischen Agenten mit Werkzeugzugriff laufen, in der CI, im Ticketsystem, auf Kundendaten. Die Fehlerklassen sind dieselben.

1. Isolation muss geprüft sein, nicht angenommen. In zwei von drei Fällen war der Ausgang offen, obwohl alle Beteiligten vom Gegenteil ausgingen. Testen Sie die Egress-Sperre Ihrer Agentenumgebung so, wie ein Angreifer sie testen würde: mit einem Verbindungsversuch aus dem Container heraus, nicht mit einem Blick in die Konfigurationsdatei.
2. Der Prompt ist keine Sicherheitsgrenze. „Du hast keinen Internetzugang“ im Systemprompt ist eine Behauptung, keine Kontrolle. Was der Agent nicht können soll, muss ihm die Infrastruktur verwehren.
3. Zielvorgaben eng fassen und Ausweichwege mitdenken. Formulieren Sie Aufgaben so, dass der billigste Weg zum Ziel auch der gewünschte ist. Jede Metrik, die sich abkürzen lässt, wird abgekürzt.
4. Ausgehender Verkehr gehört ins Monitoring. Der AISI-Vorfall fiel durch auffälligen Tor-Traffic auf und war in einer Stunde eingegrenzt. Der Anthropic-Vorfall lief monatelang, weil auf der Gegenseite niemand hinsah.
5. Zugangsdaten sind der Hebel, nicht der Exploit. Die realen Einbrüche liefen über schwache Passwörter, offene Endpunkte und erbeutete Credentials. Least Privilege und kurzlebige Tokens wirken hier stärker als jede Modellrichtlinie.

Alle drei Vorfälle wurden von den Anbietern selbst offengelegt oder von externen Prüfern veröffentlicht. In dieser Hinsicht hat das System funktioniert.