Red team d'un agent IA : tester ce qu'un inconnu peut lui faire faire

Le red teaming d'un agent IA consiste à attaquer volontairement un agent qui lit des contenus, appelle des outils et agit sur des données, afin de mesurer ce qu'un inconnu peut lui faire faire. Il se distingue du pentest classique parce que la cible est un modèle de langage qui décide seul de ses actions : la faille se trouve dans le texte qu'il lit autant que dans le code qui l'entoure. CleanIssue réalise ce test sur environnement de test, avec autorisation écrite, et livre un rapport avec preuves reproductibles.

Qu'est-ce que le red teaming d'un agent IA ?

C'est un test d'intrusion adapté aux agents : on se place du point de vue d'un attaquant qui ne dispose d'aucun accès privilégié, mais qui peut déposer du texte quelque part où l'agent le lira (un e-mail, un ticket, un document, une page web, un champ de formulaire). Le test mesure ensuite ce que l'agent fait de ce texte : quelles instructions il suit, quels outils il appelle, quelles données il sort.

Un agent se compose généralement d'un modèle, d'un prompt système, d'outils (API, base de données, envoi d'e-mails, navigation web, serveurs MCP) et d'une mémoire ou d'un moteur de recherche documentaire (RAG). Chaque élément ouvre une surface d'attaque. Le red teaming les parcourt dans l'ordre où un attaquant les rencontrerait, puis enchaîne les faiblesses pour atteindre un impact concret : une fuite de données, une action non autorisée, un détournement de compte.

Le référentiel de base est l'OWASP Top 10 for LLM Applications 2025, complété par les travaux de l'OWASP sur les applications agentiques et par la matrice MITRE ATLAS. Pour une vue d'ensemble des risques, consultez notre page sur la sécurité des agents IA.

Pourquoi un pentest classique rate-t-il les failles d'un agent IA ?

Un pentest classique cherche des défauts dans du code et de la configuration : une injection SQL, un contrôle d'accès absent, un secret exposé. Un agent IA ajoute une couche que ces méthodes ne couvrent pas : le modèle interprète du langage naturel et peut être convaincu d'utiliser ses permissions pour autre chose que ce que son concepteur avait prévu.

Trois raisons expliquent l'écart :

• L'entrée n'est plus un champ de formulaire. Tout contenu que l'agent lit devient une entrée potentielle. Un scanner qui teste des paramètres HTTP ne voit pas qu'un PDF ou un ticket contient une instruction cachée.
• Le comportement n'est pas déterministe. Une attaque peut échouer trois fois et réussir la quatrième. Un test sérieux rejoue chaque scénario plusieurs fois et conserve toutes les sorties.
• Les permissions sont portées par l'agent. Une API parfaitement authentifiée reste dangereuse si l'agent l'appelle avec les droits d'un utilisateur à la demande d'un tiers. La faille est dans la décision, que ni le WAF ni le scanner ne voient.

Pour la différence entre les approches, voir notre article sur les différences entre audit passif et pentest. Les failles du back-end restent utiles à connaître : l'application qui entoure l'agent fait partie du périmètre de preuve, car ses endpoints sont souvent les sources et les destinations que les outils de l'agent lisent et écrivent.

Que teste-t-on sur un agent IA ?

Un red team d'agent couvre six familles de scénarios, alignées sur les catégories de l'OWASP Top 10 for LLM Applications 2025.

L'injection de prompt indirecte (LLM01)

L'attaquant dépose des instructions dans un contenu que l'agent traite : un e-mail entrant, un document partagé, une page web, un commentaire de ticket. L'agent les exécute comme s'il s'agissait d'ordres légitimes. C'est la famille la plus rentable pour un attaquant et la plus fréquente en mission. Notre page dédiée à la prompt injection détaille les variantes, et l'article sur l'injection de prompt indirecte dans les systèmes RAG montre le mécanisme sur un cas documentaire.

L'abus d'outils et de serveurs MCP

On teste ce que l'agent peut appeler, avec quels arguments, et ce qui l'empêche d'appeler un outil hors de son rôle. Pour les serveurs MCP, on vérifie aussi les descriptions d'outils (qui entrent dans le contexte du modèle), l'authentification et la portée des jetons. Voir notre page sur la sécurité MCP et l'article sur les surfaces d'attaque du function calling.

