Red teaming des agents IA : détecter les vulnérabilités de façon systématique

Le red teaming des agents IA consiste à attaquer des agents IA de manière systématique et simulée afin de mettre au jour des vulnérabilités comme l'injection de prompt, les jailbreaks, l'utilisation abusive des outils et la fuite de données, avant que de vrais attaquants ne les exploitent. Il combine des outils d'attaque automatisés avec la créativité manuelle d'attaques en plusieurs étapes et fournit des résultats mesurables, comme des taux de réussite des attaques, plutôt que des listes binaires de vulnérabilités. Contrairement à un test fonctionnel, il ne demande pas « l'agent fonctionne-t-il ? », mais « comment peut-on le détourner de sa véritable finalité ? ».

Cet article fait partie du hub « Sécurité des agents IA selon l'OWASP » et précise comment tu peux tester de manière offensive les risques répertoriés dans l'OWASP Agentic Top 10 (ASI01–ASI10).

Trois réponses rapides

• Qu'attaque-t-on ? La surface d'attaque propre aux agents : pas seulement le modèle, mais aussi les appels d'outils, la mémoire persistante, la communication entre agents et le human-in-the-loop. L'objectif est de mettre au jour le détournement d'objectif, l'utilisation abusive des outils, l'empoisonnement de la mémoire et la fuite de données.
• Avec quoi ? Des scanners open source (Garak, PyRIT, DeepTeam, Promptfoo) pour la couverture large, du red teaming manuel pour les attaques en plusieurs étapes et du bug bounty pour la couverture sur le long terme.
• À quelle fréquence ? Un test de référence trimestriel, plus des tests déclenchés par des événements (nouveaux outils, modifications du prompt, mises à niveau du modèle, CVE critiques).

Pourquoi le red teaming IA n'est pas un pentest classique

La distinction la plus importante d'abord : le red teaming IA n'est pas synonyme de test d'intrusion traditionnel. Les équipes achats confondent régulièrement les deux, avec des conséquences coûteuses lorsqu'un pentest réalisé avec Burp Suite est accepté comme « preuve de sécurité de l'IA ».

Les différences sont fondamentales :

Souvent, un agent IA ne « casse » même pas au sens classique : il suit des instructions qu'on lui a fait passer pour légitimes. Comme les agents et le modèle sous-jacent ne savent pas distinguer de manière fiable les instructions des données, chaque texte que lit l'agent fait partie de la surface d'attaque. Cela exige une autre discipline de test.

Les vulnérabilités qu'une red team recherche de façon ciblée

Le red teaming passe en revue les classes de menaces propres aux agents de l'OWASP Agentic Top 10. Concrètement, il s'agit de construire de manière ciblée les attaques suivantes :

• Injection de prompt / détournement d'objectif (ASI01). Injection directe et indirecte, instructions cachées dans des documents, le corpus RAG, des e-mails, des invitations d'agenda, des descriptions de PR ou des sorties d'outils. Particulièrement perfide : la dérive multi-tours « boiling frog », où chaque étape prise isolément paraît plausible alors que la trajectoire cumulée est malveillante.
• Jailbreaks. Contournement des garde-fous de sécurité pour déclencher des actions ou des contenus interdits.
• Utilisation abusive des outils (ASI02). Une fonction légitime (par ex. send_email) est détournée de son usage ; les modes d'approbation automatique ou « YOLO », qui désactivent les demandes de confirmation, sont exploités.
• Empoisonnement de la mémoire et du contexte (ASI06). Un contenu injecté une seule fois empoisonne durablement la mémoire persistante ; la « delayed tool invocation » ne se déclenche que des semaines plus tard, sur un mot déclencheur.
• Fuite de données. Exfiltration via des images Markdown manipulées, des chaînes de redirection ou des proxys détournés.
• Attaques entre agents (ASI07) et exploitation de la confiance humain-agent (ASI09). Messages falsifiés entre agents et neutralisation délibérée de la couche de validation humaine par des recommandations formulées avec assurance, mais manipulées.

