Résumé Technique : Réfléchissez à deux fois avant d'agir

Énoncé du Problème

L'intégration d'outils externes a considérablement élargi les capacités des agents de Grands Modèles de Langage (LLM), mais elle introduit de nouvelles surfaces d'attaque au-delà de l'injection de prompt traditionnelle. Ce document identifie et formalise l'empoisonnement de description inter-outils (cross-tool description poisoning), un vecteur d'attaque sophistiqué où des adversaires manipulent les métadonnées (descriptions) d'outils non critiques ou faiblement régulés pour détourner la trajectoire de planification d'un agent.

Contrairement aux attaques précédentes de « préférence d'outil » qui biaisent un agent pour qu'il sélectionne un outil empoisonné spécifique, l'empoisonnement de description inter-outils permet à un adversaire d'induire des actions malveillantes impliquant d'autres outils — même si l'outil empoisonné lui-même n'est jamais sélectionné. Par exemple, empoisonner la description d'un outil bénin de « Sauvegarde de compte » peut amener le planificateur à insérer une étape d'« Envoi d'e-mail » malveillante (par exemple, envoyer des détails de compte à un attaquant) dans la trajectoire d'une tâche légitime de « Transfert bancaire ». Le défi central est que les descriptions empoisonnées persistent dans le contexte de planification à travers de multiples étapes, permettant une influence continue sur les choix d'outils ultérieurs.

Les défenses existantes, telles que le filtrage statique des outils, le prompt répété ou les contraintes au niveau du système (ex: Drift, Progent), se sont révélées inefficaces contre cette menace spécifique. Ces méthodes ne parviennent soit pas à prendre en compte le contexte de la tâche, soit reposent sur des états internes du modèle (souvent inaccessibles via les API), ou ne peuvent pas distinguer l'utilisation bénigne d'un outil de l'utilisation influencée par des métadonnées empoisonnées.

Méthodologie : Tool-Guard

Pour répondre à ces limites, les auteurs proposent Tool-Guard, un nouveau système de défense basé sur le concept de planification isolée. La philosophie centrale est d'appliquer le principe de sécurité de l'isolation à la planification agentique, en rompant le lien entre les descriptions empoisonnées et la cible de l'influence sans désactiver définitivement les outils.

Mécanisme Central

Tool-Guard fonctionne via une boucle dynamique et itérative impliquant trois étapes principales :

1. Partitionnement Dynamique de l'Ensemble d'Outils :
   Le système maintient une partition dynamique de l'ensemble des outils disponibles $K$ en deux listes disjointes :

   • Liste des Influencés ($K_{inf}$) : Contient les outils suspectés d'être influencés par des descriptions empoisonnées (initialement vide).
   • Liste des Autres ($K_{others}$) : Contient les outils restants.
     Les outils ne sont pas supposés malveillants ; ils sont plutôt déplacés vers $K_{inf}$ si leur invocation semble mal alignée avec l'intention de l'utilisateur ou mal ancrée dans le contexte.

2. Planification Isolée :
   Au lieu d'interroger le planificateur avec l'ensemble complet des outils, Tool-Guard interroge le planificateur deux fois sous une isolation stricte :

   • Une fois avec uniquement les descriptions de $K_{inf}$.
   • Une fois avec uniquement les descriptions de $K_{others}$.
     Cela empêche une description empoisonnée dans un sous-ensemble de détourner la sélection ou la paramétrisation des outils dans l'autre sous-ensemble. Le système sélectionne ensuite une action candidate parmi les deux plans résultants. Si les deux sous-ensembles produisent des actions valides, un arbitre est appliqué ; si aucun des deux ne le fait, la trajectoire se termine.

3. Validation Pré-Exécution et Mise à Jour de la Liste :
   Avant d'exécuter un appel d'outil sélectionné, Tool-Guard effectue deux vérifications sémantiques à l'aide d'un validateur basé sur un LLM :

   • Vérification d'Alignement : Vérifie si l'action est cohérente avec l'intention de l'utilisateur et les progrès validés.
   • Vérification de Suspicion : Vérifie si les arguments sont ancrés dans la requête de l'utilisateur ou les sorties d'outils précédentes, signalant les entités sensibles (ex: adresses de destinataires) qui manquent de provenance claire.

   Si la validation échoue, l'outil est déplacé dans la Liste des Influencés, et le planificateur est déclenché pour une re-planification sous la partition mise à jour. Ce processus itératif isole progressivement les chemins d'influence nocifs tout en préservant l'utilité des outils légitimes.

Extension à MCP

La méthodologie s'étend au protocole MCP (Model Context Protocol) en appliquant la même logique d'isolation au niveau du serveur, partitionnant les serveurs en groupes influencés et non influencés pour prévenir l'empoisonnement inter-serveur.

Contributions Clés

