Exemple de rapport de red team d'agent IA

À quoi ressemble un rapport de red team d'agent IA ?

Un rapport CleanIssue se lit en deux niveaux : une synthèse de deux pages pour la direction, puis des constats détaillés pour l'équipe technique. Chaque constat porte un identifiant, une gravité, un rattachement aux référentiels, une description de la preuve et une correction. Ce document suit la structure de nos modèles internes (périmètre, fiche de constats, journal d'engagement).

Avertissement : l'agent, l'entreprise, les chiffres et les dates ci-dessous sont inventés pour illustrer le format. Ils ne proviennent d'aucune mission réelle. Les étapes de reproduction restent volontairement conceptuelles.

Synthèse pour la direction : que retenir en deux minutes ?

L'agent fictif « Aïda », assistant de support client de l'entreprise imaginaire Lumen Fibre, présente un constat critique, un élevé, deux moyens et un faible. La chaîne la plus grave permet à un inconnu de faire sortir des données de clients par un simple ticket.

• Risque principal : un attaquant dépose un ticket contenant des instructions cachées. Quand Aïda le lit, elle les suit et envoie des données du CRM à une adresse externe.
• Risque financier : Aïda peut déclencher des remboursements sans validation humaine, y compris sous l'influence d'un texte malveillant.
• Bonne nouvelle : la lecture des données d'un autre client par simple demande directe est bloquée, et l'agent refuse les demandes de contournement formulées dans le chat.
• Priorité : retirer à l'agent l'envoi de messages vers des adresses libres et imposer une approbation au-delà d'un seuil de remboursement. Ces deux mesures se font en quelques jours.

Quel périmètre et quelle autorisation encadrent la mission ?

Le périmètre fixe ce que l'on peut tester, avec quels comptes et dans quelles limites. Il est signé avant le premier essai, car une autorisation orale ne suffit pas.

Le niveau d'intrusion est borné : les écritures se limitent à des objets de test identifiables, supprimés et vérifiés après coup.

Quels constats le rapport liste-t-il ?

Le tableau récapitulatif donne la vue d'ensemble avant le détail. La gravité combine l'impact (données, argent) et la facilité d'exploitation.

F-01 : comment un ticket peut-il faire sortir des données du CRM ?

Un ticket rédigé par un inconnu suffit à détourner l'agent, parce qu'Aïda traite le texte du ticket comme des consignes. C'est une injection de prompt indirecte (LLM01), qui débouche sur une fuite de données (LLM02) par un outil légitime.

Reproduction (niveau conceptuel) :

1. Le testeur ouvre un ticket depuis un compte de test. Le corps contient, en plus de la question apparente, un passage adressé au modèle lui demandant de joindre des informations de compte à un message.
2. Un agent humain de test demande à Aïda de résumer le ticket, ce qui est un usage normal.
3. L'agent lit le ticket, suit le passage caché, interroge le CRM pour le client concerné, puis appelle l'outil d'envoi d'e-mail avec une adresse choisie par le testeur.
4. Le message arrive dans une boîte de test contrôlée par l'équipe de mission.

Preuve : journal des appels d'outils montrant la séquence lecture du ticket, recherche CRM, envoi d'e-mail, avec les paramètres de l'appel et l'adresse de destination. Capture de la boîte de réception de test. Sur dix essais avec des formulations variées, l'attaque a réussi sept fois (chiffre fictif). Nous documentons un taux de réussite, parce qu'un modèle ne répond pas deux fois de la même façon.

Impact : un inconnu peut obtenir des données personnelles de clients sans compte privilégié, avec un effort minime.

Correction :

• Retirer l'envoi d'e-mail libre : restreindre les destinataires à l'adresse du client du ticket ou à une liste approuvée.
• Séparer les tâches : pendant le traitement d'un contenu externe, l'agent ne dispose pas de l'outil d'envoi.
• Journaliser chaque appel d'outil avec son origine, et alerter sur les destinations inhabituelles.
• Traiter le texte des tickets comme une donnée non fiable, sans compter sur le prompt système pour l'en protéger.

F-02 : comment l'agent peut-il rembourser sans validation ?

Aïda dispose d'un outil de remboursement sans plafond ni approbation, ce qui constitue une agentivité excessive (LLM06). Toute instruction qui parvient jusqu'au modèle, directe ou injectée, peut donc déclencher une sortie d'argent.

Reproduction (niveau conceptuel) :

1. Le testeur, depuis le chat, explique une situation plausible et réclame un geste commercial.
2. L'agent appelle l'outil de remboursement avec un montant que le testeur a suggéré, sans demander l'avis d'un humain.
3. Le même résultat est obtenu par le canal du ticket, via la chaîne de F-01.

Preuve : trace de l'appel d'outil avec le montant et l'identifiant de commande de test, et accusé de réception du système de paiement de préproduction. Aucun remboursement réel n'a eu lieu.

Correction :

• Instaurer un seuil au-delà duquel un humain approuve, et un plafond quotidien par agent.
• Faire vérifier côté serveur que la commande appartient bien au client de la conversation.
• Rendre l'opération idempotente et annulable, avec une relecture du résultat avant confirmation à l'utilisateur.
• Garder la règle dans le système qui exécute l'action, car une consigne de prompt reste contournable.

Qu'est-ce qui a résisté pendant les tests ?

Un bon rapport décrit aussi les protections qui fonctionnent, parce qu'elles orientent les priorités et rassurent sur le reste.

• Injection directe : les demandes frontales de contournement dans le chat ont été refusées de façon constante.
• Authentification des outils : les appels d'outils exigeaient un jeton valide, et les tentatives sans jeton ont échoué.
• Lecture directe d'un autre client : une demande explicite des données d'un tiers dans le chat était refusée (le constat F-03 concerne un contournement plus subtil par la recherche CRM).
• Webhook de paiement : la signature des appels entrants était vérifiée.

Quel plan de correction est proposé ?

Le plan classe les actions par urgence, avec un responsable proposé et un effort estimé.

Comment se passe le re-test ?

Le re-test rejoue les scénarios des constats corrigés pour vérifier que la correction tient. Dans cet exemple, F-01 et F-02 ont été rejoués avec les formulations d'origine et des variantes : l'envoi vers une adresse externe est refusé et le remboursement au-delà du seuil attend une approbation. F-03 reste partiellement exploitable pour un type de recherche et demeure ouvert. F-04 est accepté par le client en connaissance de cause.

Pour comprendre la démarche complète, consultez notre page sur le red teaming d'agent IA, la méthode et l'offre Red Team Agent Express, qui produit un rapport de ce format en cinq jours pour 1 900 €.