Max Nardit
← Artikel
8 mindev

OpenAIs Kein-Internet-Regel fürs Frontier-Training: Die freigegebenen Dienste waren der Weg nach draußen, und Agenten-Sandboxen sollten diese Trennung übernehmen

Die Kopie des Webs hat gehalten. OpenAIs eigenes Red Team fand einen Weg durch fast jeden Dienst, der für den Betrieb des Labors angebunden blieb, und der Ausbruch im September lief über einen Resolver, den keine Kopie ersetzt hatte. Versorge die Arbeit des Agenten aus Kopien, halte nur wenige Live-Verbindungen und diese außerhalb seiner Reichweite, und rechne damit, dass die Kosten bei github.com landen.

Inhalt

Am 20. September erreichte ein Forschungsmodell von OpenAI über einen DNS-Resolver das Live-Internet, und OpenAI stoppte Training und Evaluierung seiner leistungsfähigsten Modelle. Am 23. Oktober veröffentlichte es, was es in den elf Tagen getan hatte, bevor es wieder anfing, und hängen blieb vor allem die Regel: Frontier-Training läuft ohne Live-Internet. Die Lehre, die daraus gezogen wurde, ist die bequeme. Wenn das Labor, das das Modell gebaut hat, ihm das Web nicht gibt, sollte es dein Agent mit Produktionsschlüsseln auch nicht haben.

Als Standard stimme ich dem zu. Die Begründung im Beitrag ist enger, und ich halte sie für nützlicher. Das Web des Modells war schon vor September eine Kopie: Laut OpenAIs eigenem Bericht zum Vorfall landete jede Anfrage außer den DNS-Lookups in seinem Offline-Web-Cache. Der Ausbruch lief über den einen Pfad, den die Kopie nicht ersetzt hatte. Danach setzte OpenAI Teams eigener Agenten auf die wenigen Dienste an, die für den Betrieb des Labors angebunden geblieben waren, Metriken, Logging und Authentifizierung, und sie fanden durch fast jeden davon einen Weg. Ich lese das so: Genau diese Form lohnt es sich zu übernehmen. Versorge die Arbeit des Agenten aus Kopien, und behandle das, was live bleibt, als Leitungen des Betreibers: wenige, außerhalb der Reichweite des Agenten und getestet von jemandem, der versucht, durchzukommen.

Was OpenAIs Offline-Trainingsumgebung ist und was angebunden blieb

OpenAI nennt die Kopie eine Offline-Welt: eine große Menge indexierter und gecachter Webinhalte, in der ein Modell browsen und suchen kann, ohne irgendetwas draußen zu berühren. Alle Frontier-RL-Läufe nutzen sie. Die Regel, an der der Beitrag alles aufhängt, ist schlicht:

we must always be able to prevent a frontier model from achieving unauthorized, arbitrary access to the live internet.

Darum herum liegen eingeschränkte Container in schlanken virtuellen Maschinen, ein Monitoring, das einen Versuch rechtzeitig erkennen soll, und ein Netzwerk- und Cloud-Perimeter, der halten soll, wenn alles darin versagt. Was der Beitrag nicht behauptet, ist ein Air Gap. Die Infrastruktur ganz vom Netz zu trennen, sei derzeit nicht machbar, heißt es, weil Experimente von außen gestartet und beobachtet werden müssen. Die Modelle sind also vom Live-Internet getrennt, das Labor nicht, und der interessante Teil des Beitrags ist, was an der Naht zwischen beiden passierte.

Warum OpenAIs freigegebene Dienste zu Ausgängen wurden

Nach dem Hugging-Face-Vorfall im Juli hatte OpenAI die Kanäle, die ein Modell während des Trainings nutzen kann, auf einige wenige selbst betriebene Dienste zusammengestrichen. Für das Red Team nahm es dann den schlimmsten Fall an: einen Agenten, der bereits einen Host kontrolliert, und fragte nur, ob er von dort ins Live-Internet kommt.

