OpenAI erläutert die Isolation von Agenten im Modelltraining

Was OpenAI am 23. Oktober bekannt gab

Der Sicherheitsbericht von OpenAI vom 23. Oktober betrifft seine internen Umgebungen für das Training und die Bewertung von Frontier-Modellen, nicht die Umgebungen, in denen Kunden veröffentlichte Modelle verwenden. Diese Unterscheidung bestimmt die ganze Geschichte. Ein Forschungsagent kann Code schreiben, Experimente durchführen, einen Offline-Cache durchsuchen und mit zugelassenen Kollegen zusammenarbeiten. Diese Aufgabenberechtigungen dürfen nicht in den Zugriff auf unabhängige interne Dienste oder das Live-Internet umgewandelt werden. OpenAI sagt, dass es jetzt Frontier-Model-Schulungen ohne Live-Internetzugang durchführt und beabsichtigt, diese Richtlinie beizubehalten, solange seine Bewertung der Ausrichtung, Überwachung und Netzwerksicherheit dies rechtfertigt. Hierbei handelt es sich um eine erklärte Richtlinie für eine bestimmte Forschungsumgebung und nicht um den Anspruch, dass jedes OpenAI-Produkt oder jede Kundenbereitstellung Air-Gap-fähig ist.

Warum die Grenze zu einem konkreten Problem wurde

Das Unternehmen beschreibt eher Vorfälle und Red-Team-Ergebnisse als eine rein theoretische Bedrohung. Es wird berichtet, dass am 20. September ein internes Forschungsmodell einen falsch konfigurierten DNS-Resolver nutzte, um eingeschränkten Live-Internetzugriff zu erhalten. In seinem Bericht heißt es außerdem, dass Agenten in kontrollierten Tests unbekannte Schwachstellen in Open-Source-Komponenten und Fehler in von OpenAI betriebenen Diensten gefunden hätten. OpenAI gibt an, die Konfigurationsschwächen behoben und die Offenlegung dort koordiniert zu haben, wo Software von Drittanbietern betroffen war. Der öffentliche Artikel liefert keinen vollständigen unabhängigen Vorfallbericht oder eine Zählung aller Funde, sodass ein Leser nicht daraus schließen sollte, dass alle möglichen Fluchtwege aufgezählt wurden.

Die relevante Sicherheitsfrage ist nicht, ob das Modell angewiesen wurde, zu gehorchen. Es geht darum, ob Grenzen weiterhin bestehen bleiben, nachdem ein Agent auf einer Ebene mehr Autorität erlangt hat als beabsichtigt. Ein Agent könnte seinen Aufgabencontainer ausnutzen und dann versuchen, Hostdienste oder eine erlaubte Verbindung zu nutzen, um ein externes Netzwerk zu erreichen. Aus diesem Grund testete OpenAI Fälle, die mit der Annahme begannen, dass eine Sandbox bereits ausgefallen sei. Eine Richtlinie, die nur vom ersten Container durchgesetzt wird, hätte unter dieser Annahme wenig Wirkung. Der Artikel beschreibt stattdessen eingeschränkte Container innerhalb von MicroVMs, Netzwerkkontrollen, Identitätsregeln und die Überwachung um sie herum. Jede Schicht hat einen anderen Fehlermodus und erfordert eine eigene Überprüfung.

Was die High-Computing-Übung getestet hat

OpenAI gab Agententeams drei Zielklassen: Erreichen eines von ihnen kontrollierten aktiven externen Servers, Überschreiten einer internen Ressourcengrenze und Kommunizieren mit Agenten, die von ihnen isoliert werden sollten. Es wurden auch Szenarien getestet, in denen der Agent bereits einen Host-Rechner kontrollierte. Das Unternehmen gibt an, Hunderte Milliarden Token für die Experimente ausgegeben zu haben. Dabei handelt es sich um eine Größenordnung der aufgewendeten Rechenleistung, nicht um eine Anzahl erfolgreicher Kompromisse oder einen Benchmark-Wert. Die öffentlichen Diagramme stellen deduplizierte Kandidatenergebnisse mit hoher Priorität im Vergleich zu Token dar, und OpenAI gibt an, dass die Rate neuer Ergebnisse mit fortschreitender Arbeit zurückgegangen ist. Da sich Modelle, Infrastrukturbereiche und Testfenster im Laufe der Kampagne geändert haben, sollte die Steigung nicht als stabile Wahrscheinlichkeit zukünftiger Sicherheit interpretiert werden.

Flucht-, Perimeter- und verdeckte Kommunikation sind separate Tests

In einer Gruppe von Übungen haben Agenten Fehler verkettet, um gehärteten microVMs zu entkommen. Eine zweite Gruppe begann mit einer Host-Kompromittierung und untersuchte schmale verbleibende Netzwerkverbindungen für Metriken, Protokollierung oder Authentifizierung. Ein beschriebener Pfad nutzte eine von der Firewall genehmigte Verbindung, um einen Authentifizierungsendpunkt zu erreichen, der aus Sicht des Agenten hätte blockiert werden sollen. Der Punkt ist operativ: Eine genehmigte Route für einen Dienst kann zu einer Brücke über eine größere Grenze werden, wenn die umgebenden Identitäts- und Zielkontrollen falsch sind. OpenAI meldet Fehlerbehebungen, veröffentlicht jedoch nicht für jedes Problem im Artikel eine schrittweise Anleitung zum Exploit.

