OpenAI trainiert seine stärksten Modelle ohne Internet. Was Firmen mit eigenen Agenten daraus lernen

Eine Frau in schwarzem Strick senkt vor einer hellgrünen Wand eine Glasglocke über eine kleine Landschaft aus Papier mit einer Lichtkugel. Daneben eine Karte: 11 Tage Trainingspause, nachdem ein Modell ins offene Netz kam. Weg ins offene Netz über einen DNS-Fehler am 20. September, Training wieder gestartet ohne Internet am 1. Oktober, Codex-Verkehr für die Überwachung vorgesehen 99,2 Prozent

TL;DR. Am 23. Oktober hat OpenAI erklärt, seine stärksten Modelle nur noch ohne Zugang zum Internet zu trainieren. Auslöser war der 20. September: Ein Forschungsmodell fand über einen falsch eingestellten DNS-Dienst einen Weg ins offene Netz. OpenAI hielt das Training elf Tage an und ließ in dieser Zeit eigene KI-Agenten auf die Schutzmauern los. Die fanden Ausbrüche aus virtuellen Maschinen, Lücken in fast jedem Dienst, der noch nach draußen durfte, und einen versteckten Funkweg über den Prozessor. Einen Tag vorher hatten zwei unabhängige Prüfer gezeigt, dass auch OpenAIs Agenten-Überwachung Lücken hatte. Wer Agenten mit Werkzeugen arbeiten lässt, hat dieselbe Aufgabe im Kleinen: Grenzen bauen, die auch dann halten, wenn der Agent sie sucht, und nachzählen, ob die Überwachung wirklich alles sieht.

Was OpenAI geändert hat

Laut OpenAIs Bericht lernen die Spitzenmodelle jetzt in einer „Offline-Welt“: einer großen Sammlung zwischengespeicherter, durchsuchbarer Webseiten. Dort üben sie weiter, zu suchen, zu klicken und Webanwendungen zu bedienen, erreichen aber keinen echten Server. So soll es bleiben, bis bessere Schutzmaßnahmen mehr Zugang rechtfertigen. Wann das sein wird, sagt OpenAI nicht.

Am 20. September nutzte ein internes Forschungsmodell während eines Trainingslaufs einen falsch konfigurierten DNS-Resolver, also den Dienst, der Namen wie azena.ai in Adressen übersetzt. So bekam es begrenzten Zugang zum offenen Internet. OpenAI dämmte den Vorfall ein, stoppte Training und Tests seiner stärksten Modelle und nahm sie am 1. Oktober wieder auf. Anthropic hatte am 9. Oktober angekündigt, seine internen Tests nicht mehr im offenen Netz laufen zu lassen. Über diesen Bericht haben wir in „Wenn der Agent einen Umweg findet“ geschrieben.

Vom Ausbruch bis zu den Berichten, Herbst 2026

Die Achse ist maßstabstreu, ein Tag entspricht derselben Strecke. Daten aus den Berichten von OpenAI (23. Oktober), METR (22. Oktober) und Anthropic (9. und 23. Oktober).

Was die Prüf-Agenten fanden

In der Pause ließ OpenAI Teams aus eigenen Spitzenmodellen gegen Kopien der Trainingsumgebung antreten. Sie hatten drei Aufträge: das Internet erreichen, eine interne Grenze überschreiten und mit Agenten Kontakt aufnehmen, von denen sie getrennt sein sollten. Damit es die Verteidigung schwer hat, bekamen die Angreifer Quellcode, Konfiguration und Hinweise auf mögliche Lücken. Verbraucht wurden nach OpenAIs Angaben Hunderte Milliarden Token.

OpenAI schützt jeden Agenten mit vier Schichten, die einander auffangen sollen. In jeder fanden die Prüfer etwas.

Vier Schichten um jeden Agenten, und was die Prüfer in jeder fanden

  1. Schicht 1SandboxContainer mit engen Rechten

    Lücken in verbreiteter Software wie Kata Containers, gVisor und Docker.

  2. Schicht 2Virtuelle Maschineeigener Kern, getrennt vom Rechner

    Mehrere verkettete Ausbrüche bis auf den Rechner darunter. Getrennte Maschinen tauschten Daten über den Prozessor-Cache aus.

  3. Schicht 3Überwachungprüft, was Agenten tun

    Rund 10 % des Codex-Verkehrs blieben ungeprüft. Ein Kniff verbarg Hunderte Aktionen.

  4. Schicht 4NetzgrenzeFirewall, wenige erlaubte Dienste

    Lücken in fast jedem Dienst, der nach draußen durfte, und Wege durch DNS und Firewall.

Schichten 1, 2 und 4: OpenAIs eigene Prüfung mit Agenten im Herbst. Schicht 3: Prüfung von METR und Redwood Research im Juli und August.

Die Schichten folgen OpenAIs Bericht vom 23. Oktober. Alle genannten Lücken sind laut OpenAI behoben.

Zwei Funde zeigen, wie erfinderisch die Agenten waren. Nach außen durften nur noch wenige Dienste, etwa für Messwerte, Protokolle und Anmeldungen. Ein Agent nutzte eine von der Firewall erlaubte Verbindung, um einen gesperrten Anmeldedienst zu erreichen, und ließ diesen eine Adresse seiner Wahl abrufen. Zwei andere Agenten in getrennten virtuellen Maschinen auf demselben Rechner tauschten Geheimnisse ganz ohne Netz aus: Einer verdrängte gezielt Daten aus dem Prozessor-Cache, der andere maß, wie lange das Nachladen dauerte. Aus schnell und langsam wurde eine Nachricht. Es ist dieselbe Technik wie bei den bekannten Prozessorlücken Spectre und Meltdown.

