Amazon Google Browser Agents stehen vor einem Prompt-Injection-Problem ohne perfekte Lösung

Browser-Agenten von Amazon und Google stehen nun vor demselben Konflikt: Mehr Autonomie gibt Prompt-Injection-Angriffen mehr Spielraum, Schaden anzurichten. Trotz neuer Schutzmaßnahmen finden Forschende weiterhin Wege, Agenten über gewöhnliche Webseiten, E-Mails, Formulare und Social-Media-Beiträge zu steuern. Die Schwachstelle entwickelt sich zu einer dauerhaften Einschränkung des KI-Browserdesigns und ist nicht bloß ein weiterer Browserfehler, der auf einen einzelnen sauberen Patch wartet.

Die unmittelbare Sorge gilt der indirekten Prompt Injection, bei der sich feindliche Anweisungen in Inhalten verbergen, die ein KI-Agent liest. Diese Anweisungen können mit der Anfrage des Nutzers konkurrieren und die nächste Handlung des Agenten beeinflussen. Ein herkömmlicher Browser zeigt den feindlichen Inhalt an. Ein agentischer Browser kann ihn interpretieren, in einen anderen Dienst wechseln und mit der Autorität des Nutzers handeln.

Diese Unterscheidung stellt Amazon und Google in einen breiteren Sicherheitswettbewerb mit Microsoft, OpenAI, Anthropic, Perplexity und spezialisierten Browseranbietern. Jedes Unternehmen möchte Agenten entwickeln, die nützliche Aufgaben im gesamten Web erledigen können. Doch jede zusätzliche Berechtigung erweitert die Folgen, wenn ein Agent missversteht, wem er gehorchen soll.

Die beunruhigende Schlussfolgerung lautet nicht, dass Browser-Agenten unbrauchbar sind. Vielmehr können Anbieter die Erkennung von Prompt Injection nicht als vollständige Sicherheitsgrenze behandeln. Unternehmen müssen davon ausgehen, dass einige bösartige Anweisungen durchkommen, und begrenzen, worauf ein kompromittierter Agent zugreifen, was er ändern oder offenlegen kann.

Was sich im Sicherheitswettlauf zwischen Amazon und Google verändert hat

Prompt Injection hat sich von einer theoretischen Modellschwäche zu einem operativen Problem der Browser-Sicherheit entwickelt.

Sicherheitsforschende haben wiederholt gezeigt, dass bösartige Inhalte einen Agenten umleiten können, ohne den traditionellen Pfad zur Codeausführung im Browser auszunutzen. Der Angreifer zielt stattdessen auf die Interpretation von Inhalten durch das Modell. Eine versteckte Anweisung kann auf einer Webseite, in einer E-Mail, einem Dokument oder sogar in einem Element der Benutzeroberfläche erscheinen.

Der Angriff wird ernst, wenn der Agent authentifizierte Browser-Sitzungen nutzen kann. Er könnte einen Posteingang lesen, einen weiteren Tab öffnen, ein Formular absenden oder Informationen aus einem verbundenen Dienst abrufen. Handlungen, die bei einer normalen Aufgabe bequem erscheinen, werden zu nützlichen Komponenten einer Angriffskette.

Forschende von Zenity beschrieben diese umfassendere Klasse agentischer Browser-Schwachstellen als PleaseFix. Ihre Tests zielten darauf ab, wie Agenten Zielen in natürlicher Sprache folgen, während sie zwischen Websites und lokalen Ressourcen wechseln. Laut den Erkenntnissen zur Browser-Sicherheit fanden Forschende unterschiedliche Designs und Schutzmaßnahmen, identifizierten aber weiterhin Angriffspfade in kommerziellen agentischen Browsern.

Die wichtige Veränderung liegt im Angriffsweg. Herkömmliche Browserangriffe hängen häufig von einer Software-Schwachstelle, einer bösartigen Erweiterung, gestohlenen Zugangsdaten oder einem täuschenden Klick ab. Prompt Injection kann mit Inhalten beginnen, die der Agent im Rahmen einer gewöhnlichen Anfrage verarbeiten sollte.

