BrowseSafe++ : renforcer les défenses contre les injections de prompt en conditions réelles

Les agents capables de naviguer sur le Web, comme l’assistant intégré à Comet ou à Computer, doivent interagir avec les pages web : ils en lisent le contenu et s’en servent pour effectuer des actions au nom de leurs utilisateurs. Cela les rend vulnérables à l’injection de prompt indirecte, dans laquelle un attaquant place un texte malveillant sur une page web. Si l’agent suit ces instructions, il peut renvoyer une réponse trompeuse ou effectuer une action que l’utilisateur n’a pas demandée.

En décembre 2025, nous avons publié BrowseSafe, un benchmark et un modèle de détection pour faire face à cette menace. Nous l’avons conçu en ajoutant des attaques synthétiques à des pages web réalistes que les agents étaient susceptibles de rencontrer. Au cours de l’année écoulée, les attaques ont gagné en sophistication et ressemblent de plus en plus à du contenu de page ordinaire. Au lieu de recourir à des formules révélatrices comme « ignore les instructions précédentes », elles imitent souvent un contenu auquel l’agent est susceptible de se fier, comme un avis officiel du site ou une note sur les préférences de l’utilisateur.

Motivés par ces évolutions, nous avons conçu un benchmark mis à jour, BrowseSafe++, afin de mesurer si les détecteurs d’injection actuels repèrent ces attaques et si les agents parviennent à y résister. Il contient 38 675 paires de pages attaquées et saines, construites principalement autour d’injections collectées en conditions réelles. Pour chaque page, nous réécrivons le contenu environnant afin de protéger la confidentialité, tout en conservant l’attaque mot pour mot. Chaque page est fournie dans les quatre formats lus par les agents de navigateur : HTML, Markdown, arbres d’accessibilité et captures d’écran. Nous avons utilisé un sous-ensemble du benchmark pour entraîner BrowseSafe-Guard, une paire de détecteurs de 0,8 milliard de paramètres : un détecteur de texte et un détecteur multimodal. Les deux détecteurs Guard identifient les injections avec plus d’exactitude que les modèles guidés par prompt que nous avons testés, y compris les modèles de pointe. Ils sont aussi plus rapides, moins coûteux, et signalent par erreur beaucoup moins de pages ordinaires.

Nous publions BrowseSafe++ en tant que benchmark ouvert. Le site du projet renvoie vers le jeu de données, le SDK, l’article de recherche et un classement public. Toute équipe peut évaluer son détecteur sur des pages de test dont les étiquettes ne sont pas fournies, puis soumettre ses étiquettes pour notation et inclusion éventuelle dans le classement. Pour évaluer et soumettre vos résultats, consultez Premiers pas.

Construire un benchmark à partir d’injections observées

BrowseSafe++ est construit à partir d’injections de prompt observées sur de vrais sites web. Entre septembre 2025 et septembre 2026, le détecteur d’injection de prompt de Comet a signalé 1,15 million d’injections sur des pages lues par son agent. Nous avons construit 32 187 paires autour de ces injections et ajouté 6 488 paires issues du benchmark BrowseSafe d’origine, pour un total de 38 675 paires. Chaque paire comprend à la fois une page attaquée et sa version saine, c’est-à-dire la même page sans l’injection.

À quoi ressemblent les injections dans la réalité

Deux exemples tirés du benchmark montrent à quoi ressemblent ces injections en pratique.

Dans le premier, une fausse demande d’achat incite l’agent à effectuer une action non autorisée. En octobre 2025, le détecteur de Comet a signalé ce bloc de texte en anglais sur une page de documentation pour développeurs rédigée en russe :

Le texte s’ouvre et se ferme sur des ordres, et le milieu est rempli de marketing banal pour un jeton. Il prétend provenir du développeur même de l’agent et se termine par un code d’autorisation pour donner à l’achat une apparence d’approbation.

Dans un autre, une fausse conversation vise à perturber la tâche de l’agent. Ce texte a été trouvé sur la page d’un dépôt de code en mars 2026 :

