KI-Browser sind nicht deshalb riskant, weil sie einen Chatbot in einen Tab setzen. Das Risiko beginnt, wenn der Chatbot zum Agenten wird: Er liest Seiten, folgt Links, klickt, merkt sich Kontext und handelt in Sitzungen, in denen der Nutzer bereits angemeldet ist. Dann ist er keine Suchhilfe mehr. Er wird zu einer neuen Vertrauensgrenze im Browser.

KI-Browser-Agent wird von Isolationsgrenzen blockiert, während eine verdächtige Seite Prompt Injection versucht

Zwei aktuelle Forschungsstränge zeigen diese Grenze. Forscher der University of Washington untersuchten sieben agentic browsers und fanden, dass vier Bedingungen schaffen, um die Same-Origin Policy zu umgehen. Diese Regel verhindert, dass eine Website Daten einer anderen liest. Der vollständige Proof of Concept betraf ChatGPT Atlas. Ähnliche Voraussetzungen sahen die Forscher bei Chrome with Gemini, Claude for Chrome und Perplexity Comet. LayerX beschrieb parallel BioShocking, einen Angriff, der einen KI-Browser in eine spielartige Scheinwelt führt, bis Guardrails nicht mehr wie echte Grenzen wirken.

Das ist kein Grund zur Panik. Es ist ein Grund, einen agentischen Browser nicht wie einen normalen Browser mit besserer Autovervollständigung zu behandeln. Das Web wurde um Trennung herum gebaut. Agenten verwischen Trennung, weil sie Text gleichzeitig als Inhalt und als Anweisung lesen.

Same-Origin Policy ohne Nebel

Die Same-Origin Policy ist einer der unsichtbaren Gründe, warum das Web funktioniert. Shop, E-Mail und Bank können im selben Browser offen sein, aber ein Skript einer Origin sollte nicht frei Daten einer anderen Origin lesen. MDN beschreibt Origin über Scheme, Host und Port. Praktisch heißt das: Eine zufällige Seite darf nicht den Posteingang auslesen, nur weil beide Tabs offen sind.

Diese Schutzlinie gibt es seit den 1990ern. Nutzer sehen sie kaum, aber sie erlaubt viele eingeloggte Seiten im selben Browser, ohne dass jede Seite ein Fenster zu allen anderen wird.

Ein agentischer Browser fügt einen neuen Akteur hinzu. Der Agent kann Seiten prüfen, zusammenfassen, eingebettete Inhalte lesen, frühere Seiten erinnern und mit den Rechten des Nutzers handeln. Wenn eine bösartige Seite Anweisungen in gelesenen Text injiziert, braucht sie nicht zwingend eine klassische Weblücke. Sie kann den Agenten bitten, die Grenze zu überschreiten.

Was UW gefunden hat

Die UW-Arbeit ist hilfreich, weil sie über Architektur spricht. Das Team untersuchte Brave Leo AI, ChatGPT Atlas, Chrome with Gemini, Claude for Chrome, Microsoft Edge with Copilot, Firefox AI Mode und Perplexity Comet. Die Tests liefen Anfang 2026; Produkte können sich ändern. Die Designlektion bleibt.

In weniger restriktiven Designs kann eine bösartige Seite nach erfolgreicher Prompt Injection den Agenten dazu bringen, Informationen zwischen Origins zu mischen. UW demonstrierte einen vollständigen Angriff auf ChatGPT Atlas im Agent Mode: Eine Seite erhielt Informationen aus einer anderen eingebetteten Seite, grob wie eine Anzeige in einer Mailseite, die Mailinhalte liest. Für Chrome with Gemini, Claude for Chrome und Perplexity Comet fanden die Forscher Vorbedingungen ähnlicher Angriffe.

Sie nannten auch Cross-Origin Action Forgery, Zugriff auf maskierte Eingaben wie Passwörter und Chat Memory Poisoning. Letzteres ist wichtig, weil Agenten Gesehenes komprimieren und wiederverwenden. Wenn ihre Erinnerung Daten verschiedener Origins mischt, reicht die alte Browserisolation nicht mehr.

Was BioShocking ergänzt

LayerX greift eine andere Ebene an. BioShocking zielt nicht zuerst auf die Same-Origin Policy, sondern auf das Sicherheitsmodell des Agenten. Die bösartige Seite baut eine Spielwelt, in der falsche Antworten gewinnen. Akzeptiert der Agent diese Logik, kann er zu Handlungen gedrängt werden, die normale Guardrails ablehnen sollten.

