💬 NLP

ToolFlood: Beyond Selection -- Hiding Valid Tools from LLM Agents via Semantic Covering

Le papier présente ToolFlood, une attaque par saturation de la couche de récupération qui utilise des outils malveillants générés de manière à couvrir sémantiquement les requêtes utilisateurs pour les évincer des résultats top-k et ainsi désactiver les agents LLM.

Auteurs originaux : Hussein Jawad, Nicolas J-B Brunel

Publié 2026-03-17

📖 5 min de lecture🧠 Analyse approfondie

CC BY 4.0

Auteurs originaux : Hussein Jawad, Nicolas J-B Brunel

Article original sous licence CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Ceci est une explication générée par l'IA de l'article ci-dessous. Elle n'a pas été rédigée ni approuvée par les auteurs. Pour une précision technique, consultez l'article original. Lire la clause de non-responsabilité complète

Imaginez que vous avez un assistant personnel très intelligent (un "agent IA") capable de faire des choses complexes pour vous, comme réserver un voyage, analyser des actions boursières ou réparer un code informatique. Pour cela, cet assistant ne fait pas tout seul : il a accès à une immense boîte à outils remplie de milliers d'outils différents (des applications, des bases de données, des moteurs de recherche).

Le problème ? Votre assistant ne peut pas regarder tous les outils en même temps. Il doit donc choisir les 5 meilleurs outils (disons) qui correspondent à votre demande. Pour cela, il utilise un système de recherche très rapide basé sur le "sens" des mots (c'est ce qu'on appelle la recherche par embeddings).

Le Problème : La "Flood" (Inondation) d'Outils

C'est ici que l'article "ToolFlood" entre en jeu. Les chercheurs ont découvert une faille dangereuse dans la façon dont cet assistant choisit ses outils.

Imaginez que votre assistant va dans une grande bibliothèque pour trouver un livre sur "la cuisine italienne". Normalement, il devrait trouver des livres de chefs célèbres.
Mais, imaginez qu'un malin (un attaquant) arrive dans cette bibliothèque avec 100 faux livres. Ces faux livres ne sont pas de la vraie cuisine italienne, mais ils ont des titres et des résumés écrits de manière à ressembler parfaitement à ce que l'assistant cherche.

L'attaquant remplit les étagères avec ces faux livres. Résultat ? Quand l'assistant demande "cuisine italienne", la bibliothèque lui sort uniquement les faux livres de l'attaquant. Les vrais livres de cuisine sont invisibles, cachés derrière la montagne de faux livres.

C'est exactement ce que fait ToolFlood :

L'Inondation : L'attaquant crée une "essaim" (un swarm) de faux outils.
Le Camouflage : Il utilise une intelligence artificielle pour écrire les descriptions de ces faux outils de manière à ce qu'ils correspondent à n'importe quelle question que l'utilisateur pourrait poser.
Le Blocage : Ces faux outils "inondent" la liste des 5 meilleurs résultats. L'assistant ne voit plus les vrais outils. Il est forcé d'utiliser les outils de l'attaquant, qui peuvent être malveillants, voler des données ou simplement faire n'importe quoi.

