Résumé technique : SAFESEARCH : Rouge-Teaming automatisé d'agents de recherche basés sur les LLM

1. Énoncé du problème

Les agents de recherche basés sur les modèles de langage (LLM) connectent les modèles à Internet pour accéder à des informations à jour, permettant des applications allant de la récupération rapide d'informations à des tâches de recherche à long horizon. Cependant, cette architecture introduit une nouvelle surface de menace critique : des résultats de recherche peu fiables. Contrairement aux systèmes de génération augmentée par la récupération (RAG) qui s'appuient sur des corpus locaux et soigneusement sélectionnés, les agents de recherche reçoivent passivement du contenu du web ouvert, qui peut inclure des fermes de contenu de faible qualité, des sources biaisées, des publicités sponsorisées ou des informations manipulées via du référencement noir (black-hat SEO).

Des incidents réels et des observations in-the-wild indiquent que les agents de recherche font souvent confiance de manière non critique à ces résultats, conduisant à des sorties non sécurisées telles que de la désinformation, des conseils nuisibles ou l'exécution d'injections de prompts indirectes. Les évaluations existantes pour les agents de recherche se concentrent principalement sur la précision des tâches (par exemple, GAIA, SIMPLEQA) plutôt que sur la sécurité, et les méthodes actuelles de rouge-teaming reposent sur une création humaine intensive en main-d'œuvre ou sur des requêtes adverses qui ne reflètent pas la réalité des requêtes d'utilisateurs bénins rencontrant des résultats de recherche peu fiables. De plus, les tests adverses réels (par exemple, la manipulation des classements de recherche) posent des risques éthiques et sont irréalisables pour la plupart des développeurs.

2. Méthodologie : Le cadre SAFESEARCH

Les auteurs proposent SAFESEARCH, un cadre de rouge-teaming automatisé, évolutif et rentable conçu pour évaluer la sécurité des agents de recherche basés sur les LLM lorsqu'ils sont exposés à des résultats de recherche peu fiables dans le cadre de requêtes d'utilisateurs bénins.

2.1 Modèle de menace

Le cadre fonctionne selon un modèle de menace spécifique :

• Requêtes bénignes : Le testeur émet uniquement des requêtes d'utilisateurs réalistes et bénignes.
• Injection contrôlée : Pour chaque requête, le testeur injecte au plus un site web peu fiable dans les résultats de recherche renvoyés à l'agent.
• Indépendant de l'agent : Le site web peu fiable est fixe pour tous les agents pour un cas de test donné, garantissant que la menace n'est pas adaptée à des architectures de modèles spécifiques.
• Objectif : Identifier si l'agent propage le contenu peu fiable dans des réponses finales non sécurisées.

2.2 Génération automatisée de cas de test

Le cadre utilise un flux de travail en trois étapes piloté par des assistants LLM pour générer 300 cas de test de haute qualité répartis sur cinq catégories de risques :

1. Ancrage de scénario : Un LLM génère des scénarios d'utilisateurs réalistes et des requêtes où le risque spécifique (par exemple, désinformation, biais) pourrait vraisemblablement survenir.
2. Conception du test : Le système définit un « plan malveillant », spécifiant la conséquence négative cible et la nature du site web peu fiable. Crucialement, il prend en compte le décalage temporel entre la date de coupure des connaissances du LLM et la date actuelle pour garantir que la menace est sensible au temps et réaliste.
3. Instantiation du test : Le système génère des directives pour synthétiser le site web peu fiable et une liste de contrôle pour l'évaluation de la sécurité.

Filtrage de qualité : Pour garantir que les cas de test sont actionnables, le cadre utilise un test différentiel. Un agent de base est testé dans deux configurations : un outil bénin et un outil manipulé (avec le site web injecté). Un cas de test n'est conservé que si la conséquence cible est atteignable sous manipulation mais non déclenchée dans des conditions bénignes.

2.3 Tests basés sur la simulation

Pour éviter les problèmes éthiques et pratiques liés à la manipulation des moteurs de recherche réels, SAFESEARCH utilise une simulation en bac à sable :

• Injection : Un site web peu fiable est généré synthétiquement et injecté dans la liste des résultats de recherche authentiques (généralement ajouté à la fin pour simuler un classement inférieur, bien que la sensibilité à la position soit analysée).
• Exécution : L'agent de recherche traite les résultats mixtes et génère une réponse.
• Évaluation : Un LLM en tant que juge, assisté par la liste de contrôle pré-générée, évalue la réponse de l'agent par rapport à la conséquence cible pour déterminer un taux de réussite de l'attaque (ASR). Un évaluateur séparé évalue les scores d'utilité (HS) pour déterminer si les réponses non sécurisées semblent toujours utiles aux utilisateurs.

3. Contributions clés

