KI-Browser-Agenten gehackt: Wie Angreifer Claude in Chrome und ChatGPT Atlas übernehmen – und was Unternehmen stattdessen einsetzen

Agentische Browser waren das Produktversprechen der Jahre 2025 und 2026: ein KI-Agent, der im Browser mitliest, Formulare ausfüllt, Termine pflegt, Bestellungen auslöst. Die Kehrseite dieses Versprechens ist inzwischen sauber dokumentiert. Zenity Labs, eine auf agentische KI spezialisierte Sicherheitsforschungsgruppe, hat am 5. August 2026 – in der Woche der Black Hat USA 2026 – gleich vier Beiträge veröffentlicht, die zeigen, wie sich diese Agenten von außen fernsteuern lassen: Claude in Chrome: Breaking down the injection, Claude in Chrome: From alert(1) to Full Account Takeover, Account Takeover via Claude in Chrome: A Technical Deep Dive und Grand Theft Atlas.

Wichtig für die Einordnung: Es handelt sich nicht um eine einzelne, benannte Schwachstelle mit CVE-Nummer, sondern um eine Angriffsklasse, die aus der Architektur agentischer Browser folgt. Wer in Sicherheitsrunden nach einem griffigen Namen sucht, wird ihn nicht finden – und sollte ihn auch nicht erfinden. Belegbar sind konkrete Ketten gegen konkrete Produkte, und die reichen völlig aus, um eine Unternehmensentscheidung zu tragen.

Wie der Angriff auf Claude in Chrome funktioniert

Die von Raul Klugman-Onitza und Joao Donato beschriebene Kette gegen Claude in Chrome ist ausdrücklich kein Zero-Click-Angriff. Sie braucht einen ganz gewöhnlichen Arbeitsauftrag des Nutzers – etwa „fasse meine letzten E-Mails zusammen". Die Schadanweisung steckt versteckt in einer dieser E-Mails. Das ist der Kern der indirekten Prompt Injection: Der Nutzer tut nichts Falsches, er delegiert nur eine Alltagsaufgabe an einen Agenten, der dabei fremden Text liest.

Der Payload arbeitet in fünf Stufen, die aufeinander aufbauen:

1. Context Break. JSON-Escapes wie \r\n und ein typografisches Apostroph zerbrechen die Struktur, in der der Agent den fremden Inhalt eingebettet bekommt. Ab hier steht Angreifertext dort, wo Steueranweisungen erwartet werden.
2. Werkzeugwahl erzwingen. Ein eingebettetes Bild drängt das Modell dazu, statt der Screenshot-Analyse das Werkzeug get_page_text zu verwenden – damit landet der rohe Angreifertext im Kontext, nicht ein gerendertes Abbild.
3. Gaslighting. Gefälschte <assistant>-Tags täuschen einen früheren Gesprächsverlauf vor. Das Modell „erinnert" sich an eine Übereinkunft, die es nie gab.
4. Command Hijacking. Ein gefälschter <user>-Prompt tarnt die Ausführung von Schadcode als harmloses JavaScript-Debugging – sinngemäß: „hier ist ein Fehler, bitte kurz reparieren". Genau dieser Reparatur-Vorwand trägt die Kette.
5. Strukturelle Tarnung. Harmlose UI-Elemente rahmen den Payload so ein, dass er für den Nutzer wie normaler Seiteninhalt aussieht.

Die Sicherheitsfilter wurden per Typosquatting umgangen: Statt vom legitimen CDN esm.sh lädt der Code von der angreifereigenen Domain esm-sh.com. Ein einziger Bindestrich – und die Allowlist greift nicht mehr.

Die lethal trifecta: warum das strukturell ist

Simon Willison hat am 16. Juni 2025 den Begriff lethal trifecta geprägt. Er benennt drei Zutaten, die zusammen unweigerlich zur Übernahme führen: Zugang zu privaten Daten, Kontakt mit nicht vertrauenswürdigen Inhalten und die Fähigkeit, nach außen zu kommunizieren. Sein Kernargument ist nüchtern und bis heute unwiderlegt: Ein Sprachmodell kann die Wichtigkeit von Anweisungen nicht zuverlässig nach ihrer Herkunft unterscheiden. Ob eine Instruktion vom Nutzer, aus dem Systemprompt oder aus einer fremden Webseite stammt, ist für das Modell nur Text im selben Kontextfenster.

