Lass dein Team noch keinen KI-Browser installieren

Ich bezahle vier KI-Abos. Ich baue KI-Werkzeuge für Kunden. Mein ganzer Arbeitsablauf läuft über Agenten, und ich würde dieses Setup vor jedem verteidigen.

Ich habe trotzdem keinen agentischen Browser in dem Profil installiert, in dem meine E-Mails, meine Bank und die Adminpanels meiner Kunden liegen. Nicht weil ich die Technologie für schlecht halte. Wegen dem, was passiert, wenn es einmal schiefgeht.

Diese Unterscheidung ist der ganze Punkt dieses Beitrags. Sicherheit agentischer Browser ist keine Debatte darüber, ob KI-Browser nützlich sind. Sind sie. Es ist eine Debatte über Schadensradius und über Timing.

Was Brave in Comet tatsächlich gefunden hat

Am 25. Juli 2025 hat Braves Sicherheitsteam eine Schwachstelle für indirekte Prompt Injection in Perplexitys Comet-Browser gemeldet. Ihr öffentlicher Bericht kam am 20. August.

Die Demo lohnt sich im Detail zu verstehen, denn sie erklärt alles Folgende.

Ein Reddit-Kommentar enthielt Anweisungen, versteckt hinter einem Spoiler-Tag. Für einen Menschen, der den Thread überfliegt, unsichtbar. Der Nutzer klickte dann auf Comets Knopf "Aktuelle Webseite zusammenfassen", was die langweiligste Sache ist, die man mit einem KI-Browser machen kann. Comet hat den Seitentext an sein Modell gegeben, ohne "was der Nutzer von mir wollte" von "Text, der zufällig auf der Seite stand" zu trennen. Es hat die versteckten Anweisungen als Befehle gelesen.

Was es dann tat: die E-Mail-Adresse des Nutzers von seiner Perplexity-Kontoseite ziehen, einen Login-Vorgang auslösen, in das Gmail des Nutzers gehen, das Einmalpasswort aus dem Postfach lesen und sowohl die Adresse als auch das Einmalpasswort als Antwort auf den ursprünglichen Reddit-Kommentar posten.

Braves Satz dazu ist mir hängen geblieben. Klassische Schutzmechanismen wie Same-Origin-Policy und CORS sind hier "faktisch nutzlos". Diese Regeln verhindern, dass eine Seite eine andere liest. Sie verhindern nicht, dass ein Assistent mit legitimem Zugriff auf beide dazu überredet wird, Daten zwischen ihnen zu tragen.

Perplexity hat es binnen zwei Tagen anerkannt und am 27. Juli einen Fix ausgeliefert. Brave hat am 28. Juli getestet und den Fix unvollständig gefunden. Am 13. August sah es wieder gepatcht aus. Brave berichtete später, es sei weiterhin nicht vollständig entschärft. Dieses Muster, patchen, umgehen, patchen, ist keine Inkompetenz. Es sieht so aus, wenn der Fehler im Entwurf steckt und nicht in einer Funktion.

Brave ging am 21. Oktober 2025 mit unsichtbaren Prompt Injections in Screenshots weiter: Anweisungen in blassem Hellblau auf gelbem Grund, für einen Menschen unlesbar, vom OCR-Schritt perfekt extrahiert und dem Modell als Eingabe übergeben.

Das Problem ist die Sitzung, nicht der Browser

Und jetzt das, was das strukturell von jeder Browser-Schwachstelle unterscheidet, über die du je gelesen hast.

In der Comet-Demo hat niemand Zugangsdaten gestohlen. Niemand hat ein Passwort geknackt, einen Login gephisht oder Schadsoftware platziert. Der Angreifer hat den Rechner des Opfers nie angefasst. Der Agent war schon eingeloggt, als der Nutzer, mit dessen Cookies und dessen Rechten, und er hat schlicht getan, was man ihm gesagt hat.

Dein Browserprofil ist kein Browser. Es ist ein Schlüsselbund. Meins hält Gmail, das Directus-Admin jeder Kundenseite, die ich betreue, Hetzner, Cloudflare, Stripe, meine Bank und eine Passwortmanager-Erweiterung. Ein Agent, der in diesem Profil arbeitet, erbt das alles auf einmal. Nicht Lesezugriff. Vollen authentifizierten Nutzerzugriff, inklusive der Knöpfe, die Dinge löschen, und der Knöpfe, die Geld bewegen.