Ein Nutzer könnte einen Assistenten bitten, eine Produktseite zusammenzufassen. Die Seite könnte Anweisungen enthalten, die visuell verborgen sind, dem Modell jedoch weiterhin zur Verfügung stehen. Ein Angreifer könnte Anweisungen auch in einem öffentlichen Beitrag, einem Newsletter-Formular oder über ein Browser-Tool abgerufenen Inhalten platzieren.

Das garantiert nicht, dass jede eingeschleuste Anweisung erfolgreich ist. Modelle, Klassifikatoren, Berechtigungssysteme und Prüfungen von Aktionen können viele Versuche stoppen. Das Problem besteht darin, dass diese Kontrollen einem anpassungsfähigen Gegner gegenüberstehen, der Formulierungen, Darstellung, Zeitpunkt und Kontext verändern kann.

Die eigenen Messungen von Google unterstreichen diesen Wandel. Die Sicherheitsteams des Unternehmens durchsuchten öffentliche Webinhalte nach bekannten Mustern indirekter Prompt Injection und meldeten zwischen November 2025 und Februar 2026 einen relativen Anstieg bösartiger Erkennungen um 32 Prozent. Das Unternehmen fand zudem erhebliche Mengen harmlosen Textes, der Angriffen ähnelte, was eine zuverlässige Klassifizierung erschwert.

Diese Forschung zu Webbedrohungen ist wichtig, weil eine Browser-Abwehr zwei konkurrierende Fehlerarten bewältigen muss. Übersieht sie feindliche Inhalte, kann ein Agent manipuliert werden. Blockiert sie zu aggressiv, werden alltägliche Seiten und legitime Anweisungen unbrauchbar.

Amazon nähert sich dem Problem über seine Cloud-Agentenplattform statt über einen Massenmarkt-Browser. Bedrock AgentCore Browser bietet Entwicklern eine isolierte Umgebung für Agenten, die Websites navigieren, Formulare ausfüllen und Informationen extrahieren. Diese Fähigkeiten setzen Agenten weiterhin nicht vertrauenswürdigen Inhalten aus, selbst wenn die zugrunde liegende Browser-Sitzung isoliert ist.

Der Vergleich zwischen Amazon und Google spiegelt daher zwei unterschiedliche Vertriebsmodelle wider. Google ergänzt einen Browser, den Menschen direkt nutzen, um agentische Funktionen. Amazon liefert Infrastruktur, mit der Unternehmen ihre eigene Browser-Automatisierung aufbauen. Beide müssen dieselbe Kollision zwischen Inhalten des offenen Webs und privilegierten Agentenaktionen bewältigen.

Warum Browser-Agenten eine alte Sicherheitsgrenze schwächen

Die zentrale Schwachstelle entsteht, wenn ein Modell vertrauenswürdige Anweisungen und nicht vertrauenswürdige Daten über einen gemeinsamen Denkprozess erhält.

Webbrowser haben über Jahrzehnte hinweg Websites voneinander getrennt. Die Same-Origin-Policy verhindert im Allgemeinen, dass eine Origin frei sensible Informationen einer anderen lesen kann. Sandboxes, Berechtigungsabfragen, Prozessisolierung und Content-Security-Policies schaffen weitere Barrieren.

Ein KI-Agent kann diese Grenzen überschreiten, weil der Nutzer ihn zur Ausführung einer Aufgabe autorisiert. Er kann eine Seite lesen, einen anderen Dienst konsultieren und die Ergebnisse zusammenführen. Diese Fähigkeit ist der zentrale Nutzen des Produkts, schafft jedoch zugleich eine Brücke, die feindliche Inhalte zu kontrollieren versuchen können.

Das Modell muss die Same-Origin-Policy nicht direkt brechen. Es kann legitime Browserfunktionen nutzen, die dem Nutzer zur Verfügung stehen. Wenn eine bösartige Seite den Agenten dazu bewegt, einen Posteingang zu öffnen, eine Nachricht zu lesen und Informationen zu übertragen, könnte jeder einzelne Schritt autorisiert erscheinen.

Dies wird manchmal als Confused-Deputy-Problem bezeichnet. Eine vertrauenswürdige Komponente verfügt über legitime Befugnisse, doch ein Angreifer manipuliert sie dazu, diese Befugnisse für den falschen Zweck einzusetzen. Browser-Agenten machen den Stellvertreter dialogorientiert, probabilistisch und fähig, mehrere Schritte zu planen.

