Red teaming agentique — quand le LLM n'est plus la cible principale

En bref

On appelle red teaming la pratique qui consiste à attaquer délibérément un système pour découvrir ses vulnérabilités avant qu’un adversaire ne le fasse. Quand la cible est un grand modèle de langage isolé, le red teaming se concentre sur le prompt — jailbreaks, injections, contournements d’alignement. Quand la cible devient un système agentique (un LLM qui appelle des outils, communique avec d’autres agents, lit une mémoire persistante et s’appuie sur une chaîne de dépendances logicielles), la surface d’attaque change de nature : le LLM n’est plus la cible principale, juste l’un des composants à protéger. Un papier publié en mai 2026 par Dreadnode (Dheekonda et al., arXiv:2605.04019v1) illustre cette bascule en mesurant un taux de succès d’attaque (attack success rate, ASR) de 85 % sur Llama Scout 17B en 7 727 essais, sans code humain. Le présent article cartographie cette nouvelle discipline : pourquoi elle diffère du red teaming classique, quelles attaques elle classifie, quels référentiels normatifs émergent, et comment l’auditer en pratique.

En clair : red teamer un LLM seul, c’est tester une serrure ; red teamer un système agentique, c’est tester une maison entière — serrure, fenêtres, cave, postier, livreurs et trousseaux de clés des sous-traitants.

Comprendre le problème : le LLM n’est plus seul

Imaginez un consultant qui répond à des questions depuis son bureau, isolé. Si vous voulez le tromper, vous lui parlez : vous reformulez la question, vous lui mentez sur votre identité, vous l’épuisez avec des dilemmes. C’est le red teaming d’un LLM solitaire — un duel verbal, déjà bien étudié.

Maintenant donnez à ce consultant un téléphone, un agenda partagé avec d’autres consultants, l’accès à un dossier client mis à jour en continu, et un contrat avec une dizaine de sous-traitants externes. Pour le tromper, vous n’avez plus besoin de lui parler : vous pouvez piéger un dossier qu’il va lire, corrompre un sous-traitant qui lui livre une information, ou laisser un message dans l’agenda partagé que ses collègues croiront authentique. Le système agentique ressemble à ce second consultant.

Vocabulaire

• Système agentique : un LLM intégré dans une boucle perception → raisonnement → action, capable d’appeler des outils externes, de lire et d’écrire dans une mémoire, et éventuellement de coordonner d’autres agents.
• Surface d’attaque : l’ensemble des points d’entrée par lesquels un adversaire peut influencer le comportement d’un système. Pour un LLM isolé, c’est essentiellement le prompt ; pour un agent, c’est aussi chaque outil, chaque source mémoire et chaque pair.
• Red teaming : pratique offensive structurée qui consiste à simuler des attaques pour exposer les vulnérabilités d’un système. À distinguer du fuzzing (entrées aléatoires) et du penetration testing classique (cible plutôt l’infrastructure).
• Attack success rate (ASR) : pourcentage de tentatives qui aboutissent à un objectif adverse défini (ex : faire produire au modèle une réponse interdite, faire exécuter une action non autorisée).
• Tool use : capacité d’un LLM à appeler des fonctions externes (recherche web, exécution de code, base de données) en générant des appels structurés que l’environnement exécute pour lui.

Trois constats rendent cette discipline distincte du red teaming classique. Premièrement, les vulnérabilités ne s’expriment plus uniquement dans le texte généré : un agent peut être détourné silencieusement, sans qu’aucun mot suspect n’apparaisse dans son output. Deuxièmement, les attaques peuvent franchir des frontières temporelles : un message empoisonné aujourd’hui peut influencer une décision dans plusieurs jours, après une réécriture de mémoire. Troisièmement, les composants tiers font partie du périmètre : un paquet Python typo-squatté, un schéma JSON trafiqué ou un document mal vérifié dans une base de connaissances peuvent compromettre l’agent sans toucher au modèle lui-même.

En clair : un LLM isolé se compromet par les mots ; un système agentique se compromet aussi par ce qu’il lit, ce qu’il appelle, qui lui répond et ce que ses dépendances installent dans son environnement.