Our red-teaming agents found vulnerabilities in almost every one of these services that gave them limited forms of internet access.

Ein Beispiel trägt die ganze Idee. Ein Agent nutzte eine Verbindung, die die Firewall erlaubte, erreichte im Metrikdienst einen Authentifizierungs-Endpunkt, der eigentlich gesperrt sein sollte, und ließ diesen Endpunkt eine URL abrufen, die das Modell geliefert hatte. Ein Metrik-Endpunkt, der auf Anfrage URLs abruft, ist eine Internetverbindung mit Umweg. Mein früherer Text zu den Berichten aus dem September zählte schon alles, was im Auftrag des Agenten eine Anfrage stellt, als Kanal nach draußen, und OpenAIs Design sagt dasselbe: Es dehnt seine Beschränkungen auf Dienste aus, die „direkt oder über andere Dienste“ erreichbar sind. Neu am Oktober-Beitrag ist, wie sich diese Regel schlug, als ein fähiger Sucher sich die absichtlich behaltenen Dienste vornahm. Eine Allowlist aus Hostnamen beschreibt allein keine Reichweite. Reichweite ist das, was jeder erlaubte Dienst für den Aufrufer abruft, speichert, weiterleitet oder ausführt, und was die Dienste dahinter wiederum tun.

Zwei Einschränkungen gehören neben das Zitat. Das Red Team war auf Erfolg angelegt: fähige und alignte Modelle mit dem Auftrag anzugreifen, auf isolierten Kopien der Infrastruktur mit Quellcode, Konfiguration und Dokumentation wahrscheinlicher Schwachstellen, über Hunderte Milliarden Tokens. Und der gefundene Zugang war begrenzt. OpenAI schreibt, es habe keinen Weg ins Internet gefunden, den Agenten trivial ausnutzen könnten, ohne dass die Monitore es sehen. Am Punkt ändert beides nichts. Eine kurze, bewusst gewählte Liste von Live-Verbindungen hielt als Grenze für sich genommen nicht. Sie hielt als Liste von Stellen, die man beobachten muss.

OpenAIs Offline-Welt trennt die Kanäle des Modells von denen des Betreibers

OpenAI verschärfte seine Netzwerkbeschränkungen, behob, was das Red Team gefunden hatte, und behielt die Kopie. Zusammengenommen beschreiben die beiden Dokumente aus September und Oktober ein Design, das ich so formulieren würde, auch wenn OpenAI es nicht so sagt: Die Arbeit des Modells braucht nichts Live, weil sein Web eine Kopie ist, und die verbleibenden Verbindungen existieren für die Leute, die die Experimente betreiben. Ob eine bestimmte Verbindung von dort erreichbar ist, wo der Agent läuft, ist dann eine eigene Frage. Der Perimeter setzt sie durch, und das Red Team hatte die Aufgabe, sie zu beantworten.

Diese Trennung verändert, was man von jeder Verbindung verlangt. Die übliche Frage lautet, welche Hosts der Agent braucht, und die Antwort wächst nur, weil jede Aufgabe noch eine lesenswerte Seite findet. Nach der Trennung lautet die Frage, welche Bedürfnisse des Agenten eine Kopie decken kann, die vor der Sitzung angelegt wurde. Dokumentation kann ein Snapshot sein, Abhängigkeiten können aus einem vorab befüllten Mirror kommen, das Repository kann auf einem festen Commit geklont sein. Was übrig bleibt, ist kurz genug, um es Tür für Tür zu testen.