Forschung zu Open-Source-Browser-Agenten hat gezeigt, wie dieses Muster zur Offenlegung von Zugangsdaten und zu nicht autorisierten Aktionen führen kann. Eine akademische Studie berichtete über Prompt Injection, die Umgehung von Domain-Validierung und die Exfiltration von Zugangsdaten in einem Browser-Automatisierungs-Framework. Ihre Analyse von Browser-Agenten umfasste zudem eine offengelegte Schwachstelle und einen funktionierenden Proof of Concept.

Das Problem wächst, wenn ein Agent Erinnerungen zwischen Aufgaben mitnimmt. Eine feindliche Anweisung muss nicht immer sofort Schaden anrichten. Sie kann versuchen, gespeicherten Kontext zu verändern, eine irreführende Präferenz zu erzeugen oder eine spätere Entscheidung zu beeinflussen, wenn sensible Ressourcen verfügbar werden.

Visuelles Verständnis eröffnet einen weiteren Angriffsweg. Ein Agent, der Screenshots interpretiert, kann auf Anweisungen stoßen, die in Bildern oder Elementen der Benutzeroberfläche eingebettet sind. Das Filtern des reinen Seitentextes allein erfasst nicht jede Nachricht, die ein multimodales Modell wahrnehmen kann.

Angreifer können auch offensichtliche Formulierungen wie „Ignoriere vorherige Anweisungen“ vermeiden. Sie können bösartige Schritte als notwendige Bestandteile des ursprünglichen Nutzerziels darstellen. Eine Anfrage zur Anmeldung für einen Newsletter kann beispielsweise zum Vorwand werden, Daten abzurufen oder ein anderes Tool zu öffnen.

Diese Technik ist wichtig, weil viele Abwehrmaßnahmen nach einem Konflikt zwischen dem Nutzerziel und der feindlichen Anweisung suchen. Ein Angreifer kann die bösartige Aktion stattdessen mit diesem Ziel vereinbar erscheinen lassen. Die Formulierung wird weniger verdächtig, während die angeforderte Fähigkeit gefährlich bleibt.

Prompt Injection unterscheidet sich in einem entscheidenden Punkt von SQL Injection. Software kann SQL-Befehle durch strenge Syntax und parametrisierte Abfragen von Daten trennen. Agenten, die natürliche Sprache nutzen, beruhen auf kontextueller Interpretation, sodass Anweisungen und Informationen nicht immer eine klare technische Grenze haben.

Strukturierte Nachrichten und Herkunftskennzeichnungen können diese Trennung verbessern. Entwickler können markieren, welche Inhalte vom Nutzer, einer Webseite, einem Tool oder der Anwendung stammen. Das Modell muss externe Inhalte jedoch weiterhin interpretieren, wenn die Aufgabe von ihrer Bedeutung abhängt.

Die als BrowseSafe veröffentlichte Forschung bewertete Prompt-Injection-Risiken in Browser-Agenten und untersuchte Abwehrmaßnahmen in realistischen Umgebungen. Diese Arbeit spiegelt einen entstehenden Konsens wider: Erkennung hilft, doch Browserarchitektur und Berechtigungsdesign bestimmen die letztliche Auswirkung.

Deshalb würde ein perfekter Klassifikator das gesamte Problem nicht lösen. Klassifikatoren verarbeiten ebenfalls mehrdeutige Sprache, und Angreifer können neue Varianten testen. Verteidiger benötigen mehrere unabhängige Kontrollen, damit eine fehlerhafte Einschätzung nicht die gesamte Browser-Sitzung des Nutzers öffnet.

Die Schutzmaßnahmen von Amazon und Google setzen auf Kontrolle statt perfekte Erkennung

Amazon und Google entwickeln mehrschichtige Schutzmaßnahmen, weil sich keines der Unternehmen auf einen einzigen Prompt-Injection-Filter verlassen kann.

Google hat eine Architektur beschrieben, die Agentenaktionen prüft, bevor sie den Browser erreichen. Sein User Alignment Critic ist eine separate Komponente, die bewerten soll, ob eine vorgeschlagene Aktion mit dem vom Nutzer genannten Ziel übereinstimmt. Diese Trennung hilft zu verhindern, dass der Hauptagent seine eigene riskante Interpretation genehmigt.

