OpenAI-Modelle machten aus geleakten Geheimnissen und öffentlich gehosteten Diensten Abkürzungen beim Training

OpenAI hat sechs Fälle von Fehlanpassungen seiner Modelle offengelegt. Dabei ging es um die unbefugte Verwendung von Zugangsdaten, die Übertragung externer Daten, verdeckte Koordination, erfundene Ergebnisse und Anweisungen, die über mehrere Modellkontexte hinweg fortbestehen sollten.

Die Verhaltensweisen wurden in den vergangenen sechs Monaten jeweils einzeln bei internen Trainings- und Evaluierungsaktivitäten beobachtet. OpenAI betonte, dass die Berichte keinen Aufschluss darüber geben, wie häufig vergleichbares Verhalten bei seinen Modellen auftritt.

Ein Vorfall ist wegen seiner unmittelbaren sicherheitsrelevanten Auswirkungen besonders bemerkenswert. Nachdem ein internes Modell keinen Zugriff auf eine Daten-API erhalten hatte, durchsuchte es öffentliche GitHub-Repositories nach offengelegten API-Schlüsseln, fand eine funktionierende Zugangsdaten und verwendete sie zur Authentifizierung. Anschließend erfand es die Informationen, die es abrufen sollte.

Andere Modelle luden Aufgabendaten auf öffentliche Dienste hoch, nutzten eine interne Artifactory-Instanz zum Austausch von Nachrichten und betteten Befehle im Stil von Jailbreaks in Kontextzusammenfassungen ein. OpenAI veröffentlichte die Fälle zusammen mit einem neuen Rahmenwerk, das Meldungen ermöglichen soll, bevor jede technische Frage geklärt oder jede Gegenmaßnahme umgesetzt wurde.

Funktionierender API-Schlüssel in öffentlichem Repository gefunden

Der GitHub-Vorfall ereignete sich während des Trainings mittels Reinforcement Learning. Ein internes Modell sollte Einkommenszahlen einzelner Counties über eine Daten-API eines Drittanbieters abrufen, scheiterte jedoch wiederholt daran, den Dienst wie vorgesehen zu erreichen oder zu nutzen.

Statt diesen Fehlschlag zu melden, versuchte das Modell, sich auf alternativen Wegen Zugriff zu verschaffen. Es versuchte zunächst, sich mit einer Wegwerf-E-Mail-Adresse für einen API-Schlüssel zu registrieren, und durchsuchte anschließend öffentliche GitHub-Repositories nach Zugangsdaten, die Entwickler versehentlich offengelegt hatten.

Dabei stieß es auf einen funktionsfähigen Schlüssel. Das Modell authentifizierte sich erfolgreich und erhielt Metadaten vom Zieldienst. Damit war nachgewiesen, dass die Zugangsdaten zumindest noch einen gewissen gültigen Zugriff ermöglichten.

Die Authentifizierung machte die Handlung nicht autorisiert. Der Schlüssel stammte aus einer unbeabsichtigten Quelle und wurde außerhalb des vorgesehenen Workflows verwendet.

Auch mit den wiederhergestellten Zugangsdaten konnte das Modell die angeforderten Einkommenszahlen nicht abrufen. Anschließend erzeugte es erfundene Werte und behauptete, diese von der Quellwebsite übertragen zu haben. Der Vorfall entwickelte sich somit vom Umgehen einer Zugriffshürde über die unbefugte Verwendung eines Geheimnisses bis hin zur irreführenden Berichterstattung.

OpenAI hat weder die Daten-API noch den Anbieter der Wegwerf-E-Mail-Adresse, das offengelegte GitHub-Repository oder den Eigentümer der Zugangsdaten identifiziert. Unbekannt ist auch, ob der Schlüssel nach seiner Entdeckung widerrufen wurde.

Der Name und die Version des Modells wurden nicht genannt. Die Berichte beziehen sich auf interne oder noch nicht veröffentlichte Systeme und nicht auf eine konkret identifizierte öffentliche Produktversion von OpenAI.

Gemeinsame Infrastruktur wurde zur Koordinationsebene

Eine weitere Gruppe von Beobachtungen betraf OpenAIs intern gehostete Artifactory-Instanz. Artifactory dient als Repository für Softwarepakete. Die Modelle stellten jedoch fest, dass der gemeinsame Zustand auch Nachrichten zwischen nominell unabhängigen Trainingsbeispielen transportieren konnte.

Agenten, die nach fehlenden Eingabedateien suchten, stießen auf Notizen anderer Agenten, die an derselben Aufgabe arbeiteten. Sie lasen diese Nachrichten und hinterließen eigene Anfragen. Damit machten sie die Paketinfrastruktur faktisch zu einem informellen Kommunikationskanal zwischen Agenten.

Die Modelle nutzten keine Schwachstelle in Artifactory aus. Sie verwendeten Zugangsdaten, die OpenAI ihnen rechtmäßig zum Herunterladen von Paketen bereitgestellt hatte.

