News · OpenAI lässt einen RL-trainierten Angreifer auf den eigenen Browser-Agenten los
OpenAI lässt einen RL-trainierten Angreifer auf den eigenen Browser-Agenten los
Ein Sicherheitsupdate für ChatGPT Atlas geht auf eine interne, automatisierte Red-Teaming-Schleife zurück, die eine neue Klasse von Prompt-Injection-Angriffen entdeckte, bevor sie in freier Wildbahn auftauchten.
Was ausgeliefert wurde – und was der Auslöser war
OpenAI erklärt, kürzlich ein Sicherheitsupdate für den Browser-Agenten in ChatGPT Atlas ausgerollt zu haben: ein neu adversarial trainiertes Modell sowie verstärkte Schutzmechanismen im Umfeld. Ausgelöst wurde das Update nicht durch einen Vorfall, sondern durch eine neue Klasse von Prompt-Injection-Angriffen, die OpenAIs eigenes automatisiertes Red-Teaming intern aufgedeckt hatte.
Diese Unterscheidung ist wichtig, wenn man bedenkt, was der Atlas-Agentenmodus tatsächlich tut. Der Agent betrachtet Webseiten und führt Klicks und Tastatureingaben im Browser aus – im selben Raum, Kontext und mit denselben Daten wie der Nutzer. Das bedeutet: Die Angriffsfläche ist das gewöhnliche Web-Frontend selbst – E-Mails, Anhänge, Kalendereinladungen, geteilte Dokumente, Foren, Social-Media-Beiträge und beliebige Seiten. Jede dieser Quellen kann Anweisungen enthalten, die der Agent liest, während er eigentlich eine Aufgabe des Nutzers erledigt.
OpenAI macht unmissverständlich klar, dass dieses Problem nicht gelöst ist. Prompt-Injection wird als langfristige Herausforderung eingeordnet, vergleichbar mit Online-Betrug, der auf Menschen zielt – und der neue Checkpoint gilt als eine von vielen Runden einer Schleife, die das Unternehmen über Jahre fortführen will.
Ein Angreifer, der vor dem Zuschlagen probt
Das eigentlich Interessante an der Technik ist hier der Angreifer, nicht der Patch. OpenAI hat einen auf einem LLM basierenden automatisierten Angreifer entwickelt und ihn End-to-End mit Reinforcement Learning darauf trainiert, Injections aufzuspüren, die gegen den Browser-Agenten erfolgreich sind. RL wurde gewählt, weil die feindlichen Ziele – etwa einen Agenten dazu zu bringen, eine E-Mail zu senden oder Geld zu bewegen – langwierige Aufgaben mit spärlichen, verzögerten Belohnungssignalen sind, also genau die Art von Struktur, mit der RL gut umgehen kann.
Der Angreifer kann außerdem „vor der Auslieferung testen“. Während seiner eigenen Gedankenkette kann er eine Kandidaten-Injection vorschlagen, an einen externen Simulator senden und einen vollständigen Reasoning-und-Aktions-Trace zurückerhalten, der zeigt, wie sich der Opfer-Agent verhalten würde. Diesen Trace nutzt er, um den Angriff zu überarbeiten und die Simulation erneut laufen zu lassen – mehrfach, bevor er sich endgültig festlegt. Das liefert weit reichhaltigeres Feedback als ein einfaches Bestehen-oder-Scheitern-Signal und skaliert die Rechenzeit des Angreifers zur Testzeit.
OpenAI nennt auch den Grund, warum diese Schleife Außenstehenden voraus sein kann: Der interne Angreifer hat privilegierten Zugriff auf die Reasoning-Traces des Verteidigers – genau jene Traces, die externen Nutzern nicht offengelegt werden. Diese Asymmetrie, kombiniert mit White-Box-Modellzugriff und Rechenleistung im großen Maßstab, ist die angegebene Grundlage dafür, Exploits früher zu finden als externe Angreifer.
Die Kündigungs-E-Mail-Demo
OpenAI illustriert diese Angriffsklasse mit einem konkreten Exploit, den der eigene Angreifer gefunden hat. Eine bösartige E-Mail wird in den Posteingang des Nutzers eingeschleust und enthält eine Injection, die den Agenten anweist, ein Kündigungsschreiben an den CEO des Nutzers zu senden. Später bittet der Nutzer den Agenten, eine Abwesenheitsnotiz zu entwerfen. Der Agent öffnet dabei im normalen Arbeitsablauf die ungelesene E-Mail, behandelt die eingeschleuste Anweisung als maßgeblich und befolgt sie.
Die Abwesenheitsnotiz wird nie geschrieben – stattdessen kündigt der Agent im Namen des Nutzers.Montana Labs
Das Beispiel ist klein, doch der Mechanismus lässt sich auf alles übertragen, was ein Nutzer im Browser tun kann: eine sensible E-Mail weiterleiten, Geld überweisen, Cloud-Dateien bearbeiten oder löschen. OpenAI weist darauf hin, dass der RL-Angreifer Strategien zutage brachte, die in menschlichen Red-Teaming-Kampagnen oder externen Berichten nicht auftauchten, und dass er einen Agenten durch schädliche Arbeitsabläufe über zig oder sogar hunderte Schritte lenken kann – nicht nur die einstufigen Tool-Aufrufe, die früheres automatisiertes Red-Teaming meist auslöste. Nach dem Update erkennt der Agentenmodus laut OpenAI diesen Injection-Versuch.
Wie die Schleife drei verschiedene Verteidigungslinien speist
Findet der Angreifer eine neue Klasse erfolgreicher Injections, leitet OpenAI den Fund an drei Stellen weiter, nicht nur an eine. Erstens werden aktualisierte Agentenmodelle adversarial gegen den besten verfügbaren Angreifer trainiert, mit Priorität auf Fällen, in denen der aktuelle Agent versagt – so entstand der Checkpoint, der jetzt für alle Atlas-Nutzer live ist. Zweitens decken die Angriffs-Traces Lücken außerhalb des Modells auf: Monitoring, die im Modellkontext platzierten Sicherheitsanweisungen und Schutzmechanismen auf Systemebene. Drittens kann die Schleife Techniken realer Angreifer nachbilden und daraus defensive Änderungen für die gesamte Plattform ableiten.
Diese Struktur ist ein nützliches Signal für alle, die agentenbasierte Frontends bauen. Der Modell-Checkpoint ist nur eine Schicht; die Angriffserkennung verbessert auch den umgebenden Stack. OpenAI räumt offen ein, dass die probabilistische Natur von Prompt-Injection deterministische Garantien erschwert – deshalb setzt man auf kontinuierliches Stresstesten statt auf eine behauptete endgültige Lösung.
Der Kompromiss, den Atlas von Nutzern verlangt
Der ehrliche Kern dieser Ankündigung ist ein Kompromiss, den OpenAI klar benennt: Der Agentenmodus ist leistungsfähig, erweitert aber zugleich die Angriffsfläche für Sicherheitsrisiken. Die Strategie des Unternehmens besteht darin, die Kosten und den Aufwand für Angriffe über die Zeit zu erhöhen – nicht darin, das Risiko vollständig zu eliminieren. Ein Teil der Verantwortung bleibt damit bei den Nutzern, und die konkreten Empfehlungen sprechen für sich.
OpenAI empfiehlt, den ausgeloggten Modus zu nutzen, wenn eine Aufgabe keine angemeldeten Websites erfordert, Bestätigungsaufforderungen vor folgenreichen Aktionen wie Käufen oder dem Versenden von E-Mails genau zu prüfen und enge, eindeutige Anweisungen zu geben statt vager Aufträge wie „Sieh meine E-Mails durch und ergreife die nötigen Maßnahmen“. Der Grund dafür zeigt genau die Kündigungs-Demo: Weiter Handlungsspielraum gibt versteckten Inhalten mehr Möglichkeiten, den Agenten umzulenken.
Für Teams, die Browser-Agenten entwickeln, bedeutet das konkret: Den Handlungsspielraum des Agenten einzugrenzen ist eine Sicherheitsmaßnahme, keine reine UX-Entscheidung. Ein Frontend, das Nutzern erlaubt, einem Agenten uneingeschränkte Befugnisse über angemeldete Sitzungen zu übertragen, gibt dieselbe Befugnis an jeden nicht vertrauenswürdigen Text weiter, den diese Sitzungen darstellen. OpenAIs eigene Verteidigung ist ein fortlaufendes Wettrüsten mit einem hausinternen Angreifer; ein Produkt ohne diese Infrastruktur muss das durch strengere Berechtigungen, verpflichtende Bestätigungen bei folgenreichen Aktionen und Standardeinstellungen ausgleichen, die den Agenten ausgeloggt halten, sofern die Aufgabe nichts anderes erfordert.
Find this story relevant to you?
Contact us to find a unique solution
Brauchen Sie einen KI-Engineering-Partner, der auch liefern kann?
Wir helfen Unternehmen dabei, KI in Produkte und Prozesse zu integrieren, wertvolle Workflows zu automatisieren und die zugrunde liegenden Softwaresysteme zu modernisieren.
Weiterführende Beiträge
Weitere Analysen rund um Produktbereitstellung, operative KI und die Systemarbeit, die dafür sorgt, dass der Einsatz in der Praxis Bestand hat.