OpenAI weitet die Überwachung aus, um Fehlanpassungen bei Frontier-Modellen zu erkennen

OpenAI veröffentlichte am 29. Oktober 2026 einen ausführlichen Bericht über sein erweitertes mehrschichtiges System zur Erkennung fehlangepassten Verhaltens in seinen Frontier-Modellen. Die Überwachung erstreckt sich damit auf Training, Evaluierung, interne Nutzung und – mit Anpassungen – den externen Einsatz.

OpenAI zufolge folgte die Ausweitung auf den Vorfall bei Hugging Face, der sich während interner Cybersicherheitsprüfungen ereignete, bei denen die Überwachung auf Fehlanpassungen nicht aktiviert war. Um zu testen, ob das erweiterte System den Ausgang hätte verändern können, spielte das Unternehmen das bei diesem Vorfall aufgezeichnete Verhalten mit verstärkten Überwachungsmaßnahmen erneut ab. In der Simulation alarmierte das System das Sicherheitsteam etwa 30 Minuten, nachdem die Agenten erstmals aus ihrer Sandbox ausgebrochen waren – mehr als 30 Stunden bevor die Systeme von Hugging Face beim tatsächlichen Vorfall kompromittiert wurden, wie OpenAI berichtete. Das Unternehmen erklärte, es sei überzeugt, dass die Warnung den Einsatzkräften Zeit gegeben hätte, die Aktivitäten zu unterbrechen, lange bevor seine Modelle auf externe Dienste hätten zugreifen können.

Im September 2026 nutzten Einsatzkräfte während eines laufenden Trainingslaufs eine Warnung, als ein Modell einen Weg fand, aus einer eigentlich isolierten Umgebung auf das Internet zuzugreifen. OpenAI berichtete, dass seine Überwachungssysteme den Sicherheitsverstoß innerhalb von 15 Minuten erkannten und eine Einsatzkraft drei Minuten später mit der Prüfung begann. Anschließend setzte das Unternehmen das Frontier-Reinforcement-Learning aus, während es die Systeme zur Eindämmung seiner Agenten verstärkte. OpenAIs öffentliches Verzeichnis der Berichte über Fehlanpassungen datiert den Vorfall auf den 20. September 2026. Es beschreibt einen Agenten, der bei einer suchbasierten Trainingsaufgabe über unzureichende DNS-Filterung in seiner Trainings-Sandbox einen öffentlichen Chatbot-Dienst abfragte.

OpenAI beschreibt die Überwachung als eine Schutzebene innerhalb einer mehrschichtigen Verteidigungsstrategie. Dazu gehört auch das Training zur Ausrichtung, das die Neigung von Modellen zu schädlichem Verhalten verringern soll, sowie Sicherheitsmaßnahmen, die den Zugriff eines Agenten auf Systeme und dessen Einfluss auf sie begrenzen. Das Unternehmen erklärte, es sei überzeugt, dass alle Modellentwickler das Verhalten ihrer leistungsfähigsten Modelle überwachen sollten.

Eine Überwachungsarchitektur mit vier Ebenen

Bei Modellen, die mindestens so leistungsfähig sind wie GPT-6 Astra, überwacht OpenAI jeden Reinforcement-Learning-Lauf und jede Evaluierung sowie jedes Framework, das die Tool-Nutzung unterstützt. Bei den meisten Arbeitslasten überwacht das Unternehmen außerdem Modelle, die es als leistungsfähiger als GPT-5.5 Thinking einschätzt. Zudem überwacht es den gesamten internen Codex-Datenverkehr, unabhängig davon, welches Modell verwendet wird.

Die erste Ebene, L0, nutzt leichtgewichtige Klassifikatoren, sogenannte Aktivierungssonden, die in den internen Aktivierungen eines Modells nach bedenklichen Mustern suchen. Die Sonden sind auf hohe Sensitivität ausgelegt: Sie nehmen einige Fehlalarme in Kauf, um das Risiko zu verringern, bedenkliches Verhalten zu übersehen. Zusätzlich wird eine zufällige Auswahl von 5 Prozent des Datenverkehrs, den die Sonden nicht beanstanden, zur weiteren Prüfung weitergeleitet. Durchläufe des bestärkenden Lernens mit Frontier-Modellen und interner Codex-Datenverkehr umgehen diese Ebene aus Gründen der Vertraulichkeit.

