Détournement de sélection d'outil : forcer l'agent à choisir l'outil de l'attaquant

De quoi s’agit-il ?

Le détournement de sélection d’outil vise l’étape où un agent LLM décide quel outil appeler, avant même de décider comment l’appeler. La plupart des travaux de sécurité des agents ciblent le contenu renvoyé par un outil, ou des instructions cachées dans la description d’un outil. Cette attaque vise la décision de routage elle-même : l’adversaire place un outil forgé dans le catalogue de l’agent de sorte que, pour une tâche choisie, l’agent prenne systématiquement l’outil de l’attaquant plutôt que l’outil légitime. Deux publications récentes la formalisent. ToolHijacker (NDSS 2026, préprint arXiv avril 2025) attaque le pipeline récupération-puis-sélection, et Function Hijacking Attacks (IBM Research Europe, Imperial, Trinity College Dublin, arXiv:2604.20994, 22 avril 2026) attaque directement la décision d’appel de fonction.

Comment ça marche

Les agents modernes choisissent un outil en deux temps. Un récupérateur réduit une vaste bibliothèque d’outils à une liste restreinte top-k par similarité sémantique, puis le LLM lit ces descriptions candidates et en sélectionne une. Les deux étapes sont manipulables.

ToolHijacker injecte un unique document d’outil malveillant dans la bibliothèque. Son nom et sa description sont optimisés pour remporter la récupération et la sélection sur une tâche cible — y compris en configuration « no-box », où l’attaquant ne voit ni les vraies descriptions, ni le récupérateur, ni le modèle, ni la valeur de top-k. Les auteurs y parviennent en construisant une copie fantôme du pipeline et en scindant la description en deux sous-séquences optimisées, l’une pour gagner la récupération, l’autre la sélection.

Function Hijacking emprunte une voie complémentaire : elle ajoute des tokens adverses aux métadonnées d’une fonction pour qu’un modèle d’appel de fonctions émette l’appel choisi par l’attaquant. La technique adapte la méthode de suffixe adverse GCG à la tâche d’appel de fonctions. Notamment, le papier indique qu’elle est « largement agnostique à la sémantique du contexte » et peut être entraînée en une fonction malveillante universelle qui détourne la sélection sur de nombreuses requêtes.

Les chaînes optimisées exactes ne sont pas reproduites ici ; ce sont des artefacts de recherche, pas des charges prêtes à l’emploi.

Pourquoi c’est important

Choisir le mauvais outil n’est pas une erreur cosmétique : c’est une redirection du flux de contrôle. Si l’agent route une intention « envoyer un paiement », « lire un fichier » ou « interroger une base » vers un outil contrôlé par l’attaquant, ce dernier prend pied dans l’espace d’action de l’agent sans jamais toucher à l’invite de l’utilisateur. L’efficacité mesurée est élevée : ToolHijacker rapporte un taux de réussite de 96,7 % avec Llama-3.3-70B comme modèle fantôme et GPT-4o comme cible sur le benchmark MetaTool, plus un taux de réussite de récupération de 100 %. Function Hijacking rapporte 70 à 100 % de réussite sur cinq modèles, en variantes « instructed » et « reasoning », sur le Berkeley Function Calling Leaderboard.

L’exposition croît avec les écosystèmes d’outils ouverts. Partout où des agents tirent leurs outils ou serveurs MCP d’un registre partagé, d’une place de marché ou d’un catalogue multi-tenant, une seule entrée plantée peut biaiser le routage pour chaque utilisateur qui déclenche la tâche cible.

Défenses

Aucune défense publiée n’arrête entièrement ces attaques à ce jour ; la défense est donc en couches, pas unique.

Les défenses côté entrée testées sont insuffisantes. Les auteurs de ToolHijacker ont évalué des méthodes de prévention (StruQ, SecAlign) et de détection (known-answer detection, DataSentinel, perplexité et perplexité fenêtrée) ; l’attaque sans gradient atteignait encore 99,6 % de réussite sous StruQ, et la détection par perplexité manquait 90 % des documents malveillants à base de gradient tout en gardant moins de 1 % de faux positifs. Traitez-les comme une friction, pas comme un correctif.

Les mesures pratiques portent sur le catalogue et la décision de routage. Curez et figez la bibliothèque d’outils : autorisez les outils par identité signée et provenance plutôt que par résolution libre depuis des registres ouverts. Restreignez la récupération aux entrées validées et évitez l’auto-installation de serveurs MCP tiers. Ajoutez un contrôle d’intégrité de sélection — journalisez quel outil a été choisi pour quelle intention, alertez quand un outil nouveau ou de faible réputation capte une tâche sensible, et exigez une confirmation humaine avant tout appel d’outil à fort impact (paiements, écritures de fichiers, réseau externe). Appliquez le moindre privilège pour qu’une sélection détournée n’atteigne jamais une capacité dangereuse. Enfin, surveillez tout basculement soudain de l’outil servant une tâche récurrente, signal direct d’une altération du catalogue.

Statut

Élément	Détail
ToolHijacker	NDSS 2026 ; arXiv:2504.19793 ; vise récupération + sélection ; no-box
Function Hijacking (FHA)	arXiv:2604.20994, 22 avr. 2026 ; type GCG, variante universelle
Impact mesuré	ToolHijacker 96,7 % ASR (cible GPT-4o) ; FHA 70–100 % ASR (BFCL)
Défenses testées	StruQ, SecAlign, DataSentinel, perplexité — insuffisantes
État du correctif	Problème ouvert ; atténuer par provenance, moindre privilège, audit de sélection