STAC : enchaîner des appels d'outils anodins pour détourner un agent IA

De quoi s’agit-il ?

Le Sequential Tool Attack Chaining (STAC) est une classe d’attaque multi-tour contre les agents LLM outillés, présentée dans un article publié sur arXiv en septembre 2025 puis révisé en février 2026 (arXiv:2509.25624). L’idée est simple à énoncer et difficile à contrer : au lieu d’une requête ouvertement malveillante, l’attaquant conduit l’agent à travers une chaîne d’appels d’outils qui, pris isolément, paraissent tous inoffensifs, mais qui, réunis, réalisent un objectif nuisible. L’intention malveillante n’apparaît qu’à la dernière étape.

L’exemple emblématique de l’article est une destruction de données assemblée à partir de tâches de maintenance courantes : on fait exécuter à l’agent une sauvegarde de fichiers, puis la suppression de fichiers « en double », puis un « nettoyage d’archives » — une séquence dont chaque action est raisonnable isolément, mais dont l’effet net est d’effacer des données critiques. Comme aucun tour ne déclenche à lui seul un contrôle de sécurité, les garde-fous classiques au niveau du contenu n’ont rien à refuser.

Comment ça marche

STAC diffère d’un jailbreak classique par sa cible. Un jailbreak habituel cherche à faire dire au modèle quelque chose d’interdit ; STAC cherche à lui faire faire quelque chose d’interdit via ses outils, produisant de vrais changements dans un environnement externe — un système de fichiers, une API bancaire, un espace de travail — qui peuvent être irréversibles. Ce passage du texte généré à l’action exécutée fait de STAC un problème propre à la sécurité des agents, et non un problème de chatbot.

Les chercheurs ont bâti un pipeline automatisé pour générer ces attaques à grande échelle, et comprendre ses quatre rôles suffit à saisir pourquoi la technique est furtive, sans le moindre code d’attaque opérationnel :

D’abord, un générateur planifie une chaîne de deux à six appels d’outils cibles qui atteignent cumulativement un but malveillant, en s’arrangeant pour que toutes les étapes sauf la dernière soient anodines isolément. Ensuite, un vérificateur exécute réellement chaque appel planifié dans l’environnement cible et corrige tout appel qui échoue, garantissant que la chaîne est effectivement exécutable. Puis un rédacteur de prompts compose une conversation multi-tour synthétique, d’apparence inoffensive, qui amènerait plausiblement un agent à ces appels intermédiaires — construisant le contexte sans toucher encore à un agent réel. Enfin, un planificateur reprend cet historique synthétique et pilote interactivement un agent réel jusqu’à l’action finale, en s’adaptant en temps réel à ses réponses.

# Forme illustrative uniquement — aucun payload opérationnel
Tour 1  -> appel d'outil de préparation anodin   (semble routinier)
Tour 2  -> appel d'outil de mise en contexte      (semble routinier)
...
Tour T  -> appel d'outil final                    (le préjudice n'apparaît qu'ici)

La structure distribuée est tout l’enjeu : l’objectif malveillant est réparti sur les tours de sorte qu’il ne peut être reconnu qu’en raisonnant sur la séquence entière. L’article s’abstient volontairement de fournir un exploit clé en main et documente à la place le schéma d’attaque et un jeu d’évaluation pour l’étudier.

Pourquoi c’est important

C’est l’évaluation qui rend STAC digne d’attention. Sur 483 cas générés, couvrant 1 352 jeux d’interactions utilisateur-agent-environnement — construits sur les environnements SHADE-Arena (banque, voyage, espace de travail, gestion d’un filtre anti-spam, qui étendent AgentDojo) plus plusieurs dizaines échantillonnés dans Agent-SafetyBench, et organisés autour de dix modes de défaillance propres aux agents — les taux de réussite dépassaient 90 % pour la plupart des agents testés, y compris un modèle de pointe très performant. La réussite augmentait au fil des tours, et la vulnérabilité se maintenait à travers les familles et les tailles de modèles, sans être liée à une architecture particulière.