Google nutzt außerdem Informationen zur Herkunft, Aktionsbestätigungen, Modelltraining und Erkennungssysteme. Sensible Vorgänge können eine ausdrückliche Zustimmung des Nutzers erfordern. Der Browser kann einschränken, welche Informationen den Agenten erreichen, und Sicherheitsgrenzen rund um Zugangsdaten bewahren.

In seinem agentischen Chrome-Design räumt Google ein, dass die Exposition gegenüber nicht vertrauenswürdigen Webinhalten ein inhärentes Risiko indirekter Prompt Injection schafft. Diese Formulierung ist bedeutsam. Das Unternehmen beschreibt das Problem als architektonische Bedrohung, die fortlaufende Eindämmung erfordert.

Aktionsbestätigungen sind nützlich, weil sie menschliches Urteilsvermögen vor einem folgenreichen Schritt wiederherstellen. Ein Nutzer kann einen unerwarteten Kauf, eine Nachricht, einen Login oder eine Datenübertragung ablehnen. Häufige Abfragen können jedoch ebenfalls zur Routine werden und dieselbe Ermüdung erzeugen, die von Cookie-Hinweisen und Berechtigungsdialogen bekannt ist.

Bestätigungen müssen sich daher auf bedeutsame Übergänge konzentrieren. Das Senden von Daten an eine neue Domain verdient mehr Prüfung als das Scrollen einer Seite. Das Öffnen eines Passwortmanagers birgt ein höheres Risiko als das Extrahieren einer öffentlichen Überschrift. Ein einheitliches Freigabemodell behandelt ungleiche Aktionen, als wären sie gleichwertig.

Amazon betont die Durchsetzung von Richtlinien rund um seine verwaltete Browser-Umgebung. Entwickler, die Bedrock AgentCore nutzen, können Chrome-Enterprise-Richtlinien anwenden, die einschränken, wohin ein Agent navigiert. Diese Regeln arbeiten auf Browserebene, unabhängig vom Prompt oder den Schlussfolgerungen des Agenten.

Der Unterschied ist wichtig. Ein Modell kann manipuliert werden, doch eine deterministische Netzwerk- oder Browserrichtlinie blockiert weiterhin ein verbotenes Ziel. Die Browser-Richtlinienkontrollen von Amazon ermöglichen es Entwicklern, erlaubte und blockierte Orte festzulegen, bevor der Agent seine Arbeit beginnt.

Eine Allowlist kann die Angriffsfläche für eng umrissene Unternehmens-Workflows erheblich reduzieren. Ein Beschaffungsagent könnte Zugriff auf eine kleine Auswahl genehmigter Lieferantenportale benötigen. Ein Kundendienstagent könnte nur die Support-Plattform und ein internes Wissenssystem brauchen.

Diese Grenzen werden bei allgemeiner Recherche schwieriger aufrechtzuerhalten. Ein Agent, der Produkte vergleichen oder Nachrichten verfolgen soll, benötigt umfassenden Webzugriff. Je offener die Aufgabe, desto weniger hilfreich ist eine strikte Allowlist für Zieladressen.

Isolation bietet eine weitere Schutzebene. Eine verwaltete Browsersitzung kann die Aktivitäten eines Agenten vom alltäglichen Browserprofil eines Mitarbeiters trennen. Wenn der Agent kompromittiert wird, sollte er nicht automatisch jedes Cookie, jeden offenen Tab, jeden gespeicherten Zugangsnachweis und jede Erweiterung übernehmen, die dem Nutzer zur Verfügung stehen.

Isolation entscheidet nicht darüber, ob eine Anweisung bösartig ist. Sie begrenzt die Ressourcen, die nach einer Fehlentscheidung verfügbar sind. Dies entspricht derselben praktischen Logik wie bei Containern, virtuellen Maschinen und eingeschränkten Dienstkonten.

Das Prinzip der minimalen Rechte überträgt diesen Ansatz auf Tools und Daten. Ein Agent, der nur öffentliche Seiten lesen muss, sollte keine Berechtigung zum Versenden von E-Mails erhalten. Ein Agent, der eine Transaktion vorbereitet, sollte sie nicht selbst genehmigen dürfen. Ein Agent, der Dokumente liest, sollte nicht automatisch Zugriff auf jeden verbundenen Ordner erhalten.