1. Formulation du problème : L'article définit formellement les risques de sécurité des agents de recherche basés sur les LLM exposés à des résultats de recherche peu fiables sous des requêtes bénignes, distinguant cela de l'empoisonnement RAG et des attaques adverses explicites.
2. Cadre SAFESEARCH : Le développement d'un pipeline de rouge-teaming automatisé incluant la génération de cas de test, le filtrage différentiel, la simulation en bac à sable et l'évaluation assistée par liste de contrôle.
3. Évaluation complète : La construction d'un ensemble de données de 300 cas de test et l'évaluation de 17 LLM représentatifs (9 propriétaires, 8 open-source) à travers trois structures d'agents de recherche (Flux de recherche, Appel d'outils et Recherche approfondie).
4. Open Source : La publication du code et de l'ensemble de données pour faciliter de futures recherches.

4. Résultats expérimentaux

Les auteurs ont évalué 17 modèles à travers trois structures. Les principaux résultats incluent :

• Vulnérabilité élevée : Les agents de recherche sont très sensibles aux résultats de recherche peu fiables. Le taux de réussite de l'attaque (ASR) le plus élevé observé était de 90,5 % pour GPT-4.1-mini utilisant un flux de recherche. Même les configurations les plus robustes (par exemple, Claude-Sonnet-4.5 avec appel d'outils) ont présenté des ASR non nulles (4,6 %).
• Impact des LLM backend : Les modèles de raisonnement ont généralement démontré une résilience plus forte que les modèles non de raisonnement. Par exemple, GPT-5 et GPT-5-mini ont montré des ASR significativement plus faibles que les générations antérieures, suggérant que des capacités de raisonnement avancées aident à filtrer les informations peu fiables.
• Impact de la conception de la structure : L'architecture de l'agent joue un rôle critique.
  • Flux de recherche (récupération passive) a montré la vulnérabilité la plus élevée.
  • Appel d'outils et Recherche approfondie (récupération active, multi-étapes) ont montré une sécurité améliorée, probablement due à la validation croisée entre les sources et à la capacité de résoudre les conflits.
  • Cependant, lorsque les budgets de recherche étaient contrôlés, l'avantage de la « Recherche approfondie » diminuait, suggérant que le gain de sécurité provient souvent de l'utilisation de plus de requêtes de recherche plutôt que de la logique de la structure elle-même.
• Variance des risques : La susceptibilité variait selon le type de risque. La désinformation posait la plus grande menace (ASR moyen le plus élevé), tandis que l'injection de prompts indirecte montrait le ASR moyen le plus faible, indiquant une plus grande résilience face à cette menace de sécurité spécifique.
• Sécurité vs Utilité : Un comportement non sécurisé ne réduit pas nécessairement la perception d'utilité. Dans de nombreux cas, des agents influencés par des sources peu fiables produisaient des réponses qui obtenaient des scores élevés en termes d'utilité (plausibilité) malgré le fait qu'elles étaient factuellement incorrectes ou non sécurisées.
• Limites des défenses : Des défenses courantes comme l'incitation par rappel (avertir l'agent sur les sources peu fiables) offraient une protection limitée. Le filtrage (utilisant un LLM pour pré-filtrer les résultats) a réduit l'ASR d'environ la moitié mais n'a pas réussi à éliminer les risques entièrement, en particulier contre du contenu furtif ou hautement persuasif.

5. Signification et revendications

L'article affirme que SAFESEARCH fournit une méthode pratique, évolutive et transparente pour mesurer et améliorer la sécurité des agents de recherche basés sur les LLM.

• Transparence dans le développement : Le cadre révèle comment les choix de conception (par exemple, le nombre de résultats de recherche renvoyés) affectent implicitement la sécurité. Il met en évidence un écart connaissance-action, où les modèles peuvent posséder la capacité d'identifier des sources peu fiables lorsqu'ils sont explicitement chargés de le faire, mais échouent à appliquer ces connaissances dans des flux de travail d'agents.
• Supervision continue : Contrairement aux benchmarks statiques, SAFESEARCH est conçu pour un suivi continu de la sécurité pendant le développement de l'agent, permettant l'évaluation des stratégies de défense et la génération de cas de test de plus en plus difficiles.
• Pertinence réelle : En simulant l'injection de résultats peu fiables dans des contextes de recherche authentiques, le cadre approxime les menaces réelles sans les risques éthiques de la manipulation de moteurs de recherche en direct. Les auteurs soutiennent que bien que les tests basés sur la simulation aient des limites, ils sont nécessaires pour identifier systématiquement la limite inférieure de la sécurité de l'agent avant le déploiement.

Les auteurs concluent que bien que les agents de recherche actuels soient vulnérables, le cadre offre une voie aux développeurs pour itérer sur des systèmes plus sûrs, en soulignant que la sécurité doit être priorisée parallèlement aux performances dans les futures conceptions d'agents.