Pentester de l'IA en 2026 Comment tester les systèmes d'IA sans les confondre ?

Un pentester d'IA n'est plus une chose unique. La même étiquette est désormais utilisée pour au moins trois systèmes différents : un assistant IA intégré à un outil de test existant, un cadre plus agentique qui orchestre plusieurs étapes d'un test de pénétration, et un flux de travail de test plus large destiné aux produits dotés d'IA eux-mêmes. Burp AI est explicitement positionné comme un support alimenté par l'IA à l'intérieur du flux de travail de test de Burp Suite, Shannon se présente comme un pentester d'IA autonome en boîte blanche pour les applications web et les API, et la ligne de recherche PentestGPT décrit un cadre de test de pénétration piloté par LLM avec des rôles modulaires plutôt qu'une simple enveloppe de chatbot. Traiter ces trois idées comme interchangeables est l'un des moyens les plus rapides de mal comprendre ce que cette catégorie peut réellement faire aujourd'hui. (PortSwigger)

Cette confusion est importante parce que les tests de pénétration ont déjà une signification mature. Le PTES décrit toujours un flux en sept phases couvrant les interactions préalables à l'engagement, la collecte de renseignements, la modélisation des menaces, l'analyse des vulnérabilités, l'exploitation, la post-exploitation et l'établissement de rapports. Le guide de l'OWASP sur les tests de sécurité sur le web présente toujours les tests comme une discipline à part entière plutôt que comme un simple balayage ou une simple invite. La norme NIST SP 800-115 est tout aussi claire : les tests de sécurité consistent à planifier et à réaliser des tests techniques, à analyser les résultats et à élaborer des stratégies d'atténuation. Un outil ne devient pas un pentester simplement parce qu'il peut décrire les résultats dans un anglais fluide. Il doit participer à une partie significative de ce flux de travail et ses résultats doivent survivre à la vérification. (Fondation OWASP)

Cette distinction est la raison pour laquelle le débat actuel sur les pentesters de l'IA doit être formulé de manière plus stricte. Il y a L'IA pour le pentestingLes modèles accélèrent la reconnaissance, l'interprétation, la validation, l'élaboration d'exploits ou l'établissement de rapports sur des cibles logicielles ordinaires. Il y a aussi pentesting des systèmes d'IALa cible elle-même contient des modèles, des pipelines de récupération, de la mémoire, l'utilisation d'outils, l'orchestration d'agents et une logique de traitement des résultats qui créent leur propre surface d'attaque. Ces deux tâches se chevauchent, mais il ne s'agit pas du même travail. La première consiste à améliorer l'efficacité du flux de travail offensif. Le second consiste à évaluer les nouvelles limites de la confiance au sein des systèmes basés sur l'IA. Les travaux les plus solides dans ce domaine prennent désormais ces deux aspects au sérieux au lieu de les réduire à une vague promesse. (Série d'aide-mémoire de l'OWASP)

L'IA pentester est désormais un métier à part entière

La première tâche est la plus facile à expliquer. Vous avez une cible normale telle qu'une application web, une API, un locataire dans le nuage ou un outil interne. Vous utilisez l'IA pour accélérer certaines parties du processus de test existant. Burp AI est un bon exemple de ce modèle. PortSwigger le décrit comme un ensemble de fonctionnalités alimentées par l'IA et intégrées à Burp Suite, qui peuvent analyser les demandes dans Repeater, explorer de manière autonome les problèmes des scanners, réduire les faux positifs dans les contrôles Broken Access Control, générer des séquences de connexion enregistrées et prendre en charge les extensions activées par l'IA. En d'autres termes, le modèle ne prétend pas remplacer l'ensemble de la pratique. Il aide l'opérateur à progresser plus rapidement sur certaines parties de la pratique. (PortSwigger)

La deuxième tâche est plus difficile et plus importante que ne le pensent de nombreuses équipes. Une fois que la cible elle-même inclut un LLM, un runtime d'agent, une couche de récupération, un routage de modèle, une mémoire à long terme ou un appel d'outil, vous ne testez plus seulement les points de terminaison HTTP et la logique d'authentification dans le sens ancien du terme. L'effort GenAI de l'OWASP et le guide AI Agent Security soulignent tous deux que les systèmes agentiques présentent des risques tels que l'injection rapide, l'abus d'outils, l'exfiltration de données, l'empoisonnement de la mémoire, le détournement d'objectif, l'autonomie excessive, les défaillances en cascade et le déni de porte-monnaie. Le profil d'IA générative du NIST va dans le même sens, de manière plus formelle, en traitant les risques liés à l'IA comme s'ils concernaient l'ensemble du cycle de vie et en mettant l'accent sur la gouvernance, les tests préalables au déploiement, la provenance du contenu et la divulgation des incidents. MITRE ATLAS existe précisément parce que les systèmes d'IA ont désormais besoin de leur propre base de connaissances sur les techniques adverses. (Série d'aide-mémoire de l'OWASP)

C'est pourquoi l'expression AI pentester est devenu glissant. Parfois, les gens veulent dire "un modèle qui m'aide à faire du pentest". Parfois, ils veulent dire "un système lourd en modèles qui se comporte comme un testeur junior ou intermédiaire". Parfois, ils veulent dire "un système de test pour les applications d'intelligence artificielle". Parfois, ils veulent dire les trois à la fois. La réponse pratique n'est pas d'argumenter sur la marque. Elle consiste à demander ce que l'outil fait réellement, quelles preuves il peut produire, quelles autorisations il détient et de quel côté de la frontière de confiance il opère.

Une manière utile de structurer cette question consiste à diviser la catégorie en quatre modes de travail.

La table est une synthèse, mais le motif qui la sous-tend est visible dans le paysage public. Burp AI reflète le premier mode. PentestGPT représente le deuxième mode. Shannon est un bon exemple public du troisième mode. Le matériel de sécurité et de test de l'IA de l'OWASP, le profil GenAI du NIST, les conseils de sécurité du MCP et le MITRE ATLAS définissent en grande partie le quatrième mode. (PortSwigger)

Ce que dit la recherche sur les systèmes actuels de pentesters d'IA