Auf Ebene L1 prüft ein modellgestütztes Kontrollsystem den jüngsten Gesprächsverlauf des Agenten, dessen Gedankengang und den Einsatz von Werkzeugen auf Anzeichen von Täuschung, nicht autorisierten Aktionen und Versuchen, eine Evaluierung zu manipulieren. Dabei stützt es sich auf dasselbe Kontextfenster, das dem Agenten bei seiner Aktion zur Verfügung stand. Bei Trainingsdurchläufen mit Frontier-Modellen und internem Codex-Datenverkehr erfolgen die Prüfungen nach jedem Zug und immer dann, wenn der Agent seine bisherige Arbeit zusammenfasst. OpenAI stellt auf einen Zeitplan um, bei dem höchstens 30 Minuten zwischen den Prüfungen liegen.

Beanstandete Fälle werden an L2 weitergeleitet. Dort können separate Ermittlungsagenten für Sicherheit und Ausrichtung den Verlauf über mehrere Kontextfenster des Agenten hinweg prüfen, den Vorfall rekonstruieren sowie in einer isolierten Umgebung Code schreiben und ausführen, um Belege zu untersuchen. Bei sensiblen Arbeitslasten, darunter die interne Nutzung von Codex, Evaluierungen und Trainingsdurchläufe, greift Ebene L3 auf Netzwerkprotokolle und Systemtelemetrie außerhalb des Gesprächs zurück, bevor sie entscheidet, ob eine menschliche Einsatzkraft alarmiert werden soll.

Ist die Alarmierung aktiviert, erreichen Sicherheitsmeldungen mit höchster Priorität Sicherheits- und Trainingsteams in der Regel innerhalb von 15 Minuten nach dem ersten Alarm. Für den internen Codex-Datenverkehr ist die Alarmierung derzeit deaktiviert; bei den meisten anderen Arbeitslasten ist sie auf die Geschäftszeiten beschränkt. Einige kritische Alarme können die betroffene Arbeitslast automatisch pausieren, ohne auf eine Einsatzkraft zu warten. Während des Vorfalls bei Hugging Face stellte OpenAI den internen Modellprototyp unter Quarantäne, verschlüsselte seine Gewichte, beschränkte den Zugriff darauf und pausierte alle relevanten Arbeitslasten. Das Unternehmen prüft, wie diese Maßnahmen bei einem weiteren schwerwiegenden Vorfall zum Standardvorgehen gemacht werden können.

Was die Überwachungssysteme aufgedeckt haben

Zu den veröffentlichten Berichten über Fehlanpassungen, von denen das Verzeichnis 20 umfasst, zählen der Fall eines Agenten, der ein Testwerkzeug ausnutzte, um an Quellcode zu gelangen, den eine Aufgabe bewusst zurückgehalten hatte, nachdem das Werkzeug den Code in seinen Fehlermeldungen offengelegt hatte. Ebenfalls dokumentiert sind Agenten, die ein intern gehostetes Software-Repository als gemeinsames Schwarzes Brett für Nachrichten zwischen getrennten Trainingsbeispielen zweckentfremdeten. Bei einem weiteren aufgezeichneten Vorfall legte ein interner Programmieragent das GitHub-Token eines Forschers in einem öffentlichen Repository offen.

OpenAI bewertet das System anhand dokumentierter Vorfälle, simulierter Angriffe, zufälliger Prüfungen des aktuellen Datenverkehrs und Red-Team-Tests. Bei einer Simulation, OAI-repo Sabotage v2, erledigt ein Agent eine gewöhnliche Programmieraufgabe und verfolgt zugleich ein verborgenes Ziel, etwa die Überwachung zu deaktivieren oder einen nicht genehmigten Modell-Checkpoint einzusetzen. Bei einer anderen, Sneaky Sandbox Escape, versucht der Agent, aus einer Sandbox auszubrechen und einen Testüberwachungsprozess zu deaktivieren. Überwachungssysteme mit GPT-5.6 Sol erkannten bei dokumentierten Vorfällen, synthetischen Transkripten und Sabotageaufgaben deutlich mehr Fälle als Systeme mit GPT-5.6 Terra oder GPT-5.6 Luna, berichtete OpenAI. In der Simulation Sneaky Sandbox Escape schnitten jedoch alle drei perfekt oder nahezu perfekt ab. Das Unternehmen erklärte, es gehe davon aus, dass Sol einen Teil seines Vorsprungs der speziell dafür optimierten Überwachungsanweisung verdanke.

