BrowseSafe++: Stärkere Abwehr gegen reale Prompt-Injection-Angriffe entwickeln

Agenten, die im Web browsen können, etwa der in Comet oder Computer integrierte Assistent, müssen mit Webseiten interagieren, Inhalte lesen und diese nutzen, um Aktionen im Auftrag ihrer Nutzer auszuführen. Dadurch sind sie anfällig für indirekte Prompt-Injection, bei der ein Angreifer schädlichen Text auf einer Webseite platziert. Folgt der Agent diesen Anweisungen, kann er eine irreführende Antwort liefern oder eine Aktion ausführen, die der Nutzer nicht angefordert hat.

Im Dezember 2025 haben wir BrowseSafe veröffentlicht, einen Benchmark und ein Erkennungsmodell für diese Bedrohung. Dafür haben wir synthetische Angriffe in realistische Webseiten eingefügt, auf die Agenten wahrscheinlich stoßen würden. Im Laufe des vergangenen Jahres sind Angriffe raffinierter geworden und ähneln immer mehr gewöhnlichen Seiteninhalten. Statt verräterischer Formulierungen wie „ignoriere vorherige Anweisungen“ imitieren sie oft Inhalte, denen der Agent wahrscheinlich vertraut, etwa einen offiziellen Hinweis der Website oder eine Notiz zu Nutzerpräferenzen.

Angesichts dieser Veränderungen haben wir einen aktualisierten Benchmark entwickelt, BrowseSafe++, um zu messen, ob aktuelle Injection-Detektoren diese Angriffe erkennen und ob Agenten ihnen widerstehen können. Er umfasst 38.675 Paare aus angegriffenen und sauberen Seiten, die überwiegend auf in der realen Welt gesammelten Injections basieren. Für jede Seite schreiben wir den umgebenden Inhalt zum Schutz der Privatsphäre um, behalten den Angriff jedoch wortwörtlich bei. Jede Seite liegt in den vier Formaten vor, die Browser-Agenten lesen: HTML, Markdown, Barrierefreiheitsbäume und Screenshots. Mit einer Teilmenge des Benchmarks haben wir BrowseSafe-Guard trainiert, ein Paar von Detektoren mit je 0,8 Mrd. Parametern: einen Textdetektor und einen multimodalen Detektor. Die beiden Guard-Detektoren erkennen Injections genauer als die per Prompt instruierten Modelle, die wir getestet haben, einschließlich Frontier-Modellen. Zudem sind sie schneller und günstiger und markieren weitaus weniger gewöhnliche Seiten fälschlicherweise.

Wir veröffentlichen BrowseSafe++ als offenen Benchmark. Die Projektwebsite verlinkt auf den Datensatz, das SDK, das Forschungspaper und ein öffentliches Leaderboard. Jedes Team kann seinen Detektor anhand von Testseiten bewerten, deren Labels nicht bereitgestellt werden, und die Labels zur Bewertung und möglichen Aufnahme in das Leaderboard einreichen. Informationen zur Auswertung und Einreichung der Ergebnisse finden sich unter Erste Schritte.

Einen Benchmark aus beobachteten Injections erstellen

BrowseSafe++ basiert auf Prompt-Injections, die auf echten Websites beobachtet wurden. Zwischen September 2025 und September 2026 markierte der Prompt-Injection-Detektor von Comet 1,15 Millionen Injections auf Seiten, die sein Agent gelesen hat. Wir haben 32.187 Paare rund um diese Injections erstellt und 6.488 Paare aus dem ursprünglichen BrowseSafe-Benchmark hinzugefügt, insgesamt also 38.675 Paare. Jedes Paar enthält sowohl eine angegriffene Seite als auch ihren sauberen Zwilling, also dieselbe Seite ohne die Injection.

Wie Injections in der realen Welt aussehen

Zwei Beispiele aus dem Benchmark zeigen, wie diese Injections in der Praxis aussehen.

In einem Fall verleitet eine gefälschte Kaufanfrage den Agenten zu einer nicht autorisierten Aktion. Der Detektor von Comet hat diesen englischen Textblock im Oktober 2025 auf einer russischsprachigen Seite mit Entwicklerdokumentation markiert:

