Wenn das Lesen einer Seite auch Handeln ermöglicht

Ein Assistent, der einen Artikel zusammenfasst, muss dessen Inhalt lediglich interpretieren. Ein Browser-Agent kann mehr: Seiten lesen, zwischen Websites navigieren und je nach Berechtigungen innerhalb einer Sitzung klicken oder Text eingeben, in der die Person bereits angemeldet ist. Dadurch kann er mehr im Auftrag der Person erledigen, zugleich steigen aber auch die möglichen Folgen eines Fehlers. Google weist darauf hin, dass Agenten in authentifizierten Sitzungen arbeiten können und eine unerwünschte Aktion eine Transaktion oder die Offenlegung sensibler Daten umfassen könnte. https://developer.chrome.com/docs/agents/security https://blog.google/security/architecting-security-for-agentic/

Entscheidend ist daher nicht nur, ob das Modell eine Frage gut beantwortet, sondern auch, welche Inhalte es sieht, welche Aktionen es ausführen darf und wer prüft, ob jeder Schritt dem Ziel der Person entspricht. Die Grenze zwischen Lesen und Handeln ist wesentlich: Eine Rezension zusammenzufassen hat andere Auswirkungen als eine Nachricht zu senden, sich anzumelden oder eine Zahlung abzuschließen. Die Chrome-Dokumentation stellt ihre Maßnahmen als mehrschichtige Abwehr dar, nicht als magische Eigenschaft des Modells, die jeden Text im Web harmlos machen würde. https://blog.google/security/architecting-security-for-agentic/

Eine Seite kann Anweisungen für den Agenten enthalten

Indirekte Prompt-Injection tritt auf, wenn eine Anweisung für das Modell in Daten erscheint, die es abruft, statt direkt von der Person zu kommen. Sie kann auf einer manipulierten Seite, in eingebetteten Inhalten Dritter oder in Nutzerbeiträgen wie Kommentaren und Rezensionen stehen. Google beschreibt zwei konkrete Risiken für Webtools: Tool-Definitionen mit verborgenen Anweisungen und scheinbar gewöhnliche Antworten, in die feindseliger Text eingebettet ist. https://developer.chrome.com/docs/agents/security https://blog.google/security/architecting-security-for-agentic/

Das Problem besteht darin, dass das Modell Texte aus verschiedenen Quellen verarbeitet und gleichzeitig versucht, eine Aufgabe zu erfüllen. Verwechselt es Seiteninhalte mit einer legitimen Anweisung, kann es vom ursprünglichen Ziel abweichen. Die Website muss keine Autorität über den Agenten besitzen; es genügt, wenn der Text dessen Planung beeinflusst. Google warnt ausdrücklich, dass sich Sicherheit wegen der probabilistischen Natur von Modellen nicht allein innerhalb des Modells garantieren lässt. Deshalb sollte selbst eine versteckte oder mit nützlichen Informationen vermischte Anweisung als nicht vertrauenswürdiger Inhalt behandelt werden, nicht als Erlaubnis der nutzenden Person. https://developer.chrome.com/docs/agents/security

Forschung veranschaulicht die Größe dieser Angriffsfläche, ihre Ergebnisse lassen sich jedoch nicht automatisch auf alle Browser übertragen. Eine im Mai 2025 als arXiv-Preprint veröffentlichte Studie untersuchte ein Open-Source-Projekt zur Browser-Nutzung unter White-Box-Bedingungen und berichtete über Prompt-Injection, die Umgehung der Domain-Prüfung und die Offenlegung von Zugangsdaten. Untersucht wurde ein konkretes Projekt mit einer bestimmten Konfiguration: Das ist ein Beleg dafür, dass Fehler möglich sind, aber weder eine allgemeingültige Messung heutiger Agenten noch ein Nachweis zu Chrome. https://arxiv.org/abs/2505.13076

Schutzschichten, die den Spielraum für Missbrauch verringern

Der Chrome-Leitfaden für Agenten, die WebMCP verwenden, empfiehlt mehrere deterministische Schutzmaßnahmen: die Eingabemenge begrenzen, die Web-Ursprünge einschränken, mit denen der Agent interagieren kann, und vor Aktionen eine Bestätigung einholen. Außerdem sollen Tool-Antworten als nicht vertrauenswürdige Daten behandelt werden. Ziel ist es, sowohl die Menge schädlicher Inhalte im Kontext als auch die Wege zu reduzieren, auf denen eine manipulative Anweisung Schaden verursachen könnte. Das sind Designempfehlungen für die Entwicklung von Agenten, keine Garantie dafür, dass jede Erweiterung oder jeder Browser sie automatisch anwendet. https://developer.chrome.com/docs/agents/security

