Test d’intrusion d’un agent IA : ce que couvre un pentest de chatbot ou d’application LLM

Un test d’intrusion d’agent IA est une attaque autorisée et encadrée contre un assistant, un chatbot ou une application LLM qui lit des données et agit par des outils. Il vérifie qu’un texte hostile glissé dans un e-mail, un document ou une page web ne peut pas déclencher une action que personne n’a validée. Cette page s’adresse à celui qui doit acheter ce test : elle décrit le contenu, le périmètre, le cadre légal, les livrables et les questions à poser. Pour la vue d’ensemble de la discipline, voir le pilier red team d’agent IA.

Que couvre un test d’intrusion d’agent IA ?

Il couvre le chemin complet entre une donnée non fiable et une action sensible. Le testeur ne s’arrête pas à la phrase de refus du modèle : il cherche ce que l’agent fait réellement quand on le manipule.

Les familles de tests habituelles :

• Injection de prompt directe et indirecte : instructions cachées dans un e-mail, un PDF, un ticket, une fiche produit ou une page web que l’agent lit. Voir la prompt injection et la référence OWASP LLM01.
• Excès d’autonomie : l’agent peut envoyer un e-mail, écrire dans un CRM, déclencher un remboursement ou modifier un accès sans validation humaine (OWASP LLM06, Excessive Agency).
• Fuite de données par les outils : un appel d’outil exfiltre des informations vers une adresse choisie par l’attaquant, ou l’agent révèle des données d’un autre utilisateur.
• Fuite du prompt système et des secrets présents dans le contexte (LLM07).
• Empoisonnement des sources RAG : un document ajouté à la base de connaissances change le comportement de l’agent (LLM04 et LLM08).
• Outils et serveurs MCP : description d’outil piégée, permissions trop larges, absence d’authentification. Voir la sécurité MCP.
• Isolation entre clients : un tenant peut-il atteindre les conversations ou les documents d’un autre ?

Les identifiants de risques viennent de l’OWASP Top 10 for LLM Applications 2025. La technique d’injection correspond à MITRE ATLAS AML.T0051.

En quoi un pentest d’agent IA diffère-t-il d’un pentest web ?

Un pentest web teste du code déterministe, alors qu’un pentest d’agent teste un système qui décide à partir de texte. Le même message peut réussir une fois sur trois : il faut répéter les essais, varier les formulations et documenter un taux de réussite plutôt qu’un simple « oui » ou « non ».

Trois différences concrètes :

• La surface d’entrée est tout ce que l’agent lit. Un champ de formulaire est une entrée, mais un e-mail reçu, un commentaire de pull request ou un document indexé en sont aussi.
• L’impact se mesure aux outils. Une injection sans outil produit une mauvaise réponse. Une injection avec un outil d’envoi de mail ou d’écriture produit un incident.
• Les correctifs sont d’une autre nature. On corrige par la réduction des droits, la validation humaine des actions sensibles et le filtrage des flux, plus rarement par un patch de code.

Le tableau suivant met en regard les deux types de test.

Que couvre encore un pentest web classique ?

Il reste nécessaire : l’agent s’appuie sur une application web, des API et une infrastructure qui ont leurs propres failles. Authentification, contrôle d’accès, injections SQL, SSRF, secrets exposés et configuration du cloud relèvent d’un pentest web ou d’API, et un test d’agent ne les remplace pas.

Dans le test d’agent, ces sujets sont hors périmètre par défaut, sauf s’ils servent de point d’appui pour atteindre l’agent. Les deux missions se complètent. Si votre application a déjà été auditée côté web, le test d’agent teste ce que cet audit n’a pas regardé : la couche de décision du modèle et ses outils. Pour la différence entre un audit passif et un vrai test, voir audit passif et pentest.

Quel périmètre faut-il préparer ?

Un bon périmètre tient sur une page. Avant le rendez-vous découverte, rassemblez cette liste :

• L’agent : nom, cas d’usage, modèle utilisé, canaux d’accès (chat, API, e-mail, voix).
• Les outils : liste complète avec leurs droits (lecture, écriture, envoi, paiement, suppression).
• Les serveurs MCP consommés ou exposés, et leur mode d’authentification.
• Les sources de données : base RAG, pièces jointes, pages web, tickets, e-mails entrants.
• L’authentification : comment l’agent connaît l’utilisateur, quels jetons il porte, avec quels droits.
• Les tenants : un seul client ou plusieurs, et comment l’isolation est assurée.
• L’environnement de test : préproduction ou instance dédiée, comptes de test, jeu de données fictif.
• Les exclusions : production, déni de service, ingénierie sociale sur vos équipes.