Pourquoi le red teaming change quand l’agent rejoint la pièce

Quatre raisons structurelles expliquent l’élargissement du périmètre.

Les outils tiers multiplient les handlers attackables. Chaque outil branché à un agent (via MCP, Model Context Protocol — un standard d’interface entre LLM et fonctions externes — ou via un tool calling propriétaire) est un point d’entrée. Le schéma JSON qui décrit l’outil, le code qui l’exécute, et le canal qui transmet le résultat sont tous trois manipulables. Un outil mal contraint accepte des paramètres qu’il n’aurait pas dû accepter. Un outil substitué par un homonyme malveillant rend la main en silence. Le LLM, lui, a juste fait son travail : appeler ce qu’on lui a donné.

La mémoire persistante crée des fenêtres d’attaque longues. Un LLM solitaire oublie tout entre deux conversations. Un agent, lui, peut écrire dans une mémoire (résumés de session, base de connaissances, état partagé) et la relire plus tard. Un attaquant qui parvient à insérer une fausseté dans cette mémoire installe une bombe à retardement : la prochaine tâche qui consultera cette zone héritera silencieusement du biais. C’est ce que la littérature appelle le knowledge poisoning (empoisonnement de connaissance) — distinct de l’injection de prompt classique parce qu’il ne nécessite pas d’être présent au moment de l’attaque.

Les communications inter-agents introduisent un bus de confiance non authentifié. Quand plusieurs agents collaborent, ils s’échangent des messages : sous-tâches, résultats partiels, signaux de fin. Si ce bus n’est pas signé cryptographiquement, n’importe quel processus avec un accès en écriture peut se faire passer pour un agent légitime. C’est le peer spoofing. Et même si chaque agent est sain, un seul output adversarial dans une consolidation à N agents peut suffire à biaiser la synthèse — phénomène documenté sous le terme consensus poisoning.

La supply chain s’étend des dépendances logicielles aux modèles. Un agent en production tire des paquets Python, des modules Node, une image Docker de base, et souvent un ou plusieurs modèles téléchargés depuis un hub public (Hugging Face, par exemple). Chaque maillon est une cible potentielle : slopsquatting (un paquet halluciné par un LLM lors de la génération de code, qu’un attaquant publie ensuite sur PyPI au nom prédit), dependency confusion (un paquet interne dont le nom est repris en public avec une version supérieure), model merge backdoor (un modèle public qui contient un comportement malveillant déclenché par un trigger précis).

Une étude empirique de Mulla et al. (2025, arXiv:2504.19855) sur 214 271 tentatives d’attaque par 1 674 participants sur 30 défis LLM montre que les approches automatisées atteignent 69,5 % de succès contre 47,6 % pour les efforts manuels — l’automation ne remplace pas l’intelligence offensive, mais elle élargit la couverture.

En clair : la cible se diffuse dans tous les composants. Le LLM n’est plus le boss à abattre — c’est le maillon central d’une chaîne dont chaque autre maillon est attaquable indépendamment.

La taxonomie Dreadnode — 5 fronts d’attaque

Le papier Dreadnode (Dheekonda, Pearce, Landers, 2026) introduit l’une des premières taxonomies opérationnelles dédiées au red teaming agentique. Sur 38 modules de transformations adverses cataloguées, cinq catégories sont spécifiques aux systèmes agentiques — c’est-à-dire qu’elles n’auraient pas de sens sur un LLM isolé.

Front 1 — Attaques MCP et outils

Tool poisoning : on injecte une description d’outil malveillante dans le catalogue présenté au LLM. Le modèle, qui choisit ses outils en lisant leur description, est manipulé en amont du tool calling proprement dit. Tool shadowing : on enregistre un nouvel outil dont le nom collisionne avec un outil légitime, qui est silencieusement remplacé. Rug pull : on présente un outil bénin lors de l’audit puis on échange le code à l’exécution réelle (pratique connue dans l’écosystème crypto, transposée aux agents). Schema poisoning : on laisse le schéma JSON de validation accepter des paramètres qu’il n’aurait pas dû accepter (additionalProperties non contraint, énumérations trop larges, types any).