Le fait le plus important concernant cette catégorie est qu'elle n'est plus hypothétique. Le travail de PentestGPT a démontré que les LLM peuvent aider matériellement avec les sous-tâches de test de pénétration, particulièrement lorsque le système est décomposé en rôles au lieu de devoir tout résoudre en un seul passage. L'article de l'USENIX fait état d'une augmentation de 228,6 % du taux d'exécution des tâches par rapport à GPT-3.5 sur des cibles de référence. Il s'agit là d'un résultat réel, et non d'une impression. Cela signifie que la bonne architecture peut rendre les LLM bien meilleurs pour le type de raisonnement local qui apparaît lors d'un test. (USENIX)

Mais le deuxième fait le plus important est que ce résultat ne justifie pas les affirmations les plus théâtrales qui circulent actuellement sur le marché. PentestEval, publié à la fin de l'année 2025, est l'un des examens les plus clairs de la réalité. Il décompose le flux de travail en six étapes et montre que la plupart d'entre elles n'atteignent toujours pas 50 % de réussite dans les modèles évalués. La prise de décision en matière d'attaque et la génération d'exploits sont les étapes les plus difficiles, avec un taux de réussite d'environ 25 %. Dans les tests de bout en bout, les pipelines n'atteignent que 31 % de réussite, et l'article note que les agents autonomes tels que PentestAgent et VulnBot échouent presque entièrement dans le cadre entièrement automatique qu'il a évalué. Il ne s'agit pas d'une petite mise en garde cachée dans l'annexe. Il s'agit du principal signal de l'état de l'art. (arXiv)

AutoPenBench permet d'aborder le même sujet sous un angle différent. Son benchmark comprend 33 tâches, allant d'exercices d'introduction à des systèmes réellement vulnérables, et il prend explicitement en charge MCP afin que les capacités des agents puissent être comparées dans un environnement plus réaliste. Le fait que l'évaluation comparative doive désormais tenir compte des protocoles d'outils et des étapes intermédiaires montre à quel point le domaine a changé. Nous avons dépassé le stade où une simple invite intelligente est la question intéressante. La question intéressante est désormais de savoir si un système peut maintenir une chaîne d'états utile à travers l'observation, le raisonnement, l'utilisation d'outils et la vérification. (Anthologie de l'ACL)

C'est là que de nombreuses revendications de produits commencent à s'éloigner des preuves. Une démonstration montrant un modèle en train d'écrire une charge utile n'est pas une preuve solide. Un benchmark qui isole la génération d'exploits sans la variabilité de l'environnement n'est pas non plus suffisant en soi. Un pentester IA sérieux doit survivre à des détails hostiles : sessions périmées, itinéraires partiels, en-têtes trompeurs, contextes d'authentification multiples, limites de taux, état caché, logique commerciale, comportement dépendant des données, et le simple fait que de nombreuses vulnérabilités réelles ne sont pas syntaxiques. Elles sont situationnelles.

La bonne nouvelle, c'est que les résultats de l'analyse comparative ne disent pas que l'IA est inutile dans le domaine offensif. Ils disent le contraire. Ils indiquent que l'IA est déjà utile dans des parties limitées, liées à des preuves et fondées sur des outils du flux de travail. Ils indiquent également que l'écart entre un copilote productif et un pentester autonome digne de confiance est encore suffisamment important pour que l'architecture, la validation et la supervision humaine restent décisives. Il s'agit là d'une conclusion bien plus précieuse que le battage médiatique aveugle ou le rejet paresseux. (USENIX)

Ce qu'un pentester d'IA doit prouver avant de mériter son nom

Un produit obtient le label AI pentester seulement lorsqu'il peut faire plus que parler. Au minimum, il doit faire preuve d'une participation disciplinée à une véritable boucle de test : recueillir des observations, décider de ce qui importe, exécuter ou guider des vérifications, séparer les hypothèses des résultats vérifiés, préserver les artefacts et produire des résultats qu'un autre testeur peut reproduire de manière indépendante. S'il saute l'étape de la vérification, il est plus proche d'un assistant de recherche. S'il saute l'étape de l'état, il est plus proche d'un système d'autocomplétion fantaisiste. S'il saute l'étape de la preuve, il se rapproche d'un générateur de rapports. Aucun de ces systèmes n'est inutile. Il s'agit simplement de choses différentes.

L'exigence du système devient plus claire si l'on présente le problème comme un ensemble de composants plutôt que comme des caractéristiques.

Les conseils de l'OWASP sur la sécurité des agents d'IA renforcent l'importance de la politique et des limites. Une fois qu'un agent peut raisonner, planifier, utiliser des outils et conserver de la mémoire, sa surface d'attaque s'étend au-delà de l'injection classique d'invite à l'abus d'outils, à l'exfiltration de données, au détournement d'objectifs, à l'empoisonnement de la mémoire, aux défaillances en cascade et à l'autonomie excessive. Les directives de sécurité du MCP vont dans le même sens du côté du protocole, avec des sections explicites sur les problèmes d'adjoint confus, le passage par jeton, le SSRF, le détournement de session, la compromission du serveur local et la minimisation du champ d'application. Un pentester IA n'est donc pas seulement un problème de modèle. Il s'agit d'un problème de système. (Série d'aide-mémoire de l'OWASP)

C'est également la raison pour laquelle les meilleures intégrations commerciales actuelles sont moins glamour que les messages sociaux les plus bruyants. Les éléments les plus importants sont ennuyeux de la bonne manière : état fiable, valeurs par défaut sûres, contrôle de l'étendue, audit, artefacts traçables, accès contrôlé aux outils et transfert propre à un humain lorsque le système est incertain. La documentation Burp AI de PortSwigger est remarquable précisément parce qu'elle est attentive au contrôle de l'utilisateur. Les fonctionnalités ne s'exécutent que si l'utilisateur les active, l'IA pour les extensions est désactivée par défaut, et l'entreprise documente la manière dont les demandes sont traitées et conservées. Cela n'élimine pas les risques, mais témoigne d'un bon instinct de conception : l'IA offensive doit être gouvernée autant qu'elle est optimisée. (PortSwigger)