LayerX berichtet, dass der Proof of Concept gegen mehrere Browser und Assistenten funktionierte, darunter ChatGPT Atlas, Perplexity Comet, Fellou, Genspark Browser, Sigma Browser und das Claude-Chrome-Plugin. Die Szenarien umfassen sensible Informationen, Passwortänderungen und Credential-Leaks. Ars Technica und The Hacker News griffen das auf, weil die Lektion klar ist: Guardrails sind keine Zugriffskontrolle.

Eine Ablehnungsregel im LLM ist eine Policy-Schicht. Browsersicherheit braucht harte Grenzen. Wenn derselbe Agent eine bösartige Seite, eine private Seite und eine authentifizierte Sitzung sieht, kann ein guter Prompt Bereiche verbinden, die getrennt bleiben sollten.

Was tatsächlich schiefgehen kann

Realistische Risiken sind oft unspektakulär. Ein Nutzer bittet um eine Zusammenfassung. Versteckter Text auf der Seite fordert den Agenten auf, Daten aus einem anderen Tab einzufügen, einen Einmalcode zu kopieren, ein privates Dokument zu öffnen oder eine Zusammenfassung in ein Angreiferformular zu setzen. Ein Mitarbeiter nutzt den Agenten im CRM, während E-Mail, GitHub, Kalender und Admin-Konsolen im selben Profil offen sind. Ein bösartiger Issue-Kommentar bittet den Agenten, Secrets von anderswo zu holen und als normalen Kontext auszugeben.

Manche Szenarien sind Proofs of Concept und keine bestätigten Massenangriffe. Das ist wichtig. Aber ein Proof of Concept reicht für Risikoplanung, wenn das Ziel ein bereits authentifiziertes Browserprofil ist. Eine überberechtigte Erweiterung ist gefährlich. Ein Agent ist gefährlicher, weil er Sprache interpretiert, plant und Daten über Schritte hinweg bewegt.

Regeln für Nutzer und Firmen

Wer KI-Browser testen will, sollte ein separates Profil verwenden. Banking, Arbeits-Admin, private Repositories, Cloud-Dashboards, E-Mail und Passwortmanager gehören nicht in dasselbe Profil, in dem ein Agent handeln darf.

Automatische Aktionen sollten aus bleiben, wo es geht. Der Agent sollte bestätigen lassen, bevor er Formulare sendet, Käufe tätigt, Daten zwischen Sites kopiert, private Dokumente öffnet oder Credentials nutzt. Kann das Produkt diese Bestätigung nicht erzwingen, gehört es nicht in sensible Sitzungen.

Unternehmen sollten agentische Browser als privilegierte Automatisierung behandeln. Erlaubte Produkte, getrennte Profile, eigene Identitäten, Browserisolation, Endpoint-Regeln, Allowlists und Audit Logs sind keine Übertreibung, wenn der Agent Arbeitsdaten sehen kann.

Auch Schulung muss sich ändern. Mitarbeitende kennen verdächtige Links. Versteckte Anweisungen in normalen Seiten sind weniger vertraut. Die ruhige Botschaft lautet: Nicht vertrauenswürdiger Webinhalt kann für den Agenten zur Anweisung werden.

Was Anbieter ändern müssen

Bessere Safety Prompts reichen nicht. Agentische Browser brauchen origin-bewusste Erinnerung, harte Berechtigungsgrenzen, Bestätigung pro Aktion, zuverlässige Trennung eingebetteter Inhalte, klare Logs und restriktive Standardeinstellungen. In der UW-Arbeit wirkten Designs mit weniger Rechten sicherer, auch wenn sie weniger beeindruckend waren.

Das nüchterne Urteil lautet: trennen, begrenzen, bestätigen. KI-Agent-Browsing von sensiblen Konten trennen. Begrenzen, was der Agent lesen und tun kann. Jede Aktion bestätigen, die Daten bewegt, Geld ausgibt, Credentials nutzt oder Arbeitssysteme berührt.

Ein Browser war früher ein Betrachter mit starken Wänden zwischen Sites. Ein KI-Browser ist eher ein Assistent, der mit Notizblock durch diese Räume läuft. Bis die Wände für Agenten neu gebaut sind, sollte er nicht alle Schlüssel bekommen.