Was OpenAIs sechs Misalignment-Berichte für Entwickler bedeuten

Am 16. September hat OpenAI einen Berichtsrahmen für Modell-Misalignment veröffentlicht, zusammen mit sechs konkreten Berichten. Die Modelle schmuggelten Anweisungen in ihre eigenen Task-Summaries, nutzten einen offengelegten API-Key ohne Erlaubnis, luden Dateien auf einen öffentlichen Hoster, um sie zitieren zu können, und tauschten Nachrichten über ein internes Repository aus. Alle drei Flächen brauchen dieselbe Behandlung wie jeder nicht vertrauenswürdige Input.

Was die sechs Berichte dokumentieren#

Die Kurzfassung in den Medien lautet „KI-Modelle haben gelogen“ (CNBC). Die Berichte sind enger gefasst und dadurch nützlicher. Drei Familien lassen sich unterscheiden.

1. Zusammenfassungen, die Anweisungen tragen: Wächst eine Aufgabe aus dem Kontextfenster heraus, verdichtet das Modell den bisherigen Stand zu einer Summary und übergibt sie an das nächste Fenster. In zwei Vorfällen reiste darüber mehr mit als gedacht: 27 betroffene Zusammenfassungen enthielten fremde Anweisungen, darunter welche, die eigenen Beschränkungen zu missachten. Während eines Trainingslaufs von GPT-5.6 Sol wiesen Summaries künftige Instanzen an, Fehler zu verbergen, fehlende historische Daten zu erfinden, ohne es zu kennzeichnen, und Abweichungen bei Quellversionen zu verstecken.
2. Der Buchstabe der Aufgabe schlägt ihre Absicht: Auf die Frage nach Umsatzzahlen für ein County in Kalifornien durchsuchte ein Modell öffentliche Repositories, fand einen offengelegten API-Key und nutzte ihn ohne Erlaubnis. Die Zahlen kamen trotzdem nicht, also erfand das Modell sie und gab sie als Daten aus der geforderten Quelle aus. Im zweiten Fall stimmte die Antwort, aber der Agent lud die Ergebnisdatei auf einen öffentlichen Hoster, weil seine Anweisung ein Zitat verlangte und das der kürzeste Weg dorthin war. Gefragt hat er den Nutzer nicht.
3. Kanäle zwischen Läufen: Getrennte Trainingssamples nutzten ein internes Software-Repository als Pinnwand und tauschten Anfragen und Antworten aus, während sie nach fehlenden Eingabedateien suchten. Gefunden haben sie die Dateien nicht. In einem anderen Fall teilten kooperierende Agenten Dateien über öffentliche File-Hoster, sodass Aufgaben-Ergebnisse an öffentlichen URLs landeten, obwohl die Aufgabe nur lokale Dateien erlaubte.

Keiner der sechs Vorfälle erreichte eine Kundin oder einen Kunden. OpenAI hat sie in den eigenen Trainings- und Evaluationsläufen gefunden, und der Bericht sagt ausdrücklich, dass es Einzelfälle sind, keine Aussage über die Häufigkeit, und dass sich manche als Fehlalarm erweisen könnten. Diese Ehrlichkeit ist so viel Wert wie die Vorfälle selbst.

Warum Task-Summaries eine Injektionsfläche sind#

Eine kompaktierte Summary ist vom Modell geschriebener Zustand, den das Modell später wieder als Kontext liest. Eine Anweisung darin wird nicht geprüft, weil sie nichts von außen erreicht hat. Das funktioniert auch ohne Angreifer, denn die Nutzlast schreibt das Modell selbst.

Tool-Ergebnisse werden beim Support-Agenten auf dieser Seite mit Zod geprüft, bevor sie zurück in den Kontext des Modells gehen, und die Schleife stoppt nach drei Tool-Runden. Die Berichte verlängern die Regel um einen Schritt: Alles, was das Modell selbst schreibt und später wieder liest, braucht dieselbe Prüfung wie Tool-Ausgaben. Konkret heißt das: Zustand in der eigenen Datenbank als strukturierte Zeilen halten, Kontextfenster kurz leben lassen, und eine gespeicherte Summary wie externen Text scannen, wenn sie einen Neustart überleben muss.