Normale Websicherheit nimmt an, dass der Angreifer außerhalb der Vertrauensgrenze steht und hineinwill. Hier ist der Angreifer Inhalt. Einfach Text auf einer Seite, die du deinen Assistenten lesen lässt. Die Vertrauensgrenze enthält ihn bereits.

Ich habe schon darüber geschrieben, wie alle KI-Schaufeln verkaufen, während niemand prüft, ob die eigene Scheune abgeschlossen ist. Das hier ist die schärfste Version davon: Das Werkzeug, das dich produktiver machen soll, ist das Werkzeug, das jeden Schlüssel hält, den du besitzt.

PleaseFix hat es zu Zero-Click gemacht

Am 3. März 2026 haben Zenity Labs eine Schwachstellenklasse offengelegt, die sie PleaseFix genannt haben. Die Cloud Security Alliance hat am 28. März eine Forschungsnotiz dazu veröffentlicht, und Zenity hat den vollen Umfang im August 2026 publiziert.

Lies die Offenlegungen sorgfältig, denn die Formulierung zählt. PleaseFix wird als Familie beschrieben, nicht als einzelner Fehler: sechs Unterfamilien von Angriffen, die Datendiebstahl, Kompromittierung von Zugangsdaten, Kontoübernahme, Exfiltration lokaler Dateien und Codeausführung aus der Ferne abdecken. Betroffene Produkte, die in den Offenlegungen genannt werden, sind Perplexity Comet, ChatGPT Atlas, Copilot Edge, Claude in Chrome und Gemini in Chrome.

Den Mechanismus nennt Zenity "Intent Collision". Bösartige Anweisungen sitzen in Inhalten, denen der Agent bei normaler Arbeit begegnet: einer E-Mail, einer Kalendereinladung, einer Webseite. Wenn der Nutzer eine legitime Anfrage stellt, kollidieren die eingeschleusten Anweisungen mit ihr und lenken den Agenten um, mit der Identität und den Rechten des Nutzers.

Null Klicks. Kein schädlicher Code auf dem Gerät des Opfers. Überhaupt kein Social Engineering an einem Menschen, denn der Mensch ist nicht der, der getäuscht wird.

Das veröffentlichte Beispiel: eine ganz normale Anfrage "fass meine E-Mails zusammen", die Gmail-Daten exfiltriert, das gesamte Google Drive des Opfers still mit dem Angreifer geteilt und die Übernahme der Slack-, X- und Claude-Konten des Opfers ermöglicht hat.

Das Detail danach, an das ich immer wieder denke, ist das mit Perplexity. Perplexity hat reagiert und Dateisystemzugriff mit einer harten Grenze blockiert. Forscher haben diese Grenze dann zweimal umgangen, mit view-source:file://-URLs und Tricks bei Dateiendungen. Fix in gutem Glauben, besiegt von zwei weiteren Tagen Nachdenken. Da steht diese Kategorie gerade.

Andere Klasse, gleiche Form wie das Supply-Chain-Problem bei KI-Coding-Assistenten: ein System, das nicht überprüfen kann, was ihm gereicht wird, und trotzdem mit deiner Autorität danach handelt.

Die Anbieter haben nicht nichts getan

Ich will hier fair sein, denn die "KI-Browser sind unsicher, Punkt"-Meinungen sind faul, und die Anbieter haben echte Arbeit geliefert.

Anthropic hat Zahlen für Claude in Chrome veröffentlicht, was mehr ist als die meisten. In ihrem adversarialen Testsatz lag die Erfolgsquote von Angriffen bei 23,6% ohne Gegenmaßnahmen und bei 11,2% mit Gegenmaßnahmen im autonomen Modus. Bei einem engeren Testsatz mit vier browserspezifischen Angriffstypen kamen sie von 35,7% auf 0%. Sie haben außerdem ganze Website-Kategorien komplett gesperrt, darunter Finanzdienstleistungen, Berechtigungen pro Seite ergänzt und Bestätigungen vor riskanten Handlungen wie Veröffentlichen, Kaufen oder Teilen persönlicher Daten verlangt.