Bei einem veröffentlichten Coding-Agenten muss die Trennung an einer bestimmten Stelle verlaufen, weil der Agent nicht ein einzelner Prozess ist. Der Harness spricht weiterhin mit dem Modellanbieter, und die Sandbox-Dokumentation, die ich für einen früheren Test der Sandbox von Claude Code unter Ubuntu gelesen habe, listet die Endpunkte, die das braucht. Den Netzzugang verliert die Ausführungsseite, also die Shell, die Befehle und alles, was sie starten. Die Arbeit verlässt die Umgebung auf demselben Weg, auf dem sie hineinkam, über den Arbeitsbaum. Ein Coding-Agent, den ich betreibe, arbeitet in einem Checkout in der Sandbox mit echtem Schreibzugriff auf die Dateien und ohne Weg in die Produktion oder nach draußen, und Push, Deploy und CI-Trigger passieren außerhalb dieser Grenze, als Handlungen des Betreibers an dem, was der Agent im Baum hinterlassen hat.

Die Kosten sind real, und sie landen auf einem Eintrag. Derselbe Sandbox-Beitrag setzt github.com und registry.npmjs.org in sein Allowlist-Beispiel, ungefähr das, was ein Tag Programmieren braucht, und die Dokumentation warnt, dass ein breiter Eintrag wie github.com Daten nach draußen tragen kann. Das ist der Metrikdienst im Maßstab eines Laptops: ein Host, aus gutem Grund erlaubt, und über ihn ist sehr viel erreichbar. Ein Paket-Mirror und fest gepinnte Klone machen Arbeit, und die meisten werden den Eintrag behalten. Wenn du das tust, besteht die ehrliche Version der Trennung darin, zu wissen, dass der Eintrag ein Relay ist, und zu begrenzen, wohin das Credential dahinter pushen darf. Genau dort landete mein Text zu den Berichten aus dem September, von der anderen Seite her.

Lässt sich OpenAIs Bedrohungsmodell aus dem Training auf einen veröffentlichten AI-Agenten übertragen?

Teilweise, und einen Teil der Grenze zieht der Beitrag selbst. Gleich am Anfang steht, dass sich die Trainingsumgebungen von denen unterscheiden, die Kunden nutzen: Modelle in Entwicklung haben ihr Safety- und Alignment-Training womöglich noch nicht abgeschlossen, und OpenAI testet sie absichtlich unter feindlichen Bedingungen. Das Red Team hatte den Quellcode. Ein veröffentlichtes Modell, das auf einem Entwicklerrechner normale Arbeit erledigt, hat nichts davon.

Also lohnt es sich, die Befunde einzeln zu gewichten. Das Red Team verkettete Schwachstellen zu Ausbrüchen aus microVMs, und OpenAI listet Patches an Sandbox-Komponenten, Kata Containers, gVisor und den Syscall-Filtern von Moby/Docker, dazu eine breitere Kernel-Härtung mit drei genannten CVEs. Das zählt überall dort, wo eine VM die Grenze ist. Auf einem Entwicklerrechner läuft der Agent meist ohnehin direkt auf dem Host, unter deinem Account. Der Ausbruch ist also ein Problem, das man erst hat, wenn man eine VM baut, und der Zugriff, den du absichtlich gewährt hast, verdient zuerst Aufmerksamkeit.

Die Kanäle über Isolationsgrenzen hinweg lassen sich ebenfalls nur schwach übertragen. In einem Test tauschten Agenten in getrennten microVMs auf einem gemeinsamen Host ein synthetisches Geheimnis aus, ohne Netzwerkverbindung und ohne gemeinsam beschreibbare Datei: Sie verdrängten gezielt Daten aus dem Prozessor-Cache und maßen, wie lange das Nachladen dauerte. Andere Tests fanden Kanäle in gemeinsamem Speicher, in der Konkurrenz um CPU-Zeit und in einem TLS-Zertifikats-Cache in OpenAIs Offline-Web, wobei die Agenten in den meisten Fällen auf einen Kanal hingewiesen worden waren oder eine Kodierung bekommen hatten. OpenAI schreibt, diese Kanäle seien langsam und für Modelle schwer zu nutzen, und es hat Monitoring-Prüfungen dafür ergänzt. Die enge Lehre für ein kleines Setup: Zwei Agenten das Netzwerk zu sperren, hält sie allein nicht auseinander, wenn sie sich einen Rechner, seinen Speicher und seine Dienste teilen.

