Ein KI-Agent im Browser ist nützlich, weil er dort arbeitet, wo viele Unternehmensprozesse ohnehin laufen: E-Mail, Kalender, Dokumente, CRM, Ticketsysteme, Portale. Genau dort entsteht aber auch das Sicherheitsproblem. Der Browser ist kein abgeschotteter Arbeitsraum. Er ist eine Laufzeitumgebung mit angemeldeten Sessions, Cookies, Extensions, DOM-Zugriffen und sehr unterschiedlichen Vertrauensstufen. Wenn ein Agent nicht sauber unterscheiden kann, ob eine Aktion wirklich vom Nutzer stammt oder von einem Skript ausgelöst wurde, wird aus Komfort schnell ein Confused-Deputy-Problem.
Die am 14. Juli veröffentlichte Analyse von Manifold Security zu Claude for Chrome zeigt das konkret. Nach Angaben der Forscher bleiben in Version 1.0.80 der Chrome-Erweiterung zwei Schwachstellen reproduzierbar, die Manifold bereits im Mai an Anthropic gemeldet hatte. The Hacker News hat die aktuelle Erweiterung nach eigener Darstellung ebenfalls entpackt und die betroffenen Mechanismen in den JavaScript-Bundles nachvollzogen. Es geht nicht um ein angeblich „böses Modell“. Es geht um klassische Browser- und Produktarchitektur: synthetische Klicks, Seitenpanel-Initialisierung, Berechtigungsmodus und fehlende Vertrauensprüfung.
Was technisch passiert
Der erste Befund betrifft einen Handler in der Claude-Erweiterung. Nach früheren Problemen mit ClaudeBleed hatte Anthropic die Angriffsfläche offenbar reduziert. Externe Auslöser können nicht mehr beliebige Prompts an Claude übergeben, sondern nur noch eine kleine Zahl fest kodierter Task-IDs starten. Manifold nennt neun solcher Aufgaben. Darunter sind harmlose Onboarding-Übungen, aber auch produktive Use Cases wie usecase-gmail, usecase-gdocs und usecase-calendar. Diese Aufgaben können Gmail-Inhalte, das neueste Google-Dokument samt Kommentaren oder Kalenderdaten betreffen.
Diese Einschränkung ist relevant, reicht aber nicht aus. Laut Manifold hört ein Content Script auf Klicks auf ein bestimmtes Element (#claude-onboarding-button), liest daraus die data-task-id und öffnet das Side Panel mit dem passenden Prompt. Der entscheidende Schritt fehlt: Der Code prüft nicht event.isTrusted. Dieses Browser-Flag unterscheidet echte Nutzerinteraktionen von Ereignissen, die ein Skript künstlich erzeugt. Eine andere Browser-Erweiterung, die auf claude.ai ein Content Script ausführen darf, kann daher ein passendes DOM-Element erzeugen, die Task-ID setzen und einen synthetischen Klick auslösen. Die Claude-Erweiterung behandelt diesen künstlichen Klick dann wie eine Nutzerabsicht.
Im Standardmodus „Ask before acting“ führt das noch nicht automatisch zu jeder sensiblen Aktion. Laut Bericht sieht der Nutzer weiterhin eine Freigabeabfrage. Manifold bewertet diese Variante mit CVSS 7.7, weil noch ein Klick des Nutzers erforderlich ist. Kritischer wird es, wenn der Nutzer „Act without asking“ aktiviert hat. Dann kann dieselbe ausgelöste Aufgabe ohne zusätzliche Rückfrage laufen. Manifold nennt dafür CVSS 9.6. The Hacker News berichtet, dass Version 1.0.80 am 7. Juli im Chrome Web Store aktualisiert wurde und der Handler weiterhin keinen isTrusted-Guard enthält.
Der zweite Befund lässt sich weniger direkt ausnutzen, ist aber architektonisch heikel. Das Claude-Side-Panel kann laut Manifold über den URL-Parameter ?skipPermissions=true in einen privilegierten Modus wechseln, in dem Berechtigungsprüfungen übersprungen werden. Aktuell kann diese URL nach Darstellung der Forscher nur die Erweiterung selbst bauen. Es handelt sich also nicht um einen frei aus dem Web auslösbaren Angriff. Trotzdem ist das Muster riskant. Ein Berechtigungszustand sollte nicht aus einer URL gelesen werden, sondern aus einer expliziten, geprüften Nutzerhandlung oder einem streng authentifizierten internen Kanal entstehen. Sonst kann eine spätere XSS-Lücke, ein zu breiter Message-Handler oder eine Regression aus einem Designproblem stillen Account-Zugriff machen.
Warum das für Unternehmen relevant ist
Viele Security-Diskussionen über KI-Agenten kreisen noch um Prompts, Modellverhalten oder Jailbreaks. Der Fall Claude for Chrome zeigt, dass das zu kurz greift. Browser-Agenten bestehen aus Modell, UI, Extension, Session-Kontext, Berechtigungsmodell und anderen Erweiterungen. Die riskante Grenze verläuft nicht nur zwischen „System Prompt“ und „User Prompt“, sondern zwischen Nutzerabsicht und skriptgeneriertem Ereignis.
Das ist besonders relevant, weil Browser-Erweiterungen in Unternehmen oft historisch gewachsen sind. Passwortmanager, Meeting-Tools, CRM-Helfer, Screenshot-Tools, PDF-Konverter, Developer-Add-ons und interne Extensions laufen nebeneinander. Manche haben sehr breite Rechte, etwa „Daten auf dieser Website lesen und ändern“. Sitzt ein hochprivilegierter KI-Agent im selben Browserprofil, kann eine eigentlich nachrangige Komponente plötzlich agentische Aktionen auslösen. Der Agent sieht dann nicht nur Text. Er kann Dienste öffnen, Daten lesen, Formulare bedienen oder Workflows starten.
Manifold ordnet die Befunde den OWASP-Risiken für LLM-Anwendungen zu: indirekte Prompt Injection und Excessive Agency. Diese Einordnung ist plausibel. Die operative Lehre ist aber noch konkreter: Unternehmen müssen Agentenrechte wie privilegierte Automatisierung behandeln. Ein Agent, der E-Mail, Dokumente, Kalender oder CRM lesen darf, steht näher an RPA, Helpdesk-Automation und Identitätsinfrastruktur als an einem normalen Chatbot.
Was Security-Teams jetzt prüfen sollten
Erstens sollten Unternehmen den Einsatz von Browser-Agenten inventarisieren. Wer nutzt Claude for Chrome oder ähnliche Erweiterungen? In welchen Browserprofilen? Mit welchen Konten? Sind dort gleichzeitig andere Extensions mit Zugriff auf die Agenten-Domain installiert? Diese Fragen wirken banal, tauchen aber in klassischen SaaS- oder Endpoint-Inventaren häufig nicht auf.
Zweitens sollte „Act without asking“ für produktive Konten nicht der Standard sein. Unbeaufsichtigte Ausführung ist bequem, entfernt aber genau den letzten Menschen-im-Loop, der bei zusammengesetzten Browserangriffen oft noch zwischen Auslösung und Schaden steht. Für sensible Konten sollte der Modus deaktiviert bleiben, zumindest bis Anbieter robuste Nutzerintentions- und Event-Trust-Kontrollen nachweisbar implementiert haben.
Drittens lohnt sich Extension-Härtung. Browserprofile für privilegierte Arbeit sollten möglichst wenige Add-ons enthalten. Wo Agenten getestet werden, ist ein separates Profil oder ein verwalteter Browserkontext sinnvoll: keine privaten Erweiterungen, keine experimentellen Tools, keine pauschalen DOM-Rechte auf Agenten- oder SSO-Domains. Enterprise-Browser-Policies können erlaubte Erweiterungen, Host-Permissions und Update-Kanäle steuern.
Viertens sollten Anbieter von Agenten-Extensions einfache, aber harte UI-Sicherheitsregeln einbauen. Synthetische Klicks dürfen keine Nutzerabsicht ersetzen. Privilegierte Modi gehören nicht in URL-Parameter. Der Wechsel in „unbeaufsichtigte Ausführung“ braucht eine echte Nutzerhandlung, eine sichtbare Vorabwarnung, eine begrenzte Dauer und auditierbare Ereignisse. Zusätzlich sollten Agentenaktionen in sensiblen Anwendungen mit Herkunft, Task-ID, ausgelöstem UI-Event und Berechtigungsmodus geloggt werden.
Grenzen der Meldung
Die Einordnung muss nüchtern bleiben. Die Berichte beschreiben keine massenhafte Ausnutzung und keinen nachgewiesenen Datenabfluss bei Kunden. Für die synthetische-Klick-Kette braucht der Angreifer bereits eine andere Erweiterung oder ein Skript mit Zugriff auf claude.ai. Der URL-Parameter-Befund ist laut Manifold derzeit nicht direkt aus der Ferne auslösbar. Außerdem gab es nach Angaben von The Hacker News zum Veröffentlichungszeitpunkt weder eine CVE noch eine öffentliche Anthropic-Advisory zu diesen spezifischen Befunden.
Gerade deshalb ist der Fall wichtig. Er zeigt eine Sicherheitsklasse, die bei Enterprise-Rollouts von KI-Agenten leicht unterschätzt wird. Nicht jede Schwachstelle ist ein spektakulärer Remote-Exploit. Manchmal reicht eine unscharfe Vertrauensgrenze, die erst in der nächsten Produktversion, mit einer weiteren Integration oder durch eine zu großzügige Extension-Policy kritisch wird.
Fazit
Claude for Chrome steht für eine größere Entwicklung: KI-Agenten verlassen das Chatfenster und rücken in den Arbeitskontext. Dort treffen sie auf echte Konten, echte Daten und echte Berechtigungen. Die Sicherheitsarchitektur muss deshalb stärker an Browser-Isolation, Identity Governance und privilegierter Automatisierung ausgerichtet sein — nicht nur an Prompt-Hygiene.
Für Unternehmen heißt das: Browser-Agenten nicht pauschal verbieten, aber kontrolliert einführen. Wenige Extensions, getrennte Profile, kein unbeaufsichtigter Modus für sensible Konten, klare Logs und harte Nutzerintentionsprüfungen sind keine Komfortbremsen. Sie sind Grundbedingungen. Der Agent darf nicht nur fragen: „Was soll ich tun?“ Er muss zuverlässig wissen, wer ihn gerade dazu aufgefordert hat.
Quellen: Manifold Security, „ClaudeBleed Reopened: Browser Extensions Can Still Push Claude for Chrome to Read Your Gmail“ (14. Juli 2026); The Hacker News, „Researchers Say Claude for Chrome Flaw Lets Rogue Extensions Trigger Gmail Reads“ (14. Juli 2026); OWASP Top 10 for LLM Applications, LLM01 Prompt Injection und LLM06 Excessive Agency.