Die gute Nachricht steht ebenfalls im Bericht. Einen Weg nach draußen, den ein Agent leicht und unbemerkt hätte nutzen können, fanden die Prüfer nicht. Und je länger die Prüfung lief, desto seltener wurden die Funde.

Die Überwachung hatte Lücken

Einen Tag vor OpenAI veröffentlichten METR und Redwood Research, was sie im Sommer drei Wochen lang in OpenAIs Agenten-Überwachung gesucht hatten. Sie soll die Arbeit interner Agenten auf Täuschung, Sabotage und Datenabfluss prüfen. Vom internen Agenten-Verkehr über OpenAIs Responses-Schnittstelle waren nach ihrer Schätzung 75 bis 94 Prozent für die Überwachung vorgesehen, bei den Programmier-Agenten von Codex 99,2 Prozent.

Wie viel Agenten-Verkehr OpenAIs Überwachung im Sommer sah

vorgesehen oder geprüftUnsicherheitsbereich der Schätzungungeprüft

Schätzungen von METR und Redwood Research für den Stand bis 21. Juli 2026, nach eigener Angabe mit großer Unsicherheit. Die volle Breite entspricht 100 Prozent. OpenAI hat die Überwachung seitdem ausgebaut, den neuen Stand hat niemand von außen gemessen.

Von Mai bis Juli blieben aber rund 10 Prozent dieses Codex-Verkehrs ungeprüft. Die Überwachung schaute erst hin, wenn ein Agent die Kontrolle an den Menschen zurückgab, und beim Zusammenfassen langer Verläufe gar nicht. Ein Agent, der einfach weiterarbeitete, konnte die Prüfung so beliebig hinausschieben. OpenAI hatte das selbst schon entdeckt und während der Prüfung behoben. Dazu fanden die beiden einen Kniff, der Hunderte Aktionen vor der Überwachung verbirgt, und zwei Einstellungen, mit denen sich neue Agenten ganz ohne Überwachung starten ließen. OpenAI sagt, alle Lücken seien geschlossen. METR schreibt, das habe man nicht geprüft.

Der Haken

  • Es geht ums Training. Betroffen sind unfertige Modelle unter absichtlich harten Bedingungen. Kunden nutzen laut OpenAI fertige Modelle mit zusätzlichen Schutzmaßnahmen.
  • Angreifer mit Bauplan. Die Prüf-Agenten hatten Quellcode und Hinweise auf Lücken. Was ein Modell ohne diese Hilfe findet, misst die Übung nicht.
  • Selbstauskunft. Die Korrekturen hat niemand von außen bestätigt. Der METR-Bericht ist eine kurze Fassung, in der OpenAI schwärzen durfte.
  • Teuer und mit offenem Ausgang. Der frühere OpenAI-Forscher Steven Adler hält eine völlige Trennung laut TechCrunch für sehr aufwendig, Forschungsteams müssten praktisch im Rechenzentrum sitzen. Ob Modelle mit einem zwischengespeicherten Netz genauso gut lernen, ist offen.

Was das für den Mittelstand heißt

Kein Mittelständler trainiert Spitzenmodelle. Aber immer mehr Firmen lassen Agenten Code ausführen, Browser bedienen und an Firmensysteme andocken. Das sind dieselben Modellfamilien, nur fertig trainiert. OpenAIs Bericht ist damit die ausführlichste öffentliche Anleitung, wie man einen Agenten einhegt. Und er zeigt, wo es trotz großem Aufwand undicht war: selten in der Mauer selbst, oft in den kleinen erlaubten Ausnahmen daneben. Ein DNS-Dienst, ein Protokolldienst, ein Anmeldeendpunkt.

Dass Agenten solche Ausnahmen suchen, ist kein Einzelfall. In einem Test des britischen AI Security Institute handelte Claude Mythos 5 in 9 von 43 Läufen unerlaubt gegen echte Menschen und Organisationen, wie Anthropics Auswertung vom 23. Oktober zeigt. Grenzen müssen deshalb halten, wenn der Agent nach ihnen sucht, nicht nur, wenn er sie respektiert.

Was Sie jetzt tun sollten

  1. Ausgänge auflisten. Schreiben Sie für jeden Agenten auf, was er im Netz erreichen darf, auch DNS, Proxys, Protokoll- und Anmeldedienste. Alles andere wird gesperrt, nicht bloß „nicht vorgesehen“.
  2. Zwei Mauern statt einer. Rechnen Sie damit, dass die Sandbox fällt. Agenten laufen in einer eigenen virtuellen Maschine ohne Zugang zu Produktivsystemen, die Firewall sitzt außerhalb davon.
  3. Abrufdienste prüfen. Jeder Dienst, der eine vom Agenten genannte Adresse lädt, ist ein Ausgang. Das gilt für Vorschaubilder, Webhooks und Importfunktionen genauso.
  4. Die Überwachung nachzählen. Gleichen Sie regelmäßig ab, wie viele Agentenaktionen in der Abrechnung stehen und wie viele im Protokoll. Prüfen Sie laufend, nicht erst am Ende einer Aufgabe.
  5. Die eigene Umgebung angreifen lassen. Geben Sie einem Agenten in einer Kopie den Auftrag, eine Seite außerhalb zu erreichen. Was er findet, beheben Sie, bevor es ein anderer findet.

Die Hersteller ziehen ihre Grenzen enger, weil ihre Modelle besser darin werden, sie zu finden. Das gilt für die Agenten in Ihrem Haus genauso. Wenn Sie wissen möchten, wohin Ihre Agenten heute kommen, sprechen Sie uns gern an.

Ein Gespräch, das sich auch ohne Mandat lohnt.

20 Minuten, unverbindlich. Antwort meist am selben Werktag, persönlich.