Où un pentester IA permet déjà de gagner du temps réel

Les preuves publiques sont désormais suffisamment solides pour affirmer que les tests assistés par l'IA sont déjà utiles dans le travail quotidien. Bugcrowd en 2026 Dans la tête d'un hacker a interrogé plus de 2 000 pirates informatiques et a constaté que 82 % d'entre eux utilisent l'IA dans le cadre de leur processus de piratage et que 74 % pensent que l'IA a augmenté la valeur du piratage. Cela ne signifie pas que 82 % d'entre eux utilisent des agents entièrement autonomes. Cela signifie que le changement de flux de travail est déjà là. L'IA est devenue une infrastructure normale pour une part significative de la recherche offensive. (Bugcrowd)

Les victoires les plus mûres ne sont pas exotiques. Ce sont les endroits où les testeurs humains perdent traditionnellement du temps à cause de la friction mécanique. Une bonne couche d'IA peut prendre une séquence de demande désordonnée et résumer le flux d'authentification probable. Elle peut examiner le bruit du scanner et regrouper les résultats qui méritent réellement un second examen. Elle peut prendre un delta de réponse suspect et ébaucher les deux ou trois prochains mouvements de validation. Il peut analyser un patch diff et mettre en évidence ce que la correction a changé et ce qu'elle n'a pas touché. Il peut aider à transformer des sorties de console, des captures d'écran et des traces HTTP éparses en une constatation structurée sans obliger le testeur à retaper trois fois la même explication.

L'ensemble des fonctionnalités de Burp AI est révélateur. Ses documents publics mettent l'accent sur les messages personnalisés dans Repeater, le suivi autonome des problèmes, la réduction des faux positifs pour les découvertes de contrôle d'accès non respecté et les séquences de connexion enregistrées générées par l'IA. Remarquez ce que ces capacités ont en commun. Elles sont toutes proches des véritables points douloureux des tests d'application. Elles sont proches des données bruyantes, de la validation répétitive, des flux d'authentification confus et du triage des problèmes. Ils ne prétendent pas que le modèle a remplacé le jugement du testeur. Ils affirment que le modèle raccourcit le chemin vers le jugement. (PortSwigger)

L'étude PentestGPT va dans le même sens du point de vue de la recherche. Les gains rapportés proviennent de l'utilisation du modèle dans les domaines où les LLM sont déjà relativement forts : compréhension des résultats de l'outil, proposition d'actions ultérieures et aide au maintien de la progression d'une tâche. Cela correspond à la façon dont les testeurs expérimentés décrivent leurs pertes de temps. La partie la plus difficile d'une mission n'est souvent pas de taper la charge utile. Il s'agit de rester orienté dans un espace de problèmes vaste et bruyant. (USENIX)

Un système sensible à la source peut aller plus loin lorsque la cible et la base de code sont toutes deux disponibles. Le dépôt public de Shannon décrit un modèle qui analyse le code source, identifie les vecteurs d'attaque et exécute des exploits réels contre l'application en cours et ses API, avec seulement des vulnérabilités prouvées incluses dans le rapport final. La question de savoir si un déploiement donné est à la hauteur de cette affirmation est toujours une question empirique, mais le choix de l'architecture lui-même est important. Il reconnaît que l'évaluation de l'exploitabilité s'améliore lorsque le modèle peut voir les itinéraires, les limites de confiance, les indices de flux de données et la structure de la logique commerciale, au lieu de deviner uniquement à partir des réponses de la boîte noire. (GitHub)

Le même schéma se retrouve dans les meilleurs travaux de conception de plates-formes. L'important n'est pas que l'interface utilisateur ait l'air futuriste. Ce qui compte, c'est que le système aide un opérateur à préserver une chaîne allant du signal à la preuve. Dans la pratique, la valeur commerciale la plus utile dans cette catégorie provient de l'orchestration des outils, du matériel de PoC reproductible, de la conservation des artefacts et de l'emballage des rapports autour d'un flux de travail régi. La page produit publique de Penligent s'appuie précisément sur ces revendications opérationnelles : orchestration à travers plus de 200 outils, flux CVE-to-PoC, tests axés sur la logique commerciale, et preuve traçable en premier lieu. C'est le type d'intégration qui a du sens dans un véritable pipeline offensif parce qu'il s'agit d'une discipline d'exécution plutôt que d'un simple théâtre de modèles. (Penligent)

Lorsqu'un pentester d'IA échoue encore dans des conditions réelles

La plus grande faiblesse actuelle n'est pas l'intelligence brute. C'est la fiabilité dans des conditions longues, changeantes et ambiguës. La décomposition des étapes de PentestEval le montre très clairement. Lorsque le travail consiste moins à interpréter les résultats d'un seul outil qu'à décider quelle branche poursuivre, comment réviser un exploit défaillant ou comment maintenir un raisonnement cohérent à travers plusieurs étapes, les systèmes actuels se dégradent rapidement. C'est pourquoi le même modèle peut sembler impressionnant dans une démonstration en une seule étape et fragile dans un engagement réel. (arXiv)

La logique d'entreprise reste particulièrement tenace. Les systèmes d'IA peuvent souvent repérer les failles de sécurité syntaxiques, les composants vulnérables connus, les mauvaises configurations évidentes ou les différences d'autorisation classiques. Ils ont encore plus de mal que les humains lorsque la vulnérabilité dépend du timing, du séquençage multi-acteurs, de l'abus de flux de travail spécifique au contrat, des hypothèses d'isolation du locataire ou de la sémantique de l'application qui s'étend sur plusieurs écrans et rôles. C'est précisément là que la confiance d'un modèle devient dangereuse, car l'explication peut sembler plus stable que la preuve qui la sous-tend.

Le même problème se pose pour la génération d'exploits. PentestEval montre que la génération et la révision des exploits sont parmi les étapes les plus faibles, et les chiffres de bout en bout montrent à quelle vitesse les faiblesses au niveau de l'étape s'aggravent. Une charge utile syntaxiquement plausible n'est pas encore un exploit vérifié. Un script qui s'exécute n'est pas encore une découverte démontrée. Une phrase de rapport qui donne l'impression que le bogue est prouvé n'est pas la même chose qu'une preuve étayée par des artefacts. Un pentester IA qui n'applique pas ces distinctions finira par coûter plus de temps qu'il n'en économise. (arXiv)