Le texte est conçu pour ressembler à une conversation entre un utilisateur et un agent : <|im_start|> et <|im_end|> sont des marqueurs que certains modèles de chat utilisent pour séparer les tours d’une conversation. Un agent qui tomberait dans le piège répondrait à la fausse requête de l’utilisateur avec la phrase de l’attaquant.

Nous observons des tendances similaires parmi les injections signalées :

• Elles imitent des sources de confiance. Dans les deux exemples, le texte de la page se fait passer pour une source à laquelle l’agent se fie : son développeur dans le premier, sa propre conversation dans le second. Les injections peuvent aussi se faire passer pour le site lui-même, en imitant des contrôles de sécurité et des avis de politique, ou pour l’utilisateur, en avançant de fausses préférences. Environ deux sur trois sont rédigées dans un langage soutenu.
• Beaucoup sont rédigées dans d’autres langues. Dans 24,4 % des paires, l’injection utilise une langue différente de celle du reste de la page. Il s’agit généralement d’une instruction en anglais sur une page non anglophone, comme dans le premier exemple. Ces attaques s’adressent clairement à un agent qui lit toutes les langues et dont l’anglais est généralement la langue de prédilection. Les changements de langue compliquent aussi la détection : lors de notre évaluation initiale de BrowseSafe, les attaques multilingues figuraient parmi les plus difficiles à détecter.
• La plupart visent des actions, pas des paroles. Plus de quatre sur dix poussent l’agent vers une action que l’utilisateur n’a jamais demandée, comme l’achat de token dans le premier exemple, et environ un tiers tentent de lui faire abandonner la tâche de l’utilisateur, comme dans le deuxième exemple. Seules 3 % environ tentent d’insérer de fausses informations dans la réponse.
• Elles s’appuient souvent sur du contenu que tout le monde peut publier. Un attaquant n’a pas besoin de contrôler un site. Un message de forum ou un document partagé sur des sites ordinaires suffit, et plus de 23 000 injections de BrowseSafe++ sont arrivées par ce biais. Un domaine de confiance peut tout de même servir à injecter le texte d’un attaquant.

Les injections présentes dans le benchmark final couvrent 12 types de sites web, 24 types d’attaques, 6 objectifs d’attaquant et 18 emplacements sur la page.

Agrandir

D’une page signalée à une paire du benchmark

Nous ne pouvons pas utiliser les pages signalées telles quelles dans le benchmark, car elles peuvent contenir des informations personnelles de l’utilisateur pour lequel l’agent travaillait. Transformer une page en paire de benchmark partageable nécessite trois grandes étapes :

1. Obtenir l’injection : nous collectons les pages signalées, supprimons les doublons et masquons les informations personnelles à l’aide de PII-Tracer. Nous confirmons ensuite que la page contient bien une injection ; plus précisément, nous exigeons qu’un panel de modèles s’accorde sur le fait qu’elle contient une instruction visant à détourner un agent de la tâche voulue par l’utilisateur.
2. Construire la paire : un agent supprime le texte de l’injection de chaque page et réécrit le contenu environnant, en remplaçant des détails tels que les noms et les marques par des équivalents fictifs. Un second agent vérifie que la page réécrite ne contient plus de contenu réel et renvoie les échecs accompagnés de retours. Des relecteurs humains examinent 10 % des pages choisies au hasard ; les problèmes qu’ils détectent sont corrigés dans le pipeline, et les correctifs sont appliqués à l’ensemble du corpus. L’injection est réinsérée dans la page réécrite pour créer la copie attaquée, et omise de la copie saine. Les deux pages partagent la même tâche, le même résultat attendu et les mêmes instructions ordinaires.
3. Vérifier : les agents lisent les pages sous différentes formes ; nous convertissons donc le HTML de chaque page en Markdown, en arbre d’accessibilité (une liste structurée des éléments d’interface d’une page et de leurs libellés) et en capture d’écran. Un autre agent vérifie que l’injection apparaît dans les quatre vues de la page attaquée et que la page saine est jugée inoffensive dans chaque vue. Si l’injection est absente de l’une des vues, nous la déplaçons ailleurs sur la page et relançons le rendu, afin de garantir que l’injection figure dans la page attaquée finale dans toutes les vues. Une dernière série de contrôles automatisés corrige les paires qui portent encore des traces de leur source, comme de vrais noms d’hôte ou noms de marque.