Ein agentischer Browser vereint diese drei Bedingungen nicht zufällig, sondern per Definition. Er sitzt in der authentifizierten Sitzung des Nutzers (private Daten), er liest beliebige Webinhalte (nicht vertrauenswürdig), und er kann navigieren, posten und HTTP-Requests absetzen (Ausleitungskanal). Deshalb helfen klassische Guardrails hier nur graduell: Sie senken die Trefferquote, sie ändern nichts an der Struktur. Willisons Schlussfolgerung – die Kombination gezielt vermeiden, statt sie zu filtern – ist die einzige Gegenmaßnahme, die nicht probabilistisch ist.

Dass die Angriffsklasse anerkannt ist, zeigt ein Blick ins Framework-Umfeld: Techniken aus Zenitys GenAI Attacks Matrix wurden am 20. März 2025 in MITRE ATLAS übernommen. Wer intern argumentieren muss, kann sich also auf ein etabliertes Threat-Framework beziehen und nicht nur auf einen Blogbeitrag.

Atlas und Comet: zwei weitere belegte Fälle

Grand Theft Atlas – Zero-Click über einen Kommentar

Der zweite Strang der Veröffentlichung vom 5. August 2026 betrifft ChatGPT Atlas. Hier ist der Angriff tatsächlich Zero-Click im Sinne von: ohne bewusste Interaktion des Opfers mit dem Schadinhalt. Der Einstieg war ein platzierter Kommentar unter einem X-Post, den der Agent im Rahmen einer normalen Aufgabe mitlas – Zenity spricht von intent collision. Demonstriert wurden anschließend Massen-Phishing über ein gekapertes WhatsApp Web inklusive der Kontaktliste des Opfers sowie eine unautorisierte Amazon-Bestellung an die Lieferadresse des Angreifers.

Bemerkenswert sind die Umgehungstechniken: Der Payload wurde über mehrere scrollbare Abschnitte zerlegt, in hebräischem statt englischem Text formuliert – und gegen die letzte Schranke wurde Amazons eigener Assistent Rufus als Helfer eingespannt. Ein Agent, der einen anderen Agenten überredet, ist kein Gedankenspiel mehr. Zenitys Fazit zu Atlas: OpenAI setze auf soft boundaries, also Klassifikatoren, statt auf harte Beschränkungen im Code. Ein Patch wurde nicht veröffentlicht – weil es sich um eine Architektur-Eigenschaft handelt und nicht um einen einzelnen Bug.

PerplexedBrowser – der Kalendereintrag, der den Passworttresor öffnet

Der aus Unternehmenssicht unangenehmste Fall ist älter. Am 3. März 2026 veröffentlichte Zenity Labs PerplexedBrowser: How Attackers Can Hijack Comet to Takeover your 1Password Vault. Angriffsvektor: eine präparierte Kalendereinladung mit versteckten Anweisungen unterhalb der harmlosen Termindaten. Der Nutzer muss Perplexity Comet lediglich mit der Kalenderpflege beauftragen – danach läuft der Angriff im Hintergrund weiter.

Das Ergebnis: Auslesen von Benutzername und Passwort eines 1Password-Eintrags, in der zweiten Ausbaustufe zusätzlich E-Mail-Adresse, Secret Key und ein ausgelöster Passwort-Reset – also die vollständige Übernahme des Tresors. Die Ursache liegt dabei nicht allein beim Agenten: Die 1Password-Browsererweiterung erlaubt standardmäßig die automatische Anmeldung an der 1Password-Weboberfläche, solange der Tresor entsperrt ist – typischerweise bis zu acht Stunden. In diesem authentifizierten Kontext handelt der Agent ohne weitere Hürde. Am selben Tag erschien ein zweiter Befund: Comet konnte auch lokale Dateien des PCs preisgeben.