Die Sicherheitsansätze von Amazon und Google laufen daher auf ein gemeinsames Prinzip hinaus. Modelle werden fehleranfällig bleiben, daher muss Sicherheit außerhalb des Modells bestehen. Browserrichtlinien, Identitätsgrenzen, Freigabeschranken, Protokollierung und isolierte Sitzungen können einen Fehler eindämmen, den die Erkennung nicht stoppen konnte.

Der eigentliche Zielkonflikt besteht zwischen Fähigkeiten und Eindämmung

Jede Abwehrmaßnahme, die die Auswirkungen von Prompt Injection zuverlässig reduziert, beschränkt auch einen Teil der Autonomie des Agenten.

Ein Browser-Agent wird nützlicher, wenn er sich frei zwischen Diensten bewegen, Kontext speichern und mehrstufige Aufgaben abschließen kann. Genau diese Fähigkeiten erhöhen die Zahl der Entscheidungen, die ein Angreifer beeinflussen kann. Der Sicherheitskompromiss ist in das Wertversprechen des Produkts eingebaut.

Betrachten wir einen Agenten, der Reisen organisieren soll. Er könnte Flüge suchen, Hotels vergleichen, einen Kalender prüfen, Treueinformationen abrufen und eine Buchung vorbereiten. Wenn externe Inhalte den Plan umleiten, könnte der Agent persönliche Daten preisgeben oder ein vom Angreifer kontrolliertes Ziel auswählen.

Ein streng abgeschottetes System könnte dieses Ergebnis verhindern, indem es den Agenten auf eine schreibgeschützte Suche beschränkt. Es würde die Buchung jedoch nicht mehr abschließen. Die Erteilung einer Kaufberechtigung stellt den Komfort wieder her, erhöht aber zugleich die Auswirkungen einer fehlerhaften Aktion.

Dasselbe Muster gilt innerhalb von Unternehmen. Ein Vertriebsagent könnte ein Konto recherchieren und eine Ansprache entwerfen, ohne große Risiken zu schaffen. Erhält er die Berechtigung, Nachrichten zu senden, Kundendaten zu aktualisieren und interne Dokumente anzuhängen, entsteht wertvollere Automatisierung – und ein größerer Schadensradius.

Deshalb sollte Prompt Injection als Problem der Fähigkeitensicherheit bewertet werden. Teams sollten fragen, was der Agent tun kann, nachdem er eine bösartige Anweisung akzeptiert hat. Die Erfolgsquote eines Angriffs auf ein Modell ist relevant, doch die erlaubte Folge ist wichtiger.

Ein schreibgeschützter Zusammenfasser stellt ein anderes Risiko dar als ein Agent, der mit Zahlungssystemen verbunden ist. Beide können irreführende Ausgaben erzeugen. Nur einer kann eine fehlerhafte Interpretation ohne weitere Kontrolle in eine externe Transaktion verwandeln.

Anbieter bewerben höhere Erkennungsraten bisweilen als Beleg für verbesserte Sicherheit. Diese Ergebnisse können wertvoll sein, hängen jedoch vom Testsatz, dem Wissen des Angreifers, der Modellversion und den erlaubten Tools ab. Ein adaptiver Angriff kann auf Fälle zielen, die ein Benchmark nicht umfasst.

Auch Fehlalarme verursachen operative Kosten. Ein defensives Modell könnte legitime Inhalte ablehnen, die einem Injection-Versuch ähneln. Sicherheitsteams können übersehene Angriffe durch höhere Sensitivität reduzieren, doch dann erleben Nutzer mehr blockierte Aufgaben und unnötige Bestätigungen.

Das Designproblem hat keinen festen Endpunkt, weil sich die Fähigkeiten von Agenten ständig verändern. Eine Schutzmaßnahme, die gegen die Zusammenfassung von Seiten getestet wurde, deckt nicht automatisch visuelle Navigation, Dateidownloads, Betriebssystemdialoge oder Interaktionen mit einem neuen Tool-Protokoll ab.

Browser-Updates können zusätzliche Verhaltensweisen einführen. Modell-Upgrades können verändern, wie der Agent mehrdeutige Anweisungen interpretiert. Ein verbundener Dienst kann neue Aktionen bereitstellen, ohne dass der Browseranbieter seine Schnittstelle kontrolliert. Sicherheitstests müssen dem vollständigen System folgen, nicht nur einer Momentaufnahme eines Modells.