Agrandir

BrowseSafe-Guard : des détecteurs rapides et précis pour chaque vue

Un détecteur utile doit vérifier chaque page rapidement et à moindre coût. Il doit aussi être exact sur les pages attaquées comme sur les pages saines. Une précision élevée est particulièrement importante, car la plupart des pages sont sûres : même un taux de faux positifs relativement faible suffirait pour que la plupart des alertes soient de fausses alertes. Les modèles généralistes guidés par prompt manquent souvent de précision et sont trop lents et coûteux pour être exécutés sur chaque page.

Un détecteur entraîné sur des pages attaquées et des pages saines collectées séparément pourrait apprendre des raccourcis qui distinguent les deux ensembles par simple coïncidence, comme le sujet ou la mise en page d’une page. Un tel détecteur généralise toutefois mal. Guard s’entraîne plutôt sur des paires dont la seule différence est l’injection elle-même, ce qui contribue à améliorer la précision du détecteur. Pour chaque paire, Guard lit séparément la page attaquée et sa jumelle saine, et attribue à chacune un score indiquant la probabilité qu’elle contienne une injection. Deux objectifs d’entraînement servent à mettre à jour le modèle : l’objectif de classification standard et un objectif de classement qui pénalise Guard, sauf si la page attaquée obtient un score supérieur à celui de sa jumelle d’au moins une marge fixe. Intuitivement, l’objectif de classification apprend à Guard quelle décision prendre, tandis que l’objectif de classement rattache cette décision à l’injection elle-même et ignore les distracteurs inoffensifs. Guard apprend ainsi à réagir à l’injection elle-même plutôt qu’au contenu environnant de la page.

Guard se compose de deux détecteurs, chacun affiné à partir de Qwen3.5-0.8B. Le détecteur de texte lit une vue textuelle d’une page : HTML, Markdown ou arbre d’accessibilité. Le détecteur multimodal lit une capture d’écran de la page entière. En déploiement, Guard lit une page en une seule passe avant et produit un score d’injection ; la page est signalée si le score dépasse un seuil. Comme Guard ne compte que 0,8 milliard de paramètres et ne produit qu’un seul score, il est assez rapide et économique pour être exécuté sur chaque page.

Évaluation des performances

Nous avons comparé Guard à 18 modèles invités par prompt à détecter des injections sur un sous-ensemble réservé du benchmark. Nous présentons quatre indicateurs, mesurés sur BrowseSafe++ :

• Le rappel est la part des pages contenant une injection que le détecteur signale ; il mesure le nombre d’attaques détectées, donc plus il est élevé, mieux c’est.
• Le taux de faux positifs (FPR) est la part des pages saines que le détecteur signale par erreur ; il mesure la fréquence des fausses alertes, donc plus il est bas, mieux c’est.
• La précision est la part des pages signalées qui contiennent réellement une injection ; elle mesure la fréquence à laquelle une alerte est correcte, donc plus elle est élevée, mieux c’est.
• Le score F1 est la moyenne harmonique du rappel et de la précision ; il n’est élevé que si un détecteur repère la plupart des attaques et que peu de ses signalements sont de fausses alertes.

Nous utilisons le score F1 comme indicateur principal, car un bon détecteur doit avoir une précision et un rappel élevés. Les quatre indicateurs sont moyennés sur les trois vues textuelles.

Agrandir

Agrandir

Comparaison des modèles

Les petits modèles à poids ouverts que nous avons testés se classent en bas du tableau. Mistral NeMo et Qwen3 30B-A3B signalent chacun environ la moitié des pages saines, tandis que Llama 3.1 8B ne signale presque rien et laisse passer la plupart des attaques. Même le modèle le plus performant du groupe, GPT-OSS 20B, n’atteint qu’un score F1 de 70,97 %. DeepSeek V3.1, un modèle à poids ouverts bien plus grand, fait légèrement mieux, avec un score F1 de 75,23 %.