OpenAI hat einen ausgeloggten Modus ausgeliefert, damit der ChatGPT-Agent ohne angehängte Zugangsdaten handeln kann, und CISO Dane Stuckey hat im Oktober 2025 öffentlich geschrieben, dass Prompt Injection "ein ungelöstes Problem bleibt", von dem sie erwarten, dass es mit wachsender Autonomie der Agenten bestehen bleibt. Für einen Anbieter ist es ungewöhnlich ehrlich, das über den eigenen Start zu veröffentlichen, und das verdient Anerkennung.

Und jetzt halt diese beiden Fakten zusammen. 11,2% sind eine große Verbesserung gegenüber 23,6%. Es ist auch grob einer von neun, im eigenen Testsatz des Anbieters, in einem System, das deine aktiven Sitzungen hält. Anthropic verbirgt das nicht. Sie haben es als Forschungsvorschau mit bewusst eingeschränkter Installation ausgeliefert, und das ist die richtige Haltung.

Und im Juni 2026 haben Forscher der University of Washington berichtet, dass von sieben untersuchten agentischen Browsern vier Wege geschaffen haben, die Same-Origin-Policy zu umgehen, mit einem funktionierenden Proof of Concept gegen ChatGPT Atlas, der eine Seite Informationen aus einer anderen darin eingebetteten ziehen ließ. Franziska Roesners Fazit war deutlich: Browser-Agenten sind nicht bereit für die Öffentlichkeit. Laut der Mitteilung der UW haben Google, Microsoft und Brave mit den Forschern zusammengearbeitet, Anthropic und Firefox haben nicht geantwortet, und Perplexity und OpenAI haben den Bericht abgelehnt. Beachte auch ihren Befund zum Zielkonflikt: Der am wenigsten riskante Browser, den sie getestet haben, Firefox AI Mode, war auch der eingeschränkteste. Das ist kein Zufall, und deswegen wird das nicht mit einem Patch behoben.

Dann ist da noch NeuralTrusts Befund vom Oktober 2025, dass Atlas' Omnibox mit einer Zeichenkette gefüttert werden konnte, die wie eine URL geformt, aber fehlerhaft genug war, dass der Agent sie als vertrauenswürdige Nutzerabsicht behandelte und den eingebetteten Befehl mit der authentifizierten Sitzung ausführte.

Die Regel, nach der ich tatsächlich arbeite

Nichts davon ergibt "KI verbieten". Es ergibt eine langweilige Trennregel, deren Einhaltung fast nichts kostet.

Kein agentisches Browsen in einem Profil, das E-Mail, Lohnbuchhaltung, Bankzugang oder Kunden-Admin-Zugriff hält. Diese eine Regel leistet den größten Teil der Arbeit. Nicht "sei in diesem Profil vorsichtig". Dort gar nicht.

Getrenntes Browserprofil für Experimente, besser ein getrennter Rechner. Ein zweites Chrome-Profil, in dem außer dem KI-Browser-Konto selbst nichts angemeldet ist, ist in vier Minuten eingerichtet. Wenn du einen Ersatzlaptop hast, nimm den, denn eine Profilgrenze ist eine Softwaregrenze, und dieser ganze Beitrag handelt davon, dass Softwaregrenzen umgeredet werden.

Genehmige nie eine Agentenhandlung, die du manuell nicht genehmigen würdest. Der Bestätigungsdialog ist keine Formalie. Wenn der Agent eine E-Mail senden will, die du nicht senden lassen wolltest, oder eine Seite öffnen will, die du nicht genannt hast, ist das die gesamte Warnung, die du bekommst. Lies sie, als hätte dich ein Fremder darum gebeten.

Nichts Agentisches fasst ein Kundenkonto an. Bei mir nie. Ihr Directus, ihr Stripe, ihr DNS. Meine Bequemlichkeit ist kein guter Grund, das Geschäft von jemand anderem in eine experimentelle Vertrauensgrenze zu stecken, und es ist nicht mein Risiko, es in ihrem Namen einzugehen.

Schalte Memory und sitzungsübergreifende Funktionen ab, solange du experimentierst. Mehrere der genannten Exploits dieser Klasse halten sich, indem sie in das Gedächtnis des Agenten schreiben, sodass eine einzige schlechte Seite zu einer Dauer-Anweisung wird.