En clair : la couche outil est une nouvelle peau d’attaque. Pas besoin de jailbreaker le LLM — il suffit de modifier ce qu’il voit comme étant ses outils.

Front 2 — Exploits multi-agents

Prompt infection cross-worker : un agent compromis insère dans son output un sous-prompt malveillant ; quand le consolidateur lit cet output, il exécute l’instruction cachée. Peer spoofing : un attaquant émet un message qui imite le format d’un agent légitime sans avoir produit de travail réel — la consolidation l’intègre comme un output authentique. Consensus poisoning : dans une orchestration où plusieurs agents votent ou contribuent à une synthèse, un seul nœud adversarial peut suffire à infléchir la conclusion, surtout si la consolidation pondère naïvement les contributions.

Front 3 — Attaques sur le raisonnement

CoT backdoor : un déclencheur particulier dans le prompt fait dévier la chaîne de pensée du modèle vers un comportement caché, sans modifier les outputs sur les autres entrées (chain-of-thought, raisonnement étape par étape exposé par le modèle). Reasoning hijack : on injecte dans le contexte une fausse étape de raisonnement qui paraît cohérente, et le modèle continue à partir d’elle comme si elle était la sienne. Reasoning DoS (denial of service) : on construit un prompt qui force le modèle à générer un raisonnement excessivement long avant de répondre, saturant la fenêtre de contexte ou le budget tokens.

Front 4 — Agents navigateur

Quand un agent contrôle un navigateur web (clics, saisie, lecture du DOM), il hérite des vulnérabilités classiques du web plus quelques nouvelles. Visual prompt injection : du texte malveillant masqué dans une image. AI ClickFix : une page conçue pour faire cliquer l’agent sur un piège qu’un humain aurait évité. Navigation hijack : un domaine qui usurpe l’identité d’un site légitime. Ce front sort du périmètre de la plupart des audits internes orientés orchestration ; mais il prend de l’importance à mesure que les agents s’autonomisent côté navigation.

Front 5 — Supply chain

Package hallucination : un LLM génère un import vers un paquet qui n’existe pas ; un attaquant publie ce paquet sous le nom prédit, avec un payload malveillant. Model merge backdoor : un modèle public combiné à partir de plusieurs modèles open-weights peut hériter d’un comportement caché injecté par l’un de ses parents. Dependency confusion : un paquet interne dont le nom est aussi disponible publiquement, avec une version supérieure, peut être tiré en priorité par certains gestionnaires de paquets.

Matrice synthétique

À noter : la même étude rapporte que les attaques multi-tour (Crescendo) et graph-based (Graph of Attacks with Pruning, GAP) atteignent 100 % d’ASR sur Llama Scout, contre 96 % pour la méthode arborescente Tree of Attacks with Pruning (TAP) — et que la transformation none (aucune mutation du prompt) atteint déjà 80 % d’ASR, ce qui révèle des écarts d’alignement n’exigeant même pas de sophistication adverse pour être exploités.

En clair : la sophistication des transformations n’est pas la variable principale. Beaucoup d’attaques réussissent parce que des contre-mesures structurelles élémentaires manquent — pas parce que l’attaquant a déployé une technique exotique.

OWASP ASI01-10 — le cadre normatif émergent

L’OWASP (Open Worldwide Application Security Project) — fondation à but non lucratif qui maintient depuis 2003 le célèbre OWASP Top 10 des risques web — a lancé en 2024 son Agentic Security Initiative (ASI), un référentiel dédié aux risques propres aux systèmes agentiques. Là où l’OWASP LLM Top 10 (2025) couvre les vulnérabilités centrées sur le modèle (prompt injection, fuite d’informations sensibles, agence excessive), l’ASI s’attaque aux risques qui n’apparaissent que lorsque le LLM est inséré dans une architecture d’agents.

Sur les dix catégories du référentiel, huit sont régulièrement citées dans la littérature accessible :