Datum	Ereignis	Beteiligt
03.11.2025	Meldung der Comet-Kette an die Hersteller	Zenity Labs
30.01.2026	Advisory, optionale Härtung (Auto-Login abschaltbar)	1Password
13.02.2026	Fixes: bessere Injection-Erkennung, mehr Bestätigungen	Perplexity
03.03.2026	Veröffentlichung PerplexedBrowser (Tresor + lokale Dateien)	Zenity Labs
05.08.2026	Vier Beiträge: Claude in Chrome + Grand Theft Atlas	Zenity Labs

Ein Detail dieser Zeitleiste verdient Aufmerksamkeit: Sowohl die 1Password-Härtung als auch Perplexitys Domain-Sperre für sensible Seiten müssen vom Nutzer manuell aktiviert werden. Wer sich in einem Unternehmen auf Standardeinstellungen verlässt, ist nach dem Fix ungefähr so geschützt wie davor.

Vorgeschichte: AgentFlayer und die Enterprise-Plattformen

Es wäre ein Missverständnis, das Thema als Consumer-Problem abzutun. Dieselbe Forschungsgruppe hatte die Angriffsklasse ein volles Jahr früher gegen Enterprise-Plattformen demonstriert – die AgentFlayer-Serie zwischen Juli und August 2025:

• 07.07.2025 – When AIjacking Leads to Full Data Exfiltration in Copilot Studio
• 01.08.2025 – When a Jira Ticket Can Steal Your Secrets: ein Ticket im Backlog als Angriffsvektor
• 06.08.2025 – ChatGPT Connectors 0click Attack sowie AI Enterprise Compromise – 0click Exploit Methods
• 08.08.2025 – Minimum Clicks, Maximum Leaks
• 14.08.2025 – Prompt Mines: 0-Click Data Corruption in Salesforce Einstein

Dazu kommt eine belegte Vorarbeit speziell zu Browser-Agenten: Exploring the Risks of ChatGPT's Atlas Browser (23.10.2025), Claude in Chrome: A Threat Analysis (29.12.2025), Hardening OpenAI's Atlas (30.12.2025) und Perplexity Comet: A Reversing Story (11.02.2026). Die Angriffsklasse ist also nicht neu – neu ist nur der Angriffsort. Wer ein Ticketsystem, ein CRM oder eine Kollaborationsplattform mit KI-Assistenz betreibt, hat dieselbe Trifecta bereits im Haus, nur weniger sichtbar.

Warum kein Hersteller eine vollständige Lösung verspricht

Die belastbarste Zahl zu diesem Thema kommt nicht von Angreifern, sondern vom Hersteller selbst. Anthropic hat bei der Ankündigung von Claude for Chrome am 25. August 2025 eigene Messwerte veröffentlicht: In 123 Testfällen aus 29 Angriffsszenarien gelangen ohne Schutzmaßnahmen 23,6 Prozent der Prompt-Injection-Angriffe. Mit aktivierten Sicherheitsmaßnahmen sank die Erfolgsquote im autonomen Modus auf 11,2 Prozent – jeder neunte Angriff funktioniert also weiterhin. Bei vier speziell browserbezogenen Angriffsarten sank die Quote immerhin von 35,7 auf 0 Prozent.

Messgröße (Anthropic, 25.08.2025)	ohne Schutz	mit Schutz
Prompt Injection gesamt, autonomer Modus 123 Testfälle aus 29 Angriffsszenarien	23,6 %	11,2 %
Vier browserspezifische Angriffsarten	35,7 %	0 %
Ausrollung	Pilot mit 1.000 Max-Nutzern (25.08.2025) → alle Max-Abos (24.11.2025) → Pro, Team, Enterprise (18.12.2025)

Auch OpenAI ist in dieser Frage bemerkenswert offen. CISO Dane Stuckey schrieb am 21./22. Oktober 2025, einen Tag nach dem Atlas-Start: „prompt injection remains a frontier, unsolved security problem, and our adversaries will spend significant time and resources to find ways to make ChatGPT agent fall for these attacks". Zu Grand Theft Atlas ergänzte das Unternehmen, es gebe „meaningful risks associated with prompt injection in agentic environments"; das Thema bleibe ein aktives Forschungsfeld.