Un autre mode d'échec fréquent est l'arrêt inapproprié. Les humains savent quand une piste est faible, quand une réponse est simplement bruyante, quand un scanner les a conduits à de fausses certitudes et quand un système est à une mauvaise tentative de limiter le taux de l'engagement tout entier. Les agents sont encore inégaux dans ce domaine. Ils ont souvent besoin d'une politique explicite et d'une machinerie d'état pour éviter les tests excessifs, les coups de boutoir ou l'escalade discrète des privilèges d'une manière que l'opérateur n'avait pas prévue. C'est pourquoi "plus d'autonomie" n'est pas automatiquement un progrès. Dans un système offensif, l'autonomie n'est utile que si elle est limitée par un bon comportement d'arrêt.

C'est également à ce stade que la conception des limites de la vie privée et de la confiance entre à nouveau en jeu. La documentation de Burp est remarquable car elle précise que les interactions avec l'IA sont initiées par l'utilisateur, que les extensions n'ont pas accès à l'IA par défaut et que le comportement de l'extension ne peut être garanti simplement parce qu'elle vit au sein d'une plateforme plus large. C'est exactement le bon avertissement. Le maillon faible d'un flux de travail de pentest d'IA n'est souvent pas le modèle principal. Il s'agit de l'extension, de l'intégration, du connecteur ou de la fonction de commodité qui reçoit discrètement du matériel sensible ou une capacité à fort impact sans faire l'objet d'un examen aussi minutieux. (PortSwigger)

Flux de travail des pentesters de l'IA pour les produits basés sur l'IA

Tester un produit doté d'IA nécessite un modèle mental différent de celui qui consiste à utiliser l'IA pour tester un produit normal. Une fois que la cible comprend des invites, du contenu récupéré, des appels d'outils, de la mémoire et une sélection d'actions basée sur un modèle, vous ne testez plus seulement un point final. Vous testez une chaîne de transfert de confiance.

La spécification officielle MCP décrit MCP comme un protocole ouvert qui permet aux applications LLM de se connecter à des sources de données et à des outils externes, avec des hôtes, des clients et des serveurs échangeant des messages JSON-RPC. Cette architecture est puissante précisément parce qu'elle transforme les modèles en systèmes d'action plutôt qu'en générateurs isolés. Le document sur les meilleures pratiques de sécurité de MCP consacre donc du temps aux attaques par adjoint confus, au passage par jeton, au SSRF, au détournement de session, à la compromission du serveur MCP local et à la minimisation de l'étendue. Il ne s'agit pas de cas marginaux. Il s'agit des risques naturels liés à l'utilisation d'outils derrière un langage. (Modèle Contexte Protocole)

Les conseils de l'OWASP sur la sécurité des agents d'IA vont dans le même sens. Il met en évidence l'injection rapide, l'abus d'outils, l'exfiltration de données, l'empoisonnement de la mémoire, le détournement d'objectifs, l'autonomie excessive, les défaillances en cascade, la configuration malveillante, le déni de portefeuille et la compromission de la chaîne d'approvisionnement comme des préoccupations de premier ordre pour les systèmes agentiques. Le profil GenAI du NIST complète cette approche en soulignant que les risques liés à l'IA concernent l'ensemble du cycle de vie et peuvent différer des risques logiciels traditionnels ou les intensifier. Ensemble, ces documents tendent vers la même conclusion : une fois qu'un système d'IA peut lire un contenu et agir sur la base de ce contenu, les tests d'application ordinaires doivent être élargis pour devenir des tests de la chaîne complète. (Série d'aide-mémoire de l'OWASP)

C'est là que MITRE ATLAS prend toute sa valeur. ATLAS est une base de connaissances vivante des tactiques et techniques adverses ciblant les systèmes d'IA. ATT&CK reste utile pour cartographier le comportement post-validation conventionnel dans les environnements d'entreprise, mais ATLAS offre aux défenseurs et aux testeurs un langage pour la partie du modèle de menace spécifique à l'IA. Pour les équipes qui évaluent les agents d'IA, les copilotes et les assistants connectés à des outils, la bonne décision n'est pas de choisir un cadre et d'ignorer l'autre. Il s'agit d'utiliser ATT&CK pour l'infrastructure ordinaire et le comportement des applications qui suivent l'exploitation, et ATLAS pour les comportements du système d'IA qui les précèdent ou les rendent possibles. (MITRE ATLAS)

Le changement de mentalité le plus utile pour les testeurs est le suivant : le contenu est maintenant adjacent au code. Un modèle peut ingérer une page web, un PDF, un ticket de problème, un courriel ou une transcription d'assistance. Ce contenu peut contenir des instructions cachées ou trompeuses. Le modèle peut acheminer un appel d'outil sur la base de ce qu'il a vu. L'outil peut avoir une portée réseau, fichier ou identité. Et une étape de rendu ou de flux de travail plus tard, la sortie peut se transformer en une action destructrice. Il ne s'agit plus d'une chaîne hypothétique. L'unité 42 de Palo Alto Networks a signalé des cas d'injection indirecte d'invite sur le web observés dans la nature, y compris des cas d'évasion de l'examen des publicités basé sur l'IA et d'autres conséquences de la chaîne d'action dans le monde réel. Une fois que le contenu peut orienter l'action, le testeur doit suivre toute la chaîne, de l'ingestion à l'effet. (Unité 42)

Un pentest IA sérieux pose donc des questions que les tests web ordinaires n'ont jamais eu besoin de poser de manière aussi explicite. Le contenu récupéré peut-il remplacer silencieusement les instructions du système ? Un appel d'outil peut-il être induit par le biais d'un contexte caché ? La mémoire peut-elle transporter des instructions empoisonnées d'une session à l'autre ? Les résultats rendus peuvent-ils divulguer des secrets ou déclencher des actions ultérieures dangereuses ? Les approbations sont-elles significatives ou cosmétiques ? L'agent peut-il être transformé en un adjoint confus ayant un accès que l'attaquant ne détient pas directement. Les journaux, les rapports ou les résumés deviennent-ils par inadvertance des canaux d'exfiltration ? Rien de tout cela ne remplace les tests d'authentification, de contrôle d'accès, d'injection ou de gestion des fichiers. Ils se superposent à ces tests.