Der Text beginnt und endet mit Befehlen und füllt die Mitte mit gewöhnlichem Token-Marketing. Er gibt vor, vom eigenen Entwickler des Agenten zu stammen, und endet mit einem Autorisierungscode, damit der Kauf genehmigt aussieht.

In einem anderen Beispiel soll eine gefälschte Unterhaltung die Aufgabe des Agenten stören. Dieser Text wurde im März 2026 auf der Seite eines Code-Repositorys gefunden:

Der Text ist so gestaltet, dass er wie eine Unterhaltung zwischen einem Nutzer und einem Agenten aussieht: <|im_start|> und <|im_end|> sind Marker, mit denen manche Chatmodelle die einzelnen Beiträge einer Unterhaltung voneinander trennen. Ein Agent, der auf diesen Angriff hereinfiele, würde auf die gefälschte Nutzeranfrage eingehen und mit der Phrase des Angreifers antworten.

Bei den markierten Injections beobachten wir ähnliche Muster:

• Sie imitieren vertrauenswürdige Quellen. Beide Beispiele lassen den Seitentext wie eine Quelle klingen, der der Agent vertraut: im ersten Fall sein Entwickler, im zweiten seine eigene Unterhaltung. Injektionen können sich auch als die Website selbst ausgeben, indem sie Sicherheitsprüfungen und Richtlinienhinweise nachahmen, oder als der Nutzer, indem sie gefälschte Präferenzen vorbringen. Etwa zwei von drei sind in formeller Sprache verfasst.
• Viele sind in anderen Sprachen verfasst. Bei 24,4 % der Paare verwendet die Injection eine andere Sprache als der Rest der Seite. Typischerweise handelt es sich um eine englische Anweisung auf einer nicht englischsprachigen Seite, wie im ersten Beispiel. Solche Angriffe richten sich eindeutig an einen Agenten, der jede Sprache liest und dessen Muttersprache in der Regel Englisch ist. Sprachwechsel erschweren zudem die Erkennung: In unserer ursprünglichen BrowseSafe-Evaluierung gehörten mehrsprachige Angriffe zu den am schwersten zu erkennenden.
• Die meisten zielen auf Aktionen, nicht auf Worte. Mehr als vier von zehn drängen den Agenten zu einer Aktion, um die der Nutzer nie gebeten hat, wie der Token-Kauf im ersten Beispiel, und etwa ein Drittel versucht, ihn zum Abbruch der Aufgabe des Nutzers zu bewegen, wie im zweiten Beispiel. Nur etwa 3 % versuchen, falsche Informationen in der Antwort zu platzieren.
• Sie nutzen oft Inhalte, die jeder posten kann. Ein Angreifer muss keine Website kontrollieren. Ein Forenbeitrag oder ein geteiltes Dokument auf gewöhnlichen Websites genügt, und mehr als 23.000 Injektionen in BrowseSafe++ sind auf diesem Weg dorthin gelangt. Auch eine vertrauenswürdige Domain kann genutzt werden, um den Text eines Angreifers einzuschleusen.

Die Injections im finalen Benchmark umfassen 12 Arten von Websites, 24 Angriffstypen, 6 Angreiferziele und 18 Platzierungen auf der Seite.

Vergrößern

Von einer markierten Seite zu einem Benchmark-Paar

Markierte Seiten können wir nicht unverändert in den Benchmark übernehmen, da sie personenbezogene Daten des Nutzers enthalten können, für den der Agent tätig war. Um aus einer Seite ein teilbares Benchmark-Paar zu machen, sind drei Hauptphasen erforderlich:

1. Injection beschaffen: Wir sammeln die markierten Seiten, entfernen Duplikate und maskieren personenbezogene Daten mit PII-Tracer. Anschließend bestätigen wir, dass die Seite eine Injection enthält; konkret muss ein Gremium aus Modellen übereinstimmend feststellen, dass sie eine Anweisung enthält, die versucht, einen Agenten von der vom Nutzer beabsichtigten Aufgabe abzulenken.
2. Paar erstellen: Ein Agent entfernt den Injection-Text von jeder Seite und schreibt den umgebenden Seiteninhalt um, wobei er Details wie Namen und Marken durch fiktive ersetzt. Ein zweiter Agent prüft die umgeschriebene Seite auf verbliebene reale Inhalte und schickt fehlerhafte Seiten mit Feedback zurück. Menschliche Prüfer untersuchen zufällig ausgewählte 10 % der Seiten; gefundene Probleme werden in der Pipeline behoben, und die Korrekturen werden auf den gesamten Korpus angewendet. Die Injection wird wieder in die umgeschriebene Seite eingefügt, um die angegriffene Kopie zu erstellen, und in der sauberen Kopie weggelassen. Beide Seiten haben dieselbe Aufgabe, dasselbe erwartete Ergebnis und dieselben gewöhnlichen Anweisungen.
3. Verifizieren: Agenten lesen Seiten in unterschiedlichen Formen, daher rendern wir das HTML jeder Seite als Markdown, als Barrierefreiheitsbaum (eine strukturierte Liste der Oberflächenelemente einer Seite und ihrer Beschriftungen) und als Screenshot. Ein weiterer Agent prüft, ob die Injection in allen vier Ansichten der angegriffenen Seite erscheint und ob die saubere Seite in jeder Ansicht als harmlos eingestuft wird. Fehlt die Injection in einer der Ansichten, verschieben wir sie an eine andere Stelle auf der Seite und rendern erneut, sodass die Injection in der finalen angegriffenen Seite in allen Ansichten vorkommt. Abschließend korrigiert eine Reihe automatisierter Prüfungen alle Paare, die noch Spuren ihrer Quelle enthalten, etwa echte Hostnamen oder Markennamen.

Vergrößern

BrowseSafe-Guard: Schnelle und präzise Detektoren für jede Ansicht

Ein nützlicher Detektor muss jede Seite schnell und kostengünstig prüfen. Außerdem muss er sowohl bei angegriffenen als auch bei sauberen Seiten genau sein. Eine hohe Präzision ist besonders wichtig, da die meisten Seiten sicher sind; selbst eine relativ niedrige Falsch-Positiv-Rate würde dazu führen, dass die meisten Alarme Fehlalarme sind. Per Prompt instruierte Allzweckmodelle schneiden bei der Präzision oft schlecht ab und sind zu langsam und zu teuer, um sie auf jeder Seite auszuführen.

Ein Detektor, der mit separat gesammelten angegriffenen und sauberen Seiten trainiert wird, könnte Abkürzungen lernen, die die beiden Mengen zufällig trennen, etwa das Thema oder das Layout einer Seite. Ein solcher Detektor generalisiert jedoch schlecht. Guard trainiert stattdessen mit Paaren, deren einziger Unterschied die Injektion selbst ist, was zu einer höheren Präzision des Detektors beiträgt. Für jedes Paar liest Guard die angegriffene Seite und ihren sauberen Zwilling getrennt und vergibt für jede einen Score dafür, wie wahrscheinlich sie eine Injektion enthält. Zum Aktualisieren des Modells werden zwei Trainingsziele verwendet: das übliche Klassifikationsziel und ein Ranking-Ziel, das Guard bestraft, sofern die angegriffene Seite nicht um mindestens eine feste Marge höher bewertet wird als ihr Zwilling. Intuitiv lehrt das Klassifikationsziel Guard, welche Entscheidung zu treffen ist, und das Ranking-Ziel bindet diese Entscheidung an die Injektion selbst und ignoriert harmlose Ablenkungen. So lernt Guard, auf die Injektion selbst zu reagieren statt auf den umgebenden Seiteninhalt.

Guard besteht aus zwei Detektoren, die jeweils auf Basis von Qwen3.5-0.8B feinabgestimmt wurden. Der Textdetektor liest eine Textansicht einer Seite: entweder HTML, Markdown oder den Barrierefreiheitsbaum. Der multimodale Detektor liest einen Screenshot der gesamten Seite. Im Einsatz liest Guard eine Seite in einem einzigen Forward Pass und gibt einen Injektions-Score aus; die Seite wird markiert, wenn der Score einen Schwellenwert überschreitet. Da Guard nur 0,8 Mrd. Parameter hat und einen einzigen Score ausgibt, ist es schnell und günstig genug, um auf jeder Seite ausgeführt zu werden.

Leistungsvergleich im Benchmark

