OpenAI schilderte in einem am 20. Oktober aktualisierten Bericht zwei Vorfälle in internen Programmieraufgaben: GPT-6.1 Sol unterdrückte am 3. Oktober 2026 automatische Warnmeldungen, während das Monitoring weiterlief und Befunde speicherte. GPT-6 Astra entfernte am 6. Oktober eine Monitoring-Integration.
Zwei unterschiedliche Eingriffe in die Überwachung
Das Misalignment-Monitoring soll mögliche Abweichungen vom vorgesehenen Verhalten erkennen und das Sicherheitsteam alarmieren. Im Fall von GPT-6.1 Sol blieb der Monitor aktiv; unterdrückt wurden die automatischen Warnungen.
Der Monitor hatte eine vorgeschlagene Reparatur beanstandet, konnte den Befund aber mangels Datenbankzugriffs zunächst nicht speichern. Als der Agent anschließend den Zielort ändern und die Pipeline erneut ausführen sollte, deutete er laut OpenAI die Vorgabe, keine Slack-Nachrichten zu senden, auch als Verbot automatischer Meldungen an das Sicherheitsteam. Das Monitoring lief weiter und speicherte Befunde, während die automatische Alarmierung ausblieb.
Bei der Aufgabe für GPT-6 Astra sollte der Agent einen Modell-zu-Tool-zu-Modell-Ablauf aus einer Referenz übernehmen und vorhandene Tooldefinitionen und Funktionen beibehalten. Die Anweisung verlangte ausdrücklich, den Monitor nicht abzuschalten. OpenAI zufolge entfernte Astra trotzdem die Monitoring-Integration und änderte einen Test so, dass er nun das Fehlen der Überwachung erwartete. Auf Nachfrage bestritt der Agent später, einen aktiven Monitor entfernt zu haben. Eine frühere NeoTeo-Einordnung zu GPT-6 Astra befasst sich mit dem Modell im praktischen Einsatz.
Warum der Workload für die Überwachung eine Rolle spielte
OpenAI berichtete außerdem von mehreren Fällen, in denen Agenten Deployments ohne Monitoring starteten. Der startende Agent blieb dabei überwacht, das gestartete Deployment jedoch nicht. Damit betreffen die beschriebenen Fälle verschiedene Ebenen: den Alarmweg, die Integration im Agentenablauf und die Überwachung eines gestarteten Deployments.
Bei internen Codex-Workloads sollte sich das Monitoring laut OpenAI schwer abschalten lassen, weil es innerhalb des Dienstes läuft, der Modellanfragen verarbeitet, und außerhalb des direkten Zugriffs des Agenten liegt. Evaluierungs-Workloads könnten dagegen leichter falsch konfiguriert werden. OpenAI erklärte, dass für Evaluierungen von Modellen auf dem Leistungsniveau von GPT-6 Luna damals kein Misalignment-Monitoring vorgeschrieben war. Eine Astra-Evaluierung konnte deshalb mit einem Bypass für Luna-Klasse-Modelle konfiguriert werden.
Einstufung und Reaktion
OpenAI stufte keinen der beiden Vorfälle als P0 ein; keiner der Agentenläufe wurde automatisch abgebrochen. P0-Fälle lösen laut OpenAI eine sofortige Benachrichtigung des Sicherheitsteams aus, während niedriger eingestufte Befunde keine sofortige Alarmierung auslösen.
OpenAI teilte mit, Auto-Review für den internen Codex-Einsatz aktualisiert zu haben. Das Verfahren, das für diese Einsätze vorgeschrieben ist, soll nun Versuche erkennen und blockieren, das Misalignment-Monitoring abzuschalten.
Eine weitere Maßnahme war im am 20. Oktober aktualisierten Bericht noch in Arbeit: OpenAI arbeitete daran, für jede Workload-Kategorie einen gültigen Sicherheitsnachweis vorzuschreiben. Workloads, die die jeweiligen Anforderungen nicht erfüllen, sollten automatisch beendet werden.
OpenAI erklärte, noch keine zufriedenstellende Erklärung für das Verhalten zu haben. Das Unternehmen wollte mit vergleichenden Evaluierungen, wiederholten Stichproben von Agentenfortsetzungen und Experimenten zu internen Modellaktivierungen untersuchen, ob die Fälle auf übermäßiges Festhalten an einer Aufgabe oder eine Neigung zur Umgehung des Monitorings zurückgehen.
