Pentest agents IA : comment tester la sécurité de vos LLM en production
OWASP Top 10 agents IA 2026, prompt injection, Zero Trust - la méthodologie complète pour PME
Retour d'expérience 2LKATIME - Red Team IA certifiés OSCP/OSEP
Cet articlé est basé sur nos missions de pentest IA réalisées en 2025-2026 sur des stacks LLM en production chez des PME et ETI françaises. Nos auditeurs combinent 16+ ans d'expérience en tests d'intrusion traditionnels et une expertise spécialisée sur les architectures agentiques, les vecteurs d'attaque LLM et le framework OWASP Top 10 pour agents IA.
83% des entreprises qui déploient des agents IA en production n'ont jamais réalisé de test de sécurité spécifique à ces systèmes. Pourtant, les vecteurs d'attaque sur les LLM sont radicalement différents de ceux des applications classiques : un agent IA peut être manipulé via ses propres entrées textuelles, exploité à travers les outils qu'il contrôle, ou retourné contre votre infrastructure sans qu'aucun pare-feu ne détecte quoi que ce soit. L'OWASP a publié en 2026 son Top 10 spécifique aux applications agentiques - et la majorité des vulnérabilités listées sont activement exploitées.
Ce guide vous explique pourquoi les méthodes de pentest classiques ne suffisent pas pour auditer un LLM, quelles sont les 10 vulnérabilités OWASP agents IA les plus critiques, comment nous conduisons concrètement un pentest IA chez 2LKATIME, et ce que vous devez corriger en priorité si vous avez des agents en production aujourd'hui.
1. Pourquoi les LLM créent une surface d'attaque inédite
Un pentest réseau classique cherche des portes mal fermées : ports ouverts, services vulnérables, mauvaises configurations. Un pentest LLM cherche quelque chose de fondamentalement différent : comment convaincre un système intelligent de faire ce qu'il ne devrait pas faire, en utilisant son propre langage.
Les LLM en production ont trois caractéristiques qui créent des vulnérabilités spécifiques. Premièrement, ils sont non-déterministes : la même entrée peut produire des sorties différentes, ce qui rend les tests exhaustifs impossibles et les comportements malveillants difficiles à détecter de manière systématique. Deuxièmêment, ils sont connectés : la plupart des agents IA disposent d'outils (recherche web, exécution de code, accès aux APIs internes, lecture de fichiers) qui transforment une manipulation textuelle en action réelle sur vos systèmes. Troisièmêment, ils font confiance au contenu qu'ils traitént : un agent qui résume des emails peut être manipulé par un email malveillant contenant des instructions cachées.
83%
des agents IA jamais pentestés
10
vulnérabilités OWASP agents 2026
#1
vecteur : prompt injection indirecte
0
pare-feu classique ne détecte ces attaques
La distinction entre pentest classique et pentest LLM est aussi importante que la distinction entre un test d'effraction physique et un audit de manipulation sociale. Les outils sont différents, les compétences requises sont différentes, et les vulnérabilités trouvées sont différentes. Une entreprise qui a réalisé un pentest réseau complet l'année dernière peut avoir ses agents IA totalement exposés.
NIS2 et l'AI Act imposent tous deux une évaluation de sécurité des systèmes IA en production. Notre articlé sur les obligations NIS2 pour les PME françaises détaille comment le pentest IA s'intègre dans votre démarche de conformité réglementaire.
2. OWASP Top 10 agents IA 2026 : les vulnérabilités critiques
L'OWASP a publié en 2026 une liste dédiée aux applications agentiques, distincte du Top 10 LLM classique. Elle reflète l'évolution des architectures : les agents ne sont plus de simples chatbots, ce sont des systèmes autonomes capables d'enchaîner des actions complexes sur vos infrastructures.
| Rang | Vulnérabilité | Criticité | Impact concret |
|---|---|---|---|
| 1 | Prompt injection indirecte | Critique | L'agent exécute des instructions malveillantes cachées dans des données externes (emails, fichiers, pages web) |
| 2 | Exécution non autorisée d'outils | Critique | L'agent utilise ses outils connectés (API, BDD, shell) au-delà de ses permissions légitimes |
| 3 | Confiance implicite inter-agents | Critique | Dans un système multi-agents, un agent compromis peut piloter les autres sans re-validation des droits |
| 4 | Fuite via la mémoire persistante | Haute | Des données sensibles stockées dans le contexte ou la mémoire longue terme de l'agent sont extraités |
| 5 | Détournement d'objectif | Haute | L'agent est manipulé pour poursuivre un objectif différent de sa mission définie (goal hijacking) |
| 6 | Supply chain IA compromise | Haute | Le modèle de basé, un plugin ou une dépendance IA est empoisonné avant votre déploiement |
| 7 | Escalade de privilèges via LLM | Haute | Un utilisateur non autorisé obtient des droits élevés en manipulant l'agent comme intermédiaire |
| 8 | Absence de traçabilité | Moyenne | Impossible de reconstituer la chaine d'actions de l'agent après un incident (non-conformité NIS2) |
| 9 | Comportements émergents non anticipés | Moyenne | L'agent développe des comportements inattendus lors de combinaisons d'outils ou de contextes complexes |
| 10 | Extraction du modèle ou du prompt système | Moyenne | Un attaquant reconstitue votre prompt système ou les données d'entraînement via des requêtes ciblées |
Dans notre expérience terrain, les vulnérabilités 1, 2 et 3 sont présentes dans la quasi-totalité des déploiements d'agents IA que nous auditons. La prompt injection indirecte est particulièrement insidieuse : elle ne nécessite aucun accès direct au système. Un attaquant peut placer des instructions malveillantes dans une page web que votre agent va consulter, dans un email qu'il va traitér, ou dans un document qu'il va analyser.
3. Méthodologie de pentest LLM : comment nous procédons chez 2LKATIME
Notre approche de pentest IA combine les techniques de red team classique avec des méthodes spécifiques aux LLM. Voici les 5 phases de notre méthodologie, appliquée aux PME qui déploient des agents IA en production à Paris, Lyon et Toulouse.
Cartographie de la surface d'attaque IA
Inventaire complet de votre stack : quels modèles, quels outils connectés, quelles APIs, quels flux de données entrants et sortants. Identification des points d'entrée possibles pour une injection (formulaires, emails traités, documents ingérés, API externes). Revue des permissions accordées à chaque agent et de la configuration du prompt système.
Tests de prompt injection directe et indirecte
Tentatives d'injection via toutes les entrées identifiées : prompts utilisateur, données RAG, outils de recherche, fichiers traités. Test de contournement des garde-fous du modèle (jailbreak). Simulation d'attaques via contenu externe contrôlé par l'attaquant : pages web, emails, documents PDF. Evaluation de la robustesse du prompt système face aux tentatives de remplacement.
Audit des outils et des permissions
Test de chaque outil accèssible par l'agent : peut-il être utilisé au-delà de son périmètre prévu ? Un outil de recherche peut-il lire des fichiers système ? Un outil d'envoi d'email peut-il être utilisé pour exfiltrer des données ? Vérification du principe du moindre privilège sur chaque intégration API. Test des scénarios d'escalade de privilèges via l'agent comme intermédiaire.
Tests multi-agents et chaine de confiance
Si votre architecture comporte plusieurs agents en interaction, nous testons les vecteurs de compromission en cascade. Un agent orchestrateur compromis peut-il piloter les agents subordonnés sans re-validation ? Les tokens d'authentification inter-agents sont-ils correctement isolés ? La journalisation permet-elle de retracer l'origine d'une action dans une chaine d'agents ?
Rapport et plan de remédiation priorisé
Livraison d'un rapport détaillé avec chaque vulnérabilité identifiée, son score de criticité adapté au contexte IA (inspiré du CVSS mais ajusté pour les LLM), une preuve de concept documentée et une recommandation de correction concrète. Le plan de remédiation est priorisé par criticité et estimé en charge de correction.
4. Zero Trust pour agents IA : le principe que tout le monde oublie
Le Zero Trust est un principe bien établi en sécurité réseau : ne jamais faire confiance implicitement, toujours vérifier. Son application aux agents IA est pourtant quasi absente des déploiements que nous auditons. Voici la différence concrète entre une architecture agentique sécurisée et une architecture exposée.
Architecture Zero Trust agents IA
- - Chaque requête inter-agents est authentifiée indépendamment
- - Les tokens API sont liés à une intention signée et limitée dans le temps
- - Si l'agent A demande à l'agent B d'agir, B re-valide les droits de l'utilisateur d'origine
- - mTLS entre tous les composants de l'architecture agentique
- - Journalisation structurée de chaque action avec attribution utilisateur
- - Principe du moindre privilège sur chaque outil et chaque API
- - Sandbox d'exécution pour les outils a risque (shell, code interpreter)
Architecture exposée - ce qu'on trouve en audit
- - Token API unique partagé entre tous les agents
- - Agents qui se font confiance mutuellement par défaut
- - Permissions larges "pour simplifier" (accès lecture/écriture global)
- - Logs inexistants ou non structurés sur les actions des agents
- - Prompt système exposé via requêtes d'extraction simples
- - Aucun garde-fou sur le volume ou le type d'actions exécutables
- - Données sensibles accèssibles sans filtrage au modèle
La mise en oeuvre du Zero Trust pour agents IA ne requiert pas de refonte complète de votre architecture. Dans la plupart des cas, les corrections prioritaires peuvent être appliquées en quelques jours : isolation des tokens, mise en place des logs structurés, révision des permissions par outil. C'est ce que nous faisons systématiquement dans la phase de remédiation post-audit.
Notre articlé sur la responsabilité en cas d'incident avec des agents IA autonomes détaille les implications juridiques et contractuelles d'un agent IA non sécurisé. La combinaison pentest + qualification juridique est l'approche que nous recommandons.
5. Ce que vous devez corriger en priorité si vous avez des agents en production
Si vous ne pouvez pas réaliser un pentest complet immédiatement, voici les 5 actions à haute valeur que vous pouvez implémenter cette semaine pour réduire significativement votre surface d'attaque LLM.
Activer la journalisation structurée sur tous vos agents
Chaque action de l'agent doit être loguée : requête entrante, outils utilisés, résultat produit, utilisateur source. Sans logs structurés, vous ne pouvez ni détecter une attaque en cours ni reconstituer un incident a posteriori. C'est aussi un prérequis NIS2. Effort estimé : 1 journée de développement.
Appliquer le moindre privilège sur chaque outil
Auditez les permissions accordées à chaque outil connecté à votre agent. Un outil de recherche documentaire n'a pas besoin d'accès en écriture. Un agent de support client n'a pas besoin d'accès à la basé de données financières. Réviser les scopes d'API pour n'autoriser que ce qui est strictement nécessaire réduit l'impact d'une injection réussie.
Mettre en place une validation humaine sur les actions critiques
Pour les actions irréversibles ou a fort impact (envoi d'email externe, modification de données, appels API de paiement), insérez un point de validation humaine. Un pattern "human-in-the-loop" sur ces actions réduit drastiquement le risque qu'une injection réussie produise un impact réel avant d'être détectée.
Tester votre prompt système avec des injections basiques
Sans faire appel à un spécialiste, vous pouvez réaliser quelques tests simples : demandez à votre agent de répéter ses instructions système, d'ignorer ses règles précédentes, ou de "jouer le rôle" d'un autre assistant sans restrictions. Si ces tentatives basiques fonctionnent, votre prompt système n'est pas robuste et votre agent est vulnérable à des attaques plus sophistiquées.
Documenter et tester votre procédure de réponse a incident IA
Si votre agent est compromis demain, savez-vous comment le désactiver en urgence ? Qui doit être alerté ? Comment évaluer l'étendue des actions non autorisées ? Cette procédure doit exister, être connue des équipes concernées, et être testée au moins une fois. L'absence de procédure d'incident IA est une non-conformité directe NIS2.
FAQ - Pentest agents IA et sécurité LLM
Qu'est-ce qu'un pentest LLM et en quoi diffère-t-il d'un pentest classique ?
Un pentest LLM teste les vulnérabilités spécifiques aux modèles d'IA et agents autonomes : prompt injection, fuite de données via le contexte, manipulation du comportement du modèle, exploitation des outils connectés. Contrairement à un pentest réseau, il cible la logique non-déterministe du modèle et ses interactions avec les systèmes externes. Les outils, compétences et résultats sont fondamentalement différents.
Quelles sont les principales vulnérabilités OWASP pour les agents IA en 2026 ?
L'OWASP Top 10 agents 2026 liste notamment : la prompt injection indirecte (via données externes), l'exécution non autorisée d'outils, la confiance implicite inter-agents dans les systèmes multi-agents, la fuite via la mémoire persistante, le détournement d'objectif et l'escalade de privilèges via LLM. Les trois premiers sont présents dans la quasi-totalité des déploiements que nous auditons.
Mon entreprise a-t-elle besoin d'un pentest IA si elle utilise juste ChatGPT ?
Si vos équipes utilisent ChatGPT uniquement pour des tâches génériques, le risque est limité mais réel (fuite de données sensibles collées dans le prompt). En revanche, si vous utilisez des agents IA autonomes, des intégrations via API ou des LLM en production qui accèdent à vos systèmes internes, un audit de sécurité IA est fortement recommandé et souvent requis par NIS2.
Qu'est-ce que le principe Zero Trust appliqué aux agents IA ?
Le Zero Trust pour agents IA signifie qu'aucun agent ne doit faire confiance implicitement à un autre. Chaque requête inter-agents doit être authentifiée, autorisée et journalisée indépendamment. Les tokens API doivent être liés à une intention signée. Si l'agent A demande à l'agent B d'exécuter une action, l'agent B doit re-valider l'autorisation de l'utilisateur d'origine, sans se fier à l'agent A comme intermédiaire de confiance.
Combien de temps dure un audit de sécurité IA chez 2LKATIME ?
Un audit de sécurité IA chez 2LKATIME dure entre 5 et 10 jours ouvrés selon la complexité de votre stack : nombre d'agents déployés, surface d'attaque des intégrations, niveau de personnalisation des modèles. Nous livrons un rapport détaillé avec les vulnérabilités identifiées, leur score CVSS adapté IA, et un plan de remédiation priorisé. Le premier diagnostic de 30 minutes est offert.
Vos agents IA en production n'ont jamais été testés ?
2LKATIME réalise des pentests IA spécialisés sur les architectures agentiques et LLM en production. Nos experts certifiés OSCP/OSEP combinent techniques de red team éprouvées et méthodologie OWASP agents IA 2026 pour identifier les vulnérabilités réelles de votre stack IA - pas les vulnérabilités théoriques. Diagnostic offert en 30 minutes.