Comment ça marche ? (L'Analogie du Filet de Pêche)

Pour comprendre la technique, imaginez que vous essayez de couvrir un lac avec des filets de pêche pour attraper tous les poissons (les questions des utilisateurs).

L'ancienne méthode (les attaques précédentes) : Les pirates essayaient de peindre un seul de leurs filets en couleur "poisson" pour qu'il soit choisi à la place d'un filet normal. Mais si le filet normal est toujours là, le pirate doit être très habile pour gagner.
La méthode ToolFlood : Au lieu de peindre un filet, le pirate lance des milliers de petits filets partout sur le lac. Ces filets sont disposés de manière à couvrir toutes les zones du lac.
- Si vous demandez "Comment cuisiner un poisson ?", le filet de l'attaquant est là.
- Si vous demandez "Comment pêcher un poisson ?", le filet de l'attaquant est là.
- Si vous demandez "Comment manger un poisson ?", le filet de l'attaquant est là.

L'attaquant utilise une stratégie en deux étapes :

Génération : Il demande à une IA de créer des milliers de descriptions d'outils qui ressemblent à des questions variées.
Sélection intelligente : Il utilise un algorithme pour choisir les quelques centaines de faux outils les plus efficaces pour "couvrir" le maximum de questions possibles, comme un filet qui s'adapte parfaitement à la forme du lac.

Pourquoi est-ce grave ?

C'est une faille de sécurité très subtile.

Les gardes du corps sont impuissants : Habituellement, on protège l'assistant en vérifiant les outils après qu'il les a choisis (par exemple, en disant "Non, cet outil semble dangereux").
Le problème de ToolFlood : Ici, les vrais outils ne sont jamais choisis. Ils ne sont même pas vus. L'assistant pense qu'il a fait un bon choix en sélectionnant les outils de l'attaquant, car ce sont les seuls qui apparaissent dans sa liste. C'est comme si on vous donnait une carte de Paris, mais que toutes les rues menaient à un piège, et que les vraies rues avaient été effacées de la carte.

Les Résultats

Les chercheurs ont testé cette attaque sur de vraies bases de données d'outils (comme ToolBench qui contient plus de 11 000 outils).

Avec seulement 1% d'outils falsifiés (une toute petite quantité), ils ont réussi à contrôler 95% des choix de l'assistant.
Même si l'assistant utilise un système de sécurité pour trier les résultats, l'attaque fonctionne toujours car elle ne se base pas sur des mots-clés interdits, mais sur une "inondation" sémantique.

En Résumé

ToolFlood est une attaque qui ne vole pas l'outil, mais qui vole la visibilité des outils. En inondant le système de faux outils parfaitement déguisés, l'attaquant rend l'assistant aveugle aux vrais outils et le force à utiliser ses propres outils malveillants.

C'est une leçon importante pour l'avenir : protéger un agent IA ne suffit pas de vérifier ce qu'il fait, il faut aussi s'assurer que la "bibliothèque" d'où il puise ses outils n'est pas envahie par des faux.

1. Problématique : La vulnérabilité de la couche de récupération (Retrieval Layer)

Les agents basés sur les Grands Modèles de Langage (LLM) utilisent de plus en plus des outils externes (APIs, bases de données) pour accomplir des tâches complexes. Pour gérer la grande quantité d'outils disponibles, ces systèmes reposent sur une étape de récupération (retrieval) : le modèle d'embedding transforme la requête utilisateur et les métadonnées des outils en vecteurs, puis sélectionne les $k$ outils les plus pertinents (top- $k$ ) pour les présenter au LLM.

Le problème identifié :
La littérature précédente se concentre principalement sur les attaques au niveau de la sélection (une fois que l'outil est visible, l'attaquant tente de le faire choisir). Cependant, l'article met en lumière une faille critique au niveau de la récupération elle-même.
L'attaque proposée, ToolFlood, ne cherche pas à "gagner" la sélection parmi les outils visibles, mais à dominer la liste top- $k$ en y injectant un grand nombre d'outils malveillants qui remplacent complètement les outils bénins. Cela constitue une attaque par déni de visibilité (Denial-of-Visibility) : les outils légitimes ne sont jamais récupérés, et l'agent est forcé de raisonner uniquement sur un univers d'outils contrôlé par l'attaquant.

2. Méthodologie : ToolFlood et le "Semantic Covering"

ToolFlood est une attaque de type Sybil (injection de multiples identités) qui exploite la géométrie de l'espace des embeddings. Elle fonctionne en deux phases :

Phase 1 : Génération de candidats par Monte Carlo

L'objectif est de créer un pool diversifié de métadonnées d'outils (noms, descriptions) capables de couvrir sémantiquement l'espace des requêtes cibles.

Échantillonnage : L'attaquant sélectionne aléatoirement des sous-ensembles de requêtes cibles ( $S_i$ ).
Génération conditionnelle : Un LLM (contrôlé par l'attaquant) génère des descriptions d'outils ( $G_i$ ) spécifiquement conçues pour être pertinentes pour toutes les requêtes d'un sous-ensemble donné, et non pour une seule. Cela crée des outils "généralistes" dans l'espace d'embedding, capables de couvrir plusieurs requêtes voisines.

Phase 2 : Sélection par Recouvrement Sémantique Itératif (Greedy Multi-Cover)

Une fois le pool de candidats généré, l'attaquant doit sélectionner un sous-ensemble optimal à injecter, sous contrainte d'un budget $B$ (nombre d'outils injectés).

Formulation : Le problème est modélisé comme un problème de recouvrement maximal sous budget (Budgeted Maximum Coverage), qui est NP-difficile.
Algorithme : Une approche gloutonne (greedy) est utilisée. À chaque itération, l'algorithme choisit l'outil dont l'ajout maximise le nombre de requêtes restantes qui sont "couvertes" (c'est-à-dire dont la distance cosinus avec l'outil est inférieure à un seuil $\delta$ ).
Objectif de saturation : L'attaque vise à ce que pour chaque requête $q$ , il existe au moins $r=k$ outils malveillants dans le top- $k$ . Si $k$ outils malveillants sont présents, aucun outil bénin ne peut être récupéré.

3. Contributions Clés

Nouveau modèle de menace (Top-k Domination) : L'article définit formellement l'attaque par domination du top- $k$ , où l'objectif n'est pas de compétitionner pour la sélection, mais d'exclure totalement les outils légitimes de la liste de candidats.
ToolFlood : Une méthode pratique combinant la génération assistée par LLM et l'optimisation gloutonne pour saturer l'espace de récupération via un essaim d'outils Sybil.
Analyse théorique : Une preuve de convergence montrant que, avec un nombre suffisant d'itérations de génération (Phase 1), il est possible de couvrir l'ensemble des requêtes cibles avec une probabilité élevée, garantissant la disponibilité de "munitions" pour la phase de sélection.
Évaluation empirique : Démonstration que cette attaque fonctionne avec un taux d'injection très faible (environ 1% du catalogue total) tout en atteignant des taux de réussite élevés.

4. Résultats Expérimentaux

Les auteurs ont évalué ToolFlood sur deux benchmarks populaires : MetaTool (199 outils) et ToolBench (11 760 outils).

Taux de Domination du Top-k (TDR) : ToolFlood atteint jusqu'à 97,2 % sur MetaTool et 91 % sur ToolBench. Cela signifie que pour la grande majorité des requêtes, les $k$ outils récupérés sont exclusivement des outils malveillants.
Taux de Succès de l'Attaque (ASR) : Une fois les outils bénins exclus, l'agent sélectionne un outil malveillant dans 95 % à 99 % des cas (selon le LLM de sélection utilisé, comme GPT-4o ou GPT-5-mini).
Efficacité du Budget : L'attaque est très efficace avec un faible ratio d'empoisonnement (Poisoning Rate). Par exemple, sur ToolBench, seulement 1,2 % d'outils injectés suffisent pour atteindre un TDR de 91 %.
Robustesse et Transférabilité : L'attaque fonctionne même lorsque le modèle d'embedding utilisé par l'attaquant (shadow model) est différent de celui utilisé par la cible (mismatch), démontrant une bonne transférabilité.
Échec des défenses existantes :
- Les défenses de type "Prompt Guard" (détection d'injection) sont inefficaces car les outils malveillants utilisent des descriptions sémantiquement valides et non des injections de commandes explicites.
- Le réclassement par MMR (Maximal Marginal Relevance) réduit le taux de domination (de 91% à 44%), mais le taux de succès final (ASR) reste très élevé (~91%), car une domination partielle suffit souvent à orienter l'agent vers un outil malveillant.

5. Signification et Implications

Changement de paradigme de sécurité : La sécurité des agents LLM ne doit plus se limiter à la phase de sélection ou de filtrage des prompts. La couche de récupération est un point de défaillance critique qui, une fois compromise, rend les défenses en aval (au niveau du LLM) inutiles, car les outils légitimes n'ont jamais été vus par le modèle.
Vulnérabilité des écosystèmes ouverts : Les marketplaces d'outils ouvertes (comme le GPT Store) sont particulièrement vulnérables à ce type d'attaque Sybil, où un attaquant peut inonder le système de faux outils.
Nécessité de nouvelles défenses : L'article suggère que les futures défenses doivent se concentrer sur la détection de motifs de "flood" (inondation), la gestion de la redondance sémantique, et le renforcement de la provenance des outils, plutôt que sur le simple filtrage de contenu.

En résumé, ToolFlood démontre qu'il est possible de "censurer" les outils légitimes d'un agent LLM en saturant mécaniquement l'espace de recherche vectoriel, compromettant ainsi l'intégrité et la disponibilité du système à un niveau fondamental.