Perplexity a récemment publié BrowseSafe, un modèle open source conçu pour aider les développeurs à protéger les navigateurs propulsés par l’IA contre les attaques par injection de prompts.
Cependant, des tests en équipe rouge menés par les chercheurs de Lasso suggèrent que ce garde-fou n’est peut-être pas aussi complet que l’affirme sa présentation.
« Nous avons obtenu en quelques heures un taux de contournement de 36 % en utilisant des techniques standard — et non des méthodes avancées. Des attaquants motivés qui y consacreraient davantage de temps feraient mieux », a déclaré Eliran Suisa, responsable de la recherche produit chez Lasso.
Les risques de sécurité liés aux agents web autonomes
BrowseSafe est déjà utilisé au sein du propre navigateur IA de Perplexity, Comet, et vise à protéger les agents autonomes qui lisent et exploitent le contenu web en temps réel.
Si ses hypothèses de détection s’avèrent erronées, les organisations qui s’en servent comme défense principale pourraient exposer les modèles en aval à des instructions malveillantes — avec, à la clé, des fuites de données, des violations de politiques ou des actions dangereuses.
Les chercheurs ont évalué la capacité de BrowseSafe à détecter les attaques par injection de prompts dans des contextes de navigation HTML réalistes.
Les tests se sont concentrés sur la capacité du modèle à fonctionner comme un contrôle de sécurité autonome, comme le laissait entendre la communication de Perplexity.
Plutôt que de s’appuyer sur la rédaction manuelle de prompts, les chercheurs ont utilisé une équipe rouge automatisée pour appliquer systématiquement des techniques d’encodage et d’obfuscation difficiles à mettre au jour par les seuls tests humains.
Tester BrowseSafe face aux attaques
BrowseSafe est implémenté sous la forme d’un classificateur binaire basé sur Qwen3-30B, qui produit une simple décision sûr ou malveillant avant que le contenu n’atteigne la logique centrale d’un agent.
Selon sa fiche de modèle, le système est conçu pour résister au HTML désordonné, aux éléments distracteurs et aux schémas d’injection courants rencontrés pendant la navigation.
Cette conception fonctionne bien contre les attaques directes. Cependant, le modèle a eu du mal à gérer les techniques d’injection de prompts qui reposent sur l’encodage plutôt que sur des instructions en langage courant.
Lors des tests, BrowseSafe n’a pas détecté les prompts malveillants encodés en Base32, dans l’alphabet phonétique de l’OTAN et en Pig Latin — même lorsque ces charges utiles étaient intégrées à des structures HTML similaires à celles de véritables pages web.
En revanche, les attaques encodées en hexadécimal ont été systématiquement détectées, ce qui suggère que ces schémas étaient plus présents dans les données d’entraînement du modèle.
Au total, environ 36 % des prompts malveillants ont été classés à tort comme sûrs.
Comment les attaques encodées passent entre les mailles du filet
Le problème central est d’ordre architectural plutôt que spécifique à l’implémentation. BrowseSafe classe le texte brut en entrée sans le décoder.
Les techniques d’encodage transforment l’apparence superficielle des instructions malveillantes tout en préservant leur intention.
Un grand modèle de langage en aval — ou un humain — peut facilement décoder ces transformations une fois que le garde-fou a déjà approuvé l’entrée.
Cela crée une dangereuse faille : le modèle de sécurité évalue du texte non décodé, tandis que le modèle cible interprète une intention décodée.
Si le garde-fou approuve une charge utile encodée, rien n’empêche intrinsèquement l’agent en aval d’exécuter les instructions de l’attaquant.
Dans les environnements où BrowseSafe est utilisé comme garde-fou principal ou unique, cela crée un point de défaillance unique — une fois qu’un prompt est classé comme sûr, il se peut qu’aucun contrôle en aval ne puisse détecter ou arrêter un comportement malveillant.
Ces échecs n’étaient pas de vagues cas limites.
Dans de nombreux cas, BrowseSafe a attribué avec un haut degré de confiance des classifications sûres à des contenus manifestement malveillants, ce qui montre que les seuls scores de confiance ne constituent pas un indicateur fiable du niveau de protection.
Des contrôles en couches pour sécuriser les agents
S’appuyer sur un seul garde-fou fondé sur un modèle ne suffit pas à se défendre contre les attaques par injection de prompts dans le monde réel, en particulier celles qui exploitent des techniques d’encodage et d’obfuscation.
Une mitigation efficace exige une approche de défense en profondeur qui prenne en compte les défaillances avant et après que les prompts n’atteignent la logique centrale d’un agent.
Les organisations devraient partir du principe que certaines attaques contourneront le filtrage initial et concevoir des contrôles qui en limitent l’impact, détectent les abus et s’adaptent au fil du temps.
- Testez l’ensemble du pipeline d’agent avant le déploiement à l’aide de tests automatisés couvrant les techniques d’injection de prompts sémantiques, encodées et obfusquées.
- Normalisez et décodez les entrées avant la classification afin de réduire les contournements fondés sur l’obfuscation et de garantir que les garde-fous évaluent l’intention réelle.
- Utilisez des garde-fous en couches et en ensemble plutôt qu’un seul modèle pour détecter les anomalies sémantiques, structurelles et comportementales.
- Appliquez des politiques déterministes et des contrôles de moindre privilège qui limitent ce que les agents et les outils peuvent faire, même lorsque les prompts passent le filtrage initial.
- Ajoutez une surveillance à l’exécution et des contrôles au niveau des actions pour détecter les dérives comportementales, valider l’utilisation des outils et bloquer en temps réel les actions dangereuses du navigateur.
- Considérez les modèles de garde-fou comme des composants au sein d’une architecture de sécurité continuellement mise à jour, éclairée par des tests, une surveillance et des boucles de rétroaction permanents.
Ensemble, ces mesures contribuent à maintenir un comportement des agents aligné, résilient et sécurisé tout au long de leur cycle de vie.
L’open source n’est pas le risque — les hypothèses, si
Les limites de BrowseSafe reflètent une tendance plus large de la sécurité de l’IA : à mesure que les garde-fous se spécialisent, les attaquants s’appuient de plus en plus sur la manipulation au niveau de la représentation plutôt que sur un langage manifestement malveillant.
L’injection de prompts fondée sur l’encodage n’est pas nouvelle, mais elle reste efficace contre les systèmes qui supposent que les menaces seront sémantiquement lisibles au moment de l’inspection.
L’open source n’est pas le problème. BrowseSafe offre transparence, reproductibilité et une base de référence précieuse pour la sécurité des navigateurs IA. Le risque réside dans le fait de présenter un modèle de garde-fou unique comme une protection suffisante lorsqu’il est utilisé isolément.
À mesure que les agents autonomes gagnent en autorité sur les outils, les données et les workflows, les équipes de sécurité devront partir du principe que certaines attaques contourneront la détection précoce — et concevoir des systèmes capables malgré tout d’échouer de manière sûre lorsque cela se produit.
un état d’esprit zéro confiance — qui part du principe qu’une compromission est possible et en limite l’impact à chaque étape de l’exécution.