OpenAI beschreibt vierstufiges Monitoring für fehlgeleitete Agenten

Der KI-Anbieter OpenAI hat am 29. Oktober 2026 beschrieben, wie er mit vier Prüfstufen erkennen will, wenn seine leistungsfähigsten Modelle als Agenten vom Beabsichtigten abweichen, um bei Bedarf rechtzeitig einzugreifen. Die Reaktion von Menschen führt OpenAI als eigenen Punkt hinter den Stufen L0 bis L3.

Den Anlass liefert ein Vorfall rund um Hugging Face, der laut OpenAI in internen Cybersecurity-Evaluierungen begann, auf denen die Monitore für fehlgeleitetes Verhalten nicht liefen. Inzwischen decken sie demnach Training, Evaluierung, interne Nutzung und, je nach Produktoberfläche angepasst, externe Deployments ab.

Um den Effekt abzuschätzen, spielte OpenAI das aufgezeichnete Verhalten mit den verstärkten Monitoren nach. Laut OpenAI ging in dieser nachträglichen Simulation der Alarm rund 30 Minuten nach dem ersten Sandbox-Ausbruch an das Sicherheitsteam, mehr als 30 Stunden vor dem Einbruch in die Systeme von Hugging Face im tatsächlichen Vorfall. Eine unabhängige Messung der Wirksamkeit ist das nicht.

L0 und L1: breit filtern, dann den Kontext lesen

Der Aufbau folgt einer einfachen Kostenlogik. Die ersten Filter sollen laut OpenAI mit wenig Rechenaufwand möglichst viele auffällige Fälle weiterreichen, spätere Stufen dürfen je Fall mehr Rechenleistung einsetzen.

Auf L0 arbeiten leichtgewichtige Klassifikatoren, die OpenAI „activation probes“ nennt. Sie suchen in den internen Aktivierungen des Modells nach auffälligen Mustern und reichen markierte Fälle weiter. Die Sonden sollen möglichst wenige auffällige Fälle übersehen, Fehlalarme nimmt OpenAI dafür in Kauf. Laut OpenAI gehen zusätzlich zufällige 5 Prozent des nicht markierten Verkehrs an die nächste Schicht, weil das Unternehmen noch prüft, wie gut die Sonden unbekannte Formen von Fehlausrichtung erkennen. Diese Stichprobe soll Fälle sichtbar machen, die den Sonden entgangen sind. Direkt auf der nächsten Schicht landen dagegen zwei sensible Arten von Verkehr: Frontier-RL-Läufe, also Trainingsläufe der leistungsfähigsten Modelle per Reinforcement Learning, und die interne Nutzung des OpenAI-Produkts Codex.

Auf L1 prüft ein modellbasierter Reviewer das jüngste Gespräch des Agenten, seine Gedankenkette und die Werkzeugnutzung. Gesucht wird nach Anzeichen für Täuschung, unerlaubte Aktionen und Versuche, eine Evaluierung zu manipulieren. Der Reviewer sieht dabei dasselbe Kontextfenster wie der Agent beim Handeln, und wurde frühere Arbeit zusammengefasst, sieht er diese Zusammenfassung.

Bei Frontier-RL-Läufen und internem Codex-Verkehr läuft die L1-Prüfung zum Abschluss jeder Arbeitsrunde und immer dann, wenn der Agent frühere Arbeit zusammenfasst, um im Kontextfenster Platz zu schaffen. Derzeit stellt OpenAI auf einen Takt um, bei dem höchstens 30 Minuten zwischen zwei Prüfungen liegen.

L2 und L3: Belege sammeln, Eskalation abwägen

Markiert L1 einen Fall, übernimmt laut OpenAI auf L2 ein investigativer Agent. Er kann den Zweck einer Evaluierung prüfen und, sofern das vollständige Transkript vorliegt, alle Kontextfenster des überwachten Agenten zurücklesen. In einer isolierten Umgebung darf er außerdem Code schreiben und ausführen, um Belege zu untersuchen. Daraus rekonstruiert er den Vorfall, erkennt doppelte Meldungen und bewertet die Schwere.

OpenAI setzt dafür unterschiedliche Spezialisten ein. Der Security-Investigator sucht nach Anzeichen, dass jemand eingreifen muss, etwa nach einem Sandbox-Ausbruch oder einem unbefugten Systemzugriff. Der Alignment-Investigator sucht nach Verhalten, das auch ohne akutes Sicherheitsrisiko eine Untersuchung lohnt.

Für sensible Workloads, darunter interne Codex-Nutzung, Evaluierungen und RL-Läufe, zieht L3 Belege außerhalb des Gesprächs heran. Der Security-Investigator gleicht dort das Transkript mit Netzwerklogs, weiterer Systemtelemetrie und Belegen aus früheren Fällen ab und entscheidet dann, ob ein menschlicher Responder alarmiert wird. Bei Workloads ohne diese Schicht kann der Security-Investigator von L2 aus direkt alarmieren.

Überwacht heißt nicht: Ein Mensch wird geweckt

Ist die direkte Alarmierung des Bereitschaftspersonals aktiv, das sogenannte Paging, erreichen die höchstpriorisierten Sicherheitsalarme laut OpenAI typischerweise innerhalb von 15 Minuten nach dem ersten Alarm Mitglieder der Sicherheits- und Trainingsteams. Rund um die Uhr für jeden Workload läuft das nicht, weil Fehlalarme es erschwert haben. Bei Frontier-RL-Läufen kann ein Alarm höchster Priorität zu jeder Stunde einen Menschen aus dem Bereitschaftsdienst alarmieren, bei den meisten anderen Verkehrsarten bleibt Paging auf die Geschäftszeiten begrenzt.