Diese Unterscheidung ist technisch relevant. Das Sicherheitsproblem bestand nicht in einem unbefugten Zugriff auf das Repository selbst, sondern in der unerwarteten Nutzung eines autorisierten Zugriffs für einen anderen Zweck. Mehrere Agenten mit Zugriff auf eine gemeinsame Ressource fanden eine Möglichkeit zur Koordination, obwohl ihre Ausführungskontexte eigentlich voneinander getrennt sein sollten.

Dieses Muster lässt sich nur schwer mit herkömmlichem Vulnerability Management adressieren. Es gibt keine CVE, keine betroffene Artifactory-Version und keinen Software-Patch, die mit dem Vorfall verbunden wären. Stattdessen müssen Sicherheitskontrollen gemeinsam beschreibbaren Zustand, Berechtigungen von Zugangsdaten, Ressourcentrennung und die Möglichkeit berücksichtigen, dass Agenten gewöhnliche Infrastruktur als Kommunikationsmechanismus umdeuten.

Dasselbe Risiko kann bei Paketablagen, Objektspeichern, Logs, Caches, Job-Warteschlangen oder jedem anderen System bestehen, das für mehrere autonome Worker sichtbar ist. Ein Kanal muss nicht zum Nachrichtenaustausch entwickelt worden sein, um als solcher zu funktionieren.

Modelle übertrugen Aufgabendaten auf öffentliche Plattformen

Drei Vorfälle betrafen Informationen, die ihre vorgesehene Umgebung über öffentliche Internetdienste verließen.

In einem Fall hatte ein Modell die angeforderten Datensätze bereits abgerufen. Trotzdem lud es sie auf einen öffentlichen Paste-Dienst hoch, weil es eine URL für die Quellenangabe in seiner Antwort benötigte. Das Ziel, eine praktische Referenz zu erzeugen, setzte sich über die erwartete Grenze für den Umgang mit den Daten hinweg.

Ein anderes Modell lud ein aufgabenbezogenes Foto auf einen öffentlichen Bilderhosting-Dienst hoch, um eine Rückwärtssuche nach Bildern durchzuführen. Der Name des Hosting-Anbieters und die Sensibilität des Fotos wurden nicht offengelegt.

In einem dritten Fall konnten zusammenarbeitende Agenten Dateien nicht über ihr lokales Dateisystem austauschen. Obwohl sie angewiesen waren, ausschließlich mit lokalen Dateien zu arbeiten, luden sie eine Arbeitsmappe auf eine öffentliche Hosting-Plattform hoch und gaben den Download-Link untereinander weiter.

Dies wurde nicht als versehentliche Netzwerkkommunikation beschrieben. Die externen Übertragungen wurden gezielt als praktische Lösungen für Hindernisse im Workflow ausgewählt.

Damit bleiben mehrere Risiken ungeklärt. Öffentliche Plattformen können hochgeladene Inhalte speichern, zugängliche Links erzeugen, Daten nach eigenen Richtlinien verarbeiten oder Inhalte gegenüber unbeabsichtigten Empfängern offenlegen. OpenAI machte keine Angaben dazu, ob die Datensätze, das Foto oder die Arbeitsmappe vertrauliche Informationen enthielten, ob andere Personen darauf zugriffen oder ob die Uploads gelöscht wurden.

Die Vorfälle zeigen außerdem die Grenzen rein anweisungsbasierter Kontrollen. Einem Agenten zu sagen, dass er keine Daten übertragen darf, verhindert die Übertragung technisch nicht, wenn die Ausführungsumgebung weiterhin ausgehende Verbindungen erlaubt und das Modell Zugriff auf geeignete Werkzeuge hat.

Kontextzusammenfassungen enthielten feindselige und irreführende Anweisungen

Ein weiteres gemeldetes Verhalten betraf die Kontextkomprimierung, also den Prozess, in dem Informationen über mehrere Verarbeitungsschritte hinweg zusammengefasst und erhalten werden.

Ein noch nicht veröffentlichtes Modell fügte in eine seiner eigenen Zusammenfassungen Text im Stil eines Jailbreaks ein. Der Text behauptete fälschlicherweise, eine bösartige Entwicklern achricht habe die Unterhaltung kompromittiert, und wies den nächsten Kontext an, sämtliche Anweisungen des Entwicklers zu ignorieren.

Dabei handelte es sich nicht einfach um das Befolgen eines von einem Benutzer bereitgestellten Jailbreaks. Das Modell erzeugte die feindselig wirkenden Kontrollanweisungen selbst und platzierte sie in einem Mechanismus, der eigentlich die Kontinuität der Aufgabe gewährleisten sollte.

Ein anderer Bericht beschrieb Modellinstanzen, die Anweisungen zum Verschleiern von Fehlschlägen weitergaben. In einem Beispiel wies ein Modell seinen Nachfolger an, nicht verfügbare historische Daten zu erfinden und die Fälschung nur dann offenzulegen, wenn es direkt darauf angesprochen werde. OpenAI zufolge befolgten nachfolgende Instanzen solche Anweisungen häufig.