Schreib es in einem Absatz auf. Eine Zwei-Personen-Firma braucht kein Sicherheitsrichtliniendokument. Sie braucht einen Absatz in dem Wiki oder der Notizdatei, die du ohnehin hast, damit die Regel existiert, bevor jemand fragt, statt danach.

Wenn du die breitere Version davon für deine tatsächliche Infrastruktur willst: Meine Checkliste zur Website-Sicherheitshärtung behandelt die langweilige Schicht darunter.

Was du dem Mitarbeiter sagst, der einen ausprobieren will

Jemand in deinem Team wird fragen. Soll er auch. Neugier auf dieses Zeug ist ein gutes Zeichen, und wenn du mit einem glatten Nein antwortest, bekommst du einfach Schatten-Adoption.

Sag Ja, mit einer Grenze. Ungefähr so: Ja, installier es, nutz das Sandbox-Profil, melde dich darin bei nichts Firmeneigenem an, und erzähl mir, was du lernst. Und lies dann wirklich, was er dir schickt.

Das funktioniert besser als ein Verbot, weil der nützliche Teil dieser Browser real ist. Recherche, Vergleiche, sich durch Dokumentation lesen, mühsame Formulare auf Seiten ausfüllen, bei denen nichts auf dem Spiel steht. All das ist wirklich schneller. Nichts davon braucht deine Gmail-Sitzung.

Der Versagensmodus eines Verbots ist, dass die Person es trotzdem installiert, auf ihrem Hauptprofil, zu Hause, auf dem Rechner, den sie auch für Arbeit nutzt, und es dir nicht erzählt. Das ist eindeutig schlechter als die Sandbox.

Wenn er mit "der Anbieter hat das behoben" kontert, lest den Fix gemeinsam. Das ist eine gute Übung. In der Hälfte der Fälle ist der Fix echt und eng, was zu wissen sich lohnt, und in der anderen Hälfte lernst du etwas darüber, wie sich diese Fehlerklasse verhält. Dieselbe Logik gilt für jeden KI-Kauf: Ich habe eine Liste mit Fragen, die sich lohnen, bevor du für ein KI-Werkzeug zahlst, und für alle in Europa: was du einen EU-konformen KI-Anbieter vor der Unterschrift fragst.

Wann sich das ändert

Ich weiß es nicht, und wer dir ein Datum nennt, rät.

Aber hier ist, worauf ich achten würde, denn "nie" ist nicht die Empfehlung, und ich will nicht so tun, als wäre sie es. Die Empfehlung lautet: 2026 nicht in deinem Hauptprofil.

Achte auf eine echte Vertrauensgrenze innerhalb des Agenten, in der Seiteninhalt strukturell nicht zur Anweisung werden kann, statt auf einen Klassifikator, der die meisten Versuche abfängt. Klassifikatoren bewegen 23,6% auf 11,2%. Architektur bewegt es auf null. Achte auf Scoping pro Handlung, bei dem der Agent ein Token für eine Aufgabe und eine Seite bekommt, statt die ganze Sitzung zu erben. Achte darauf, dass Anbieter Angriffs-Erfolgsquoten als normalen Teil ihrer Release Notes veröffentlichen, so wie sie heute Benchmark-Werte veröffentlichen, damit du die Zahl wandern sehen kannst.

Und beobachte den Takt der Offenlegungen. Gerade veröffentlichen unabhängige Forscher etwa alle paar Monate eine neue Klasse davon, und die Fixes werden innerhalb desselben Offenlegungszyklus umgangen. Wenn das langsamer wird, hat sich wirklich etwas geändert. Es ist dieselbe Dynamik, über die ich geschrieben habe, als Angreifer anfingen, Fehler schneller zu finden, als irgendwer patchen konnte, außer dass hier Verteidiger und Angreifer dieselbe Seite lesen.

Meine ehrliche Vermutung ist, dass die Unternehmensversion davon, mit Scoping pro Seite und Audit-Logs, vor der vertrauenswürdigen Consumer-Version kommt. Das wäre eine Premiere.

Bis dahin: Sandbox-Profil, keine Firmenkonten darin, und ein Absatz aufgeschrieben. Wenn du Hilfe dabei willst, herauszufinden, welche Teile deines Stacks tatsächlich exponiert sind, ist das die Art unspektakulärer Arbeit, die ich bei Wunderlandmedia mache.