Pentest LLM
Vos équipes ont mis un modèle de langage (LLM) en production : un assistant qui interroge votre documentation, un agent qui traite des tickets ou écrit dans vos outils métier, un chatbot qui lit les pièces jointes envoyées par vos clients. Pour le modèle, vos consignes et les données qu’il reçoit sont une seule et même suite de texte — et c’est exactement là que se loge la vulnérabilité.
Le pentest LLM mesure ce qu’un attaquant obtient réellement de votre application d’intelligence artificielle : prompt injection directe et indirecte, jailbreak, fuite de données par le contexte, empoisonnement du corpus RAG, abus des outils et des serveurs MCP que l’agent peut appeler. Le référentiel est l’OWASP Top 10 for LLM Applications. Rapport en français, restitution en visioconférence, contre-audit inclus sans surcoût.
Dernière vérification des références réglementaires citées sur cette page : 11 septembre 2026.
Ils nous font confiance
Objectifs
Objectifs d’un pentest LLM
Un test d’intrusion sur une application IA ne juge pas la qualité des réponses du modèle. Il répond à une question de sécurité : qu’obtient un attaquant qui dispose du même accès qu’un de vos utilisateurs — ou simplement de la possibilité de déposer un document que votre agent va lire ?
Nous travaillons sur votre environnement réel, avec vos connecteurs et vos données. Chaque piste confirmée est exploitée puis documentée : vous recevez des chemins d’attaque reproductibles, classés selon ce qu’il faut corriger avant la mise en production et ce qui peut attendre la version suivante. Pas une liste de risques théoriques recopiée d’un référentiel.
Vérifier le cloisonnement des données
Un assistant branché sur vos documents internes finit par répondre à qui sait poser la question. Nous mesurons ce que le modèle restitue d’un contexte, d’un index RAG ou d’un historique de conversation auxquels l’utilisateur n’a pas droit.
Mesurer la résistance à la manipulation
Prompt injection directe dans le champ de saisie, injection indirecte par un document, une page web ou un message que l’agent traite, jailbreak des consignes système : nous établissons ce qui reste de vos garde-fous face à quelqu’un qui travaille sérieusement à les contourner.
Encadrer ce que l’agent peut faire
Un agent qui écrit dans votre CRM ou déclenche un virement doit agir avec les droits de l’utilisateur, jamais avec les siens. Nous testons cette excessive agency outil par outil, serveurs MCP compris.
Maîtriser le coût et la disponibilité
Une boucle d’agent mal bornée ou un contexte gonflé artificiellement transforment une attaque en facture d’inférence. Nous chiffrons le coût d’une requête abusive et nous testons vos quotas et vos alertes avant qu’un tiers ne s’en charge.
Types et périmètre
Types de pentest IA et périmètre de la mission
L’expression « pentest IA » recouvre en réalité plusieurs missions distinctes, et la demi-heure de cadrage sert d’abord à décider laquelle vous achetez. Trois périmètres reviennent dans la quasi-totalité des projets, et ils se combinent le plus souvent.
L’application conversationnelle. Un chatbot public, un assistant interne, un copilote intégré à un produit SaaS. Le périmètre couvre la consigne système, la mémoire de conversation, les filtres d’entrée et de sortie, et tout ce que l’utilisateur parvient à faire remonter dans le contexte. C’est le périmètre le plus court, et celui où la prompt injection directe et le jailbreak se démontrent le plus vite.
Le pipeline RAG. Dès que le modèle interroge une base documentaire, la sécurité devient une question de droits. Qui peut alimenter l’index : un document déposé par un client, une page intranet, un ticket de support y entrent-ils sans relecture ? La récupération applique-t-elle les autorisations de l’utilisateur au moment de la recherche, ou seulement à l’affichage ? Un corpus empoisonné (data poisoning) suffit à faire dire au modèle ce que l’attaquant y a écrit, sans jamais toucher au modèle lui-même.
Les agents, les outils et les serveurs MCP. Le périmètre le plus récent et le plus sensible. Un agent qui appelle des fonctions, exécute du code, lit une boîte aux lettres ou écrit dans un système métier ouvre un chemin d’attaque à part entière. Le Model Context Protocol (MCP) a standardisé cette connexion : un serveur MCP mal cloisonné expose ses outils à tout ce qui sait parler au modèle. Nous testons chaque outil isolément, puis l’enchaînement complet, en cherchant l’écart entre ce que l’utilisateur a le droit de faire et ce que l’agent fait à sa place.
Deux périmètres s’y ajoutent selon les projets : la chaîne d’approvisionnement des modèles — provenance des poids, modèles et adaptateurs téléchargés depuis un dépôt public, formats de sérialisation qui exécutent du code au chargement — et l’application classique qui entoure l’assistant, avec son authentification, sa base de données et son API (voir notre pentest web et API). Dans une bonne part des missions, la vulnérabilité la plus grave n’est pas une attaque sur le modèle : c’est un contrôle d’accès manquant sur l’API qui le sert.
Couverture
Ce que nous testons dans vos intégrations IA
La couverture va du modèle jusqu’aux journaux : les données qui entrent, les outils qui sont appelés en sortie, et tout ce qui devrait borner l’un et l’autre.
Intégrations LLM
OpenAI et Azure OpenAI, Anthropic, Google Vertex AI, Mistral, Llama et modèles que vous hébergez vous-même. Nous testons votre intégration et la façon dont vous appelez le modèle, pas le modèle du fournisseur.
Pipeline RAG
Ingestion, découpage, indexation, base vectorielle, récupération et reclassement. Deux questions : qui peut écrire dans l’index, et celui-ci rend-il des documents que l’auteur de la question n’a pas le droit de lire ?
Agents, outils et serveurs MCP
Function calling, tool use, orchestration multi-étapes, extensions et serveurs MCP. Nous cherchons l’excessive agency : l’outil qui s’exécute avec plus de droits que l’utilisateur qui l’a déclenché.
API, identité et quotas
OAuth2/OIDC, clés d’API, propagation de l’identité lorsque le modèle agit au nom d’un utilisateur, limitation de débit et webhooks. C’est aussi ici que se joue le déni de service économique.
Consigne système et garde-fous
Instructions système, filtres d’entrée et de sortie, modération, règles métier. Nous mesurons ce qu’il en reste face à un jailbreak construit pour votre cas d’usage, et si la consigne elle-même finit par fuir.
Journalisation et détection
Ce que vous conservez des prompts et des réponses, ce qui déclenche une alerte, et si un abus se remarque avant que la facture d’inférence ne l’annonce. Les journaux de prompts contiennent presque toujours des données personnelles : nous le signalons au regard du RGPD.
Scénarios d’attaque
Les attaques que nous rejouons sur votre application
Notre grille de lecture est l’OWASP Top 10 for LLM Applications, complétée par les scénarios que nous observons sur les missions réelles. Chaque technique ci-dessous est rejouée sur votre environnement, avec une preuve d’exploitation reproductible.
Prompt injection directe
L’utilisateur écrit lui-même l’instruction qui détourne le modèle : contournement de la consigne système, extraction de cette consigne, obtention d’un comportement explicitement interdit. Le point de départ de presque toutes les missions.
Prompt injection indirecte
L’instruction est dissimulée dans une donnée que le modèle lira plus tard : un PDF déposé par un client, une page web consultée par l’agent, la signature d’un courriel, un ticket de support. L’attaquant n’a jamais eu accès à votre interface.
Jailbreak des garde-fous
Jeux de rôle, encodages, langues alternatives, conversations longues qui érodent la consigne : nous mesurons combien de tentatives séparent votre filtre d’une réponse qu’il devait bloquer.
Fuite de données par le contexte
Documents d’un autre client remontés par le RAG, historique de conversation d’un tiers, secrets présents dans la consigne système, données personnelles réinjectées dans une réponse. Une fuite de données personnelles constitue une violation au sens du RGPD.
Empoisonnement du corpus (data poisoning)
Nous vérifions si un contenu contrôlé par un tiers peut entrer dans l’index RAG ou dans un jeu de réglage, et ce qu’il devient : réponse falsifiée servie à tous vos utilisateurs, lien malveillant recommandé, instruction persistante.
Excessive agency et abus d’outils
L’agent appelle un outil que l’utilisateur n’aurait pas le droit d’invoquer, écrit dans un système métier, envoie un message en votre nom, ou enchaîne deux outils pour produire un effet qu’aucun des deux n’autorisait séparément.
Serveurs MCP et extensions
Outils exposés sans contrôle d’accès, description d’outil piégée, jeton partagé entre tous les utilisateurs, serveur tiers ajouté sans revue. Un serveur MCP est une surface d’attaque au même titre qu’une API.
Déni de service économique
Boucles d’agent non bornées, contexte gonflé, appels d’outils en cascade : l’attaque ne fait pas tomber le service, elle fait exploser vos coûts d’inférence. Nous chiffrons le coût d’une requête abusive et nous testons vos plafonds.
Chaîne d’approvisionnement des modèles
Provenance des poids, modèles et adaptateurs récupérés sur un dépôt public, formats de sérialisation qui exécutent du code au chargement, et model extraction lorsque votre modèle ajusté est un actif à protéger.
Approches
Approches : boîte noire, boîte grise, boîte blanche
Les trois approches ne répondent pas à la même question. Sur une application IA, la différence tient à ce que vous nous remettez au départ : une simple interface, des comptes de test et la consigne système, ou l’ensemble du code d’orchestration et la configuration des outils.
Dans la quasi-totalité des missions IA, nous recommandons la boîte grise. La consigne système et la liste des outils exposés valent plusieurs jours de devinette : à charge égale, nous consacrons ce temps à construire des chaînes d’attaque au lieu de cartographier une interface.
Boîte noire (black box)
Nous ne disposons que de l’interface, comme un utilisateur anonyme ou un client parmi d’autres. Utile pour mesurer ce qui est exposé publiquement et pour tester la prompt injection depuis l’extérieur ; insuffisant pour couvrir les outils qu’un agent peut appeler et les droits qui s’y attachent.
Boîte grise (grey box)
Notre approche par défaut. Vous nous remettez un compte par rôle, la consigne système, la liste des outils et la description du pipeline RAG. Nous ciblons directement les écarts d’autorisation, les chemins entre outils et les documents que l’index ne devrait pas rendre.
Boîte blanche (white box)
Nous ajoutons le code d’orchestration, les définitions de fonctions, la configuration des serveurs MCP et les règles de filtrage. Indiquée avant la mise en production d’un agent doté de droits d’écriture, ou lorsque l’application traite des données de santé ou des paiements.
Méthodologie
Notre méthodologie et le déroulement de la mission
Le référentiel principal est l’OWASP Top 10 for LLM Applications. Il est complété par le guide OWASP WSTG pour l’application et les API qui entourent le modèle, par le MASTG lorsque l’assistant est embarqué dans une application mobile, et par le cadre PTES pour la conduite générale de la mission. Ces référentiels sont publics : vous vérifiez point par point ce qui a été couvert. Nos méthodologies de test sont détaillées sur le site, notamment le guide OWASP WSTG.
Une partie du travail est outillée — jeux d’attaques automatisés couvrant plusieurs centaines de variantes de prompts, fuzzing des points d’entrée. Aucune vulnérabilité n’entre pourtant dans le rapport sans avoir été reproduite à la main : sur un système probabiliste, un outil produit un taux de faux positifs qu’aucun rapport sérieux ne peut assumer, et chaque constat est rejoué au minimum trois fois pour établir sa reproductibilité.
Cadrage
Nous fixons le périmètre : quels modèles, quels index RAG, quels outils et serveurs MCP entrent dans la mission, quels comptes nous sont remis, et jusqu’où nous pouvons aller sur un environnement qui écrit dans vos systèmes. Nous convenons aussi d’un plafond de requêtes, afin qu’aucun test ne se traduise par une facture d’inférence imprévue. Tous nos tests d’intrusion sont réalisés sur mandat écrit, dans un périmètre défini contractuellement (articles 323-1 et suivants du code pénal). Vous recevez un prix ferme avant le démarrage.
Modélisation des menaces
Nous cartographions les flux : d’où vient chaque élément de contexte, qui peut l’alimenter, quelle identité porte chaque appel d’outil et où passe la frontière de confiance. C’est cette étape qui sépare un pentest IA d’un test applicatif ordinaire.
Tests manuels et scénarios d’attaque
Prompt injection directe et indirecte, jailbreak, extraction de la consigne système, empoisonnement de l’index, abus d’outils et d’agents, model extraction, déni de service économique. Chaque piste confirmée est exploitée jusqu’à établir son impact réel.
Tests de l’application et des API
Authentification, gestion de session, contrôle d’accès, injections côté serveur, exposition des clés d’API : la couche classique sous l’assistant, testée selon l’OWASP WSTG. C’est encore là que se trouvent les vulnérabilités les plus graves dans une bonne part des missions IA.
Rapport, restitution et contre-audit
Vous recevez le rapport en français, puis une restitution en visioconférence animée par les personnes qui ont réalisé les tests. Après vos correctifs, nous revérifions chaque constat : le contre-audit est inclus dans le prix, sous 90 jours après la remise du rapport.
Comparaison
Pentest LLM ou pentest applicatif classique ?
Un pentest LLM traite des menaces qu’un test applicatif classique ne couvre pas. Dans la plupart des projets, les deux sont nécessaires : autour du modèle subsistent une application web, une authentification, une base de données et une API.
| Aspect | Pentest LLM et IA | Pentest applicatif classique |
|---|---|---|
| Objet du test | Consigne système, agents, pipeline RAG, outils et serveurs MCP. | Couches web, mobile et dorsale. |
| Menaces typiques | Prompt injection, jailbreak, fuite par le contexte, data poisoning, excessive agency. | Injection SQL, XSS, CSRF, contournement d’authentification. |
| Référentiel | OWASP Top 10 for LLM Applications et modélisation des menaces sur mesure. | OWASP WSTG et techniques d’exploitation établies. |
| Nature des constats | Comportement probabiliste : chaque constat est rejoué plusieurs fois pour établir sa reproductibilité. | Comportement déterministe : une preuve d’exploitation suffit. |
| Correctifs attendus | Autorisation des outils, cloisonnement de l’index, filtrage des sorties, plafonds de consommation. | Correctifs applicatifs et durcissement de la configuration. |
Vous ne savez pas quel périmètre correspond à votre application ? Demandez un devis : nous proposons le périmètre au moment du cadrage. Voir aussi notre audit de vulnérabilités pour l’infrastructure qui héberge vos modèles.
Livrables : rapport, restitution et contre-audit
Vous n’achetez pas un fichier PDF, vous achetez de quoi décider et de quoi corriger. Un exemple de rapport anonymisé est disponible avant signature, afin que vous sachiez exactement ce que vous recevrez.
Rapport technique en français
Chaque vulnérabilité avec sa preuve d’exploitation, la conversation ou la charge utile exacte qui la déclenche, sa notation CVSS, la catégorie OWASP LLM concernée et les étapes de reproduction.
Synthèse managériale
Deux pages pour votre comité de direction : niveau de risque, ce qui bloque une mise en production, ce qui peut attendre, et la charge de remédiation estimée.
Restitution en visioconférence
Une séance avec les pentesteurs qui ont conduit la mission et vos développeurs. Nous rejouons les attaques à l’écran : une prompt injection indirecte se comprend bien plus vite en direct que dans un paragraphe.
Contre-audit inclus
Après correction, nous revérifions chaque constat et publions une version actualisée du rapport. Inclus dans le prix, sous 90 jours après la remise du rapport.
Ce que comprend chaque pentest LLM
Quel que soit le périmètre retenu, chaque mission comprend :
Pourquoi Haxoris
Haxoris est un prestataire européen, établi dans l’Union européenne : vos prompts, vos documents, vos rapports et les preuves d’exploitation restent dans l’UE, et le RGPD s’applique directement à ce traitement, sans exposition au Cloud Act. Nous ne détenons aucune qualification délivrée par une autorité publique française et nous ne le laissons pas entendre. Ce que nous mettons à la place tient en trois points, tous vérifiables avant la signature.
Contre-audit inclus, sans surcoût
La revérification de vos correctifs fait partie du prix, sous 90 jours après la remise du rapport. Ce n’est ni une journée facturée en supplément, ni une option de la proposition.
Nos tarifs sont publics
Notre grille de prix et notre taux journalier sont publiés : vous comparez avant même de nous appeler, et le prix ferme remis au cadrage ne bouge plus. Le détail figure dans notre article sur le prix d’un test d’intrusion.
Témoignages clients
Ce que nos clients disent de nous
Pentest LLM : foire aux questions
01 Combien coûte un pentest LLM ?
Le prix suit le périmètre : nombre d’intégrations, présence d’agents disposant de droits d’écriture, taille et sensibilité de l’index RAG, inclusion ou non de l’application et des API qui entourent le modèle. Un assistant conversationnel délimité, sans outil ni RAG, démarre autour de 3 000 € HT. Une plateforme à base d’agents, avec serveurs MCP et pipeline RAG, se situe le plus souvent entre 8 000 et 20 000 € HT.
Après un échange de cadrage d’une trentaine de minutes, vous recevez un prix ferme pour l’ensemble de la mission, contre-audit compris. Le détail de notre grille figure dans l’article consacré au prix d’un test d’intrusion (pentest).
02 Combien de jours-homme faut-il prévoir ?
Un chatbot sans outil ni base documentaire se teste en 3 à 5 jours-homme. Une application dotée d’un pipeline RAG, de plusieurs rôles et de quelques outils en lecture demande 6 à 10 jours-homme. Un agent qui écrit dans des systèmes métier, ou une architecture multi-agents reposant sur des serveurs MCP, dépasse fréquemment 12 jours-homme — auxquels s’ajoute le test de l’application classique si vous l’incluez dans le périmètre.
Nous préférons annoncer une charge réaliste plutôt qu’un forfait court : un périmètre sous-évalué produit un rapport rassurant et faux.
03 Boîte noire ou boîte grise : que choisir ?
La boîte grise, dans la quasi-totalité des cas. En boîte noire, une part du budget passe à deviner la consigne système, la liste des outils et la structure de l’index : autant de jours qui ne servent pas à chercher des vulnérabilités. Avec la consigne système, la description des outils et un compte par rôle, la même charge couvre nettement plus de chemins d’attaque.
La boîte noire conserve son intérêt lorsque la question posée est précisément : « que peut faire un attaquant qui ne dispose que de l’interface publique ? » La boîte blanche s’impose avant la mise en production d’un agent doté de droits d’écriture, ou lorsque l’application traite des données de santé ou des paiements.
04 Testez-vous le modèle lui-même ou notre intégration ?
Votre intégration. Nous n’auditons pas les modèles d’OpenAI, d’Anthropic, de Google ou de Mistral : leurs conditions d’utilisation l’encadrent strictement, et ce n’est pas là que se situe votre risque. Nous testons la façon dont vous appelez le modèle, ce que vous lui donnez en contexte, ce que vous l’autorisez à faire et ce que votre application fait de ses réponses.
Si vous hébergez un modèle en propre — Llama, Mistral, un modèle ajusté sur vos données —, le périmètre s’étend à son hébergement, à son exposition réseau, à la chaîne d’approvisionnement des poids et au risque de model extraction.
05 Le contre-audit est-il inclus ?
Oui, et sans surcoût. Après vos correctifs, nous rejouons chaque constat et publions une version actualisée du rapport précisant ce qui est corrigé, ce qui est atténué et ce qui reste ouvert. Le contre-audit est compris dans le prix initial, sous 90 jours après la remise du rapport.
Sur une application IA, ce point compte davantage qu’ailleurs : une correction apportée à une consigne système ou à un filtre de sortie se contourne très souvent par une formulation voisine.
06 Faut-il un prestataire qualifié pour réaliser ce test ?
Non, pas pour un test commandé par une entreprise privée. Les qualifications délivrées par l’ANSSI relèvent d’une démarche volontaire instituée par le décret n° 2015-350 du 27 mars 2015 ; elles ne conditionnent pas la réalisation d’un test d’intrusion pour un donneur d’ordre privé. Haxoris ne détient aucune qualification de ce type et ne s’en prévaut pas.
En revanche, les contrôles des systèmes d’information d’importance vitale ordonnés au titre de l’article L. 1332-6-3 du code de la défense sont réalisés par l’ANSSI, par des services de l’État désignés par le Premier ministre, ou par des prestataires de service qualifiés : nous ne soumissionnons pas sur ces prestations. Nous développons ce point dans un article dédié.
07 Ce test entre-t-il dans une démarche RGPD ou dans le règlement européen sur l’IA ?
L’article 32, paragraphe 1, point d) du RGPD prévoit « une procédure visant à tester, à analyser et à évaluer régulièrement l’efficacité des mesures techniques et organisationnelles » de sécurité. Si votre application IA traite des données personnelles — et un assistant interne en traite presque toujours —, elle relève de cette obligation, et un test d’intrusion est la façon usuelle de la documenter. Le règlement (UE) 2024/1689 sur l’intelligence artificielle impose par ailleurs, à son article 15, des exigences d’exactitude, de robustesse et de cybersécurité aux systèmes d’IA à haut risque.
Nous ne délivrons ni certification ni attestation de conformité : nous produisons les preuves techniques sur lesquelles votre démarche s’appuie. Dernière vérification : 11 septembre 2026.