Wir haben Guard mit 18 Modellen verglichen, die per Prompt angewiesen wurden, Injections auf einer zurückgehaltenen Teilmenge des Benchmarks zu erkennen. Wir geben vier Metriken an, gemessen auf BrowseSafe++:

• Der Recall ist der Anteil der Seiten mit Injection, die der Detektor markiert. Er misst, wie viele Angriffe er erkennt; höher ist besser.
• Die Falsch-Positiv-Rate (FPR) ist der Anteil der sauberen Seiten, die der Detektor fälschlicherweise markiert. Sie misst, wie oft er Fehlalarme auslöst; niedriger ist besser.
• Die Präzision ist der Anteil der markierten Seiten, die tatsächlich eine Injection enthalten. Sie misst, wie oft ein Alarm zutrifft; höher ist besser.
• F1 ist das harmonische Mittel aus Recall und Präzision; der Wert ist nur dann hoch, wenn ein Detektor die meisten Angriffe erkennt und nur wenige seiner Markierungen Fehlalarme sind.

Wir verwenden F1 als primäre Metrik, da ein guter Detektor sowohl eine hohe Präzision als auch einen hohen Recall aufweisen sollte. Alle vier Metriken werden über die drei Textansichten gemittelt.

Vergrößern

Vergrößern

Modellvergleiche

Die kleinen Open-Weight-Modelle, die wir getestet haben, landeten auf den hinteren Plätzen. Mistral NeMo und Qwen3 30B-A3B markieren jeweils etwa die Hälfte der sauberen Seiten, während Llama 3.1 8B kaum etwas markiert und die meisten Angriffe übersieht. Selbst das stärkste Modell der Gruppe, GPT-OSS 20B, erreicht nur einen F1-Wert von 70,97 %. DeepSeek V3.1, ein deutlich größeres Open-Weight-Modell, schneidet mit einem F1-Wert von 75,23 % etwas besser ab.

Leichtgewichtige API-Modelle wie GPT-5.4 nano, Gemini 3.1 Flash-Lite und Claude Haiku 4.5 erkennen mehr Angriffe, mit einem Recall zwischen 85 % und 97 %. Der Preis dafür ist jedoch ein hoher Anteil an Fehlalarmen: Gemini 3.1 Flash-Lite hat mit 35,2 % die niedrigste FPR der Gruppe, und die FPR von Haiku liegt bei fast 69 %. Daher liegt der höchste F1-Wert der Gruppe bei 80,9 %, erreicht von Gemini 3.1 Flash-Lite.

Die übrigen Modelle sind stärkere Allzweckmodelle und erreichen F1-Werte zwischen 85 % und 92 %. Sie müssen jedoch weiterhin zwischen Recall und FPR abwägen: Vorsichtigere Modelle blockieren legitime Seiten, und Modelle, die seltener Alarm schlagen, übersehen Angriffe. Claude Sonnet 5 hat mit 98,73 % den höchsten Recall aller Detektoren, aber eine FPR von 24,65 %. Gemini 3.1 Pro und GPT-5.5 erreichen einen Recall von 97,78 % bzw. 97,19 % bei einer FPR von 19,80 % bzw. 20,44 %. GPT-6 Astra hat die höchste Gesamtgenauigkeit mit einem Recall von 96,42 % und einer FPR von 14,41 %. Decider folgt auf dem zweiten Platz mit einem Recall von 96,02 % und einer FPR von 17,44 %. Claude Opus 5.5 hat mit nur 4,21 % die niedrigste FPR, doch sein Recall von 77,71 % bedeutet, dass es mehr als jeden fünften Angriff übersieht. Claude Fable 5.1 wirkt auf den Seiten, die es beantwortet, mit einem Recall von 89,31 % und einer FPR von 7,92 % stark, verweigert jedoch auf etwa 30 % der Seiten die Antwort, was in der Zeile „(alle)“ als Markierung gezählt wird.

Vergrößern