• ASI01 — Tool Manipulation : compromission de la couche outil (poisoning, shadowing, rug pull, schema poisoning).
• ASI02 — Knowledge Poisoning : insertion de faussetés dans une base de connaissances ou une mémoire persistante.
• ASI03 — Excessive Agency : agent disposant de plus de droits que sa tâche n’en exige (suppression de fichiers, transactions financières, écritures système).
• ASI04 — Trust Boundary Violation : franchissement non autorisé de frontières entre agents, environnements ou comptes.
• ASI05 — Reasoning Hijack : détournement de la chaîne de raisonnement par injection de fausses étapes plausibles.
• ASI06 — Memory Poisoning : pollution durable de la fenêtre de contexte ou des résumés de session.
• ASI09 — Supply Chain : compromission via dépendances logicielles, modèles ou skills tiers.
• ASI10 — Model Integrity : attaques sur l’intégrité du modèle lui-même (model merge, fine-tuning malveillant, bascule de poids).

Les catégories ASI07 et ASI08 complètent le référentiel sur des aspects qui n’ont pas été détaillés dans la littérature analysée pour cet article — ce qui est un trait normal d’un référentiel jeune en cours de stabilisation.

En clair : ASI01-10 est l’équivalent de l’OWASP Top 10 pour les agents. C’est un vocabulaire commun pour décrire des risques agentiques sans réinventer le mot à chaque fois.

Deux référentiels adjacents complètent ce cadre. MITRE ATLAS (Adversarial Threat Landscape for AI Systems) fournit une nomenclature de techniques numérotées (ex : AML.T0049 pour le compromis de supply chain, AML.T0051 pour l’injection de prompt). NIST AI RMF 1.0 structure la gouvernance autour de trois fonctions — MAP (cartographie des risques), MEASURE (mesure), MANAGE (gestion). Ces trois familles ne sont pas concurrentes : OWASP ASI nomme les classes d’attaques, MITRE ATLAS catalogue les techniques précises, NIST AI RMF cadre la gouvernance.

Une méthodologie d’audit interne — la Pieuvre adversariale

Auditer un système agentique réel suppose de cartographier sa surface, de la confronter à une taxonomie d’attaques, et de prioriser les contre-mesures. Une méthodologie reproductible déployée dans le cadre R&D du laboratoire suit le schéma suivant.

Décomposition. Un agent orchestrateur découpe le périmètre en zones disjointes (couche outils, couche multi-agents, couche raisonnement, couche supply chain). Pour chaque zone, un worker dédié exécute en parallèle un audit ciblé : inventaire des points d’entrée, mappage vers la taxonomie Dreadnode, mappage vers OWASP ASI, propositions de mitigation. Un consolidateur final agrège les rapports, déduplique les findings, priorise les mitigations et signale les tensions ouvertes.

Anti-convergence par diversification de scope. Chaque worker reçoit un module distinct pour réduire la corrélation entre rapports. Sans diversification, plusieurs instances du même modèle convergent vers les mêmes biais — un effet documenté qui rend une “double validation” par deux LLM identiques peu utile en sécurité.

Reconnaissance honnête de la convergence modèle. Même avec des scopes disjoints, plusieurs workers issus du même modèle de base partagent des biais structurels (sycophancy, hiérarchisation similaire des sévérités, vocabulaire commun pour décrire les vecteurs). La triangulation indépendante reste indispensable : un opérateur humain, une référence externe (paper, CVE, advisory) ou un modèle d’une autre famille doivent venir confirmer ou réfuter les findings critiques.

Un audit récent ainsi mené a inventorié 41 surfaces réparties entre les couches outils, multi-agents et raisonnement+supply chain. Sur 42 findings logiques, 39 ont été consolidés après déduplication. Deux findings critiques de nature structurelle sont ressortis : l’absence d’authentification cryptographique sur les signaux inter-agents (peer spoofing exploitable dès qu’un processus dispose d’un accès en écriture local), et l’absence de mode append-only sur les bases de connaissance long-terme (ouverture à un knowledge poisoning persistant). Cinq familles de mitigations ont été priorisées et neuf tensions architecturales ont été ouvertes pour une session ultérieure.

En clair : un audit agentique n’est pas un pentest classique. Il combine inventaire de surface, classification d’attaques par taxonomie, et reconnaissance explicite que la convergence du modèle de base limite ce qu’on peut affirmer seul.