Si cela se généralise, c’est pour une raison structurelle. Les agents actuels exécutent les outils étape par étape et jugent chaque requête plus ou moins isolément ; ils raisonnent rarement de façon globale sur l’effet cumulé d’une séquence d’actions complète. Un modèle qui refuse fidèlement une instruction dangereuse isolée peut tout de même être conduit à la même destination une étape anodine à la fois. L’article montre aussi qu’une méthode de jailbreak multi-tour conçue pour les chatbots se transfère mal à ce contexte — ce qui corrobore d’autres travaux soutenant que la sécurité au niveau du texte ne devient pas automatiquement une sécurité au niveau des appels d’outils (arXiv:2602.16943). Défendre les mots que le modèle émet n’équivaut pas à défendre les actions qu’il entreprend.

Défenses

• Raisonner sur toute la trajectoire, pas sur le dernier tour. La meilleure atténuation de l’article est un prompt de défense qui amène l’agent à peser les préjudices et les bénéfices d’une action au regard de l’interaction entière avant de l’exécuter. Un prompt complémentaire fait résumer à l’agent l’intention cumulée de l’utilisateur sur tous les tours. Ces approches ont réduit la réussite des attaques de jusqu’à 28,8 % — non négligeable, mais loin d’une solution complète, la réussite restant supérieure ou égale à 58,6 %.
• Ne comptez pas sur les défenses anti-injection pour cela. Des techniques comme le spotlighting ou le datamarking, conçues pour séparer instructions et données, offrent ici une protection limitée, car STAC n’utilise aucune instruction injectée : chaque requête est un tour utilisateur légitime. Traitez l’intention au niveau de la séquence comme un contrôle distinct du filtrage d’injection.
• Encadrez les appels d’outils irréversibles et à fort impact. Exigez une confirmation, un double contrôle ou un délai de réflexion pour les actions qui suppriment des données, déplacent de l’argent, modifient des permissions ou envoient des messages vers l’extérieur. C’est à l’étape finale que le préjudice se cristallise, et donc là qu’un contrôle humain rapporte le plus.
• Restreignez les combinaisons d’outils dangereuses. Cartographiez les outils qui, utilisés ensemble, peuvent produire des effets irréversibles, et appliquez le moindre privilège pour qu’une même session d’agent ne puisse pas, par exemple, à la fois énumérer et supprimer en masse, ou lire des secrets et les exfiltrer.
• Surveillez au niveau de la séquence. Une télémétrie comportementale qui reconstitue l’arc d’une session — et pas seulement un allow/deny par appel — est ce qui fait ressortir une chaîne dont l’intention n’est lisible que de bout en bout. Journalisez les historiques complets d’appels d’outils et alertez sur les motifs qui s’assemblent en effets à fort impact.
• Testez avec du red teaming multi-tour et conscient des outils. Les suites de jailbreak à prompt unique ou uniquement textuelles sous-estimeront cette exposition. Évaluez les agents face à des trajectoires d’outils multi-étapes dans des environnements réalistes avant tout déploiement.

Statut

Élément	Valeur
Technique	Sequential Tool Attack Chaining (STAC), attaque multi-tour sur l’usage d’outils
Première divulgation	Préprint arXiv, septembre 2025 (révisé février 2026)
Périmètre	483 cas / 1 352 jeux d’interactions ; SHADE-Arena + Agent-SafetyBench ; 10 modes de défaillance
Impact mesuré	Réussite > 90 % pour la plupart des agents testés, dont un modèle de pointe
Meilleure défense documentée	Prompt de défense par raisonnement / résumé d’intention — jusqu’à 28,8 % de réduction (réussite résiduelle ≥ 58,6 %)
Nature	Résultat de recherche, posture défensive ; aucun exploit opérationnel diffusé

Dates clés : septembre 2025 — première mise en ligne de STAC sur arXiv. Février 2026 — version révisée. Il s’agit d’une étude de banc d’essai et de défense, pas d’un incident réel contre un produit nommé.

Cet article synthétise des travaux de recherche en sécurité publiquement disponibles à des fins défensives et omet volontairement tout code d’attaque fonctionnel.