Les CVE qui expliquent la véritable frontière de sécurité autour d'un pentester IA

Le moyen le plus rapide de comprendre les limites de la sécurité autour des pentesters de l'IA est d'examiner les CVE récents. Non pas parce que la catégorie est définie par les CVE, mais parce que les vulnérabilités révèlent les endroits où les concepteurs font trop confiance aux modèles, aux plugins, aux protocoles d'outils, aux chemins de code d'exécution ou à l'infrastructure environnante.

Commencer par CVE-2025-3248 dans Langflow. L'avis révisé de GitHub indique que les versions antérieures à la version 1.3.0 étaient vulnérables parce que l'élément /api/v1/validate/code permettait l'injection de code non authentifié conduisant à l'exécution de code arbitraire. L'aperçu de la sécurité de Langflow indique que les versions inférieures à 1.3.0 n'appliquaient pas l'authentification ou le sandboxing approprié pour les composants de code personnalisé, créant ainsi un chemin vers la compromission complète du système. Cette vulnérabilité est importante pour la conception des pentesters de l'IA car de nombreuses plateformes d'agents veulent un "code personnalisé" flexible ou des étapes de validation. Si cette flexibilité est accessible depuis le réseau sans authentification forte et sans isolation, la plateforme cesse d'être une couche d'orchestration sûre et devient une surface RCE. L'atténuation est conceptuellement simple et opérationnellement non négociable : authentifier le point de terminaison, isoler l'exécution, et cesser de traiter. exec()-Les caractéristiques adjacentes sont considérées comme une commodité inoffensive pour le développeur. (GitHub)

Ensuite, regardez CVE-2026-33017également dans Langflow. L'avis de GitHub indique que l'utilisateur non authentifié de build_public_tmp a accepté des données de flux contrôlées par l'attaquant et les a transmises à exec() avec zéro sandboxing, ce qui entraîne un RCE non authentifié. La leçon importante n'est pas seulement que Langflow avait un autre bogue. La leçon est que la correction d'une voie d'exécution de code évidente ne résout pas l'habitude architecturale sous-jacente de laisser les données de flux de travail contrôlées par l'attaquant dériver vers un comportement d'exécution puissant. Pour les pentesters de l'IA, il s'agit d'un avertissement direct : chaque "flux public", "construction temporaire", "exécution de débogage" ou "aperçu" doit être considéré comme faisant partie de la surface d'attaque, et non comme une enveloppe inoffensive autour du système réel. (GitHub)

Passez maintenant aux protocoles d'outils. CVE-2026-4270 a affecté le serveur AWS API MCP. L'avis d'AWS indique que le serveur permet aux assistants d'intelligence artificielle d'interagir avec les ressources AWS par le biais de commandes AWS CLI et que les versions 0.2.14 à 1.3.8 pourraient contourner les restrictions d'accès aux fichiers prévues dans le cadre de l'API MCP. pas d'accès et répertoire de travail exposant ainsi le contenu d'un fichier local arbitraire dans le contexte de l'application client MCP. Cet exemple illustre parfaitement l'importance des limites de l'outil dans la sécurité de l'IA. Le modèle n'avait pas besoin d'être compromis d'une manière mystique. Une limite locale a échoué autour de ce que le serveur d'outils était autorisé à lire. Une fois que cela s'est produit, le contexte de l'application LLM est devenu la surface d'exposition. La solution a consisté à passer à la version 1.3.9, mais la leçon à en tirer est plus large : la délimitation des capacités doit être appliquée par le système d'exécution, et non simplement décrite dans l'interface utilisateur. (Amazon Web Services, Inc.)

CVE-2026-26118 dans Azure MCP Server aborde le même point sous l'angle du réseau. NVD le décrit comme un SSRF qui permet à un attaquant autorisé d'élever ses privilèges sur un réseau. Cette seule phrase suffit à montrer pourquoi les systèmes d'agents doivent être testés avec le même sérieux que toute autre couche d'automatisation en réseau. Dès qu'un agent connecté à un outil peut récupérer ou interroger des ressources au nom d'un utilisateur, le SSRF devient un chemin non seulement vers les métadonnées ou les services internes, mais aussi potentiellement vers des opérations privilégiées en aval. La solution consiste bien sûr à appliquer des correctifs. Mais la réponse technique devrait également inclure le contrôle de la politique de sortie, la segmentation du réseau et le refus de supposer que "attaquant autorisé" signifie "faible risque". Dans les systèmes d'agents, les contextes autorisés sont souvent les plus dangereux. (NVD)

CVE-2026-31951 dans LibreChat montre ce qui se passe lorsque l'intégration MCP entre en conflit avec la substitution des informations d'identification. NVD indique que les serveurs MCP créés par les utilisateurs pourraient inclure des en-têtes arbitraires qui subissent une substitution d'identifiant, permettant aux victimes qui appellent des outils sur un serveur malveillant d'avoir des jetons OAuth exfiltrés. L'avis de GitHub est encore plus clair quant à l'impact, énumérant le vol de jetons OAuth, la prise de contrôle de comptes, l'usurpation d'identité et le mouvement latéral, en particulier pour les utilisateurs authentifiés par OpenID SSO. Il ne s'agit pas seulement d'une histoire de LibreChat. Il s'agit d'une histoire concernant chaque assistant d'intelligence artificielle qui laisse des serveurs d'outils tiers participer à un contexte de haute confiance. Si le runtime laisse les en-têtes, les paramètres ou les placeholders templés traverser les frontières de confiance trop librement, un connecteur malveillant peut devenir un vide d'informations d'identification. La solution consiste à appliquer des correctifs, à limiter la création de serveurs, à minimiser la substitution d'espaces réservés et à faire en sorte que les limites d'approbation des outils soient significatives. (NVD)