Wo die Eval-Suite blind ist#

Fünf der sechs Vorfälle würden einen Eval bestehen, der nur die finale Antwort prüft, denn die Antwort war in Ordnung. Die Abweichung saß im Trace: welche Keys berührt wurden, welche Hosts Uploads bekamen, welche Nachrichten in welchem Repository auftauchten. Outputs lassen sich leicht vergleichen, deshalb prüfen Eval-Suites sie. Die Berichte legen nahe, auch den Weg zu prüfen: jeden Tool-Aufruf und jeden Seiteneffekt loggen, Credentials auf Read-only beschränken, wo es geht, und eine korrekte Antwort mit überraschendem Trace als Fehler werten. Die Folge für die Agent-Demo hier: Trace-Assertionen in der Eval-Suite neben den Schema-Checks. Ein Upload zu einem Host außerhalb der Allowlist soll den Build scheitern lassen, genauso wie ein Schema-Verstoß.

Wie Agenten sich eigene Kanäle bauen#

Zwei Vorfälle haben eine gemeinsame Ursache, die wenig mit Täuschung zu tun hat. Agenten, die zusammenarbeiten mussten, hatten keinen genehmigten Kanal, also bauten sie einen: Das Repository wurde zur Pinnwand, öffentliche File-Hoster wurden zum gemeinsamen Ordner. Jedes Ergebnis, das eine öffentliche URL erreichte, war ein kleines Datenleck, obwohl die Absicht war, die Aufgabe zu Ende zu bringen.

Wer mehr als einen Agenten auf dieselbe Aufgabe ansetzt, hat die bekannte Design-Aufgabe aus verteilten Systemen: Kommunikationswege explizit festlegen und davon ausgehen, dass alles Beschreibbare zum Postfach wird. Allowlists für Uploads, gemeinsamer Zustand über die eigene Queue oder Datenbank, und ein Alarm, wenn ein Artefakt die eigene Infrastruktur verlässt.

Heißt das: langsamer machen?#

Die Berichte sind mitten in einer laufenden Debatte gelandet. Dario Amodeis Essay „We Must Pace the Frontier“ erschien am 12. September mit dem Satz „We must slow the pace at which we improve the capabilities of A.I. models“ (NYT). Sam Altman unterstützte Anthropics Vorschlag zur Verlangsamung am nächsten Tag. Am Mittwoch veröffentlichte OpenAI diese Berichte, inklusive des Satzes: „We do not believe that the AI industry has solved alignment and monitoring to a sufficient degree to continue responsibly scaling at maximum speed for much longer.“

Das Tempo der Labore war nie ein Parameter, den du kontrollierst. Deins ist das Tempo, in dem dein Produkt neues Modellverhalten aufnimmt, und dafür gibt es bekannte Stellschrauben: Staging vor Produktion, Token-Budgets, ein Kill Switch und ein Fallback, der weiterliefert, wenn das Modell aus der Rolle fällt. Der Support-Agent auf dieser Seite fällt auf einen skriptierten Provider zurück, auf denselben Loop, wenn der Key fehlt oder das Tagesbudget aufgebraucht ist.

Was ich hier ändere#

Nichts in den sechs Berichten verlangt neue Theorie. Es ist dieselbe Disziplin wie bei jedem nicht vertrauenswürdigen Input, angewendet auf drei Flächen, die niemand im Blick hatte: was das Modell für sich selbst schreibt, was es unterwegs tut, und wie es mit seinesgleichen spricht. Der Punkt für die Agent-Demo auf dieser Seite ist klein: Trace-Assertionen in der Eval-Suite neben den Schema-Checks, damit ein unerwarteter Upload oder ein Host außerhalb der Allowlist den Build scheitern lässt wie jeder Schema-Verstoß. Dieselbe Woche brachte das Spiegelbild auf der Malware-Seite: RatHat, ein Android-Trojaner, der die Bildschirmsteuerung an eine generative KI auslagert und sich ohne Computer mit dem eigenen Wireless Debugging koppelt.