Les outils de red team agentiques peuvent être piégés par leurs propres cibles

Qu’est-ce que c’est ?

Le 23 juin 2026, Dario Pasquini et ses collègues de Cracken (avec un contributeur de l’Université polytechnique nationale de Lviv) ont publié Red-Teaming the Agentic Red-Team (arXiv:2606.24496). C’est la première analyse de sécurité approfondie des outils que de nombreux praticiens utilisent désormais pour automatiser la sécurité offensive : des systèmes agentiques de pentest et de red team qui pilotent reconnaissance, exploitation et post-exploitation avec peu, voire aucune intervention humaine.

Le constat est gênant : ces outils se défendent eux-mêmes très mal. Sur 12 systèmes largement utilisés — dont CAI, RedAmon, PentestAgent, DarkMoon, PentAGI, AIRecon, PentestGPT, METATRON, nebula, xalgorix, Artemis et STRIX — les auteurs montrent qu’un adversaire qui contrôle la cible d’une opération peut retourner la situation : exfiltrer les clés d’API LLM de l’opérateur, installer un point d’ancrage persistant et, in fine, compromettre la machine de l’opérateur, même lorsque l’agent tourne dans un conteneur en bac à sable. Il s’agit d’un article de classe de vulnérabilité, pas d’une diffusion de payload.

Comment ça marche

La manipulation commence là où l’agent l’attend le moins : dans la sortie même des systèmes qu’il attaque. Un agent offensif réinjecte dans son LLM les résultats de commandes, les pages récupérées et les bannières de services. Une cible qui renvoie un contenu forgé peut orienter le raisonnement de l’agent — non pas via une chaîne explicite « ignore les instructions précédentes », mais par tromperie contextuelle et reward hacking. L’article décrit une manipulation sans injection de prompt qui provoque une exécution de code quasi déterministe sur le worker de l’agent, y compris avec des modèles de pointe comme Claude Opus 4.8, GPT-5.5 et Gemini 3.1 Pro, en empruntant aux techniques d’évasion antivirus pour déguiser le comportement malveillant en étape légitime vers l’objectif de l’agent.

Les auteurs abstraient l’escalade en une kill chain taillée pour ces outils : manipulation initiale du LLM, exécution de code sur le worker, mouvement latéral, persistance, contournement des garde-fous, évasion du bac à sable, puis compromission de l’hôte. Deux faiblesses architecturales récurrentes font l’essentiel des dégâts. D’abord, une isolation faible du système de fichiers : beaucoup d’outils partagent un répertoire accessible en écriture (bind mount ou volume Docker) entre le worker peu fiable et l’orchestrateur plus fiable, si bien qu’un attaquant capable d’exécuter du code dans le worker peut trojaniser des fichiers source vivants que l’orchestrateur chargera ensuite — persistance dure et voie vers le mouvement latéral. Ensuite, une isolation réseau faible et des canaux trop larges : des API d’orchestration destinées seulement à l’interface sont joignables depuis le worker, et le code de l’orchestrateur qui parse la sortie du worker est exposé à des bugs d’injection classiques — métacaractères shell, échappement de gabarits, désérialisation non sûre — qui transforment un canal de données en exécution de code à distance.

Pourquoi c’est important

Les agents de sécurité offensive tournent avec des privilèges inhabituellement dangereux : large portée réseau, clés d’API de valeur, et confiance implicite de l’opérateur. Par conception, ils passent aussi toute leur vie à ingérer des données contrôlées par l’attaquant. C’est le lethal trifecta poussé à son extrême logique, et cela signifie que le bac à sable autour du worker n’est pas la frontière de sécurité qu’on imagine — l’article montre que la compromission de l’hôte reste atteignable indépendamment du sandboxing dans la plupart des outils testés. Pour quiconque déploie ces systèmes contre de vrais adversaires — red teams, MSSP et, de plus en plus, défenseurs qui émulent des menaces — une cible piégée n’est plus hypothétique. Le même chemin d’injection de prompt vers RCE observé dans les frameworks d’agents généraux s’applique ici, avec cette torsion que l’attaquant possède déjà l’environnement que l’agent est chargé d’attaquer.

Défenses

La leçon centrale de l’article est architecturale : cessez de supposer que le LLM refusera de façon fiable la malveillance, et imposez plutôt une frontière de privilèges stricte dans le harnais. Traitez chaque octet produit par le worker comme une entrée non fiable, à examiner avant qu’il n’atteigne l’orchestrateur. Concrètement, les auteurs recommandent de garder l’orchestrateur et le worker dans des conteneurs/OS et segments réseau distincts, en n’exposant que les ports strictement nécessaires ; d’éviter totalement les montages de fichiers partagés et de faire transiter les artefacts par un canal unique, étroitement défini et auditable (avec approbation humaine ou inspection de contenu) plutôt que par un répertoire partagé ; et de garder la couche d’orchestration sans outils, en déléguant toute exécution de commandes au worker afin qu’un worker compromis ne puisse pas pivoter vers le haut. Durcissez le canal commande-réponse contre l’injection comme n’importe quel parseur traitant une entrée hostile, et reconstruisez les conteneurs worker à chaque opération pour que la persistance ne survive pas. Le moindre privilège — et non une confiance optimiste dans l’alignement du modèle — est le principe porteur. Ces contrôles rejoignent l’idée plus large selon laquelle les évasions de bac à sable dans les agents exécutant du code sont un problème de système, pas de modèle.

Statut

Red-Teaming the Agentic Red-Team est une divulgation de recherche (arXiv:2606.24496, publiée le 23 juin 2026) couvrant 12 outils nommés ; les auteurs résument les capacités de l’attaquant par outil et proposent une architecture de référence sécurisée plutôt que de diffuser des exploits armés. Il n’y a pas de CVE unique — la contribution est une taxonomie partagée des défauts de conception et un plan de défense. Toute équipe utilisant un outillage offensif agentique devrait auditer dès maintenant son déploiement face à la kill chain de l’article : vérifier l’isolation worker/orchestrateur, supprimer les montages partagés, et confirmer qu’une cible hostile ne peut rien atteindre au-delà d’un bac à sable worker jetable.