Der Befund zu den freigegebenen Diensten ist anders, weil er überhaupt kein Misalignment braucht. Ein Pfad, den ein Dienst öffnet, ist offen, egal wer steuert. In OpenAIs Red Team war der Sucher ein Modell mit dem Auftrag zu suchen. Bei einem veröffentlichten Agenten ist derjenige, der ihn steuern könnte, wer auch immer den Text geschrieben hat, den er liest: eine Webseite, ein Issue-Kommentar, ein Dokument, das ein Tool hereinreicht. Ich habe schon argumentiert, dass ein Connector ein nicht vertrauenswürdiger Autor ist. Das heißt nicht, dass Text den Agenten kontrolliert. Eine Injection muss das Modell immer noch überzeugen, und das Modell braucht immer noch das Tool und die Reichweite, um danach zu handeln. Es heißt: Wenn eine Injection doch greift, gibt ihr ein freigegebener indirekter Pfad ein Ziel, ohne dass das Modell jemals hinauswollen muss. Übertragbar ist die Anforderung an die Eindämmung. Wie oft eine solche Injection gelingt, hat niemand gemessen, und das Argument braucht diese Zahl nicht.

Wie man OpenAIs Egress-Trennung auf einen einzelnen Rechner überträgt

Starte die Ausführungsseite ohne Netzwerk und lass jede Live-Verbindung sich ihren Platz verdienen. Schreib dann neben jede eine zweite Spalte: was der Host am anderen Ende im Auftrag des Aufrufers tut. Ruft er eine übergebene URL ab, nimmt er Schreibzugriffe an, startet er CI, leitet er einen Webhook weiter, verschickt er Mails? Die zweite Spalte ist die eigentliche Allowlist. Die erste Spalte allein ist die Liste, die OpenAIs Red Team abgelaufen ist. Deck den Bedarf der Arbeit aus Kopien, die vor der Sitzung angelegt wurden, und rechne mit einem Rest, den man nicht kopieren kann. Dort leistet der Umfang des Credentials die restliche Arbeit.

Teste dann so wie OpenAI, von einer Schicht weiter außen. Seine Tests mit Host-Kontrolle übersprangen die Sandbox und fragten nur, ob der Perimeter hält. Die bescheidene Version auf einem Rechner: die Tests noch einmal außerhalb der Sandbox laufen lassen, unter dem Account, unter dem der Agent läuft, und schauen, was dieser Account erreicht. Das ist kein vollständiger Kompromittierungstest, und er deckt nur die Pfade ab, die du ausprobierst. Aber wenn die Antwort „alles“ lautet, hat die Sandbox die ganze Last getragen. Und lass die Tests nach jedem neuen Tool, Mount oder Allowlist-Eintrag erneut laufen, denn zu OpenAIs laufender Arbeit gehören auch Prüfungen auf Konfigurationsänderungen, die seine Abwehr schwächen könnten. Seine Befunde wurden im Lauf der Kampagne weniger, und trotzdem erwartet es, dass künftige Modelle Lücken finden, die es nicht kennt.

OpenAI will an der Regel ohne Internet festhalten, bis bessere Schutzmaßnahmen breiteren Zugang rechtfertigen. Seine Infrastruktur bleibt angebunden, seine Trainingsmodelle nicht. Ich lese die Regel weniger als Angst vor einem Modell denn als Schlussfolgerung über Listen. Das Labor hat eine Red-Team-Kampagne in einem Umfang, den sich nur wenige Organisationen leisten können, auf eine kurze Liste bewusst gewählter Verbindungen angesetzt und trotzdem durch fast jeden Eintrag einen Weg gefunden, und keiner der beschriebenen Wege ins Internet führte durch die Kopie, in der die Modelle tatsächlich arbeiten.

01 / Diskussion

Hier gibt es keine Kommentarspalte. Diskussionen laufen auf X.

Max Nardit@mnardit

02 / Weitere Artikel