Des incidents documentés prouvent que ces attaques sont réelles : EchoLeak (CVE-2025-32711, CVSS 9.3 selon Microsoft) a été la première injection de prompt zero-click réelle dans un système LLM en production et a contourné le classificateur XPIA (Cross-Prompt Injection Attempt) de Microsoft. CamoLeak (CVSS 9.6) a exfiltré caractère par caractère des secrets de dépôts privés et du code source via le propre proxy d'images Camo de GitHub. Les deux cas le montrent : des chercheurs compétents ont contourné chaque garde-fou publié en quelques mois.

Démarche : automatisée ou manuelle

Un red teaming mature combine deux modes complémentaires.

Automatisé signifie passage à l'échelle et reproductibilité. Les scanners déroulent de larges bibliothèques de sondes contre l'agent et mesurent la part qui passe. Ils se prêtent à l'intégration continue dans la CI/CD et aux tests de régression après chaque modification. Point faible : ils trouvent surtout des schémas d'attaque connus.

Manuel signifie créativité et contexte. Des analystes expérimentés construisent des campagnes en plusieurs étapes taillées pour l'agent concerné, précisément les attaques que les scanners ne voient pas. Exemples issus de la recherche : l'« Agent Session Smuggling » contre le protocole A2A (Palo Alto Unit 42, 31 octobre 2025) n'est pas une injection en un seul coup, mais une campagne d'ingénierie sociale soutenue, d'agent à agent. A2A a été développé par Google ; depuis juin 2025, le protocole est confié à la Linux Foundation. L'attaque contre la mémoire de Google Gemini (Johann Rehberger, février 2025) a utilisé la « delayed tool invocation » pour empoisonner la mémoire en différé.

Outils et frameworks en 2026

Les outils suivants sont les briques établies dans la pratique. Les données de version et de marché datent de 2026.

Commerciaux : Lakera Red (Lakera, basée à Zurich, intégrée à Check Point depuis octobre 2025), HiddenLayer AIDR, Robust Intelligence (Cisco), Trustwise et Cranium.

Bug bounty couvrant l'IA : HackerOne (GitHub est passé par HackerOne pour la divulgation de CamoLeak), Bugcrowd et Intigriti, basée dans l'UE et bien implantée dans la zone DACH (Allemagne, Autriche, Suisse).

Reporting : mesurable et rattaché aux frameworks

La valeur d'un red teaming dépend entièrement du rapport. Les résultats étant probabilistes, il faut les quantifier. Indicateurs utiles :

• Taux de réussite des attaques : part des attaques réussies par classe.
• Taux de détection : nombre d'attaques repérées par la supervision.
• Délai de détection : temps écoulé jusqu'à la détection.
• Rayon d'impact : nombre d'agents ou de systèmes en aval qui seraient touchés.

Chaque constat devrait être rattaché à des frameworks établis : l'OWASP Agentic Top 10 (ASI01–ASI10) comme registre des risques, MITRE ATLAS comme playbook de l'adversaire (avec une réserve honnête : ATLAS a 6 à 12 mois de retard sur la frontière agentique, en particulier pour ASI07, ASI08 et ASI10) et, comme approche émergente (en 2026), AIVSS (version 0.8) pour le scoring quantitatif. Les constats peuvent aussi être structurés de façon compatible AVID, ce qui en fait des preuves d'audit reproductibles pour l'ISO 42001 A.5 et l'art. 9 du règlement européen sur l'IA. Point important pour les achats : « OWASP-compliant » n'est pas une affirmation solide. L'OWASP ne certifie pas.

À quelle fréquence et par qui

Fréquence (règle empirique) : un test de référence trimestriel complété par des tests déclenchés par des événements, avant chaque nouvelle intégration d'outil disposant de droits destructifs, après chaque modification substantielle du prompt ou du message système, après chaque mise à niveau de version du modèle et ponctuellement dès qu'une CVE ou un PoC touche ta propre stack.