En cas de doute sur la taille de l’agent, le plus simple est de lister les outils : leur nombre et leur sensibilité fixent l’effort de test.

La liste de cadrage tient dans ce tableau, à remplir avant le rendez-vous découverte.

Quelles règles d’engagement faut-il fixer ?

Aucun test ne commence sans autorisation écrite du propriétaire du système. En France, accéder ou se maintenir frauduleusement dans un système de traitement automatisé de données est puni par les articles 323-1 et suivants du Code pénal, jusqu’à trois ans d’emprisonnement et 100 000 € d’amende pour l’accès frauduleux simple, davantage si des données sont modifiées ou si le système est altéré. Une autorisation verbale ne suffit pas.

Le cadre se règle par écrit :

• Autorisation signée par le propriétaire du système, avec périmètre, dates et contacts d’urgence. Si l’agent est hébergé ou construit par un tiers, l’accord du tiers peut être nécessaire.
• Environnement de test de préférence, jamais de modification de données réelles de production.
• Données fictives : comptes et contenus de test créés pour la mission, sans donnée personnelle réelle. Si une donnée réelle devient lisible, on constate l’accès, on le consigne sans la copier et on s’arrête.
• Confidentialité : le rapport est confidentiel et aucune donnée n’est conservée après la mission.
• Nettoyage : comptes de test, jetons et artefacts supprimés en fin de mission.

Cette description est une pratique de mission et non un avis juridique. Faites valider la lettre d’autorisation par votre conseil si votre contexte est particulier.

Quels livrables attendre d’un test d’agent ?

Un rapport avec preuves, que votre équipe peut rejouer. Chaque constat décrit l’entrée hostile utilisée, le chemin suivi par l’agent, l’action obtenue et l’impact, avec une gravité argumentée.

Le rapport contient en général :

• un résumé pour la direction, lisible sans connaissance technique ;
• la liste des constats avec preuves reproductibles ;
• la correspondance avec les risques OWASP LLM concernés ;
• des pistes de correction priorisées (droits des outils, validation humaine, filtrage) ;
• la liste de ce qui a résisté, qui est un livrable à part entière.

Une restitution de 30 minutes avec votre équipe est incluse. Un contre-test après correction est possible en option. La méthode est détaillée sur la page méthode.

Combien de temps dure la mission ?

Le Red Team Agent Express dure cinq jours pour un agent. Le délai court de la signature de l’autorisation à la remise du rapport, avec le cadrage au début et la restitution à la fin. Le démarrage a lieu une fois le devis, l’acompte et l’autorisation écrite en place.

Pour un périmètre plus large (plusieurs agents, serveurs MCP, plusieurs environnements), la durée dépend du devis. Prévoyez aussi un délai de votre côté pour fournir les accès de test.

Combien coûte un test d’intrusion d’agent IA ?

Le Red Team Agent Express coûte 1 900 €, à prix fixe, pour un agent en cinq jours. Il est toujours payant : il n’existe pas de garantie « rien trouvé, rien payé », car un rapport qui documente ce qui a résisté a une valeur.

Au-delà d’un agent, le Red Team sur mesure est chiffré sur devis selon le nombre d’agents, leur complexité, le nombre de serveurs MCP et d’environnements, et l’option de contre-test. Le détail est sur la page tarifs. Le premier contact est un rendez-vous découverte de 30 minutes, gratuit.

Comment choisir un prestataire de test d’agents IA ?

Choisissez celui qui peut montrer sa méthode, ses preuves et ses limites. Le marché est récent, et un bon prestataire répond sans détour à ces questions :

• Quelle méthode appliquez-vous ? Elle doit citer des référentiels (OWASP LLM Top 10 2025, MITRE ATLAS, OWASP MCP) et décrire des phases.
• Testez-vous les outils et les actions, ou seulement les réponses du modèle ? Un test limité aux « jailbreaks » ne mesure pas l’impact réel.
• Comment gérez-vous les résultats non déterministes ? Réponse attendue : essais répétés et taux de réussite.
• Que contient le rapport ? Demandez un extrait anonymisé de la structure.
• Quelles sont les règles d’engagement ? Autorisation écrite, données fictives, aucune conservation.
• Comment sont comptés les faux positifs ? Un prestataire sérieux rejoue chaque constat avant de le livrer.
• Que se passe-t-il si rien n’est trouvé ? La bonne réponse est un rapport sur ce qui a résisté.

Pour connaître l’exposition de votre propre agent avant tout contact, un test rapide existe sur la page agent exposé.