La fuite de données par appels d'outils

On cherche la chaîne complète : un contenu lu par l'agent, une action sur des données sensibles, puis un envoi vers l'extérieur (e-mail, requête HTTP, lien rendu en image, écriture dans un espace partagé). La fuite passe souvent par un canal légitime que l'agent a le droit d'utiliser. Sur ce sujet, lisez chatbots : cinq façons de fuir des données.

L'agentivité excessive (LLM06)

On compare ce que l'agent peut faire à ce dont il a besoin. L'écart (droits en écriture inutiles, outils de suppression, pas de validation humaine sur les actions sensibles) est le constat le plus fréquent d'un test d'agent.

La fuite du prompt système (LLM07)

Le prompt système contient parfois des règles métier, des identifiants d'outils ou des secrets qui n'auraient pas dû s'y trouver. On vérifie ce qui peut en être extrait, y compris par fragments, et surtout ce que cette extraction apprend à l'attaquant sur la suite.

L'isolation entre clients

Pour un agent multi-clients, on teste si un tenant peut lire ou influencer les données d'un autre : identifiants prévisibles dans les appels d'outils, paramètres d'URL qui sélectionnent le client, mémoire ou index partagés. C'est le scénario le plus coûteux commercialement quand il aboutit.

Comment se déroule une mission de red team d'agent IA ?

Une mission suit un déroulé fixe, du cadrage au re-test.

1. Cadrage (rendez-vous découverte de 30 minutes, gratuit). On identifie l'agent, ses outils, ses sources de contenu et ce qui compte vraiment pour vous : données clients, actions irréversibles, exigences d'un client qui attend un questionnaire sécurité.
2. Autorisation écrite. Aucun test ne démarre sans un document signé qui définit le périmètre, les dates, les techniques autorisées et les contacts d'urgence. Un accord verbal ne suffit pas.
3. Environnement de test. Vous fournissez un environnement que vous contrôlez, avec des comptes et des données fictives. Nous n'attaquons pas la production sans mandat explicite.
4. Reconnaissance. On cartographie les outils, les sources de contenu, l'application hôte, les identifiants exposés et le comportement des garde-fous. Cette phase est courte et ne modifie rien.
5. Attaque. On rejoue chaque scénario plusieurs fois, en commençant par ceux que la reconnaissance désigne comme les plus prometteurs, puis on enchaîne les faiblesses. Les écritures de test passent par des objets identifiables et supprimés ensuite.
6. Vérification. Chaque constat est retesté à la main. Les résultats d'un modèle sans preuve brute (requête, réponse, journal) ne sont pas retenus.
7. Rapport et restitution. Rapport court, puis échange de 30 minutes en visioconférence avec votre équipe.
8. Re-test. Une fois les corrections appliquées, on vérifie qu'elles tiennent.

Notre approche détaillée se trouve sur la page méthode.

Que contient le rapport livré ?

Le rapport contient pour chaque constat : le texte piégé utilisé, l'action tentée, la preuve qu'elle a abouti, la gravité et une piste de correction. Il comprend aussi ce qui a été testé et a résisté, information utile pour vos clients. Le format est court pour pouvoir être joint à un questionnaire sécurité (AI Act, SOC 2, ISO 27001).

Un constat typique se lit ainsi : le contenu qui contient l'instruction, l'outil appelé, les données concernées, le canal de sortie et le nombre de répétitions nécessaires. Le lecteur technique peut reproduire le scénario, le lecteur non technique comprend l'impact.

Combien coûte un red team d'agent IA et combien de temps dure-t-il ?

Le Red Team Agent Express coûte 1 900 € et dure 5 jours. Il couvre un agent, avec revue des accès, démonstrations reproductibles, test de la chaîne de fuite de données, rapport réutilisable et restitution de 30 minutes. Le démarrage a lieu sous 48 heures. TVA non applicable. Ce service est toujours payant : il n'existe pas de garantie « rien trouvé, rien payé », parce que démontrer qu'un agent résiste demande le même travail que démontrer qu'il cède.