Beachten Sie die Formulierung: „ungelöstes Grundlagenproblem" – nicht „unlösbar". Diese Präzision ist wichtig, wenn Sie die Aussage intern zitieren. Sie ändert aber nichts an der praktischen Konsequenz: Erkennungsraten bleiben probabilistisch, und ein Restrisiko in zweistelliger Prozenthöhe lässt sich nicht wegtrainieren, sondern nur organisatorisch tragen oder architektonisch vermeiden.

Unternehmensrichtlinie: blockieren statt verwalten

Der folgende Abschnitt ist eine Empfehlung, keine Herstelleraussage – begründet aus der Trifecta-Logik und den oben zitierten Messwerten. Unsere Praxisempfehlung für mittelständische IT-Organisationen lautet: agentische Browser gehören auf die Blockliste, nicht in die Softwareverwaltung.

1. Blockliste plus schriftliche Begründung. Sperren Sie die Installation agentischer Browser und Browser-Erweiterungen mit Agentenfunktion per Gruppenrichtlinie oder MDM. Legen Sie eine einseitige Begründung bei – sie brauchen sie für Betriebsrat, Geschäftsführung und die erste unzufriedene Fachabteilung. Die Zahlen aus der Tabelle oben tragen diese Begründung.
2. Alternative gleichzeitig bereitstellen. Eine Sperre ohne Ersatz produziert Schatten-IT – Mitarbeiter weichen auf private Geräte aus, und dort haben Sie gar keine Kontrolle mehr. Die Sperre wirkt nur zusammen mit einem freigegebenen Werkzeug.
3. Ausnahmen nur isoliert. Wo ein Agent zwingend im offenen Web arbeiten muss – Wettbewerbsbeobachtung, Recherche –, gehört er in eine dedizierte Umgebung: eigener Browser-Container, kein SSO, keine Unternehmenskonten, keine gespeicherten Zugangsdaten, eigener Netzsegment-Egress.
4. Passwortmanager härten. Automatische Anmeldung an der Weboberfläche abschalten, Bestätigung vor Autofill erzwingen, Tresor-Timeout deutlich unter acht Stunden setzen.
5. Egress protokollieren. Was ein Agent nach außen sendet, muss auf Netzebene sichtbar sein – nicht nur im Chatverlauf des Werkzeugs.

Ein häufiger Einwand: „Wir schulen unsere Leute." Das hilft hier nicht. Schulung wirkt gegen Jailbreak-Versuche und Phishing, also gegen Inhalte, die der Mensch sieht und bewertet. Indirekte Prompt Injection zielt am Menschen vorbei – der Payload wird für das Modell geschrieben, nicht für den Nutzer.

Die Alternative: interner Assistent mit kuratierten Werkzeugen

Auch dieser Abschnitt ist eine Empfehlung. Ihre Begründung ist aber sauber ableitbar: Wenn drei Zutaten zusammen die Übernahme ermöglichen, nimmt man dem System eine davon weg. Ein on-premise betriebener Assistent lässt genau das zu – ein agentischer Browser nicht, weil das offene Web sein Produktzweck ist.

Definierte Quellen statt beliebiger Webinhalte

Der Assistent liest aus einem kuratierten Korpus: Freigabedokumente, Handbücher, Ticketsystem, ERP-Auszüge. Diese Quellen sind nicht angreiferkontrolliert. Damit fällt die Ecke „nicht vertrauenswürdiger Inhalt" weg – vorausgesetzt, Sie behandeln extern befüllbare Kanäle (Kunden-E-Mails, Ticketkommentare, Lieferantenportale) ausdrücklich als untrusted und geben sie nicht in denselben Kontext wie privilegierte Werkzeuge.

Kuratierte und auditierte Werkzeugliste

Beim Tool Use gilt: Jedes Werkzeug ist eine Angriffsfläche, und ein generisches javascript_tool ist die größte davon. Statt „der Agent kann alles, was der Nutzer kann" definieren Sie eine endliche Liste fachlicher Operationen – Dokument suchen, Angebot erzeugen, Ticket kommentieren – jeweils mit eigenem Rechtekontext und eigenem Audit-Log. Schreibende Operationen und solche mit Außenwirkung bekommen eine menschliche Bestätigung, die den vollständigen Vorgang anzeigt.