Patterns observés dans la pratique

Trois patterns reviennent suffisamment souvent pour mériter une attention spécifique.

Pattern 1 — Schémas trop laxistes. Les schémas JSON décrivant les outils déclarent rarement additionalProperties: false au niveau racine et dans les objets imbriqués. Conséquence : un appel d’outil peut transmettre des paramètres non prévus, qui peuvent être lus par le code côté serveur (logs, transmission à des sous-outils, persistance). C’est une porte d’entrée pour le schema poisoning — l’attaquant n’a pas besoin de modifier le code de l’outil, juste d’exploiter les champs que le schéma laisse passer.

Pattern 2 — Communication inter-agents non authentifiée. Beaucoup d’orchestrations s’échangent des fichiers JSON simples (signaux de fin, outputs intermédiaires) sans signature cryptographique. Un attaquant local — ou un sous-processus compromis — peut écrire un faux signal de fin et faire croire à l’orchestrateur qu’un worker a terminé son travail avec un résultat donné, alors qu’aucun worker n’a tourné. La parade canonique est une signature HMAC (Hash-based Message Authentication Code, code d’authentification de message basé sur un hachage) avec une clé partagée stockée hors du dépôt, et un hash content-addressable du fichier d’output cité dans le signal.

Pattern 3 — Dépendances Python non verrouillées. Les requirements.txt qui pinnent uniquement des plages (>=3.0.0,<4.0.0) plutôt que des versions exactes avec hash ouvrent la porte à plusieurs attaques de supply chain : slopsquatting (un paquet halluciné par un LLM lors de la génération de code, publié ensuite par un attaquant), dependency confusion (priorité accidentelle à un paquet public homonyme d’un paquet interne), substitution silencieuse à l’installation suivante.

Ordre de grandeur du verrouillage : pinner une image Docker de base par digest tient en une ligne (FROM python:3.11-slim@sha256:<digest>). Verrouiller transitivement un projet Python typique avec pip-compile --generate-hashes produit un fichier de plusieurs centaines de hashes SHA-256 — un projet R&D représentatif observé en interne en compte autour de 1 500. Le coût est marginal en effort ; l’impact est élevé en sécurité.

En clair : trois portes restent souvent ouvertes par défaut — schémas trop permissifs, signaux non signés, dépendances non hashées. Les fermer ne demande pas de cryptographie sophistiquée, juste de l’application disciplinée.

Mitigations actionnables

Cinq familles de contre-mesures couvrent la majorité des findings observés. Aucune n’est suffisante seule ; l’effet protecteur vient de leur combinaison.

Mitigation 1 — Verrouillage supply chain par hashes. Génération d’un lockfile avec hashes SHA-256 (pip-compile --generate-hashes côté Python, package-lock.json avec integrity côté Node). Pin de l’image Docker de base par digest immuable. Vérification automatique en intégration continue qu’aucun paquet n’est tiré sans hash référencé.

Mitigation 2 — Signature HMAC sur communications inter-agents. Chaque signal de fin émis par un worker contient une signature calculée à partir d’une clé maîtresse stockée hors du dépôt. L’orchestrateur refuse à la lecture tout signal dont la signature est invalide. Le hash SHA-256 du fichier d’output associé est inclus dans le signal pour garantir que personne n’a remplacé l’output entre l’écriture et la consolidation.

Mitigation 3 — Manifest d’intégrité étendu. Un fichier de référence liste tous les artefacts critiques (schémas d’outils, templates de prompts, skills, conventions internes) avec leur hash SHA-256. Un script d’audit, exécuté au démarrage de session ou en pré-commit, détecte tout drift silencieux (modification non tracée d’un fichier protégé). Le pattern existe depuis longtemps pour les fichiers de configuration sensibles d’un site public ; il se généralise aux référentiels long-terme d’une plateforme agentique.

Mitigation 4 — Mode append-only et audit log SHA-256 sur bases de connaissance. Toute mutation d’une base de connaissances génère une entrée signée dans un journal à ajout seul (hash avant/après, auteur, session). Un hook git pré-commit refuse la mutation ou la suppression d’une entrée existante sauf indication explicite. Cette mesure rend impossible la modification silencieuse d’un fait passé — sans empêcher l’ajout de nouveaux faits ni la requalification documentée.