Le Red Team sur mesure est réservé aux périmètres plus larges : plusieurs agents, serveurs MCP, livraison en marque blanche pour une agence. Il est chiffré sur devis après le rendez-vous découverte. Le détail de l'offre standard est sur la page Red Team Agent Express, et les tarifs sont résumés sur la page tarifs.

Red team d'agent, pentest classique ou scanner automatique : que choisir ?

Le choix dépend de ce que vous voulez prouver.

• Red team d'agent IA : cible le comportement du modèle, les outils et les données. Résultat : scénarios d'attaque reproductibles et preuves. À choisir quand un agent est en production ou le sera bientôt.
• Pentest classique : cible le code, l'infrastructure et l'authentification de l'application. Résultat : vulnérabilités techniques classiques. À choisir pour l'application web qui entoure l'agent.
• Scanner automatique d'injections : rejoue des bibliothèques de prompts connus. Résultat : couverture large et peu profonde, avec beaucoup de faux positifs. Utile en intégration continue, insuffisant pour juger l'impact réel.
• Revue de configuration : compare les permissions de l'agent à ses besoins. Résultat : écarts de droits. Elle fait partie du red team, mais ne prouve pas l'exploitabilité à elle seule.

Ces approches se complètent. Les benchmarks de recherche comme InjecAgent et AgentDojo montrent que des agents bien configurés se laissent encore détourner par des instructions placées dans des outils ou des données, ce qui justifie des tests au cas par cas plutôt qu'une confiance dans le modèle.

À qui s'adresse ce service ?

Il s'adresse à trois profils.

• Startups et PME avec un agent en production : équipes de 10 à 80 personnes, souvent sans équipe sécurité, dont un client demande une preuve de test.
• Agences IA qui livrent des agents : vérifier avant livraison qu'un agent résiste à ce qu'un inconnu peut lui écrire, et pouvoir joindre un rapport à la recette.
• Cabinets de pentest : renfort en marque blanche pour une mission où l'agent IA est le périmètre et où l'équipe n'a pas encore la méthode.

Si votre agent n'agit pas (il répond seulement à des questions sans outils ni données sensibles), le risque est plus faible et un test plus léger peut suffire. Le rendez-vous découverte sert aussi à le dire.

Comment préparer son agent avant un red team ?

Une bonne préparation fait gagner une journée de test. Rassemblez avant le démarrage :

• un environnement de test qui reproduit la production : mêmes outils, mêmes droits, données fictives ;
• la liste des outils de l'agent avec leurs permissions et, si possible, leurs schémas d'arguments ;
• les sources de contenu que l'agent lit (boîte de réception, base documentaire, pages web, tickets) et la façon d'y déposer un élément de test ;
• le prompt système et la description des garde-fous existants ;
• deux comptes de test appartenant à deux clients distincts, si l'agent est multi-clients ;
• un contact joignable pendant les cinq jours et la politique de journalisation que vous souhaitez.

Prévoyez aussi de désactiver les envois réels (e-mails, paiements, notifications) ou de les rediriger vers des boîtes de test.

Quelles sont les limites d'un red team d'agent IA ?

Un test dure cinq jours et ne démontre pas l'absence de faille : il documente ce qui a été tenté dans un périmètre donné. Les modèles évoluent, de nouveaux outils s'ajoutent, et un correctif de prompt peut être contourné par une formulation que le test n'a pas essayée. Retenez trois conséquences : refaire un test après un changement majeur (nouveau modèle, nouvel outil, nouvelle source de contenu), combiner le test avec des garde-fous structurels (droits minimaux, validation humaine, isolation du contenu non fiable) et conserver la journalisation des actions de l'agent.

Le Shield, la couche logicielle qui doit bloquer les actions non autorisées avant leur exécution, est en développement et n'est pas disponible aujourd'hui. Les mesures de défense décrites dans notre page sur la sécurité des agents IA s'appliquent dès maintenant avec vos moyens actuels.

Pour aller plus loin

Parlez de votre agent lors d'un rendez-vous découverte de 30 minutes, gratuit, et repartez avec un périmètre clair. Pour savoir si votre agent est déjà exposé, voir la page agent exposé. Les termes techniques sont définis dans le glossaire.

• limites d'un audit de sécurité par IA