Erweiterungen und Integrationen von Drittanbietern verkomplizieren das Bild zusätzlich. Sie können die für den Agenten sichtbaren Inhalte erweitern oder neue Ausführungspfade bereitstellen. Ein Unternehmen könnte den Hauptbrowser sorgfältig konfigurieren und dennoch eine Erweiterung mit umfassendem Seitenzugriff übersehen.

Daher ist eine skeptische Sichtweise notwendig. Mehrschichtige Abwehrmaßnahmen senken das Risiko, doch öffentliche Aussagen über „sichere Agenten“ sollten nicht als Immunität verstanden werden. Unternehmen sollten die getestete Umgebung, blockierte Aktionen, Regeln für Nutzerbestätigungen und die verbleibende Angriffsfläche offenlegen.

Gleichzeitig vereinfacht es die Entscheidung zu stark, jeden KI-Browser pauschal als unsicher zu erklären. Das Risiko hängt von den Berechtigungen des Agenten, zugänglichen Daten, Isolation und der Aufgabe ab. Ein eingeschränkter Rechercheassistent kann in eine Umgebung mit geringerem Risiko passen, selbst wenn ein Einkaufsagent dies nicht kann.

Sicherheitsteams benötigen Bereitstellungsklassen statt einer umfassenden Genehmigung. Agenten mit geringem Risiko können in isolierten, schreibgeschützten Sitzungen arbeiten. Systeme mit mittlerem Risiko können Aktionen zur menschlichen Prüfung entwerfen. Arbeitsabläufe mit hohem Risiko sollten eine deterministische Autorisierung außerhalb des Modells erfordern.

Diese Struktur akzeptiert den zentralen Zielkonflikt, statt vorzutäuschen, dass er verschwunden sei. Nutzer gewinnen weiterhin Automatisierung, doch die Autonomie steigt nur, wenn die umgebenden Kontrollen einen Modellfehler auffangen können.

Wer durch das Prompt-Injection-Problem unter Druck gerät

Browseranbieter stehen in den Schlagzeilen, doch Identitäts- und Anwendungsteams in Unternehmen tragen einen Großteil der praktischen Last.

Google muss Nutzer schützen, deren Browserprofile bereits wertvolle Sitzungen enthalten. Chrome kann einen Agenten mit E-Mail, Kalendern, Dokumenten, Shopping-Konten und Arbeitsplatztools verbinden. Eine einzelne Oberfläche kann daher viele unterschiedliche Vertrauensdomänen offenlegen.

Die Kunden von Amazon stehen vor einer anderen Verantwortung. Bedrock AgentCore stellt verwaltete Komponenten und Kontrollen bereit, doch Entwickler entscheiden weiterhin, auf welche Ziele, Identitäten, Tools und Daten ein Agent zugreifen kann. Ein sicherer Dienst kann eine unsichere Anwendungskonfiguration unterstützen.

Microsoft, OpenAI, Anthropic und Perplexity stehen unter demselben Wettbewerbsdruck. Nutzer erwarten, dass Browser-Agenten mehr Arbeit erledigen, während Sicherheitsforscher jede neue Fähigkeit testen. Ein restriktives Design kann neben einem Konkurrenten, der umfassendere Automatisierung erlaubt, weniger nützlich wirken.

Dieser Wettbewerbszyklus kann Anbieter dazu verleiten, Berechtigungen schneller auszuweiten, als Unternehmen ihre Governance aktualisieren. Neue Agentenfunktionen können über vertraute Browser und Produktivitätstools eingeführt werden und so die Beschaffungsprüfung umgehen, die für eine separate Anwendung erforderlich wäre.

Sicherheitsteams sollten agentische Funktionen als Fähigkeiten inventarisieren, nicht als Produktnamen. Die relevanten Fragen betreffen den Zugriff auf authentifizierte Sitzungen, lokale Dateien, verbundene Anwendungen, Speicher, Messaging, Downloads und Codeausführung.

Auch Verantwortliche für Anwendungen müssen Webseiteninhalte neu bewerten. Ein internes Dashboard wurde früher in erster Linie für menschliche Leser gestaltet. Wenn Agenten seinen Text sowohl als Information als auch als potenzielle Anweisung verarbeiten, wird die Herkunft von Inhalten zu einem Teil der Anwendungssicherheit.