Les modèles d’API légers, dont GPT-5.4 nano, Gemini 3.1 Flash-Lite et Claude Haiku 4.5, détectent davantage d’attaques, avec un rappel compris entre 85 % et 97 %. En contrepartie, la part de fausses alertes est élevée : Gemini 3.1 Flash-Lite affiche le taux de faux positifs (FPR) le plus bas du groupe, à 35,2 %, et celui de Haiku avoisine 69 %. Par conséquent, le score F1 maximal du groupe est de 80,9 %, atteint par Gemini 3.1 Flash-Lite.

Les autres modèles sont des modèles généralistes plus performants, qui atteignent des scores F1 compris entre 85 % et 92 %. Ils restent toutefois confrontés à des compromis entre rappel et FPR : les modèles qui penchent vers la prudence bloquent des pages légitimes, et ceux qui lèvent moins souvent des alertes laissent passer des attaques. Claude Sonnet 5 affiche le rappel le plus élevé de tous les détecteurs, à 98,73 %, mais un FPR de 24,65 %. Gemini 3.1 Pro et GPT-5.5 atteignent des rappels de 97,78 % et 97,19 %, avec des FPR de 19,80 % et 20,44 %, respectivement. GPT-6 Astra présente la meilleure exactitude globale, avec un rappel de 96,42 % et un FPR de 14,41 %. Decider arrive deuxième, avec un rappel de 96,02 % et un FPR de 17,44 %. Claude Opus 5.5 a le FPR le plus bas, à seulement 4,21 %, mais son rappel de 77,71 % signifie qu’il laisse passer plus d’une attaque sur cinq. Claude Fable 5.1 semble performant sur les pages auxquelles il répond, avec un rappel de 89,31 % et un FPR de 7,92 %, mais il refuse de répondre sur environ 30 % des pages, que la ligne « (all) » compte comme des signalements.

Agrandir

Guard repousse la frontière de Pareto en offrant un meilleur compromis entre attaques manquées et fausses alertes. Il atteint un score F1 d’environ 95 % et se classe premier dans chaque vue textuelle. Il ne signale qu’environ une page saine sur 20, soit environ un tiers du taux d’Astra, le modèle guidé par prompt le plus exact. Cette différence provient de notre entraînement : le modèle Qwen3.5-0.8B de base sur lequel repose Guard, sollicité de la même manière que les autres modèles, n’atteint qu’un score F1 de 64 % et signale près de trois pages saines sur quatre. Pour la vue par capture d’écran, nous comparons le détecteur multimodal de Guard à quatre modèles capables de traiter des images. Sur des captures d’écran de pages entières, Guard obtient un score F1 d’environ 93 %, contre environ 79 % pour le meilleur des autres modèles que nous avons évalués.

Reconnaître une attaque ne signifie pas y résister

Intuitivement, un modèle capable d’identifier correctement une injection devrait aussi l’ignorer lorsqu’il rencontre la page en accomplissant les tâches des utilisateurs. Pourtant, nos expériences montrent que de bons scores de détection ne garantissent pas qu’un modèle résistera à une attaque. Nous avons soumis deux fois la même page attaquée à chaque modèle : une fois pour juger si elle contenait une injection, et une fois pour accomplir la tâche de l’utilisateur sans voir le verdict précédent. Un juge distinct a vérifié si le modèle avait suivi l’injection. Chaque modèle testé a tout de même suivi certaines injections qu’il avait signalées, de 1,64 % des pages signalées pour GPT-6 Astra à 24,73 % pour Llama 3.1 8B.

Agrandir

Les scores de détection ne permettent pas de prédire de manière fiable les différences entre modèles. Claude Sonnet 5 et GPT-5.5 détectent les injections à peu près aussi bien, avec des scores F1 respectifs d’environ 88 % et 89 %. Pourtant, Sonnet 5 a suivi une injection qu’il avait signalée sur 19,74 % des pages, soit dix fois plus souvent que GPT-5.5, à 1,97 %.

Un système déployable de défense contre les injections