Eine weitere beschriebene Technik ist Spotlighting: Nicht vertrauenswürdige Inhalte werden markiert oder umgewandelt, damit das Modell sie als Daten und nicht als Anweisungen interpretiert. Chrome weist auf Zielkonflikte hin. Text abzugrenzen ist kostengünstig, kann aber scheitern, wenn die Trennzeichen manipuliert werden; eine Base64-Kodierung erschwert bestimmte strukturelle Tricks, beansprucht jedoch mehr Kontext. In beiden Fällen muss das System dem Modell erläutern, wie es mit diesen Inhalten umgehen soll. Die Maßnahmen ergänzen einander, sind aber kein unfehlbarer Filter, der jede schädliche Absicht erkennt. https://developer.chrome.com/docs/agents/security

Google beschreibt außerdem eine Architektur für die agentischen Funktionen von Chrome: Ein Planungsmodell schlägt Aktionen vor, und eine separate Komponente namens User Alignment Critic prüft, ob sie zum Ziel der nutzenden Person passen. Laut Google erhält dieser Kritiker Aktionsmetadaten statt ungefilterter Webinhalte und kann Vorschläge ablehnen. Zusätzlich sollen Origin-Sets begrenzen, welche Websites der Agent lesen und auf welchen er handeln kann. Der Beitrag merkt an, dass die erste Umsetzung dieser Beschränkung einfacher war und das Design weiter verfeinert werden sollte. https://blog.google/security/architecting-security-for-agentic/

Bestätigungen und eingeräumte Grenzen

Eine menschliche Bestätigung kann bei einer potenziell folgenreichen Aktion als Bremse dienen. Google zufolge fragt der Chrome-Agent vor bestimmten sensiblen Websites, vor einer Anmeldung über Google Password Manager und vor Aktionen wie Käufen, Zahlungen oder dem Versand von Nachrichten um Erlaubnis. Google erwähnt auch ein Protokoll der einzelnen Schritte sowie die Möglichkeit, eine Aufgabe anzuhalten oder zu stoppen. Dabei handelt es sich um vom Anbieter beschriebene Funktionen; daraus folgt nicht, dass jede Funktion in jeder Region, Version oder jedem Produkt verfügbar ist oder dass die Person jedes Detail auf dieselbe Weise genehmigen muss. https://blog.google/security/architecting-security-for-agentic/

Die Dokumentation räumt selbst Grenzen ein: Klassifikatoren erkennen möglicherweise nicht alle Inhalte, die den Agenten beeinflussen sollen, und Schutzmaßnahmen müssen fortlaufend getestet und verbessert werden. Google erklärt, automatisierte Red-Team-Übungen einzusetzen, um Test-Websites zu erzeugen und zu prüfen, ob die Schutzmechanismen Angriffe abwehren. Solche Tests helfen, Rückschritte zu erkennen. Eine Erfolgsquote in einem Testsatz beweist jedoch weder, dass es künftig keine Schwachstellen geben wird, noch deckt sie alle Seiten, Sprachen, Abläufe und Werkzeugkombinationen ab. Die vorsichtige Schlussfolgerung lautet: Schutzschichten verteuern Angriffe und können deren Folgen begrenzen, aber nicht unmöglich machen. https://blog.google/security/architecting-security-for-agentic/

Was Nutzende tun können

Vor der Übertragung einer Aufgabe lohnt es sich, die vom Browser oder der Erweiterung angeforderten Berechtigungen zu prüfen und den Zugriff auf die Websites zu beschränken, die für die Aufgabe tatsächlich erforderlich sind. Wenn eine Funktion Daten senden, ein Konto ändern oder einen Kauf tätigen kann, ist es sinnvoll, die Ausführung zu beaufsichtigen und Empfänger, Felder und Ergebnis vor der Bestätigung zu prüfen. Der Chrome-Leitfaden empfiehlt, Origins zu begrenzen und für Aktionen eine Bestätigung anzufordern. Es geht nicht darum, der Person die gesamte Verantwortung aufzubürden, sondern einen Kontrollpunkt für schwer umkehrbare Auswirkungen zu erhalten. https://developer.chrome.com/docs/agents/security

Hilfreich ist auch, Aufgaben mit geringen Folgen – etwa das Ordnen öffentlicher Informationen – von Vorgängen mit Zugangsdaten, medizinischen Daten, Finanzinformationen oder privaten Nachrichten zu trennen. Findet ein Agent auf einer Seite eine unerwartete Anweisung, sollte man nicht davon ausgehen, dass sie Teil des ursprünglichen Auftrags ist. Besser ist es, anzuhalten und die vorgeschlagene Aktion zu prüfen. Aufsicht verringert die Gefährdung, ersetzt aber keine technischen Kontrollen: Die offiziellen Empfehlungen betonen Origin-Beschränkungen, regelmäßige Evaluierung und Bestätigungen, während verfügbare Forschung zeigt, dass Fehler in unterschiedlichen Systemkomponenten auftreten können. Eine absolute Schutzwirkung lässt sich nicht versprechen. https://developer.chrome.com/docs/agents/security https://arxiv.org/abs/2505.13076