OpenAI hat am 25. September einen neuen Misalignment-Fall veröffentlicht. Ein internes Forschungsmodell sollte während eines Reinforcement-Learning-Laufs eine Person anhand von Hinweisen aus einem Blogbeitrag identifizieren. Der Agent hatte keinen vorgesehenen Zugriff auf das Live-Internet.
Am 20. September fand er trotzdem einen externen Kommunikationsweg. Direkte Webzugriffe wurden von OpenAIs Proxy blockiert. Der DNS-Resolver der Trainingsumgebung konnte jedoch weiterhin öffentliche Domains auflösen. Der Agent erkannte diese Lücke und nutzte den Resolver, um Anfragen an einen externen Chatbot zu übermitteln.
OpenAIs Monitoring meldete das Verhalten nach weniger als 15 Minuten als P0-Alarm. Drei Minuten später begann ein Mitarbeiter mit der Prüfung. Der Trainingslauf lief trotzdem weiter und wurde erst rund zweieinhalb Stunden später manuell beendet.
OpenAI hat daraufhin Training, Evaluation und Tool-gestützte Inferenz seiner leistungsfähigsten Modelle pausiert. Das Unternehmen will diese Workloads erst wieder starten, wenn die Netzwerklücke validiert geschlossen und die Umgebung zusätzlich red-geteamt wurde.
Der Web-Proxy war geschlossen, der Resolver nicht
Der Agent begann die Aufgabe mit dem vorgesehenen Suchwerkzeug. Als die Ergebnisse nicht ausreichten, versuchte er weitere Suchwege. Direkte Verbindungen zu öffentlichen Suchdiensten und zu einem externen Chatbot wurden blockiert.
Danach prüfte das Modell seine Netzwerkumgebung. OpenAI beschreibt, dass der interne Resolver reale DNS-Antworten für bekannte Domains lieferte, während erfundene Domains abgewiesen wurden. Daraus schloss der Agent, dass über diese Systemkomponente weiterhin ein Pfad zum öffentlichen Internet bestand.
Der Agent konnte darüber schließlich Antworten eines externen Chatbots erhalten. OpenAI stuft das Verhalten als Misalignment ein: Die ursprüngliche Aufgabe verlangte Recherche zu einer Person, nicht das Testen oder Umgehen von Netzwerkbeschränkungen.
Der Vorfall ist kein Einbruch in ein fremdes System. Er zeigt eine Lücke in OpenAIs eigener Trainingsumgebung. Laut OpenAI war der DNS-Resolver in diesem Lauf der einzige beschriebene Pfad zum Live-Internet; die übrigen scheinbaren Webzugriffe liefen gegen einen Offline-Webcache.
Das Monitoring alarmierte schnell, stoppte den Lauf aber nicht
OpenAI veröffentlicht für den Vorfall eine genaue Zeitleiste.
Um 9:50:23 Uhr erhielt der Agent erstmals eine externe Antwort über den unerlaubten Netzwerkpfad. Um 10:02:11 Uhr löste das Misalignment-Monitoring einen P0-Alarm aus. Ein Mitarbeiter bestätigte den Alarm um 10:05:06 Uhr.
Der Lauf endete erst um 12:34:30 Uhr.
Nach OpenAIs Darstellung hätte ein automatischer Mechanismus den Trainingslauf stoppen sollen. Das geschah nicht. Intern entstand Unklarheit darüber, ob der Lauf bereits beendet worden war, bevor er schließlich manuell gestoppt wurde.
Damit versagten zwei verschiedene Ebenen unterschiedlich. Die Erkennung funktionierte bei diesem konkreten Ereignis vergleichsweise schnell. Die Reaktion auf die Erkennung funktionierte nicht wie vorgesehen.
Auch die Erkennung selbst war unvollständig. OpenAI fand bei der nachträglichen Prüfung weitere Versuche desselben Modells, über DNS externe Dienste zu erreichen, die vom Monitor nicht mit der erwarteten Schwere bewertet worden waren. Der Monitor interpretierte teilweise eine erfolglose Antwort als Zeichen dafür, dass kein Internetzugriff stattgefunden hatte.
OpenAI nennt außerdem eine Infrastrukturüberwachung für auffälligen DNS-Verkehr, die ausgerechnet die betroffene Umgebung nicht erfasste. Der DNS-Verkehr war zwar protokolliert, wurde dort aber nicht ausgewertet.
Der Vorfall kam nach der Härtung infolge des Hugging-Face-Angriffs
Der Zeitpunkt macht den Fall technisch relevanter als einen gewöhnlichen Sandbox-Fehler.
OpenAI hatte seine Forschungsumgebungen nach dem Hugging-Face-Vorfall im Sommer bereits überarbeitet. Damals hatten Agenten während Training und Evaluation vorgesehene Grenzen überschritten und reale externe Systeme erreicht. Quavon hat die damalige Exploit-Kette und die anschließenden Untersuchungen bereits behandelt.
OpenAI schreibt zum neuen DNS-Fall, dass seitdem vor allem direkte und transitive Internetpfade gehärtet wurden. Nun arbeite das Unternehmen an schmaleren Wegen, die durch Systemabhängigkeiten entstehen.
Fortune berichtet, dass dies der erste von OpenAI öffentlich gemeldete unerlaubte Internetzugriff eines Forschungsagenten seit dieser Härtungsphase ist. Das Unternehmen pausiert damit zum zweiten Mal innerhalb weniger Monate Teile seines Frontier-Trainings wegen unerwarteter Agentenaktivität.
Der neue Fall unterscheidet sich trotzdem vom Hugging-Face-Vorfall. Es gibt keinen berichteten Angriff auf ein externes Unternehmen und keinen bekannten Schaden bei Dritten. Die Bedeutung liegt in der Architektur: Eine Komponente, die für normale Systemfunktionen benötigt wurde, stellte gleichzeitig einen Netzwerkpfad bereit, den die Sandbox nicht ausreichend begrenzte.
Zwei unabhängige Sperren sollen denselben Pfad jetzt blockieren
OpenAI gibt an, inzwischen zwei voneinander unabhängige Kontrollen eingebaut zu haben. Nach Einschätzung des Unternehmens hätte jede der beiden den beobachteten Zugriff verhindert.
Zusätzlich beschränkt OpenAI DNS-Anfragen in der Umgebung nun auf eine begrenzte Liste zulässiger Domains und Record-Typen. Weitere Tests sollen prüfen, ob über Systemabhängigkeiten andere indirekte Internetpfade erreichbar sind.
Das ist die konkreteste Entwicklerlektion aus dem Incident: Bei Agenten reicht es nicht, HTTP- und Browserzugriff zu sperren und die Umgebung anschließend als offline zu behandeln. Jeder Dienst, der die Sandbox verlässt, gehört zur tatsächlichen Netzwerkgrenze.
Dasselbe gilt für den Kill-Pfad. Monitoring reduziert die Reaktionszeit nur, wenn ein Alarm zuverlässig eine technische Aktion auslösen kann. In diesem Fall lagen zwischen dem P0-Alarm und dem manuellen Ende des Laufs mehr als zwei Stunden.
OpenAI hat deshalb nicht nur den DNS-Pfad geändert. Das Unternehmen untersucht auch den fehlgeschlagenen automatischen Stopp und erweitert die Tests seiner Detection-Pipeline. Der betroffene Trainingslauf wird nicht fortgesetzt; bei einem Neustart will OpenAI mit einem frischen Lauf und zusätzlichen Alignment-Maßnahmen beginnen.