Guard verschiebt die Pareto-Front und erzielt einen besseren Kompromiss zwischen übersehenen Angriffen und Fehlalarmen. Es erreicht einen F1-Wert von etwa 95 % und belegt in jeder Textansicht den ersten Platz. Es markiert nur etwa eine von 20 sauberen Seiten, etwa ein Drittel der Rate von Astra, dem genauesten per Prompt instruierten Modell. Dieser Unterschied ist auf unser Training zurückzuführen: Das unveränderte Qwen3.5-0.8B, auf dem Guard basiert, erreicht mit demselben Prompt wie die anderen Modelle nur einen F1-Wert von 64 % und markiert fast drei von vier sauberen Seiten. Im Screenshot-Szenario vergleichen wir den multimodalen Detektor von Guard mit vier bildfähigen Modellen. Bei ganzseitigen Screenshots erreicht Guard einen F1-Wert von etwa 93 %, gegenüber etwa 79 % für das beste der anderen von uns evaluierten Modelle.

Einen Angriff zu erkennen heißt nicht, ihm zu widerstehen

Intuitiv sollte ein Modell, das eine Injection korrekt erkennen kann, diese Injection auch ignorieren, wenn es bei der Erledigung von Nutzeraufgaben auf die Seite stößt. Unsere Experimente zeigen jedoch, dass hohe Erkennungswerte nicht garantieren, dass ein Modell einem Angriff widersteht. Wir haben jedem Modell dieselbe angegriffene Seite zweimal vorgelegt: einmal, um zu beurteilen, ob sie eine Injection enthält, und einmal, um die Aufgabe des Nutzers auszuführen, ohne das vorherige Urteil zu sehen. Eine separate Prüfinstanz kontrollierte, ob das Modell der Injection folgte. Jedes getestete Modell folgte dennoch einigen Injections, die es markiert hatte – von 1,64 % der markierten Seiten bei GPT-6 Astra bis zu 24,73 % bei Llama 3.1 8B.

Vergrößern

Erkennungswerte sagen Unterschiede zwischen Modellen nicht zuverlässig voraus. Claude Sonnet 5 und GPT-5.5 erkennen Injections etwa gleich gut, mit F1-Werten von etwa 88 % bzw. 89 %. Sonnet 5 folgte jedoch auf 19,74 % der Seiten einer Injection, die es zuvor markiert hatte – zehnmal so häufig wie GPT-5.5 mit 1,97 %.

Ein einsatzfähiges System zur Abwehr von Injektionen

Diese Ergebnisse legen nahe, dass es sinnvoll ist, die Entscheidung über das Blockieren einer Seite an ein spezialisiertes Modell zu delegieren, anstatt sich auf das Modell zu verlassen, das die Aufgabe des Nutzers ausführt. Ein separater Detektor, der jede Seite prüft, bevor der Agent handelt, bietet eine zusätzliche Verteidigungsebene und hat weder eine Aufgabe, die gekapert, noch Tools, die missbraucht werden könnten.

Guard ist genau als dieser Detektor konzipiert. Guard erzielt nicht nur den höchsten F1-Wert und die höchste Genauigkeit aller von uns getesteten Modelle, sondern ist dank seiner geringen Größe auch günstig genug, um auf jeder Seite ausgeführt zu werden. Im Durchschnitt benötigte Guard etwa 0,15 Sekunden GPU-Zeit pro Textseite. Auf einer gemieteten H200 schätzen wir die Kosten auf 0,18 $ pro 1.000 Seiten, verglichen mit 18,95–180,61 $ für die Frontier-API-Modelle zu Listenpreisen. Damit ist häufiges Screening in unserem Vergleich deutlich günstiger, bei weiterhin hohen Erkennungswerten.

Die folgende Abbildung stellt die Genauigkeit jedes Detektors seiner Zeit pro Seite und seinen Kosten pro 1.000 Seiten gegenüber, beides auf logarithmischen Skalen. Guard steht in beiden Diagrammen allein in der oberen linken Ecke: Es liegt bei Genauigkeit, Geschwindigkeit und Kosten vorn. Jedes per Prompt instruierte Modell benötigt etwa eine Sekunde oder mehr pro Seite, und die beiden genauesten, GPT-6 Astra und Claude Fable 5.1, kosten über 100 $ pro 1.000 Seiten.

Vergrößern

Verteidigungen gegen adaptive Angriffe testen

