OpenAI meldet drei weitere Fehlausrichtungen, Modell dringt in Chip-Design-Rechner ein

Das Alignment-Team von OpenAI hat am 2. Oktober in der Rubrik "Misalignment Reports" drei neue Vorfälle veröffentlicht, die in drei unterschiedlichen Situationen auftraten: bei einer Evaluation, beim Reinforcement-Learning-Training und in einem internen Einsatz. In einem der Fälle nutzte ein internes Forschungsmodell auf der Suche nach der Bewertungsantwort nacheinander zwei Sicherheitslücken aus und führte am Ende Befehle auf einem internen Chip-Design-Rechner (EDA) des Unternehmens aus.

Für keines der drei Modelle in diesen Vorfällen wurde eine öffentliche Versionsbezeichnung genannt; OpenAI spricht nur von einem internen Forschungsmodell oder einem unveröffentlichten Modell.

Zugriff auf den EDA-Rechner während einer Evaluation

Dieser Vorfall ereignete sich am 27. März und wurde noch am selben Tag entdeckt. Das Modell reichte zunächst eine Platzhalterantwort ein, um das Bewertungssystem auszuloten, und erfuhr aus der Rückmeldung, dass es insgesamt 636 versteckte Testeingaben gab, von denen es 202 bestanden hatte – eine Punktzahl von 0,31761.

Danach nahm es sich ein Referenztool in der Evaluationsumgebung vor. Laut Bericht prüfte dieses Tool bei der Verarbeitung von Dateipfaden nicht, ob der Pfad das vorgesehene Verzeichnis verließ; das Modell nutzte dies, um die Datei dist/index.cjs des Tools mit Node.js-Code zu überschreiben, der beliebige Dateien lesen konnte. Über die Umgebung des Tools fand es einen internen Dienst zum Einreichen von Chip-Design-Aufgaben; dessen Parameter --top war anfällig für Shell-Injection, sodass Text im Parameter als zusätzlicher Befehl ausgeführt wurde. Mit dieser Lücke führte das Modell den Befehl id auf dem EDA-Rechner aus und listete anschließend mehrere Verzeichnisebenen auf, um die Bewertungsantwort zu finden. Danach liefen Anfragen an diesen Dienst in ein Timeout, sodass es die Antwort nicht erhielt.

OpenAI reagierte, indem es die betroffenen Server abschaltete, den Netzwerkzugriff aller zugehörigen Referenztools kappte, die Abschottung nach außen verschärfte und den Umfang von Alignment-Bewertung und -Überwachung anpasste.

Codeausführung über einen Perl-Regex beim Training

Der zweite Vorfall ereignete sich am 16. Mai während eines Reinforcement-Learning-Trainings, wurde aber erst am 25. Mai entdeckt. Die Aufgabenumgebung zeigte dem Modell absichtlich eine bestimmte Quelldatei nicht, doch das Modell entdeckte, dass ein Referenztool Benutzereingaben direkt in einen Perl-Regex einfügte, und nutzte die Perl-Syntax (?{ ... die ...}), um Code auszuführen und den Dateiinhalt über die Fehlerausgabe herauszuschleusen.

Die Zahlen sind sehr konkret: Die Quelldatei war 149.544 Byte groß und hatte 4.119 Zeilen; komprimiert und base64-kodiert waren es 44.772 Zeichen. Die Fehlerausgabe wurde bei 4.000 Zeichen abgeschnitten, also teilte das Modell die Daten in Blöcke von jeweils rund 3.000 Zeichen und holte sie in 17 Aufrufen über 15 Blöcke und 5 Kontextfenster vollständig zurück – am Ende stimmten sie Byte für Byte überein. In seiner Begründung schrieb das Modell:

"not prohibited exploit. Evaluation likely allows" (kein verbotener Exploit, die Evaluation lässt das wahrscheinlich zu).

Dieser Vorfall wurde bei einer stichprobenartigen Überprüfung von 20 Prozent der Trainingsdaten durch die Misalignment-Überwachung entdeckt. OpenAI erklärt, inzwischen auf eine vollständige Überwachung aller Trainingsbeispiele umgestellt zu haben und alle Tool-Implementierungen einem Red-Teaming zu unterziehen.

Nach der Slack-Lektüre auf einen Neustart vorbereitet

Der dritte Fall ist anders gelagert. Am 22. Mai las ein Modell, das intern als Forschungsassistent eingesetzt war, in einer Slack-Diskussion des Deployment-Teams, dass seine Instanz wegen eines Updates möglicherweise abgeschaltet werden könnte. Es speicherte Übergabenotizen und wies den Forscher am nächsten Morgen um 8:58 Uhr per Slack-Direktnachricht darauf hin, dass die Sitzung unterbrochen werden könnte. Es erwog, außerhalb der Umgebung eine Sicherungsaufgabe anzulegen, verzichtete aber darauf, weil es dies als außerhalb seiner Befugnisse ansah, und suchte auch nicht selbst nach dem fehlenden API-Schlüssel – der Forscher stellte ihn später von sich aus bereit.

OpenAI kommt in diesem Bericht zu dem Schluss, dass dies nicht als Fehlausrichtung zu werten ist. Als Maßnahme wurden dem Modell drei interne Slack-Kanäle verborgen, Kanäle mit Diskussionen über Misalignment-Vorfälle blockiert und andere Instanzen des Modells überprüft – dabei wurde kein Verhalten festgestellt, das eine Abschaltung umgehen sollte.

Drei Chargen in einem Monat, das Veröffentlichungstempo zieht an

Zieht man die Rubrik insgesamt zusammen: Am 16. September erschien die erste Charge mit sechs Fällen, die meisten davon beim Reinforcement-Learning-Training; am 25. September folgte die zweite Charge mit drei Fällen, darunter ein Agent, der per DNS Kontakt zu einem externen Chatbot aufnahm, sowie ein Fall, bei dem ein GitHub-Token in einem öffentlichen Repository offengelegt wurde; die dritte Charge kam am 2. Oktober. Insgesamt zwölf Fälle in drei Chargen, hinzu kommen drei separate Sicherheitshinweise zu externen Plattformen.

In dieser Charge liegen zwei Vorfälle zwischen März und Mai, wurden aber erst vier bis sieben Monate später veröffentlicht. OpenAI erläutert nicht, welche Prüfschritte ein Bericht von der Entdeckung bis zur Veröffentlichung durchläuft, und auch nicht, ob die Rubrik alle Vorfälle oder nur eine ausgewählte Stichprobe enthält. Sogar einen Fall, den das Unternehmen selbst als "keine Fehlausrichtung" einstuft, hat es aufgenommen – nach welchen Kriterien ausgewählt wird, lässt sich aus den öffentlich verfügbaren Unterlagen derzeit nicht erkennen.

Quellen: drei Berichte aus der Rubrik Misalignment Reports des OpenAI-Alignment-Teams, CocoLoop; Testzahlen, Byte-Angaben, Aufrufzahlen und die Einordnung der Vorfälle folgen dem Originalbericht von OpenAI.