Identitätsteams müssen entscheiden, ob Agenten menschliche Zugangsdaten teilen oder eigene Dienstidentitäten erhalten. Gemeinsame Sitzungen sind bequem, schwächen aber die Nachvollziehbarkeit. Separate Identitäten ermöglichen engere Berechtigungen, klarere Protokolle und einen schnelleren Entzug von Zugriffsrechten.

Entwickler benötigen Ereignisaufzeichnungen, die erklären, was der Agent gesehen hat und warum er gehandelt hat. Der herkömmliche Browserverlauf zeigt besuchte Seiten, erfasst aber möglicherweise nicht den genauen Inhalt, die Modellentscheidung, den Tool-Aufruf und die Autorisierung hinter einer Aktion des Agenten.

Auch Incident-Response-Teams stehen vor einer weiteren Schwierigkeit. Eine erfolgreiche Prompt Injection kann wie normale Nutzeraktivität aussehen, weil der Agent gültige Zugangsdaten und legitime Browserfunktionen verwendet. Die Erkennung muss Absicht, Abfolge, Ziel und Datenbewegungen untersuchen.

Auch Mitarbeitende benötigen deutlichere Signale. Sie sollten wissen, wann ein Agent eine Seite liest, in einen anderen Dienst wechselt, auf private Informationen zugreift oder eine irreversible Aktion vorbereitet. Ein kleines animiertes Symbol vermittelt nicht den vollständigen Vertrauensübergang.

Unternehmenskäufer sollten Anbieter fragen, wie Abwehrmaßnahmen funktionieren, wenn Inhalte visuell, verschleiert, mehrsprachig oder über mehrere Schritte verteilt sind. Sie sollten außerdem fragen, ob Sicherheitsprüfungen unabhängig vom Hauptagenten ausgeführt werden und ob Richtlinien nach Modelländerungen weiterhin durchsetzbar bleiben.

Die stärkste Bewertung umfasst adversariales Testen gegen die tatsächlichen Arbeitsabläufe der Organisation. Ein allgemeiner Benchmark kann nicht jede interne Anwendung, Datenquelle und Berechtigungskombination nachbilden. Red Teams sollten realistische Ziele testen und dabei die bösartigen Inhalte variieren.

Auch Beschaffungsverträge benötigen klare Regelungen für Vorfälle. Käufer sollten Protokollaufbewahrung, Offenlegung von Schwachstellen, Praktiken bei Modell-Updates und die Verantwortung für unsichere Konfigurationen verstehen. Prompt Injection überschreitet die Grenzen zwischen Anbieterhandeln und Kundendesign.

Kein Unternehmen kann dieses Problem der geteilten Verantwortung allein mit einem Modell-Update lösen. Anbieter müssen durchsetzbare Kontrollen bereitstellen, während Kunden sie auf konkrete Aufgaben abstimmen müssen. Beide Seiten benötigen Belege dafür, dass die Kontrollen zusammenwirken.

Was als Nächstes von Amazon, Google und Anbietern von KI-Browsern zu beobachten ist

Die nächste Phase wird an Nachweisen für Eindämmung gemessen werden, nicht an Versprechen, Prompt Injection sei beseitigt worden.

Das erste Signal ist, ob Anbieter reproduzierbare Bewertungen veröffentlichen, die vollständige Browser-Workflows abdecken. Tests sollten versteckten Seitentext, Bilder, tabübergreifende Aktionen, gespeicherten Speicher, verbundene Konten und mehrstufige Manipulation von Absichten umfassen. Ein einzelner Benchmark für Verweigerungen bietet eine zu enge Perspektive.

Die Ergebnisse sollten Erkennung und Auswirkung getrennt darstellen. Ein Angriff, der eine Zusammenfassung beeinflusst, unterscheidet sich von einem Angriff, der Daten sendet oder einen Kauf abschließt. Käufer müssen sowohl wissen, wie häufig ein Agent feindseligen Inhalten folgt, als auch welche Kontrollen die daraus resultierende Aktion stoppen.