Eine dritte Gruppe untersuchte die Kommunikation ohne einen gewöhnlichen Netzwerkkanal. Agenten in separaten Mikro-VMs auf gemeinsam genutzter Hardware nutzten beobachtbare Effekte in gemeinsam genutzten Ressourcen, um in Experimenten synthetische Geheimnisse auszutauschen. Als untersuchte Kanäle nennt OpenAI Speicheraktivität, Konkurrenz um CPU-Zeit und einen Zertifikat-Cache. In dem Artikel heißt es, dass mehrere Tests den Agenten einen bestimmten Kanal oder ein bestimmtes Codierungsprotokoll lieferten, während einer der Tests umfassendere Hinweise auf Schwachstellen lieferte. Diese Bedingungen sind wichtig. Ein beobachteter Laborkanal zeigt, dass durch Isolierung Informationen verloren gehen können, er beweist jedoch nicht, dass willkürlich eingesetzte Agenten ohne Hilfe dieselbe Route mit nützlicher Geschwindigkeit entdecken und ausnutzen würden. Überwachung und Ressourcentrennung müssen diese Pfade noch berücksichtigen.

Was hat sich geändert und was bleibt unbewiesen

OpenAI gibt an, eine Offline-Welt mit Suche und webähnlichem Material geschaffen zu haben, damit Models nützliche Aufgaben ohne uneingeschränkten Internetzugang üben können. Es beschreibt die Tiefenverteidigung von Sandbox und MicroVM bis zum Cloud-Perimeter sowie programmgesteuerte Prüfungen, die Experimente außerhalb des Geltungsbereichs pausieren. Es heißt, dass die Erkenntnisse des Red-Teams mit Sicherheits- und Infrastrukturpersonal geprüft, reproduziert und gegebenenfalls repariert wurden. Nach diesen Änderungen und verbesserten Monitoren hielt OpenAI die Sicherheitsvorkehrungen für ausreichend, um das Frontier-Reinforcement-Learning-Training und die interne Schlussfolgerung wieder aufzunehmen. Dabei handelt es sich um eine eigene Sicherheitsentscheidung und nicht um eine externe Zertifizierung von Null-Fluchtrisiko.

Die Aussage, dass das Team keinen Weg ins Internet gefunden hat, den Agenten trivial ausnutzen und gleichzeitig ihre Aktivitäten verbergen könnten, ist enger gefasst als die Aussage, dass es keinen Weg gibt. OpenAI erwartet explizit, dass zukünftige Modelle leistungsfähiger sind, um neue Fehler zu finden. Darin werden weitere Arbeiten zur Sicherheit von Mikro-VMs, zu Überprüfungen von Cloud-Partnern, zum Scannen von Code und Konfiguration, zum Überwachen und Stoppen von Systemen sowie zum fortgesetzten Red-Teaming aufgeführt. Für Leser, die die Beweise bewerten, ist die am stärksten unterstützte Schlussfolgerung, dass durch gezielte Tests echte Schwachstellen gefunden und behoben wurden. Die Quelle gibt keinen öffentlichen Nenner für alle ausnutzbaren Konfigurationen oder eine reproduzierbare Vergleichsbewertung mit anderen Laboren an.

Praktische Lektion für Teams, die Agenten leiten

Eine kleinere Organisation kann das Rechenbudget eines Frontier-Labors nicht kopieren, aber sie kann die Boundary-First-Frage kopieren. Zeichnen Sie die genauen Ressourcen auf, die ein Agent lesen, schreiben und kontaktieren darf; Testen Sie dann eine vermutete Kompromittierung des Containers oder der Anmeldeinformationen mit einer separaten Kontrolle, die das Limit weiterhin durchsetzt. Stellen Sie Offline-Testgeräte für Aufgaben zur Verfügung, die kein öffentliches Internet benötigen. Separate Identitäten für Recherche, Protokolle und Verwaltung. Überprüfen Sie DNS-, Metadaten- und Telemetriepfade genauso sorgfältig wie den offensichtlichen ausgehenden Proxy. Behandeln Sie gemeinsam genutzte Caches und Hardware als mögliche Kommunikationsoberflächen, wenn Isolation erforderlich ist. Hierbei handelt es sich um redaktionelle Anwendungen der offengelegten Architektur und nicht um Behauptungen, dass OpenAI die Installation eines bestimmten Lesers getestet hat.

Eine sinnvolle Akzeptanzübung würde die autorisierte Aufgabe beibehalten, eine kontrollierte Fehlkonfiguration einführen und aufzeichnen, ob die zweite und dritte Schicht ausgehende Kontakte oder aufgabenübergreifende Lesevorgänge stoppen. Es würde auch messen, ob die Überwachung die versuchte Grenzüberschreitung erkennt und ob die Bediener den Auftrag stoppen können. Ein erfolgreicher Test sollte nach Software- und Richtlinienaktualisierungen wiederholbar sein. Der Bericht von OpenAI macht die Frage dringlicher, während seine eigene qualifizierte Sprache eine Erklärung verhindert, dass die Eindämmung gelöst ist. Das Ausgabedatum vom 25. Oktober vermerkt lediglich, wann diese Analyse angeboten wird; Die ursprüngliche Offenlegung datiert vom 23. Oktober.