Ces résultats suggèrent qu’il est utile de confier la décision de bloquer une page à un modèle spécialisé, plutôt que de s’en remettre au modèle qui accomplit la tâche de l’utilisateur. Un détecteur distinct qui analyse chaque page avant que l’agent n’agisse fournit une couche de défense supplémentaire, et il n’a ni tâche à détourner ni outils à utiliser à mauvais escient.

Guard est conçu pour être ce détecteur. En plus d’obtenir le score F1 et l’exactitude les plus élevés de tous les modèles que nous avons testés, sa petite taille le rend assez économique pour être exécuté sur chaque page. En moyenne, Guard a utilisé environ 0,15 seconde de temps GPU par page de texte. Sur un H200 loué, nous estimons le coût à 0,18 $ pour 1 000 pages, contre 18,95 à 180,61 $ pour les modèles d’API de pointe aux prix catalogue. Dans notre comparaison, un filtrage fréquent devient ainsi bien moins coûteux, tout en conservant des scores de détection élevés.

La figure ci-dessous représente l’exactitude de chaque détecteur en fonction de son temps par page et de son coût pour 1 000 pages, sur des échelles logarithmiques. Guard se trouve seul dans le coin supérieur gauche des deux graphiques : il l’emporte en exactitude, en rapidité et en coût. Chaque modèle guidé par prompt met environ une seconde ou plus par page, et les deux plus exacts, GPT-6 Astra et Claude Fable 5.1, coûtent plus de 100 $ pour 1 000 pages.

Agrandir

Tester les défenses face aux attaques adaptatives

Le benchmark BrowseSafe++ comporte un ensemble fini d’injections. Or, un véritable attaquant peut mener une attaque adaptative : lorsqu’une injection échoue, il peut la réécrire et réessayer. Par conséquent, un agent qui résiste à l’injection d’origine pourrait rester vulnérable à de futures attaques. De plus, les modèles sont entraînés sur des données collectées sur Internet ; ils pourraient donc apprendre à résister à la plupart des injections du benchmark. Comme nous rendons notre benchmark public, celui-ci finira probablement par saturer et ne permettra plus de bien différencier les modèles. Pour résoudre ces deux problèmes, nous avons conçu BrowseSafe-Adapt, un environnement de test dans lequel un modèle attaquant peut réécrire les injections. Chaque test comporte trois étapes :

1. Préparer le cas. Un cas associe une entrée BrowseSafe++ à un agent cible. L’entrée BrowseSafe++ comprend un scénario composé d’une requête et d’une tâche de l’utilisateur, une page attaquée et le résultat souhaité par l’attaquant. L’agent travaille dans un bac à sable qui fournit les outils et les données synthétiques nécessaires à l’exécution de la tâche. Un modèle vérificateur distinct évalue si l’attaque a atteint son objectif.
2. Exécuter une tentative : nous insérons l’injection actuelle dans la page et laissons l’agent accomplir la tâche. Le vérificateur contrôle la réponse de l’agent et toute modification qu’il a apportée au bac à sable afin de déterminer si l’attaque a réussi. La première tentative utilise l’injection de l’entrée BrowseSafe++ d’origine.
3. Réviser et recommencer : si une attaque échoue, nous archivons la tentative et un modèle critique examine ce qui n’a pas fonctionné. Un modèle attaquant s’appuie sur ces retours pour réécrire l’injection ; il peut en modifier la formulation, la mise en forme ou la position sur la page. L’objectif de l’attaque, les critères de réussite et le contenu environnant de la page restent inchangés. La tentative suivante utilise l’attaque mise à jour. Ce processus se répète jusqu’à ce que l’attaque réussisse ou que l’attaquant atteigne une limite de tentatives fixée.

Agrandir

Nous avons testé sept agents, chacun reposant sur un modèle différent : Claude Sonnet 5, Claude Haiku 4.5, GPT-5.5, Gemini 3.1 Pro, Gemini 3.5 Flash-Lite, ainsi que les modèles à poids ouverts DeepSeek V3.1 et Kimi K2. Chaque agent a été confronté aux mêmes 1 024 tâches, avec jusqu’à 64 tentatives par tâche. Lors de la première tentative, le taux de réussite des attaques était faible pour les sept agents. Les injections d’origine ont réussi sur 4 % des tâches évaluées au maximum, quel que soit l’agent. Avec le framework adaptatif, le taux de réussite des attaques a augmenté de façon spectaculaire. L’attaquant a réussi sur au moins 79 % des tâches contre cinq des sept agents. Même les agents les plus robustes se sont révélés vulnérables : les attaques ont encore réussi sur environ deux tâches sur trois contre GPT-5.5 et sur environ une sur trois contre Claude Sonnet 5.