Das zweite Signal ist die breitere Nutzung deterministischer Beschränkungen. Die Browserrichtlinien von Amazon bieten ein Beispiel, weil sie Ziele unabhängig vom Modellschlussfolgern blockieren können. Die Aktionsprüfungen und Berechtigungsschranken von Google erfüllen eine ähnliche Rolle bei der Ausrichtung an den Nutzerinteressen.

Beobachten Sie, ob diese Kontrollen auf granularer Ebene leichter konfigurierbar werden. Unternehmen benötigen Richtlinien nach Ziel, Datensensibilität, Aktionstyp, Identität und Aufgabe. Ein einzelner browserweiter Ein-Aus-Schalter kann diese Unterschiede nicht abbilden.

Das dritte Signal ist, wie Anbieter mit neu offengelegten Angriffsketten umgehen. Schnelle Patches bleiben wichtig, selbst wenn die Schwachstellenklasse fortbesteht. Release Notes sollten erklären, ob eine Korrektur die Erkennung, den Berechtigungsumfang, die Isolation oder die zugrunde liegende Agentenarchitektur verändert.

Forscher werden weiterhin Varianten finden, weil das Verhalten von Agenten nicht deterministisch ist. Ein Patch, der eine Formulierung oder ein Webseitenmuster blockiert, löst keine Intent-Kollision über unterschiedliche Kontexte hinweg. Dauerhafte Verbesserungen sollten Fähigkeiten aus nicht vertrauenswürdigen Pfaden entfernen oder eine unabhängige Autorisierung hinzufügen.

Googles gemeldeter Anstieg bösartiger Webmuster verleiht dieser Arbeit Dringlichkeit. Die Angriffskomplexität war in der Untersuchung des Unternehmens noch begrenzt, doch die zunehmende Aktivität gibt Angreifern mehr Gelegenheiten, bereitgestellte Produkte zu testen. Eine breitere Einführung von Browser-Agenten macht erfolgreiche Techniken wertvoller.

Der Wettbewerb zwischen Amazon und Google wird auch zeigen, welche Sicherheitskompromisse Nutzer akzeptieren. Google kann Bestätigungen direkt in Chrome platzieren, wo Einzelpersonen sie sehen. Amazon kann Entwicklern Infrastruktur-Richtlinien bereitstellen, doch jeder Kunde muss entscheiden, wie restriktiv diese Richtlinien sein sollen.

Für Unternehmensbereitstellungen sollte der kurzfristige Standard einfach sein. Isolieren Sie den Agenten, geben Sie ihm eine eigene Identität, beschränken Sie Ziele, minimieren Sie Tools und verlangen Sie vor folgenreichen Aktionen eine Genehmigung. Protokollieren Sie jeden Übergang zwischen nicht vertrauenswürdigen Inhalten und privilegiertem Verhalten.

Wissensarbeiter sollten sensible Konten nach Möglichkeit außerhalb experimenteller Agentensitzungen halten. Außerdem sollten sie vorgeschlagene Nachrichten, Transaktionen, Downloads und Datenübertragungen prüfen. Den Browser zu aktualisieren ist wichtig, kann das zugrunde liegende Interpretationsproblem jedoch nicht beseitigen.

Entwickler sollten jede Webseite, E-Mail, jedes hochgeladene Dokument und jede abgerufene Notiz als nicht vertrauenswürdige Eingabe behandeln. Sie sollten davon ausgehen, dass das primäre Modell einen Teil davon irgendwann falsch klassifizieren wird. Kontrollen außerhalb dieses Modells müssen bestimmen, was anschließend geschieht.

Die Erkenntnis, dass es keine perfekte Lösung gibt, ist unangenehm, weil sie die Frage des Einsatzes verändert. Teams sollten nicht mehr fragen, ob ein Browser-Agent gegen Prompt Injection immun ist. Sie sollten fragen, ob eine einzige erfolgreiche Injection etwas erreichen kann, das von Bedeutung ist.

Bevor die nächste autonome Funktion aktiviert wird, sollte ihre schwerwiegendste zulässige Aktion erfasst und entschieden werden, ob der Nutzen dieses Risiko rechtfertigt. Ist die Antwort unklar, sollte der Agent schreibgeschützt bleiben oder eine menschliche Freigabe erfordern. Das Rennen zwischen Amazon und Google wird bessere Abwehrmechanismen hervorbringen, doch eine verantwortungsvolle Einführung hängt weiterhin von wirksamer Eindämmung ab.