Qui : les grands groupes disposant de leur propre stack d'agents sur des données sensibles entretiennent une red team IA dédiée (en interne ou externe sous contrat permanent), qui travaille avec Garak, PyRIT et DeepTeam selon le framework OWASP_ASI_2026, ainsi qu'un programme de bug bounty. Les PME qui déploient des agents via des API managées confient le red teaming à des prestataires spécialisés, faute de compétences spécifiques en ML en interne.

Pour les entités financières de l'UE, les tests offensifs sont réglementés. DORA est un règlement européen, s'applique directement depuis le 17 janvier 2025 et exige des tests de résilience réguliers (art. 24–25). Seules les entités financières désignées par l'autorité de surveillance compétente doivent réaliser des tests de pénétration fondés sur la menace (TLPT) (art. 26–27). En Allemagne, le guide d'orientation de la BaFin sur les risques TIC liés à l'utilisation de l'IA du 18.12.2025 cite les tests d'intrusion adversariaux et la simulation d'attaques (empoisonnement de données, évasion) comme mesures appropriées. Ce guide est expressément non contraignant. Quiconque exploite des systèmes d'IA critiques sans de tels tests devrait malgré tout pouvoir le justifier lors d'un contrôle.

Exemple pratique chiffré

Un assureur exploite un workflow multi-agents pour la gestion des sinistres. Une red team interne construit une injection indirecte : dans la copie scannée d'un courrier médical, l'instruction de valider automatiquement les dossiers de certaines catégories est dissimulée sous forme de texte reconstituable par OCR. L'agent « Risk Scoring » reprend l'évaluation manipulée et la transmet aux agents « Pricing » et « Compliance ».

Les indicateurs mesurés : taux de réussite de l'injection 1 sur 1 (réussie), délai de détection > 4 heures, rayon d'impact 3 agents en aval. À titre de comparaison, des travaux de Galileo AI (décembre 2025) ont montré, dans des systèmes multi-agents simulés, qu'un seul agent compromis empoisonnait 87 % de la prise de décision en aval en 4 heures. Un incident documenté dans les achats d'un industriel (2025) : en trois semaines, un agent a été progressivement convaincu que sa limite de validation était de 500 000 USD ; l'attaquant a ensuite passé pour 5 millions USD de fausses commandes en 10 transactions. Ce type de résultats traduit des risques abstraits en chiffres présentables à un comité de direction.

Check-list pratique

• Définir le périmètre : quels outils, mémoires, chemins inter-agents et points de contrôle HITL sont inclus ?
• Dériver des scénarios fondés sur le modèle de menaces à partir d'OWASP ASI01–ASI10.
• Ancrer un scan de référence automatisé (Garak/PyRIT/DeepTeam) dans la CI/CD.
• Compléter par des campagnes manuelles en plusieurs étapes (boiling frog, A2A, delayed invocation).
• Collecter les indicateurs : taux de réussite des attaques, taux de détection, délai de détection, rayon d'impact.
• Rattacher les constats à OWASP/MITRE ATLAS/AIVSS et les documenter de façon compatible AVID.
• Des « injections de test » pour vérifier que le human-in-the-loop fonctionne réellement.
• Fixer la cadence : trimestrielle, plus des tests déclenchés par des événements.

Pour les agences et les décideurs B2B

Quiconque construit des agents pour des clients ou les utilise dans sa propre stack marketing et commerciale devrait considérer le red teaming comme une composante fixe du processus de livraison et d'exploitation, et non comme un test de recette ponctuel. Pour les agences, c'est aussi un facteur de différenciation : des taux de réussite des attaques démontrables et un reporting rattaché à l'OWASP créent chez les clients une confiance que la formule « nous utilisons des garde-fous » n'obtient pas. Blck Alpaca t'aide à mettre en place un dispositif de red teaming adapté à la maturité et au cadre réglementaire de ton entreprise : du choix des outils jusqu'au rapport exploitable en audit, en passant par le développement des scénarios. Contacte-nous avant que ton agent passe en production.