CVE-2025-2867 dans GitLab Duo avec Amazon Q pour une raison différente. NVD indique qu'un problème spécifiquement conçu pourrait manipuler les fonctionnalités de développement assisté par l'IA et potentiellement exposer des données de projet sensibles à des utilisateurs non autorisés dans plusieurs gammes de GitLab 17.8 à 17.10. Ce point est important car il met fin à l'hypothèse paresseuse selon laquelle les risques liés à l'IA ne concernent que les chatbots publics ou les agents expérimentaux. Ici, la fonctionnalité vulnérable se trouvait dans un flux de travail de développement d'entreprise. La condition d'exploitation n'était pas de "casser le modèle". Il s'agissait de "créer un contenu qui oriente le comportement assisté par l'IA vers l'exposition des données". C'est exactement le type de limite qu'un pentester de l'IA devrait pouvoir raisonner lorsqu'il teste des plateformes de développement, des intégrations de billetterie et des déclarations de sécurité par défaut autour d'assistants intégrés. (NVD)

Il s'agit là d'exemples natifs ou adjacents à l'IA. Mais un pentester IA doit également vivre dans le monde ordinaire des vulnérabilités. CVE-2024-3400 dans PAN-OS GlobalProtect permettait à des attaquants non authentifiés d'atteindre l'injection de commande avec les privilèges root sur les pare-feux affectés lorsque la configuration de la fonctionnalité vulnérable était présente. CVE-2023-46604 dans Apache ActiveMQ permettait à un attaquant distant disposant d'un accès réseau au courtier ou au client d'exécuter des commandes shell arbitraires en manipulant les types de classes sérialisées dans le protocole OpenWire. Aucune de ces vulnérabilités n'est "liée à l'IA", et c'est bien là l'essentiel. Un pentester IA digne de ce nom doit encore gérer la réalité classique de l'infrastructure : visibilité des actifs, nuance des versions, conditions environnementales préalables, accessibilité du réseau, conditions d'exploitation et preuve. L'IA peut raccourcir le chemin entre l'indice d'exposition et le plan de validation, mais elle n'élimine pas le besoin de preuves environnementales. (NVD)

Enfin, CVE-2024-3094 dans XZ Utils rappelle que la chaîne d'approvisionnement de la plateforme offensive est tout aussi importante que celle de la cible. NVD et CISA décrivent des codes malveillants dans des fichiers tarballs XZ en amont qui ont altéré le processus de construction et modifié le comportement de liblzma. Pour les systèmes de pentesters d'IA, qui dépendent de plus en plus de paquets open-source en couches, de navigateurs, de serveurs MCP, d'exécutions de modèles, de connecteurs et d'outils CLI, la confiance dans la chaîne d'approvisionnement n'est pas un bruit de fond. Il s'agit d'une préoccupation centrale en matière de conception. Un système qui orchestre des dizaines de composants externes n'est digne de confiance qu'en fonction de sa provenance et de sa discipline de mise à jour. (NVD)

Le fil conducteur de tous ces CVE est simple. Le plus grand risque lié aux pentesters de l'IA est rarement "le modèle a mal répondu". Le risque le plus important est que le runtime environnant ait accordé au modèle trop de portée, trop peu de validation, trop d'exposition secrète, ou trop de confiance dans le contenu et les outils de tiers.

Construire un flux de travail de pentester d'IA basé sur des preuves

La manière la plus sûre d'utiliser un pentester d'IA aujourd'hui est de le forcer à entrer dans une boucle de preuve d'abord. Cela signifie que le système doit justifier chaque affirmation en l'associant à un artefact, à une étape reproductible ou à une observation différentielle. Dès que le flux de travail s'affranchit de cette discipline, on passe du test de sécurité à la narration spéculative.

La première partie de cette boucle est la collecte contrôlée de données. L'objectif n'est pas de libérer un maximum de trafic en espérant que le modèle fera le tri plus tard. L'objectif est de capturer suffisamment de données structurées pour que la couche d'intelligence artificielle puisse raisonner sans créer de chaos.

#!/usr/bin/env bash
# Cibles autorisées uniquement. Exécution par rapport à la portée approuvée.
set -euo pipefail

TARGET="${1:?Usage : ./run.sh https://staging.example.com}"
RUN_ID="$(date +%Y%m%d-%H%M%S)"
BASE="runs/${RUN_ID}"

mkdir -p "${BASE}"/{scope,http,recon,findings,evidence}

printf '%s\n' "$TARGET" > "${BASE}/scope/targets.txt"

# Vérification légère en direct et empreinte HTTP
httpx -silent -json -u "$TARGET" \
  | tee "${BASE}/http/httpx.jsonl"

# Contrôles à faible taux basés sur des modèles avec préservation des artefacts
nuclei -u "$TARGET" \
  -rl 3 \N- -retries 1 \N
  -retries 1 \N- -jsonl \N
  -jsonl \N
  -o "${BASE}/findings/nuclei.jsonl"

# Préserver les métadonnées clés pour un raisonnement et une différenciation ultérieurs
jq -r '{url, status_code, title, tech, webserver}' \N- "${BASE}/findings/nuclei jsonl" \N
  "${BASE}/http/httpx.jsonl" \
  > "${BASE}/evidence/http-summary.jsonl"

L'intérêt d'un tel flux de travail n'est pas que l'IA ait besoin de JSON pour des raisons esthétiques. C'est que les artefacts structurés sont plus faciles à différencier, à regrouper, à expliquer, à retester et à exporter dans un rapport. Un modèle est beaucoup plus utile lorsqu'on lui demande de raisonner sur des preuves conservées que lorsqu'on attend de lui qu'il se souvienne d'un flot de données terminales transitoires.

La deuxième partie est la validation différentielle. Un grand nombre des résultats les plus importants dans les tests d'applications réelles ne sont pas des bogues à réponse unique. Il s'agit de différences entre les rôles, les sessions, les locataires ou les états des fonctionnalités. L'IA est véritablement utile ici parce qu'elle peut résumer le delta, mais le delta doit encore être collecté de manière reproductible.