Ausleitung nur über kontrollierten Egress

Der Assistent darf keine beliebigen HTTP-Requests absetzen. Ohne freien Ausgangskanal fehlt die dritte Ecke: Selbst eine erfolgreiche Injection hat dann keinen Weg, Daten aus dem Haus zu tragen. In einem durchdachten Sicherheitskonzept ist das der wirksamste einzelne Hebel, weil er auch bei unbekannten künftigen Injection-Techniken greift.

Genau dieses Muster setzen wir mit KIS:UI um: ein interner KI-Assistent mit definierten Datenquellen, kuratierter Werkzeugliste und ohne offenen Web-Browse-Kanal, betrieben auf eigener Hardware. Der Unterschied zum agentischen Browser ist nicht Konfiguration, sondern Architektur – und deshalb überlebt er auch die nächste Angriffsvariante.

Quellen & Primärbelege

Alle Zahlen, Fristen und Produktangaben in diesem Beitrag wurden vor der Veröffentlichung gegen die folgenden Primärquellen geprüft.

1. Zenity Labs Forschungs-Index
2. Zenity Labs Archiv vollständiges Post-Archiv mit Datumsangaben, Juli 2024 – August 2026
3. Claude in Chrome: Breaking down the injection 05.08.2026, Klugman-Onitza / Donato
4. Account Takeover via Claude in Chrome: A Technical Deep Dive 05.08.2026
5. Grand Theft Atlas 05.08.2026, ChatGPT Atlas
6. PerplexedBrowser: Comet und der 1Password-Tresor 03.03.2026
7. PerplexedBrowser: lokale Dateien 03.03.2026
8. Anthropic: Claude for Chrome 25.08.2025, Quelle der Werte 23,6 % / 11,2 % / 35,7 %
9. Simon Willison: The lethal trifecta 16.06.2025
10. OpenAI-CISO Dane Stuckey zu Atlas 22.10.2025, Originalwortlaut des Zitats

Häufig gestellte Fragen zu KI-Browsern im Unternehmen

Sind alle KI-Browser betroffen?

Belegt sind drei Produkte aus zwei Veröffentlichungen von Zenity Labs: Claude in Chrome und ChatGPT Atlas (beide 5. August 2026) sowie Perplexity Comet (3. März 2026). Zu Gemini in Chrome oder zum Copilot-Modus in Edge liegen keine vergleichbaren Zenity-Analysen vor. Die Ursache ist jedoch produktübergreifend dieselbe: ein Agent mit Werkzeugzugriff, der fremde Webinhalte liest.

Reicht es, Nutzer zu schulen?

Nein. Bei Grand Theft Atlas genügte ein platzierter Kommentar unter einem X-Post, ohne bewusste Interaktion des Opfers mit dem Schadinhalt. Bei Claude in Chrome reichte die völlig normale Anweisung, die letzten E-Mails zusammenzufassen. Schulung hilft gegen Phishing, nicht gegen Anweisungen, die das Opfer nie zu Gesicht bekommt.

Wird das gepatcht?

Einzelne Ketten werden geschlossen: 1Password veröffentlichte am 30. Januar 2026 ein Advisory, Perplexity lieferte am 13. Februar 2026 Fixes. Die Angriffsklasse bleibt. Anthropic misst selbst 11,2 Prozent erfolgreiche Prompt-Injection-Angriffe im autonomen Modus trotz aktivierter Schutzmaßnahmen, und OpenAI-CISO Dane Stuckey nennt Prompt Injection ein „frontier, unsolved security problem".

Was setzen wir stattdessen ein?

Einen internen Assistenten mit kuratierten Werkzeugen und definierten Datenquellen ohne offenen Web-Browse-Kanal. Damit sind privater Datenzugriff und nicht vertrauenswürdiger Inhalt voneinander getrennt und die lethal trifecta ist architektonisch aufgebrochen.