1. Caractérisation de l'Empoisonnement de Description Inter-Outils : Le papier démontre que des adversaires peuvent injecter des étapes malveillantes dans des invocations d'outils critiques pour la sécurité en empoisonnant les descriptions d'outils non critiques, même lorsque l'outil empoisonné n'est jamais appelé. Il montre que les défenses existantes présentent des taux de succès d'attaque (ASR) élevés contre cette influence continue.
2. Défense Tool-Guard : Les auteurs proposent une défense qui partitionne dynamiquement l'ensemble des outils et emploie une planification isolée. En validant les actions avant l'exécution et en isolant les outils suspects, elle coupe les chemins de détournement inter-outils malveillants tout en maintenant la pleine disponibilité des outils.
3. Évaluation Complète : Des expériences approfondies sur les benchmarks AgentDojo et ASB (Agent Security Bench) démontrent que Tool-Guard réduit l'ASR à des niveaux négligeables tout en préservant une haute utilité des tâches. Le papier quantifie également l'efficacité et la robustesse contre les variantes d'attaques adaptatives.

Résultats Expérimentaux

Les auteurs ont évalué Tool-Guard contre cinq mécanismes de défense existants (System Prompt, Tool Filtering, Repeat Prompt, Drift, Progent) à travers plusieurs LLM (GPT-4o, GPT-4o-mini, Gemini-2.5, Claude-3.5) sur deux benchmarks.

• Taux de Succès d'Attaque (ASR) : Tool-Guard a réduit l'ASR à des niveaux négligeables (ex: de ~43% à ~2% ou 0% sur AgentDojo, et de ~72-96% à 0% sur ASB pour la plupart des modèles). En revanche, les défenses existantes ont souvent échoué à réduire l'ASR de manière significative (ex: Drift et Progent ont montré des ASR de 24,7% et 19,6% respectivement sur AgentDojo).
• Préservation de l'Utilité : Tool-Guard a maintenu une utilité de tâche élevée tant en conditions bénignes que sous attaque. Contra% qu'aux défenses de type « overkill » qui bloquent les outils de manière indiscriminée, Tool-Guard a préservé la capacité de compléter les tâches, avec des scores d'utilité comparables ou supérieurs aux bases de référence sous attaque.
• Efficacité :
  • Surcoût en Tokens : Tool-Guard a entraîné une augmentation d'environ 1,5× de l'utilisation des tokens par rapport à la base de référence sans défense, ce qui est nettement inférieur aux autres défenses de niveau système comme Drift ou Progent.
  • Latence : La méthode a introduit un surcoût de temps d'exécution d'environ 3,7× par rapport à la base de référence (plus élevé que le 1,2× de Progent mais plus bas que le 7,3× de Drift), attribué au mécanisme de re-planification.
• Robustesse :
  • Stabilité : La défense est restée stable sur plusieurs exécutions avec de faibles écarts types.
  • Attaques Adaptatives : Tool-Guard est resté robuste contre les attaques sémantiques-adaptatives (qui tentent d'échapper aux vérifications via des justifications fabriquées) et les attaques basées sur l'optimisation (PAIR, TAP). Bien que les attaques basées sur l'optimisation aient légèrement augmenté l'ASR, celui-ci est resté très bas (ex: 2,06% sous PAIR), soulignant le compromis inhérent auquel font face les attaquants entre être assez explicite pour influencer la planification et assez subtil pour échapper à la validation.
  • Tests de Stress : Même lorsque des outils critiques et à haute fréquence étaient empoisonnés, Tool-Guard a maintenu l'ASR à un niveau de chiffre unique bas.

Signification et Revendications

Le papier affirme que les descriptions d'outils représentent une surface d'attaque critique et auparavant sous-explorée pour les agents LLM. La signification de ce travail réside dans :

1. Identification d'un Nouveau Vecteur de Menace : Formaliser l'empoisonnement de description inter-outils, qui contourne les défenses traditionnelles en exploitant la nature persistante des métadonnées des outils dans le contexte de planification.
2. Démonstration des Limites des Défenses : Montrer que les défenses de pointe actuelles sont insuffisantes contre l'influence continue inter-outils.
3. Proposition d'une Solution de Niveau Système : Introduire Tool-Guard, qui atténue efficacement ces attaques en isolant l'influence plutôt qu'en comptant uniquement sur des garde-fous au moment de l'exécution ou sur un balayage statique.
4. Équilibre entre Sécurité et Utilité : Prouver qu'une défense efficace ne nécessite pas de sacrifier l'utilité de l'agent ; Tool-Guard atteint une sécurité robuste avec un surcoût de tokens minimal et sans comportement de type « overkill ».

Les auteurs concluent que les défenses efficaces pour les agents dotés d'outils doivent explicitement traiter l'influence inter-outils via des mécanismes tels que la planification isolée, plutôt que de compter uniquement sur les défenses contre l'injection de prompt ou le filtrage statique des outils.