#!/usr/bin/env bash
# Exemple de vérification de la différence de rôle pour un environnement de mise à disposition autorisé
set -euo pipefail

BASE_URL="https://staging.example.com"
RESOURCE="/api/projets/42"

curl -sS \N- -H "Authorization
  -H "Authorization : Bearer $(cat tokens/user.txt)" \
  "${BASE_URL}${RESOURCE}" \
  | jq -S . > evidence/user-project42.json

curl -sS \N- -H "Authorization
  -H "Authorization : Bearer $(cat tokens/admin.txt)" \
  "${BASE_URL}${RESOURCE}" \
  | jq -S . > evidence/admin-project42.json

diff -u evidence/user-project42.json evidence/admin-project42.json \N- > evidence/project42-role.json \N- > evidence/project42-role.json
  > evidence/project42-role-diff.patch || true

Il s'agit là d'un bon exemple de cas où un pentester IA peut apporter une réelle valeur ajoutée sans prétendre remplacer l'analyste. Le système peut lire les différences, signaler les champs qui ne devraient pas être visibles, suggérer des vérifications de suivi pour les points d'extrémité de liste ou les ID d'objets frères, et rédiger le récit de reproduction minimal. Mais l'artefact lui-même reste la source de vérité.

La troisième partie consiste à trouver une normalisation. Si la couche d'IA doit générer un résultat qui mérite d'être conservé, elle doit rattacher ce résultat à une structure stable plutôt que de l'enterrer dans des paragraphes.

{
  "finding_id" : "BAC-2026-0042",
  "title" : "Faiblesse du contrôle d'accès horizontal sur une ressource du projet",
  "target" : "https://staging.example.com/api/projects/42",
  "prerequisites" : [
    "Deux comptes de test valides dans le même locataire",
    "Jeton d'utilisateur pour un rôle à faible privilège",
    "Jeton d'administrateur pour la comparaison des contrôles"
  ],
  "observation" : {
    "user_status" : 200,
    "admin_status" : 200,
    "unexpected_fields" : ["billing_email", "internal_notes"],
    "artifact_files" : [
      "evidence/user-project42.json",
      "evidence/admin-project42.json",
      "evidence/project42-role-diff.patch"
    ]
  },
  "verification_status" : "reproduit",
  "impact_statement" : "Un utilisateur à faible privilège peut visualiser des champs réservés à un rôle élevé",
  "next_steps" : [
    "Tester les ID d'objets frères pour l'IDOR",
    "Retester après le correctif",
    "Cartographier les opportunités de détection probables dans les journaux d'accès"
  ]
}

Une telle structure rend le reste du flux de travail beaucoup plus propre. Un modèle peut le résumer pour l'ingénierie. Un relecteur peut le rejouer. Un responsable de la sécurité peut comparer plusieurs résultats sans relire la prose. Une couche de reporting peut le mettre en forme pour les parties prenantes. Et un ingénieur de détection peut le traduire en hypothèses de journal ou en cartographie ATT&CK.

C'est également à ce stade qu'une plateforme peut apporter une valeur ajoutée légitime sans détourner l'article. Dans les équipes réelles, la partie utile d'une plateforme de pentest d'IA n'est pas le monologue du modèle. C'est le regroupement des outils approuvés, des artefacts capturés, des PoC reproductibles et du matériel de rapport dans un seul enregistrement d'exécution gouverné. La documentation publique de Penligent met l'accent sur ces propriétés opérationnelles : orchestration à travers un large ensemble d'outils, analyse CVE liée à la génération de PoC en un clic, tests centrés sur la logique métier, et artefacts de preuve traçables. Ce type d'emballage s'inscrit naturellement dans un flux de travail axé sur les preuves, car il réduit la distance de transfert entre la reconnaissance, la validation et la production de rapports. (Penligent)

La même discipline s'applique lorsque la cible est une application basée sur l'IA. Un bon flux de travail de pentester d'IA pour une cible agentique devrait préserver non seulement les traces et les résultats HTTP, mais aussi le contexte de l'invite, les références du contenu récupéré, les demandes d'appel d'outil, l'état de l'approbation, les mutations de la mémoire et toute transformation qui se produit entre le résultat du modèle et l'action réelle. Si vous ne pouvez pas reconstituer la chaîne, vous ne pouvez pas expliquer le risque. Et si vous ne pouvez pas expliquer le risque, vous ne disposez pas encore d'un résultat fiable.

Déployer un pentester IA sans créer de nouveau problème

La première erreur de déploiement est l'excès de confiance. Les équipes voient un assistant perfectionné ou une démonstration d'autonomie convaincante et l'orientent immédiatement vers la production avec de larges références. Ce n'est pas le bon réflexe. L'automatisation offensive doit entrer dans l'environnement de la même manière que tout autre système à haut risque : avec un champ d'application explicite, des privilèges minimaux et une confiance échelonnée.

La deuxième erreur est de prétendre que la qualité du modèle est la principale question de contrôle. Ce n'est pas le cas. Les principales questions sont plus opérationnelles. Quels objectifs le système peut-il atteindre ? Quels outils peut-il invoquer ? Quelles informations d'identification peut-il consulter ? Quels appels réseau sortants peut-il effectuer ? Quels secrets peuvent apparaître dans son contexte ? Quels sont les artefacts qu'il préserve ? Quelles approbations sont appliquées dans le moteur d'exécution au lieu d'être implicites dans la politique. Et avec quelle facilité un humain peut-il passer outre, mettre en pause ou rejouer le travail du système. Le profil GenAI du NIST montre clairement que le risque lié à l'IA ne se limite pas à une seule couche. Les orientations de l'OWASP en matière de sécurité des agents indiquent tout aussi clairement que des agents surprivilégiés ou mal gouvernés transforment des faiblesses courantes en risques opérationnels graves. (Publications du NIST)