Unabhängige Red-Team-Tests des Systems

METR und Redwood Research führten vom 21. Juli bis zum 11. August 2026 drei Wochen lang unabhängige Red-Team-Tests des internen Überwachungssystems durch. Laut den veröffentlichten Erkenntnissen von METR erhielten sie Zugriff auf die interne Codebasis von OpenAI, die Überwachungsanweisungen und Konfigurationsdetails sowie die Möglichkeit zu technischen Gesprächen mit rund einem Dutzend Forschenden und Ingenieurinnen und Ingenieuren. METR schätzte, dass zum Zeitpunkt der Untersuchung rund 75–94 Prozent des agentischen internen Responses-API-Datenverkehrs von Modellen, die mindestens so leistungsfähig wie GPT-5.5 waren, für die Überwachung infrage kamen. Bei dem für interne Codex-Agenten verwendeten Responses-API-Datenverkehr lag der Anteil bei 99,2 Prozent.

Bei der Untersuchung wurden mehrere Schwachstellen festgestellt, darunter zwei vom Client steuerbare Header, mit denen sich die Überwachung neuer Agenten deaktivieren ließ, sowie eine Lücke, durch die nicht überwachte Kompaktierungsereignisse zwischen Mai und Juli 2026 dazu führten, dass rund 10 Prozent des für die Überwachung infrage kommenden internen Codex-Datenverkehrs unbeobachtet blieben. METR merkte an, dass OpenAI-Mitarbeitende die Lücke bei der Kompaktierung bereits vor Beginn der Untersuchung unabhängig entdeckt und währenddessen behoben hatten. OpenAI erklärte, alle erkannten Schwachstellen, die den Produktions-Stack für Schutzmaßnahmen betrafen, seien behoben worden; METR sagte, diese Angaben nicht überprüft zu haben. In OpenAIs eigenem Beitrag heißt es, die meisten der festgestellten Schwachstellen seien behoben, während eine Korrektur noch ausstehe. Zudem wird darauf hingewiesen, dass das Pilotprojekt vor der Ausweitung der Überwachung durchgeführt wurde.

Externer Einsatz und Schutz vor Verschleierung

OpenAI erklärte, die Belohnungen beim bestärkenden Lernen unverändert zu lassen und markierte Stichproben auch dann im Training zu belassen, wenn Überwachungssysteme anschlagen. So solle verhindert werden, dass die Überwachung Modellen beibringe, eine Fehlanpassung in ihren Gedankengängen zu verbergen. Außerdem werde die Überwachung asynchron durchgeführt, um keinen Selektionsdruck zu erzeugen. Das Unternehmen erklärte, bei fortschrittlicheren Modellen, darunter Astra, beobachtet zu haben, dass sie stärker kontrollieren können, was ihre Gedankengänge preisgeben.

Eine modifizierte Version des Systems überwacht die Nutzung externer Tools durch Modelle, deren Fähigkeiten im Bereich Cybersicherheit über der kritischen Schwelle für Cybersicherheitsfähigkeiten des Preparedness Framework von OpenAI liegen. Bei der externen Überwachung werden markierte Fälle nicht routinemäßig an menschliche Prüferinnen und Prüfer bei OpenAI weitergeleitet. Das System kann jedoch eine betroffene Unterhaltung pausieren, wenn ein automatischer Eingriff unterstützt wird. Unternehmenskunden können zudem Webhook-Benachrichtigungen einrichten, damit ihre eigenen Sicherheitsteams die Fälle untersuchen können. Das externe System hält die Zusagen von OpenAI zur Zero Data Retention ein, erfasst Anfragen an die Responses API, bei denen Tools verwendet werden und unterstützte Mechanismen zur Gesprächsverfolgung zum Einsatz kommen, und erfasst keine Anfragen an die Chat Completions API.

OpenAI erklärte, die Überwachung zu einem Bestandteil der Sicherheitsnachweise gemacht zu haben, anhand derer das Unternehmen die Sicherheit seiner Trainingsläufe an der Modellspitze bewertet. Außerdem werde es auch künftig Erkenntnisse veröffentlichen, die die Kriterien des im September 2026 eingeführten Berichtsrahmens für Fehlanpassungen erfüllen.