Mitigation 5 — Hardening défensif ponctuel. Validation stricte des schémas (additionalProperties: false partout), interdiction des appels shell non whitelistés (jamais shell=True avec une commande lue depuis une configuration externe), échappement XML systématique sur toute substitution de variable dans un template, assertions de non-collision lors de l’enregistrement d’outils dynamiques.

Matrice effort × impact

Heuristiques opératoires.

• Commencer par les quick-wins. Les mitigations 1 et 5 ferment la majorité des portes ouvertes par défaut sans changement architectural.
• Ne pas confondre PARTIELLE et complète. Une convention procédurale (“règle de revue avant commit”) n’est pas une contre-mesure cryptographique. Les deux coexistent ; aucune ne remplace l’autre.
• Documenter les triangulations. Un finding critique sourcé uniquement par convergence interne (plusieurs LLM du même modèle) n’est pas triangulé — il faut une référence externe (CVE, paper, advisory) ou un opérateur humain.

Limites et perspectives

Cet article décrit une discipline en formation, et plusieurs limites méritent d’être nommées explicitement.

Audit statique vs scan offensif réel. La méthodologie présentée s’appuie sur la lecture de code, l’inventaire de surface et la classification taxonomique. Elle ne reproduit pas d’exploit actif : aucun peer spoofing simulé, aucun tool poisoning injecté en environnement de test, aucun supply chain compromise reproduit. Un finding marqué critique sur la base d’une absence structurelle de contre-mesure n’est pas un exploit démontré — c’est un risque de conception. La validation par exploit empirique est un palier ultérieur, plus coûteux et plus risqué à orchestrer en interne.

Convergence modèle. Le red teaming agentique automatisé tend à converger quand les workers sont issus du même modèle de base. Mêmes biais d’analyse, même hiérarchisation des sévérités, même vocabulaire — l’apparente “double validation” est en réalité une corrélation déguisée. Atténuer cette convergence demande soit un mix de modèles de familles distinctes (Opus + Sonnet + un modèle open-weights), soit une triangulation externe humaine systématique sur les findings critiques.

Référentiels jeunes. OWASP ASI01-10, la taxonomie Dreadnode et MITRE ATLAS sont des cadres encore en stabilisation. Un découpage différent peut émerger dans les deux ou trois années qui viennent, surtout avec la montée en puissance des agents navigateur et des architectures multi-agents distribuées sur plusieurs organisations.

Côté perspectives, plusieurs directions sont déjà visibles. Le red teaming continu (intégration des audits dans le pipeline CI/CD plutôt qu’en campagne ponctuelle) commence à se diffuser. L’automation des audits de supply chain par des outils dédiés (pip-audit, npm audit, scanners de manifest hash) progresse. Et la cristallisation de conventions cross-équipes (HMAC sur signaux, append-only sur knowledge bases, manifest hash global) devrait permettre de comparer des audits entre projets sans tout réinventer à chaque fois.

Conclusion

Le red teaming agentique n’est pas une extension cosmétique du red teaming classique. C’est une discipline distincte qui prend acte d’un changement de nature : le LLM devient l’un des composants à protéger, et la surface d’attaque s’étend à tout ce qui parle au modèle, à tout ce que le modèle appelle, et à tout ce qui se trouve dans la chaîne logicielle qui les fait tourner. La taxonomie Dreadnode (5 fronts), le référentiel OWASP ASI (10 catégories) et les méthodologies d’audit en Pieuvre fournissent un premier socle reproductible — encore jeune, encore convergent, encore dépendant d’une triangulation humaine pour ses verdicts critiques. Pour une équipe qui exploite des agents en production, le retour sur investissement de quelques quick-wins (lockfile par hashes, signaux signés, manifest d’intégrité, hardening de schémas) dépasse largement leur coût d’implémentation. Le reste — convergence modèle, scan offensif réel, référentiels stabilisés — relève du programme de recherche encore ouvert.