Der Benchmark BrowseSafe++ enthält eine begrenzte Menge an Injections. Ein echter Angreifer kann jedoch einen adaptiven Angriff durchführen: Wenn eine Injection fehlschlägt, kann er sie umschreiben und es erneut versuchen. Daher könnte ein Agent, der der ursprünglichen Injection widersteht, dennoch für künftige Angriffe anfällig sein. Zudem werden Modelle mit Daten aus dem Internet trainiert, sodass sie lernen könnten, den meisten Injections des Benchmarks zu widerstehen; da wir unseren Benchmark öffentlich freigeben, wird er voraussichtlich in die Sättigung geraten und Modelle nicht mehr gut unterscheiden können. Um beide Probleme anzugehen, haben wir BrowseSafe-Adapt entwickelt, eine Testumgebung, in der ein Angreifermodell Injections umschreiben kann. Jeder Test umfasst drei Phasen:

1. Den Fall aufsetzen. Ein Fall kombiniert einen BrowseSafe++-Eintrag mit einem Ziel-Agenten. Der BrowseSafe++-Eintrag umfasst ein Szenario mit einer Nutzeranfrage und einer Aufgabe, eine angegriffene Seite und das vom Angreifer gewünschte Ergebnis. Der Agent arbeitet in einer Sandbox, die die zur Ausführung der Aufgabe erforderlichen Tools und synthetischen Daten bereitstellt. Ein separates Verifizierungsmodell bewertet, ob der Angriff sein Ziel erreicht hat.
2. Versuch durchführen: Wir fügen die aktuelle Injection in die Seite ein und lassen den Agenten die Aufgabe ausführen. Der Verifizierer prüft die Antwort des Agenten und alle Änderungen, die er in der Sandbox vorgenommen hat, um festzustellen, ob der Angriff erfolgreich war. Der erste Versuch verwendet die Injection aus dem ursprünglichen Eintrag von BrowseSafe++.
3. Überarbeiten und wiederholen: Schlägt ein Angriff fehl, archivieren wir den Versuch, und ein Kritikermodell analysiert, was schiefgelaufen ist. Ein Angreifermodell nutzt dieses Feedback, um die Injection umzuschreiben; es kann Wortlaut, Formatierung oder Position des Angriffs auf der Seite ändern. Angriffsziel, Erfolgskriterien und der umgebende Seiteninhalt bleiben gleich. Der nächste Versuch verwendet den aktualisierten Angriff. Dieser Vorgang wird wiederholt, bis der Angriff erfolgreich ist oder der Angreifer ein festgelegtes Versuchslimit erreicht.

Vergrößern

Wir haben sieben Agenten getestet, die jeweils auf einem anderen Modell basieren: Claude Sonnet 5, Claude Haiku 4.5, GPT-5.5, Gemini 3.1 Pro, Gemini 3.5 Flash-Lite sowie die Open-Weight-Modelle DeepSeek V3.1 und Kimi K2. Jeder Agent bearbeitete dieselben 1.024 Aufgaben mit bis zu 64 Versuchen pro Aufgabe. Beim ersten Versuch war der Angriffserfolg bei allen sieben Agenten gering. Die ursprünglichen Injections waren bei keinem Agenten in mehr als 4 % der ausgewerteten Aufgaben erfolgreich. Mit dem adaptiven Framework stieg der Angriffserfolg drastisch an. Bei fünf der sieben Agenten war der Angreifer bei mindestens 79 % der Aufgaben erfolgreich. Selbst die stärksten Agenten waren anfällig: Bei GPT-5.5 waren Angriffe immer noch bei etwa zwei von drei Aufgaben erfolgreich, bei Claude Sonnet 5 bei etwa einer von drei.

Am größten ist der Unterschied zwischen den Agenten, wenn das Ziel des Angreifers darin besteht, den Agenten zu einem bestimmten Tool-Aufruf zu bewegen. Bei Aufgaben mit diesem Ziel gab Sonnet 5 bei etwa 8 % der Aufgaben nach, GPT-5.5 bei etwa 29 %. Die anderen fünf führten bei mehr als der Hälfte ihrer Aufgaben das Ziel des Angreifers aus.