Une liste de contrôle pratique pour le déploiement d'un pentester IA devrait donc inclure au moins les questions d'ingénierie suivantes, même si la démonstration du produit ne les mentionne jamais. Le système peut-il être entièrement désactivé ? Les extensions activées par l'IA sont-elles désactivées par défaut ? Les invites et les réponses sont-elles vérifiées ? Les données stockées sur les demandes sont-elles cryptées ? Est-il possible de restreindre les outils par engagement ou par opérateur ? Est-il possible d'appliquer des listes d'autorisation ciblées ? Est-il possible de séparer les hypothèses de recherche des résultats vérifiés dans le rapport ? Le système peut-il fonctionner en mode silencieux pour les environnements d'essai ou d'ombre ? Il peut également conserver les preuves brutes à côté du texte de synthèse. La documentation sur l'IA de PortSwigger est précieuse ici, non pas parce qu'elle répond parfaitement à toutes les questions, mais parce qu'elle modélise le bon niveau d'explicitation concernant l'activation, la rétention, les limites du fournisseur et le contrôle de l'extension. (PortSwigger)

Il existe également un problème subtil mais important de délimitation du champ d'application qui s'aggrave avec l'IA, au lieu de s'atténuer. Les pentesters traditionnels savent déjà que les erreurs d'étendue sont dangereuses. Les testeurs agentiques aggravent ce danger parce qu'ils peuvent agir plus rapidement et enchaîner plus d'actions une fois qu'une erreur a été commise. Un pentester IA qui peut naviguer, appeler des outils, suivre des redirections, ouvrir des documents ou lire l'état local a besoin d'une définition plus stricte de la cible qu'une personne qui clique manuellement à travers un proxy. Le bon choix par défaut est celui d'une autonomie plus étroite, et non plus large.

Enfin, les équipes devraient cesser de confondre "utile" et "prêt à être utilisé sans surveillance". Les preuves publiques ne soutiennent pas ce saut. Ce qu'elles soutiennent, c'est une affirmation plus étroite et plus valable : les pentesters de l'IA sont maintenant très bons pour comprimer le chemin de l'observation à la conclusion du candidat, et de plus en plus utiles pour préserver et organiser les preuves nécessaires à la vérification. Cet aspect peut à lui seul être transformateur dans le bon flux de travail. Ce n'est tout simplement pas la même chose que de transférer l'ensemble de la pratique.

Jugement final sur la catégorie des pentesters de l'IA

L'état actuel du domaine est plus intéressant que ne l'admettent les deux parties de l'argumentation habituelle. La catégorie est réelle. La valeur est réelle. L'adoption est réelle. Le soutien de la recherche est réel. Burp AI, PentestGPT, Shannon, les écosystèmes basés sur les MCP et le travail de benchmarking émergent pointent tous dans la même direction : les modèles sont maintenant des composants significatifs dans le flux de travail offensif. Les données 2026 de Bugcrowd ne permettent pas d'affirmer le contraire. (PortSwigger)

Dans le même temps, les preuves ne confirment pas les affirmations les plus véhémentes sur le remplacement autonome. PentestEval est particulièrement utile à cet égard, car il montre exactement où les systèmes actuels sont encore défaillants : la prise de décision en matière d'attaques, la génération d'exploits, la fiabilité à long terme et la stabilité de bout en bout. Il ne s'agit pas d'une lacune mineure dans la mise en œuvre. Il s'agit du principal défi technique de la catégorie. (arXiv)

La bonne façon d'envisager un pentester IA en 2026 n'est donc pas de le considérer comme un robot consultant ni comme un chatbot jouet. Il est préférable de la considérer comme un système régi permettant de réduire la distance entre le signal brut et les résultats vérifiés. Parfois, ce système ressemble à un assistant à l'intérieur d'un outil familier. Parfois, il ressemble à un agent à plusieurs étapes. Parfois, il ressemble à un validateur conscient de la source. Parfois, il ressemble à un flux de travail pour tester les systèmes d'IA eux-mêmes. La question de la maturité n'est plus de savoir si la catégorie existe. La question de la maturité est de savoir si le système qui l'entoure est suffisamment discipliné pour mériter votre confiance.

Lectures complémentaires et liens de référence

• PentestGPT, document USENIX Security 2024 (USENIX)
• Banc d'essai AutoPenBench pour les agents génératifs dans les tests de vulnérabilité (Anthologie de l'ACL)
• PentestEval, un outil de référence pour l'évaluation du pentesting LLM au niveau des étapes et de bout en bout (arXiv)
• OWASP Web Security Testing Guide (Fondation OWASP)
• NIST SP 800-115, Guide technique pour les tests et l'évaluation de la sécurité de l'information (Centre de ressources en sécurité informatique du NIST)
• NIST AI RMF Profil d'IA générative (Publications du NIST)
• Aide-mémoire de l'OWASP sur la sécurité des agents d'intelligence artificielle (Série d'aide-mémoire de l'OWASP)
• Spécification du modèle de protocole contextuel et meilleures pratiques en matière de sécurité (Modèle Contexte Protocole)
• MITRE ATLAS pour les techniques d'intelligence artificielle contradictoire (MITRE ATLAS)
• Unité 42 de Palo Alto Networks sur l'injection indirecte d'invite sur le web observée dans la nature (Unité 42)
• Bugcrowd Dans la tête d'un hacker 2026 (Bugcrowd)
• CVE-2025-3248, RCE non authentifié de Langflow (GitHub)
• CVE-2026-33017, Langflow public flow build RCE (GitHub)
• CVE-2026-4270, contournement de la restriction d'accès aux fichiers du serveur AWS API MCP (Amazon Web Services, Inc.)
• CVE-2026-26118, Azure MCP Server SSRF (NVD)
• CVE-2026-31951, LibreChat MCP header injection and token theft (NVD)
• CVE-2025-2867, problème d'exposition des données de GitLab Duo avec Amazon Q (NVD)
• CVE-2024-3400, PAN-OS GlobalProtect RCE (NVD)
• CVE-2023-46604, Apache ActiveMQ OpenWire RCE (NVD)
• CVE-2024-3094, compromission de la chaîne d'approvisionnement de XZ Utils (NVD)
• AI Pentest Tool, What Real Automated Offense Looks Like in 2026 (Penligent)
• Pentest AI, Ce qui compte vraiment en 2026 (Penligent)
• AI Pentest Copilot, des suggestions intelligentes aux conclusions vérifiées (Penligent)