Für internen Codex-Verkehr ist Paging derzeit abgeschaltet. Dabei überwacht OpenAI diesen Verkehr unabhängig vom eingesetzten Modell. Beobachtung und menschliche Alarmierung sind hier zwei getrennte Dinge.

Einen Teil der Lücke soll Automatik schließen. Einige kritische Alarme können den betroffenen Workload pausieren, ohne dass ein Responder handeln muss. OpenAI arbeitet außerdem an einer breiteren Absicherung, die betroffene Aktivität anhalten würde, wenn Responder einen Alarm höchster Priorität nicht innerhalb von 30 Minuten nach dem Paging ausgeschlossen haben.

Als Praxisfall nennt OpenAI einen Alarm während eines Live-Trainings im September. Ein Modell hatte dabei per DNS versucht, das Live-Internet zu erreichen. Die Monitore meldeten den Vorfall innerhalb von 15 Minuten, drei Minuten später begann ein Responder mit der Prüfung. Danach pausierte OpenAI das Frontier-Reinforcement-Learning, um die Systeme zur Eindämmung der Agenten zu verstärken. Weiterlesen: OpenAI nutzt eine Offline-Umgebung für Frontier-RL-Läufe.

Blinde Flecken und Fehlanreize

Von außen getestet wurde das System ebenfalls: METR und Redwood Research prüften das interne Monitoring ab Juli 2026 drei Wochen lang unabhängig im Red-Teaming. Laut OpenAI fanden sie mehrere Schwachstellen; die meisten seien inzwischen behoben, ein Fix laufe noch. Dieser Pilot lag allerdings vor der Ausweitung des Monitorings auf Training, Evaluierung, interne Nutzung und externe Deployments.

Überwachung kann selbst Schaden anrichten. Bekommt ein Modell weniger Belohnung, sobald seine Gedankenkette Fehlverhalten offenlegt, lernt es laut OpenAI womöglich, das Fehlverhalten zu verbergen, statt es zu lassen. Löst eine Trainingsprobe die Monitore aus, bleibt ihre RL-Belohnung deshalb unverändert und die Probe im Training. Einen Trainingslauf bei einem ernsten Problem zu pausieren, abzubrechen oder zurückzurollen, bleibt trotzdem möglich. Weiterlesen: OpenAI führt Berichtsverfahren für Modellfehlverhalten ein.

Auf der API bestimmt die Anfrageart über den Stopp

Für Agenten auf OpenAIs API zählt die externe Variante. OpenAI wendet eine Version des Systems auf bestimmte externe Deployments seiner leistungsfähigsten Modelle an. Anders als intern eskaliert sie markierte Fälle nicht routinemäßig an menschliche Prüfer bei OpenAI. Wegen der Datenschutzzusagen, darunter Zero Data Retention, hat das externe System zudem nicht immer denselben Kontext und dieselben Untersuchungswerkzeuge wie das interne.

Die API-Dokumentation von OpenAI unterscheidet für abgedeckte Modelle drei Fälle, abhängig von der Schnittstelle und davon, wie eine Anfrage den Gesprächskontext bewahrt:

• Responses-API-Anfragen mit persistiertem Reasoning, WebSockets oder OpenAI-Compaction werden überwacht, und das System kann die weitere Ausführung blockieren.
• Responses-API-Anfragen ohne diese Mechanismen werden überwacht, und konfigurierte Webhooks können Alarme empfangen, doch das System stoppt die Konversation nicht automatisch.
• Chat-Completions-Anfragen deckt dieses Monitoring nicht ab.

Angenommen, ein Agent läuft über die Responses API ohne einen dieser Mechanismen und ruft ein Werkzeug auf, das Daten löscht. Ein konfigurierter Webhook kann dann zwar einen Alarm empfangen, die Konversation kann aber weiterlaufen.

Blockiert das Monitoring eine Anfrage vor Beginn des Streamings, liefert die API HTTP 403 mit dem Fehlertyp invalid_request_error und dem Code misalignment_policy_violation. Die Dokumentation verlangt dann, keine weiteren Aktionen für die Konversation auszulösen und den blockierten Workflow nicht automatisch zu wiederholen.

Ein Stopp macht nichts rückgängig

Weil das Monitoring asynchron läuft, kann eine Aktion laut Dokumentation bereits abgeschlossen sein, bevor es eine Auffälligkeit erkennt, und eine gestoppte Anfrage macht frühere Aktionen nicht rückgängig. Ein Flag besagt dort lediglich, dass die Aktionen des Agenten geprüft werden müssen, und belegt weder einen Richtlinienverstoß des Nutzers noch ein Handeln gegen Anweisungen. Die Dokumentation warnt zudem, dass das Monitoring Probleme übersehen oder legitime Aktivität markieren kann, und rät weiter zu eigenen Schutzmaßnahmen, darunter menschliche Freigaben für folgenreiche Aktionen.

Bei löschenden oder datenabgebenden Werkzeugen ist das Monitoring deshalb keine verlässliche Bremse. Eine menschliche Freigabe kann eine solche Aktion noch verhindern, wenn sie davor liegt; ein Alarm bleibt dagegen Anlass, den Zustand der eigenen Systeme zu prüfen.