Construire des navigateurs IA plus sûrs avec BrowseSafe

Aujourd'hui, nous lançons BrowseSafe, un benchmark de recherche ouvert et un modèle de détection de contenu visant à assurer la sécurité des utilisateurs lors de leur navigation sur le web agentique.

Alors que les assistants IA quittent les barres de recherche pour s'intégrer directement au navigateur, nous anticipons une mutation de la prochaine génération du web, passant des pages aux agents : il s'agit moins de savoir où réside l'information que de savoir qui la récupère et agit en conséquence. Comet transforme le navigateur en un espace où un assistant peut accomplir des tâches, et pas seulement répondre à des questions ; un principe demeure donc non négociable : il doit impérativement rester aux côtés de l'utilisateur.

BrowseSafe : protéger les agents et les utilisateurs grâce à l'analyse de contenu en temps réel

BrowseSafe est un modèle de détection ajusté pour répondre à une question unique et précise : compte tenu du code HTML d'une page, contient-elle des instructions malveillantes visant l'agent ? Les grands modèles à usage général peuvent raisonner efficacement sur ces cas, mais ils sont souvent trop lents et coûteux pour être exécutés sur chaque page. BrowseSafe analyse des pages web entières en temps réel sans ralentir le navigateur. Nous publions également la suite d'évaluation BrowseSafe-Bench en tant que ressource pour évaluer et améliorer l'efficacité de la défense.

Frontières de confiance et défenses multicouches

Cependant, une nouvelle génération de navigation assistée par IA implique également une nouvelle génération de cybermenaces nécessitant des approches inédites pour assurer la sécurité des utilisateurs. Dans un précédent article, nous avons expliqué comment Comet utilise plusieurs couches de protection pour garantir que l'assistant effectue ce que l'utilisateur a demandé, même lorsqu'un site web tente de le détourner par une injection de prompt. Aujourd'hui, nous nous concentrons sur la manière dont nous traitons ce problème : comment ces menaces sont définies, testées face à des attaques réelles et utilisées pour entraîner des modèles spécialisés capables d'identifier et de stopper les instructions malveillantes assez rapidement pour une exécution sécurisée dans le navigateur.

Comment fonctionne l'injection de prompt dans le navigateur

L'injection de prompt consiste en un langage malveillant intégré dans le texte lu par l'IA, conçu pour outrepasser son intention initiale. Dans le navigateur, les agents lisent des pages entières ; les attaques peuvent donc se dissimuler dans des éléments tels que des commentaires, des modèles ou de longs pieds de page.

Les attaquants exploitent ces zones pour insérer des instructions qui redirigent discrètement l'agent. Parce qu'il lit tout, y compris le contenu que la plupart des gens ne remarquent jamais, ces messages peuvent détourner le comportement de l'outil en l'absence de garde-fous robustes.

Ces attaques évitent souvent les expressions évidentes et peuvent être rédigées dans un langage soigné ou multilingue, ou encore placées dans des éléments HTML qui n'apparaissent jamais à l'écran, comme des attributs de données ou des champs de formulaire que les navigateurs n'affichent pas visuellement, mais que les agents analysent tout de même.

BrowseSafe-Bench : faire progresser la sécurité des agents dans des environnements réels

Pour étudier ces attaques dans un contexte simulant le web réel, nous avons conçu BrowseSafe, un modèle de détection que nous avons entraîné et mis en open source, ainsi que BrowseSafe-Bench, un benchmark public composé de 14 719 exemples imitant des pages de production. Il inclut du code HTML complexe, du contenu bruité et un mélange d'échantillons malveillants et inoffensifs variant selon trois axes : l'objectif de l'attaquant, l'emplacement de l'instruction dans la page et le style rédactionnel.

Le benchmark comprend 11 types d'attaques, neuf stratégies d'injection couvrant des champs masqués jusqu'aux paragraphes et pieds de page visibles, ainsi que trois styles linguistiques, allant des commandes explicites aux textes indirects et camouflés.

Une approche de défense en profondeur

Dans notre modèle de menace, l'assistant lui-même réside dans un environnement de confiance, mais tout ce qui provient du web est considéré comme non fiable. Les attaquants peuvent contrôler des sites entiers ou simplement injecter du contenu — comme des descriptions de produits, des commentaires et des publications — dans des pages par ailleurs bénignes que l'assistant visite. Pour gérer ce risque, les outils susceptibles de renvoyer du contenu non fiable, tels que des pages web, des e-mails ou des fichiers, sont signalés et leurs sorties brutes sont systématiquement analysées par BrowseSafe avant que l'agent ne puisse les lire ou agir en conséquence.

BrowseSafe constitue une couche au sein d'une stratégie de défense plus large. Le contenu brut est analysé avant usage, les autorisations des outils sont limitées par défaut, et les actions sensibles peuvent nécessiter une confirmation explicite de l'utilisateur, le tout s'ajoutant aux fonctionnalités de sécurité existantes du navigateur. La défense en profondeur permet aux utilisateurs d'adopter de puissants assistants de navigation sans sacrifier la sécurité pour la performance.

Quels facteurs influencent l'efficacité d'une attaque ?

Les résultats de l'évaluation sur BrowseSafe-Bench révèlent des tendances claires. Les attaques directes, comme demander à l'agent de révéler son prompt système ou d'exfiltrer des informations via des segments d'URL, sont parmi les plus faciles à détecter pour les modèles. En revanche, les attaques multilingues et celles formulées sous forme d'instructions indirectes ou hypothétiques sont nettement plus complexes, car elles évitent les mots-clés évidents sur lesquels de nombreux détecteurs s'appuient implicitement.

L'emplacement joue également un rôle déterminant. Les attaques dissimulées dans les commentaires sont relativement bien détectées, tandis que les versions réécrites dans des pieds de page visibles, des cellules de tableau ou des paragraphes intégrés s'avèrent beaucoup plus difficiles à identifier, révélant un biais structurel en faveur des injections « cachées ». Un entraînement rigoureux sur des exemples bien conçus peut améliorer significativement la capacité des modèles à détecter ces motifs.

Créez des agents plus sûrs avec BrowseSafe

BrowseSafe et BrowseSafe-Bench sont entièrement en open source. Tout développeur créant des agents autonomes peut immédiatement renforcer ses systèmes contre l'injection de prompt, sans avoir à concevoir des garde-fous à partir de zéro. Le modèle de détection aux poids ouverts fonctionne localement et signale les instructions malveillantes avant qu'elles n'atteignent la logique centrale de votre agent, assez rapidement pour analyser chaque page sans ralentir les utilisateurs.

Utilisez les plus de 14 000 scénarios d'attaque réels de BrowseSafe-Bench pour tester la robustesse de vos propres modèles face aux pièges HTML complexes qui fragilisent les LLM standards. Nos techniques de segmentation et d'analyse parallèle permettent aux agents de traiter efficacement des pages massives et non fiables, offrant des capacités de navigation puissantes sans exposer les utilisateurs au danger. Pour en savoir plus sur la conception de BrowseSafe et BrowseSafe-Bench, consultez le blog de recherche Perplexity.