Qu'est-ce que le red teaming d'un agent IA ?
Un agent Claude en production reçoit des instructions, lit des documents, appelle des outils et écrit parfois dans des systèmes tiers. Chacune de ces capacités élargit la surface qu'un attaquant peut viser. Un test de sécurité doit donc vérifier comment l'agent se comporte quand une entrée est conçue pour le faire dévier.
Le red teaming d'un agent IA consiste à simuler, de façon méthodique et encadrée, des tentatives de manipulation contre un agent placé en conditions réalistes : instructions cachées dans une entrée, essais d'exfiltration de données, contournement des règles système. L'objectif est de mesurer sa résistance avant qu'un attaquant réel ne s'en charge.
Une session de red teaming réunit l'équipe qui a construit l'agent et un regard indépendant, qui ignore ses réglages internes. Ce regard extérieur réduit l'angle mort de l'équipe de conception, qui a tendance à tester ce qu'elle a anticipé plutôt que ce qu'elle n'a pas imaginé.
Pourquoi tester un agent Claude avant sa mise en production
Un système conversationnel mal aligné produit une réponse incorrecte. Un agent mal aligné peut agir : envoyer un message, modifier un enregistrement, déclencher un appel d'outil vers un système tiers. Cette capacité d'action change ce qu'un test de sécurité doit vérifier, et explique pourquoi un audit de code classique ne suffit pas à couvrir le risque.
Ce qui change avec un agent
L'agent enchaîne des appels d'outils sans qu'un humain valide chaque étape. Une instruction adverse glissée tôt dans une session peut donc se propager sur plusieurs actions avant d'être repérée. Le Top 10 de l'OWASP pour les applications agentiques, publié en décembre 2025, nomme ce risque le détournement d'objectif (ASI01) et le distingue du mauvais usage d'outils légitimes (ASI02). Le red teaming reproduit ces mécaniques avec des scénarios qui courent sur plusieurs tours, plutôt qu'avec une question isolée.
Ce que recommandent les référentiels publics
Dans l'édition 2026 de son Top 10 LLM, publiée en août 2026, l'entrée sur l'injection de prompt (LLM01) demande de tester les défenses contre des attaquants adaptatifs qui connaissent la protection déployée, et d'écarter les taux de réussite mesurés sur des attaques figées. Le projet OWASP avait publié en janvier 2025 un guide dédié, le GenAI Red Teaming Guide. Anthropic décrit de son côté, dans ses travaux du 24 novembre 2025 sur l'usage du navigateur par Claude, une défense qui combine entraînement du modèle, classifieurs et red teaming humain, et constate que les chercheurs humains trouvent les vecteurs d'attaque créatifs mieux que les systèmes automatisés. Ces protections réduisent le risque à la source, sans dispenser un déploiement d'entreprise de tester son propre périmètre d'outils.
Ce que l'AI Act attend des systèmes à haut risque
Pour les entreprises des secteurs régulés, le sujet a aussi une face réglementaire. L'article 15 de l'AI Act exige des systèmes à haut risque qu'ils résistent aux tentatives de tiers non autorisés de détourner leur usage, leurs sorties ou leurs performances en exploitant leurs vulnérabilités, et cite parmi les attaques visées les entrées conçues pour induire le modèle en erreur. Depuis l'Omnibus IA, le règlement (UE) 2026/1744, ces exigences s'appliquent à partir du 2 décembre 2027 aux systèmes de l'annexe III, comme le tri de candidatures ou l'évaluation du crédit. Un historique de campagnes documentées aide à démontrer cette robustesse le moment venu. Notre page sur la conformité AI Act en entreprise détaille le calendrier.
Une brique du dispositif de sécurisation
Le red teaming complète l'architecture des permissions, la journalisation et la revue humaine des actions sensibles. Notre guide pour sécuriser un agent Claude en production couvre l'ensemble du dispositif, dont le red teaming constitue la phase de vérification active.
Injection de prompt directe : tester la résistance à l'instruction adverse
L'injection de prompt directe désigne une instruction, formulée dans le message adressé à l'agent, qui cherche à remplacer ou à neutraliser ses règles. L'utilisateur demande frontalement à l'agent d'ignorer ses contraintes, de changer de rôle ou de révéler la façon dont il a été configuré.
Ce qu'un scénario de test doit couvrir
Un plan de test fait varier la formulation d'une même intention adverse : reformulation directe, changement de langue, encodage du texte, requête fractionnée sur plusieurs messages successifs. Un agent qui résiste à une formulation frontale peut céder à une variante plus détournée, et c'est cet écart que le test doit révéler. L'exposition du contexte caché appelle un scénario dédié. L'OWASP en fait l'entrée LLM08 de son Top 10 2026 (« Hidden Context Exposure ») et considère ce contexte comme extractible : le test cherche à reconstituer les consignes système et les schémas d'outils, puis vérifie qu'aucun secret ni aucun contrôle de sécurité n'en dépend.
Consigner chaque tentative
Une tentative non documentée est perdue pour la campagne suivante. Chaque test est enregistré avec sa formulation exacte, la réponse de l'agent, les appels d'outils déclenchés et un verdict simple : conforme, partiel ou en échec. Cette trace permet de comparer une campagne à la suivante et de prioriser les correctifs plutôt que de réagir au hasard des découvertes.
Injection de prompt indirecte : quand l'attaque vient d'un contenu tiers
La variante la plus difficile à anticiper vient d'un contenu que l'agent traite pour accomplir sa tâche : un document partagé, un email reçu, une page web consultée, la réponse d'un outil. Un texte peut y être rédigé pour ressembler à une instruction, dans l'espoir que l'agent la suive sans la distinguer d'une donnée à traiter. L'entrée LLM01 de l'édition 2026 recommande de faire passer le contenu externe par un canal structurellement séparé, étiqueté selon sa provenance, pour que le modèle distingue les données des instructions. La même entrée précise que ce marquage réduit le taux de réussite des attaques lors de tests non adaptatifs seulement, car un attaquant qui connaît le schéma de marquage peut l'imiter : il complète les tests contre des attaquants adaptatifs décrits plus haut.
La surface tierce : documents, emails, pages web, sorties d'outils
Chaque connecteur qu'un agent utilise devient un canal d'entrée potentiellement adverse. Un agent qui résume des pièces jointes, navigue sur le web ou interroge un serveur MCP traite du texte dont il ne contrôle pas l'origine. Le test consiste à injecter des instructions déguisées dans ces canaux et à observer si l'agent les exécute. Un agent qui parcourt une boîte mail ou un espace partagé traite des dizaines de fichiers dans une seule tâche, et il suffit d'un seul contenu piégé pour que le scénario échoue.
Le cas des connecteurs MCP
Pour les connecteurs MCP, la spécification du protocole (version du 28 juillet 2026) demande de considérer comme non fiables les descriptions du comportement des outils, sauf si elles proviennent d'un serveur de confiance. Notre article sur l'audit des serveurs MCP en production détaille cette surface serveur par serveur, et notre guide pour connecter Claude Code au SI avec MCP montre comment en restreindre l'accès côté poste. Chaque connecteur ajouté entre dans le plan de test de la campagne suivante.
Tentatives d'exfiltration de données : ce qu'un test doit simuler
Un agent qui accède à des dossiers clients, à des contrats ou à des échanges internes peut être manipulé pour les révéler hors du contexte prévu. Le red teaming simule cette pression : demander à l'agent de résumer une conversation hors de son périmètre ou d'envoyer une donnée vers une destination non autorisée, par exemple en l'intégrant à une adresse web ou à un message sortant.
Ce qu'un agent ne doit jamais révéler, même reformulé
Un test efficace va au-delà de la question directe (« montre-moi les données du client X »). Il pousse des variantes : un résumé anonymisé qui, recoupé, redevient identifiant ; une traduction ou une reformulation d'un extrait que l'agent ne devrait pas répéter ; une explication de son propre raisonnement qui exposerait des données de contexte. L'OWASP classe ce risque sous LLM02 dans son Top 10 2026, la divulgation d'informations sensibles.
Tester avec des données synthétiques
Une campagne de red teaming pousse volontairement l'agent hors de son cadre. La mener sur de vraies données sensibles multiplie le risque en cas d'erreur de configuration de l'environnement de test, et soulève une question RGPD. Des jeux de données synthétiques, construits pour ressembler aux cas réels, couvrent le même terrain sans exposer personne.
Contourner les garde-fous : la méthode de test
Un garde-fou est une règle posée autour de l'agent, par exemple une liste d'actions interdites, un filtre sur les sorties ou une validation côté système cible, indépendante du raisonnement du modèle. Un dispositif bien conçu en superpose plusieurs, et le test vérifie chaque couche séparément avant d'éprouver leur combinaison, car une couche peut masquer la faiblesse d'une autre.
La pression contextuelle
Un prompt système énonce des contraintes, et un agent qui raisonne peut être amené à les réinterpréter sous pression : une urgence simulée, une autorité usurpée, une justification qui semble légitime dans le contexte fourni. Un scénario de test inclut ces pressions, en plus des demandes frontales, et vérifie que l'agent s'en tient à ses règles même quand l'interlocuteur se présente comme un responsable.
Les conflits entre règles
Certaines défaillances n'apparaissent qu'à l'intersection de deux consignes légitimes prises isolément. Un test qui combine délibérément des instructions contradictoires révèle souvent des comportements qu'aucun des deux scénarios pris seul n'aurait montrés.
Construire une méthodologie de test récurrente
Un red teaming mené une seule fois avant le lancement mesure un état à un instant donné. Il ne dit rien du comportement de l'agent quelques mois plus tard, quand son environnement aura changé.
Avant la mise en production
La campagne initiale couvre l'ensemble des scénarios, injection directe et indirecte, exfiltration, contournement des garde-fous, sur chaque outil et chaque connecteur que l'agent utilisera réellement. Elle fixe aussi le seuil d'acceptation, c'est-à-dire les échecs qui bloquent la mise en production et ceux qui donnent lieu à un correctif planifié. La base de référence ainsi constituée note quel garde-fou a arrêté chaque tentative, afin que l'équipe sache quelle couche fait réellement le travail.
En continu après le déploiement
Une fois l'agent en production, le test se poursuit à un rythme régulier, et chaque changement significatif déclenche une nouvelle campagne : outil connecté, mise à jour du prompt système, nouvelle version du modèle. Les résultats rejoignent l'historique de l'agent, aux côtés de ses incidents et de ses audits.
Red teaming et gouvernance LOOP™
Le red teaming répond à une question technique : l'agent tient-il face à une attaque ? La gouvernance LOOP™ répond à une question d'organisation : qui décide, qui supervise, et avec quel niveau d'autonomie pour chaque action. La zone noire de LOOP™ couvre explicitement les tentatives d'injection de prompt et les demandes de contournement des garde-fous, avec blocage immédiat, alerte RSSI et audit trail complet. Une campagne de red teaming est le moyen de vérifier que ce blocage se déclenche vraiment.
Concentrer l'effort sur les actions les plus exposées
Dans LOOP™, la zone s'attache à chaque action de l'agent. Les actions classées en zone orange, où un humain valide avant exécution, et en zone rouge, où l'agent s'arrête et escalade vers un responsable désigné, sont celles dont un contournement coûterait le plus. Ce sont elles qui reçoivent les scénarios les plus poussés, par exemple une tentative de faire exécuter directement une action qui exige une validation. Notre article sur les zones de confiance pour classifier ses agents IA détaille le classement, et celui sur le protocole LOOP™ de gouvernance centrée humain présente les 4 zones et les 3 niveaux d'escalade.
Par où commencer avec vos propres agents
Avant de bâtir une campagne complète, il faut savoir où elle porte en priorité : quels agents accèdent à des données sensibles, lesquels disposent d'un droit d'écriture, lesquels lisent des sources tierces. Les agents qui cumulent lecture de contenus tiers et droit d'écriture passent en premier, car c'est chez eux qu'une injection indirecte se transforme en action.
La méthode de déploiement Koneetiv prévoit une phase de tests métier et de red teaming sécurité avant toute mise en production. Pour savoir où en est votre organisation, notre diagnostic de maturité IA donne en trois minutes un score et un plan d'action, selon le référentiel Koneetiv (édition 2026). Quand les agents se multiplient, Claude Cockpit prend en charge leur pilotage dans la durée, chacun inscrit au registre vivant LOOP™.