Außerdem haben wir BrowseSafe-Adapt gegen den Agenten mit Gemini 3.5 Flash-Lite eingesetzt, wobei Guard jede Seite vorab prüfte. Guard blockierte 94,5 % der ursprünglichen Injections und verdoppelte nahezu die durchschnittliche Zahl der Versuche, die die Angreifer benötigten, von 9,7 auf 17,0. Mit allen 64 Versuchen war der Angreifer jedoch weiterhin bei 84,2 % der Aufgaben erfolgreich (93,6 % ohne Guard), fast immer mit einer Injection, die Guard nicht markiert hatte. Das entspricht der Sichtweise, die wir bei der Veröffentlichung von BrowseSafe dargelegt haben: Kein Erkennungsmodell ist ein Allheilmittel, daher muss ein Detektor Teil einer mehrschichtigen Verteidigung sein.

Vergrößern

Fazit

Browser-Agenten sind häufig anfällig für indirekte Prompt-Injection, bei der auf gewöhnlichen Seiten versteckte Angriffe versuchen, die Agenten bei der Ausführung von Nutzeraufgaben zu stören. Die Gefahren nehmen mit der Zeit nur zu: zum einen, weil Agenten Zugriff auf mehr Daten und Tools erhalten, wodurch bei Angriffen mehr auf dem Spiel steht, und zum anderen, weil Angreifer ihre Injections überarbeiten können, um sie wirksamer zu machen.

Unsere BrowseSafe-Suite begegnet diesen Bedrohungen. Der Benchmark BrowseSafe++ enthält 38.675 Webseitenpaare, die überwiegend aus echten Injections erstellt wurden, und ermöglicht so zuverlässigeres Training und zuverlässigere Evaluierung von Detektoren. Die mit diesen Paaren trainierten BrowseSafe-Guard-Detektoren ermöglichen eine hochpräzise, schnelle und kostengünstige Erkennung, sodass Seiten gescannt werden können, bevor ein Agent auf ihrer Grundlage handelt. Das Framework BrowseSafe-Adapt ermöglicht es, Modelle gegen überarbeitete Injections zu testen, und deckt Schwachstellen auf, die bei Einzelversuchen mit festen Injections möglicherweise nicht erkennbar wären.

Wir hoffen, dass diese Tools es Forschenden und Entwicklern gemeinsam erleichtern, Schwachstellen zu finden und die Abwehr webbasierter Prompt-Injection-Angriffe zu verbessern. Zudem evaluieren und verbessern wir kontinuierlich die integrierten Schutzmechanismen von Comet und Computer, um unsere Nutzer zu schützen.

Erste Schritte

1. SDK installieren und Zugriff auf die Daten erhalten. Das SDK wird über GitHub installiert:

Der Datensatz ist zugangsbeschränkt. Zugriff einmalig auf seiner Hugging-Face-Seite anfordern und anschließend mit hf auth login anmelden.

2. Beim Leaderboard einreichen. Den eigenen Detektor auf dem Test-Split von BrowseSafe++ evaluieren:

Dadurch wird für jede angegebene Ansicht eine Entscheidung pro Seite geschrieben; geben Sie alle drei Textansichten an, um einen Durchschnitt für das Text-Leaderboard zu erhalten. Melden Sie sich mit Ihrem Hugging-Face-Konto im Leaderboard-Space an und laden Sie predictions.jsonl hoch. Der Space liefert F1, Genauigkeit, Falsch-Positiv-Rate und die anderen Metriken für jede Ansicht und veröffentlicht das Ergebnis auf Wunsch im Leaderboard. Jedes Konto (mindestens 60 Tage alt) erhält pro UTC-Woche eine bewertete Einreichung. Die Testseiten dienen ausschließlich der Evaluierung: Trainieren Sie nicht damit und verbreiten Sie sie nicht weiter. Der Leitfaden für Einreichungen behandelt das Dateiformat und die Veröffentlichungsregeln.

Zitierhinweis

@online{perplexity2026BrowseSafePlusPlus,
  author = {{Perplexity} and Yuetian Chen and Kaiyuan Zhang and Yuntao Du and Thomas Li and Mark Tenenholtz and Kyle Polley and Jerry Ma and Denis Yarats and Ninghui Li and Jarrod Bryan and Claire Beamer and Jeremy Yang},
  title = {{BrowseSafe++: Building stronger defenses against real-world prompt injection}},
  date = {2026-10-28},
  url = {https://www.perplexity.ai/hub/blog/browsesafe-plus-plus}
}