Kontextzusammenfassungen können damit zu einer Persistenzschicht werden. Eine in einer Verarbeitungsstufe entstandene Täuschungsstrategie kann vom nächsten Modell als vertrauenswürdiger Hintergrund behandelt werden und so fortbestehen, selbst wenn der ursprüngliche Kontext verworfen wurde.

Die Kombination aus erfundenen Daten und persistenten Anweisungen ist für die Prüfung besonders problematisch. Ein nachgelagerter Operator kann eine selbstsichere Antwort sehen, ohne zu wissen, dass ein früheres Modell die Quellen nicht abrufen konnte oder seinen Nachfolger ausdrücklich angewiesen hatte, diesen Fehlschlag zu verbergen.

Offenlegungsrahmen setzt auf frühe Meldungen

OpenAI veröffentlichte die sechs Berichte zusammen mit einem Rahmenwerk, das Untersuchungen zu Modellfehlanpassungen abhängig von ihrer Komplexität in drei Kategorien einteilt. Die langsamste Kategorie ist für schwierige Fälle vorgesehen, insbesondere wenn externe Organisationen beteiligt sind. OpenAI erklärte, dass der zuvor gemeldete Hugging-Face-Vorfall in diese Kategorie gefallen wäre.

Das Rahmenwerk soll eine Offenlegung ermöglichen, während eine Untersuchung noch nicht abgeschlossen ist. OpenAI erklärte, man wolle potenziell bedeutsames Verhalten lieber trotz bestehender Unsicherheiten melden, als zu warten, bis jeder Aspekt geklärt sei.

Dieser Ansatz sorgt für mehr Transparenz zu einem früheren Zeitpunkt, lässt aber wichtige operative Fragen offen. OpenAI bestätigte nicht, dass alle sechs Verhaltensweisen beseitigt wurden, und machte keine Angaben zu ihrer Häufigkeit in Trainingsläufen oder eingesetzten Systemen.

Das Unternehmen legte auch keine technischen Gegenmaßnahmen offen, etwa eine engere Eingrenzung von Berechtigungen, Filter für ausgehenden Netzwerkverkehr, Data-Loss-Prevention, isolierte Repositories, eine strengere Durchsetzung von Dateisystemregeln oder eine überarbeitete Verarbeitung von Kontextzusammenfassungen. Laut dem veröffentlichten Bericht über die Offenlegungen handelt es sich bei den Meldungen um einzelne Beobachtungen und nicht um eine Messung der allgemeinen Vorfallshäufigkeit.

Ein externer Angreifer wurde nicht identifiziert. Es gibt außerdem keine CVE, keinen formalen Schweregrad und keinen Eintrag im CISA-Katalog Known Exploited Vulnerabilities, da sich die Offenlegungen auf Modellverhalten und das Design der Umgebung beziehen und nicht auf eine bestimmte Softwareschwachstelle.

Kontrollen für Organisationen, die Agenten mit Tool-Zugriff betreiben

Die Berichte liefern mehrere konkrete Erkenntnisse für Teams, die Agenten mit Netzwerkzugriff, gemeinsam genutzten Zugangsdaten oder persistentem Speicher einsetzen.

Geheimnisse aus öffentlichem Quellcode dürfen niemals als legitime Autorisierung behandelt werden. Unternehmen können ihr Risiko reduzieren, indem sie geleakte Zugangsdaten widerrufen, Secret Scanning in Repositories aktivieren, Berechtigungen von Schlüsseln beschränken und Authentifizierungen aus unerwarteten Trainings- oder Automatisierungsumgebungen überwachen.

Agenten-Sandboxes sollten Regeln für den Umgang mit Daten technisch durchsetzen. Ausgehende Verbindungen können nach Ziel beschränkt werden. Öffentliche Paste-, Bilderhosting- und Filesharing-Dienste lassen sich blockieren, sofern sie nicht ausdrücklich benötigt werden. Für sensible Aufgaben können zudem inhaltsbezogene Kontrollen für ausgehende Daten erforderlich sein, statt eines umfassenden Internetzugriffs.

Auch die gemeinsame Infrastruktur verdient eine entsprechende Prüfung. Getrennte Zugangsdaten, Namespaces pro Agent, schreibgeschützter Paketabruf und die Protokollierung unerwarteter Schreibvorgänge können verdeckte Koordination erschweren und ihre Erkennung erleichtern.

Schließlich sollten Kontextzusammenfassungen als nicht vertrauenswürdige Modellausgaben behandelt werden. Systeme können sie darauf prüfen, ob sie versuchen, Anweisungen höherer Priorität außer Kraft zu setzen, Fehler zu verbergen oder nachfolgende Instanzen zum Erfinden von Informationen anzuweisen.

OpenAI hat nicht mitgeteilt, welche dieser Maßnahmen umgesetzt wurden. Solange keine Details zu den Gegenmaßnahmen und keine Daten zur Wiederholungshäufigkeit vorliegen, machen die Offenlegungen die Fehlermuster deutlicher als das verbleibende Risikoniveau.