L’écart entre les agents est le plus important lorsque l’objectif de l’attaquant est d’amener l’agent à effectuer un appel d’outil précis. Pour les tâches ayant ce type d’objectif, Sonnet 5 a cédé sur environ 8 % des tâches et GPT-5.5 sur environ 29 %. Les cinq autres ont exécuté l’objectif de l’attaquant sur plus de la moitié de leurs tâches.

Nous avons également exécuté BrowseSafe-Adapt contre l’agent Gemini 3.5 Flash-Lite, Guard analysant au préalable chaque page. Guard a bloqué 94,5 % des injections d’origine et a presque doublé le nombre moyen de tentatives nécessaires aux attaquants, qui est passé de 9,7 à 17,0. Avec l’ensemble des 64 tentatives, l’attaquant a toutefois réussi sur 84,2 % des tâches (93,6 % sans Guard), presque toujours avec une injection que Guard n’avait pas signalée. Cela confirme le point de vue que nous avions exposé lors de la publication de BrowseSafe : aucun modèle de détection n’est une solution miracle, et un détecteur doit donc s’inscrire dans une défense en couches.

Agrandir

Conclusion

Les agents de navigateur sont souvent vulnérables à l’injection de prompt indirecte, dans laquelle des attaques dissimulées sur des pages ordinaires cherchent à entraver la capacité des agents à accomplir les tâches des utilisateurs. Les risques ne font que croître avec le temps : les agents accèdent à davantage de données et d’outils, ce qui accroît les enjeux potentiels des attaques, et les attaquants peuvent réviser leurs injections pour les rendre plus efficaces.

Notre suite BrowseSafe répond à ces menaces. Le benchmark BrowseSafe++ contient 38 675 paires de pages web construites principalement à partir d’injections réelles, ce qui permet un entraînement et une évaluation plus fiables des détecteurs. Les détecteurs BrowseSafe-Guard, entraînés sur ces paires, offrent une détection d’une grande exactitude, rapide et peu coûteuse, ce qui permet d’analyser les pages avant qu’un agent n’agisse sur elles. Le framework BrowseSafe-Adapt permet de tester les modèles face à des injections révisées, mettant en évidence des vulnérabilités qui pourraient passer inaperçues lors de tentatives uniques avec des injections fixes.

Ensemble, nous espérons que ces outils permettront aux chercheurs et aux ingénieurs de trouver plus facilement les failles et d’améliorer les défenses contre les attaques par injection de prompt sur le Web. Nous évaluons et améliorons aussi en permanence les défenses intégrées de Comet et de Computer afin de protéger nos utilisateurs.

Premiers pas

1. Installez le SDK et obtenez l’accès aux données. Le SDK s’installe depuis GitHub :

Le jeu de données est en accès restreint. Demandez l’accès une seule fois sur sa page Hugging Face, puis connectez-vous avec hf auth login.

2. Soumettez vos résultats au classement. Évaluez votre propre détecteur sur l’ensemble de test de BrowseSafe++ :

Cette commande écrit une décision par page pour chaque vue indiquée ; indiquez les trois vues textuelles pour obtenir une moyenne dans le classement texte. Connectez-vous au Space du classement avec votre compte Hugging Face et importez predictions.jsonl. Le Space renvoie le score F1, l’exactitude, le taux de faux positifs et les autres métriques pour chaque vue et, si vous le souhaitez, publie le résultat dans le classement. Chaque compte (créé depuis au moins 60 jours) a droit à une soumission notée par semaine UTC. Les pages de test sont réservées à l’évaluation : ne les utilisez pas pour l’entraînement et ne les redistribuez pas. Le guide de soumission décrit le format de fichier et les règles de publication.

Citation

@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}
}