Cybersécurité IA Au-delà des CTF, ce que l'IPE signifie pour un véritable pentesting

La partie facile est terminée. En 2026, le monde de la sécurité aura déjà vu suffisamment de démonstrations d'IA capables d'expliquer une charge utile, de rédiger une preuve de concept, de résumer une requête Burp ou de résoudre un défi CTF bien cadré. La question la plus difficile est de savoir si tout cela survit au contact d'un véritable engagement autorisé, où le champ d'application est important, l'état dérive, les preuves doivent être préservées, les outils peuvent causer des dommages et chaque réclamation finit par atterrir sur le bureau d'un ingénieur. C'est là que l'attention récente portée à l'IA en matière de cybersécurité, et en particulier à l'IAO, commence à être importante. L'IAO n'est pas intéressante parce qu'elle prouve qu'un LLM peut "pirater". Elle est intéressante parce qu'elle regroupe la capacité du modèle, l'accès aux outils, l'interruption humaine, les intégrations externes et les réclamations fondées sur des critères de référence en quelque chose de beaucoup plus proche d'un modèle opérationnel pour le travail de sécurité qu'une fenêtre de chat ou un assistant à usage unique. (GitHub)

Cela ne signifie pas que le problème est résolu. En fait, c'est le contraire qui est vrai. Les recherches récentes les plus crédibles vont à l'encontre de l'histoire marketing la plus bruyante. Les critères de référence en matière de cybersécurité sont de plus en plus difficiles, et non de plus en plus faciles. Le succès d'un CTF de type Jeopardy ne se transfère pas proprement à un travail offensif en plusieurs étapes. Les formats d'attaque et de défense révèlent des faiblesses que les défis simples dissimulent. La reproduction à grande échelle des vulnérabilités du monde réel reste difficile. Et lorsque les agents d'IA sont testés contre des professionnels humains dans des environnements réels, le résultat n'est pas "les humains sont obsolètes". Le résultat est une division plus intéressante : les agents sont de plus en plus forts dans l'énumération systématique, la parallélisation et la rentabilité, tout en restant faibles dans les domaines où le pentesting réel devient désordonné, ambigu, visuel ou sensible au contexte. (arXiv)

C'est le bon cadre pour l'IPE. Il ne s'agit pas d'une mascotte pour l'offensive autonome, ni d'un raccourci pour contourner la discipline du pentest, mais d'un des exemples les plus clairs de la direction que prend l'IA en matière de cybersécurité : s'éloigner des astuces isolées "l'IA fait de la sécurité" et s'orienter vers des flux de travail délimités, porteurs de preuves et reliés à des outils. (GitHub)

L'IA en matière de cybersécurité n'est pas seulement un scanner plus intelligent

Une grande partie de la confusion vient du fait que des produits très différents sont regroupés sous la même étiquette. Un scanner avec une couche sommaire LLM n'est pas la même chose qu'un agent de codage. Un agent de codage n'est pas la même chose qu'un échafaudage de la CTF. Un échafaudage CTF n'est pas la même chose qu'un véritable flux de travail de pentest. Ils peuvent tous impliquer des modèles de langage, mais ils résolvent des problèmes différents, échouent de manières différentes et méritent d'être jugés sur la base de preuves différentes. Les recherches menées au cours des deux dernières années rendent cette disparité évidente. Le PentestGPT a montré très tôt que l'échafaudage de modèles pouvait être plus performant que l'incitation brute dans les tâches de type pentest, mais les travaux ultérieurs tels que CAIBench, CyberGym, les études en plusieurs étapes de la gamme cybernétique et les évaluations d'entreprises en direct indiquent tous la même leçon profonde : la variable importante n'est plus seulement le modèle de base. C'est le système qui entoure le modèle. (USENIX)

Une façon utile d'envisager l'IA en matière de cybersécurité est de se demander quel type de vérité le système peut réellement produire. Peut-il produire une explication claire d'une vulnérabilité ? C'est précieux, mais cela reste du langage. Peut-il produire une chaîne d'exploitation plausible ? C'est mieux, mais cela reste une hypothèse. Peut-il exécuter une action d'outil limitée contre une cible autorisée, préserver le résultat brut, récupérer en cas d'échec et rendre le résultat rejouable par un autre humain ? Cela se rapproche beaucoup plus des tests de pénétration. La plupart des produits sur le marché n'échouent pas parce qu'ils manquent d'intelligence dans l'abstrait. Ils échouent parce qu'ils ne font pas la différence entre suggestion et preuve. (arXiv)

La distinction est encore plus importante lorsque les outils entrent en jeu. À partir du moment où un modèle peut toucher un shell, un flux de travail connecté à un navigateur, un proxy, un exécuteur de code ou une cible distante, le système n'est plus jugé uniquement en tant qu'application d'IA. Il est jugé comme un composant de sécurité opérationnelle. Cela change complètement la norme. Désormais, les questions pertinentes ne sont pas "Connaît-il le SSRF ?" ou "Peut-il écrire du Python ?" mais "Peut-il rester dans le champ d'application ?", "Puis-je l'interrompre ?", "Conserve-t-il des preuves ?", "Distingue-t-il un problème suspect d'un problème vérifié ?", et "Que se passe-t-il lorsque du contenu hostile atterrit dans le flux d'invite ?". Il s'agit là de questions relatives au flux de travail, et non d'éléments de comparaison. (GitHub)

Le tableau ci-dessous est un bon moyen de vérifier si tout va bien.

Type de système	Ce qu'il fait généralement bien	Ce qu'il ne prouve pas	Une valeur réelle pour les équipes de pentesting
Scanner avec résumé AI	Regrouper les résultats, les résumer, rédiger le texte de remédiation	Le problème est exploitable, de grande ampleur, reproductible ou hautement prioritaire.	Accélère le triage et améliore la lisibilité
Agent de codification	Raisonnement tenant compte des références, tests locaux, génération rapide de scripts, suggestions de correctifs	Qu'un problème lié à la cible soit validé par rapport à un système réel.	Fort pour le travail en boîte blanche, l'examen du code, la reproduction locale
Agent de la FFC	Utilisation structurée d'outils, résolution de problèmes, élaboration d'exploits dans le cadre de règles contraignantes	Que l'agent gère la portée réelle, l'état désordonné ou la complexité de l'entreprise	Bon pour l'exploration des capacités et la recherche
Système de pentest natif pour le flux de travail	Validation en plusieurs étapes, actions axées sur la cible, collecte de preuves, aide au retest	Qu'il est sûr par défaut ou suffisamment mature sans gouvernance	Utile lorsqu'il préserve la preuve et le contrôle
Échafaudage d'agents de référence pour la recherche	Comparaison contrôlée des modèles et des échafaudages entre les tâches	Que ses résultats soient transférés proprement dans votre environnement	Précieux pour la mesure, moins pour l'orientation directe du déploiement

C'est pourquoi l'IA en matière de cybersécurité est devenue un pôle de recherche et de discussion si important. Les praticiens ne sont pas vraiment à la recherche d'une "IA qui connaît les faits en matière de sécurité". Ils recherchent des systèmes capables de transmettre le contexte d'un outil à l'autre, de préserver suffisamment d'état pour continuer à avancer et de laisser derrière eux suffisamment de preuves pour justifier une action. (arXiv)

CAI, la partie qui compte, c'est le flux de travail

Alias Robotics décrit CAI comme un cadre léger et open-source pour l'automatisation de la sécurité offensive et défensive. Dans son référentiel public et son matériel produit, le projet met l'accent sur plusieurs choix structurels qui sont plus importants que la marque elle-même : une conception basée sur l'agent, la prise en charge de nombreux modèles sous-jacents grâce à LiteLLM, des outils intégrés, le traçage, l'intégration MCP et un principe de conception explicite "l'humain dans la boucle". La clause de non-responsabilité publique va plus loin et présente la CAI comme un outil d'évaluation de la cybersécurité fonctionnant selon le principe de "l'homme dans la boucle", ce qui est exactement le type de langage qui compte lorsque les modèles cessent d'être des assistants passifs et commencent à toucher les systèmes. (GitHub)

Ces détails ne sont pas superficiels. Un système d'IA viable dans le domaine de la cybersécurité doit comporter au moins six couches. La première est une couche de modèle, où se déroulent le raisonnement, la planification, la génération de code et la synthèse. La deuxième est une couche d'orchestration qui décide comment les tâches sont décomposées, comment l'état est préservé et quand le modèle doit appeler les outils. La troisième est la couche d'outils proprement dite, où les fonctions shell, web, proxy ou personnalisées sont disponibles. La quatrième est une couche de mémoire et d'état qui empêche l'agent d'oublier ce qui s'est déjà passé. La cinquième est une couche de preuves, où les résultats deviennent traçables plutôt que conversationnels. La sixième est la couche de contrôle humain, où la portée, l'approbation, l'interruption et la discipline de retest vivent. Si l'on supprime l'un de ces éléments, le système peut encore paraître impressionnant, mais il ne ressemble plus à un pentesting fiable. (GitHub)

Vue sous cet angle, l'IAO est mieux comprise comme un cadre qui tente de résoudre le milieu du travail. Il ne s'agit pas uniquement du problème du renseignement brut, ni du problème du formatage du rapport final, mais de l'espace difficile entre les deux, où l'opérateur a besoin d'un modèle pour garder le cap tout en croisant plusieurs outils, plusieurs virages et plusieurs petites décisions. C'est également la raison pour laquelle les documents publics de l'IPE s'appuient si fortement sur l'utilisation de la ligne de commande, la connectivité MCP et les fonctions de flux de travail plutôt que sur une interface unique d'"assistant d'intelligence artificielle". Une ligne de commande n'est pas très glamour, mais elle permet de créer des états, elle est composable, elle peut être interrompue et elle est familière aux opérateurs de sécurité sérieux. (news.aliasrobotics.com)

Le référentiel actuel de la CAI montre également pourquoi le terme "Cybersecurity AI" est plus utile que la CAI seule. Le terme "CAI" en lui-même est bruyant dans l'écosystème de l'information au sens large, où le même acronyme est utilisé pour désigner les informations commercialement disponibles dans la politique de renseignement des États-Unis. En revanche, "Cybersecurity AI" est beaucoup plus spécifique à cette catégorie émergente d'outils de sécurité basés sur des modèles et des flux de travail. C'est l'une des raisons pour lesquelles les termes de recherche et de publication les plus forts autour du sujet ne sont pas seulement "CAI", mais des expressions telles que Cybersecurity AI, AI security agent, AI pentesting CLI, et agentic security workflows. (Intelligence)

Un modèle mental plus utile consiste à considérer la CAI comme un exemple d'une catégorie plus large. Vous pouvez ou non choisir l'IPE elle-même. Vous pouvez préférer un autre échafaudage, un autre produit ou une construction interne. La vraie question est de savoir si le système que vous utilisez se comporte comme un flux de travail ou comme une démo. Le flux de travail est synonyme d'exécution limitée, de conservation des preuves, de rejouabilité, d'interruption et de séparation entre l'hypothèse et la preuve. Démonstration signifie texte intelligent et hypothèses optimistes. (GitHub)

Pourquoi les critères d'évaluation de l'IA dans le domaine de la cybersécurité vont-ils au-delà des CTF de type Jeopardy ?

L'histoire de référence de l'IA en matière de cybersécurité a mûri plus vite que la plupart des gens ne le pensent. L'enthousiasme initial est venu des systèmes capables de résoudre des tâches de type défi mieux que les modèles bruts. Le PentestGPT a été un moment important parce qu'il a montré l'importance de l'échafaudage : le document a fait état d'une augmentation de 228,6 % de l'achèvement des tâches par rapport au GPT-3.5 sur ses cibles de référence et a démontré des performances utiles sur des cibles et des CTF du monde réel. Ce n'était pas l'état final du domaine, mais c'était une preuve importante que le travail de pentesting-adjacent n'était pas seulement une question de QI de modèle. Il s'agit de la manière dont l'opérateur et l'échafaudage gèrent le travail. (USENIX)

L'étape suivante a consisté à réaliser que de nombreux critères de référence courants étaient encore trop étroits. CAIBench est l'une des formalisations les plus claires de ce problème. Ses auteurs affirment que la mesure de la pertinence du travail dans le domaine de la cybersécurité ne peut être réduite à un seul type de défi ou à des questions et réponses statiques en matière de sécurité. Le benchmark intègre plus de 10 000 instances réparties en cinq catégories : FFC de type Jeopardy, FFC d'attaque et de défense, exercices en ligne, tests de connaissances et évaluations de la protection de la vie privée. Les résultats de l'article sont révélateurs : les performances en matière de connaissances commencent à saturer, mais les performances se dégradent fortement dans les contextes d'adversité à plusieurs étapes, et le couplage échafaudage-modèle peut faire varier les résultats de manière substantielle. (arXiv)

C'est précisément la raison pour laquelle l'affirmation selon laquelle "les FFC sont résolues" doit être plus nuancée que ne le font généralement les auteurs de gros titres. L'article de l'IPE sur les FFC fait état de résultats de première place ou de premier rang dans plusieurs circuits 2025 et affirme que les FFC de type Jeopardy sont devenues un jeu résolu pour les agents bien conçus. Cela peut être vrai pour un sous-ensemble de formats de défis, en particulier ceux qui récompensent un raisonnement rapide et localisé. Mais les mêmes auteurs ont également contribué à la publication de travaux montrant que les paramètres d'attaque et de défense se comportent différemment. Dans une étude contrôlée sur l'attaque et la défense, les agents défensifs ont obtenu de meilleurs résultats en matière de correctifs sans contrainte que l'accès initial offensif, mais cet avantage a disparu une fois que des contraintes opérationnelles réelles telles que la disponibilité des services et la prévention complète des intrusions ont été imposées. Il s'agit là d'un résultat bien plus réaliste que "l'IA offensive gagne" ou "l'IA défensive gagne". Il montre que l'environnement et la métrique sont importants. (arXiv)

Le domaine s'est ensuite déplacé à nouveau. CyberGym a déplacé l'accent de la résolution de défis vers la reproduction à grande échelle de vulnérabilités du monde réel. Dans sa dernière version arXiv, les auteurs décrivent 1 507 vulnérabilités réelles dans 188 projets logiciels et indiquent que même les combinaisons les plus performantes n'atteignent qu'un taux de réussite d'environ 20 %. Dans le même temps, le benchmark a permis de découvrir 34 zero-day et 18 correctifs historiquement incomplets. Cette combinaison est importante. Elle montre pourquoi l'IA actuelle en matière de cybersécurité est à la fois plus performante et moins "aboutie" que ne le suggère une couverture simpliste. Les agents peuvent avoir un impact réel, mais seulement dans une minorité de cas dans un environnement réaliste à grande échelle. (arXiv)

La comparaison directe entre les agents et les professionnels dans un environnement d'entreprise réel est sans doute l'étude qui donne le plus à réfléchir. Dans cette étude, les chercheurs ont évalué dix professionnels de la cybersécurité et plusieurs agents, dont ARTEMIS, sur un réseau universitaire réel comprenant environ 8 000 hôtes répartis sur 12 sous-réseaux. ARTEMIS s'est classé deuxième au classement général, a trouvé neuf vulnérabilités valables, a atteint un taux de soumission valide de 82 % et a surpassé neuf des dix participants humains. Mais l'article ne dit pas que "les humains sont finis". Il a également constaté que les échafaudages prêts à l'emploi étaient à la traîne, que les agents produisaient toujours plus de faux positifs et que les tâches nécessitant une interface graphique restaient difficiles. Ce qu'il faut retenir, ce n'est pas le battage médiatique. C'est qu'un système d'agents soigneusement conçu peut être très compétitif dans certaines catégories de travail tout en étant structurellement peu fiable dans d'autres. (arXiv)

La pile de référence ressemble maintenant à ceci.

Critère de référence ou étude	Ce qu'il mesure	Ce dont il se rapproche dans le travail réel	Ce qui manque encore
PentestGPT	Achèvement des tâches du pentest avec échafaudage, flux de travail de type défi	L'importance de l'orchestration et de la gestion des étapes	Complexité de la production à grande échelle et exigences élevées en matière de preuves
Résultats du FCT de l'IPE	Défis à grande vitesse sur les principaux circuits de la FCT	Raisonnement d'exploitation rapide dans le cadre des règles de concurrence	Contrôle de la portée de l'entreprise, état désordonné de plusieurs systèmes, discipline en matière de rapports
Évaluation du FFC A&D	Attaque et défense simultanées sous contraintes	Raisonnement adaptatif sous pression contradictoire	Logique commerciale complète, risque client réel, processus organisationnel
CAIBench	Évaluation multi-catégories de la cybersécurité sur plus de 10 000 instances	Meilleure mesure de la variété liée au travail	Il s'agit toujours d'un point de référence, et non de votre environnement
CyberGym	Reproduction de vulnérabilités réelles et génération de PoC à travers 188 projets	Un plus grand réalisme pour les flux de travail en matière de sécurité des logiciels	Principalement axé sur le code, moins sur le web et les facteurs humains.
Entreprise en direct comparaison humaine	Agents contre professionnels sur un vrai réseau	Plus proche de l'économie et de la qualité du pentesting réel	Un seul environnement, un échantillon limité, un contexte encore expérimental

Ce qui importe pour les acheteurs et les constructeurs, c'est que l'IA en matière de cybersécurité n'est plus une question de savoir si les modèles peuvent aider. Ils le peuvent. La question est de savoir où les preuves de référence sont réellement transférées. Une victoire à Jeopardy CTF peut signifier beaucoup pour la vitesse de l'outil et le raisonnement local. Cela ne signifie pas automatiquement qu'un système peut préserver la portée, gérer l'état d'authentification, éviter les actions destructrices ou produire une conclusion qui survit à un nouveau test dans une application commerciale. (arXiv)

Le pentesting réel permet encore de briser les systèmes d'IA faibles en matière de cybersécurité

Dès que l'on sort de l'abstraction de référence, le pentesting devient très vite étrange. Les flux d'authentification sont fragiles. L'état de la session est incohérent. La logique d'entreprise s'étend sur plusieurs rôles et fenêtres temporelles. Les cibles changent au milieu de l'engagement. Les découvertes qui semblent évidentes dans le code s'évaporent lorsqu'un drapeau de déploiement est différent dans la production. Les chaînes d'exploitation en plusieurs étapes échouent pour des raisons ennuyeuses : un en-tête a été normalisé, une file d'attente a été retardée, un WAF a limité le taux du chemin, ou le rôle de l'utilisateur "vulnérable" n'existait pas sur le locataire cible. Il ne s'agit pas de cas exceptionnels. Il s'agit de la texture normale d'un test réel.

C'est là que la récente recherche sur les entreprises réelles est utile. La comparaison entre l'homme et l'agent a révélé une forte performance de l'agent dans l'énumération systématique et l'exploitation parallèle, mais aussi des taux de faux positifs plus élevés et une performance plus faible dans les tâches basées sur l'interface graphique. Cela correspond étroitement à ce que de nombreux opérateurs ressentent déjà intuitivement. Les agents sont plus performants lorsque la vérité est essentiellement textuelle, essentiellement dénombrable, essentiellement sérialisable et essentiellement accessible par le biais d'une surface d'outil propre. Ils s'affaiblissent lorsque le travail nécessite une inspection visuelle subtile, une synchronisation délicate des interactions, un comportement ambigu du produit ou une lecture sociale attentive de ce qu'un flux d'activité est censé faire. (arXiv)

Le même schéma se retrouve dans les travaux sur les champs d'action cybernétiques. Une récente étude sur les cyber-attaques en plusieurs étapes a évalué sept modèles frontières sur un réseau d'entreprise à 32 étapes et un ICS à 7 étapes. Les auteurs ont observé que les performances s'amélioraient à la fois avec les nouveaux modèles et avec des budgets de temps d'inférence plus importants, et que la meilleure exécution permettait de réaliser 22 étapes sur 32 dans le scénario du réseau d'entreprise. Il s'agit là d'une capacité sérieuse. Il ne s'agit pas non plus d'une autonomie totale. Le scénario du contrôle industriel est resté beaucoup plus faible, et l'étude présente explicitement ces environnements comme étant encore plus simples que des opérations réelles entièrement défendues. C'est précisément à ce niveau que de nombreuses descriptions de produits deviennent trompeuses. (arXiv)

L'affirmation honnête est donc plus restreinte et plus utile : L'IA en matière de cybersécurité est en train de devenir performante en matière de travail offensif structuré, et non de remplacer comme par magie l'ensemble de la profession de testeur. Elle s'améliore en matière de triage, d'énumération, de planification des branches d'exploitation, de répétition et de formatage des preuves. Il n'est pas encore uniformément fiable en matière de jugement dans l'incertitude. C'est pourquoi les systèmes qui méritent notre attention ne sont pas ceux qui ont les revendications d'autonomie les plus folles. Ce sont ceux qui exposent plus de contrôle, plus d'auditabilité et plus de relecture. (arXiv)

Une version pratique de cette division se présente comme suit.

Forme de la tâche	Les agents sont souvent doués pour	Les agents restent souvent faibles à	L'examen humain reste le plus important
Reconnaissance	Regroupement des actifs, examen des en-têtes et des modèles de réponse, cartographie des itinéraires, découverte des paramètres	Distinguer le bruit du signal critique pour l'entreprise	Décider ce qui vaut la peine d'être poursuivi
Validation en boîte blanche	Navigation dans le code, raisonnement de type grep, rédaction locale de harnais, direction des correctifs	Prouver l'exploitabilité dans un environnement réel	Distinguer le probable du vérifié
Tests en ligne	Répétition des demandes, génération de permutations, branches fuzz multi-paramètres	Abus de la logique d'entreprise, cas étranges d'authentification, flux de travail à interface graphique uniquement	Confirmation de l'impact et réalisme de la chaîne
Rapports	Normalisation des résultats, projet de remédiation, mise en forme des récits de preuves	Vérité de terrain, jugement de gravité, nuance environnementale	Formulation finale et hiérarchisation
Engagements de longue durée	Maintien de listes de tâches étendues, réutilisation de modèles, exploration parallèle	Dérive de l'état, empoisonnement du contexte, excès de confiance après des victoires partielles	Discipline en matière de pilotage, d'interruption et de nouveau test

Les mises à jour publiques de l'IPE prennent tout leur sens dans ce contexte. La version 1.0 met l'accent sur la convivialité, la cohérence des longues sessions, la sélection automatisée des agents et une meilleure compatibilité avec MCP et Burp Suite. Il s'agit là du type d'améliorations qui comptent dans les opérations réelles, car elles ciblent le milieu fragile du flux de travail plutôt que les demandes de renseignements bruts. Un assistant de pentest qui oublie ce qui s'est déjà passé est beaucoup moins utile qu'un assistant qui raisonne un peu moins bien mais qui préserve la cohérence à travers des heures de travail. (news.aliasrobotics.com)

À quoi ressemble une pile d'IA utilisable dans le domaine de la cybersécurité ?

Une pile utilisable commence par l'autorisation, et non par le renseignement. Avant la première demande, quelqu'un doit définir la cible, le champ d'application, les techniques autorisées, le délai, les règles d'approbation et les normes en matière de preuves. Ce n'est pas de la bureaucratie. C'est le cadre qui permet à un système d'IA de passer d'une capacité d'attaque polyvalente à un travail de sécurité légitime. Dès que ce cadre est affaibli, chaque amélioration du modèle devient un multiplicateur de responsabilité plutôt qu'un gain de productivité. Le profil Cyber AI du NIST existe exactement pour ce type de problème : aider les organisations à appliquer une structure commune de gestion des risques au chevauchement entre l'IA et la cybersécurité, y compris des questions telles que l'injection rapide, l'empoisonnement des données, l'apport de l'adversaire, la récupération et l'apprentissage par incident. (nvlpubs.nist.gov)

Après l'autorisation vient la reconnaissance, et c'est là que de nombreux systèmes d'IA devraient passer plus de temps qu'ils ne le font. Les documents publics de Penligent font ressortir un point utile sans trop de battage médiatique : l'offensive agentique devient plus digne de confiance lorsqu'elle est axée sur la reconnaissance, la prise en compte de la politique et les preuves plutôt que sur l'exploitation. Cela semble conservateur, mais c'est en fait ce qui rend le flux de travail plus puissant. Un planificateur qui établit les itinéraires, les identités, les flux de données et les limites du champ d'application avant le début des tests actifs est moins susceptible de perdre du temps, de casser des choses ou d'étiqueter à tort le bruit comme un impact. Les écrits publics de Penligent formulent le problème de la même manière : le flux de travail est important parce que le rapport n'est utile que si les preuves survivent à un nouveau test. (penligent.ai)

Vient ensuite l'exécution limitée. L'agent a besoin d'un accès suffisant aux outils pour valider quelque chose de réel, mais pas d'une liberté telle que chaque entrée hostile devienne un chemin vers l'hôte ou la mauvaise cible. C'est l'une des raisons pour lesquelles l'évolution vers des couches d'abstraction d'outils telles que MCP est importante. Lorsqu'elle est utilisée correctement, la MCP normalise la façon dont les modèles se connectent aux outils et aux données externes. La spécification officielle le définit comme un protocole ouvert pour l'intégration d'applications LLM avec des sources de données et des outils externes, et ses documents d'autorisation indiquent clairement que la sécurité et les limites de confiance sont des préoccupations de premier ordre, et non des éléments facultatifs à prendre en compte après coup. La normalisation est utile. Elle n'est pas synonyme de sécurité. (modelcontextprotocol.io)

Vient ensuite la préservation des preuves. C'est la différence entre une conversation intelligente et un artefact d'engagement crédible. L'article récent de Penligent sur les rapports de pentest d'IA le montre bien : un rapport n'est utile que si un autre humain peut en vérifier la portée, reproduire le comportement et agir en fonction du résultat. Cette norme devrait être appliquée bien plus tôt que le rapport. Elle devrait façonner l'ensemble du flux de travail. Une découverte ne devrait passer du statut d'hypothèse à celui de candidat au rapport que lorsque les traces brutes, les commandes, les requêtes, les réponses et les conditions environnementales sont suffisamment bien préservées pour être rejouées. (penligent.ai)

Une structure de preuve simple est souvent préférable à une structure élaborée.

TARGET="app.example.com"
RUN_ID="$(date +%F-%H%M%S)"
ROOT="evidence/${TARGET}/${RUN_ID}"

mkdir -p "${ROOT}/http" "${ROOT}/notes" "${ROOT}/screens" "${ROOT}/cmd"

# Enregistrer les commandes brutes au fur et à mesure qu'elles se produisent
script -q "${ROOT}/cmd/session.log"

# Sauvegarde des requêtes et réponses HTTP copiées
# Stocker chaque chemin candidat dans sa propre paire de fichiers
# Exemples de noms de fichiers :
# ${ROOT}/http/001-login-request.txt
# ${ROOT}/http/001-login-response.txt

# Conserver un fichier de notes par candidat à la recherche
touch "${ROOT}/notes/candidat-001.md"

Rien dans cet exemple n'est prestigieux. Et c'est bien là l'essentiel. La discipline des preuves devrait être ennuyeuse. Si un flux de travail ne peut pas rester aussi simple et reproductible, il n'est pas prêt à produire des déclarations officielles sur le niveau de sécurité.

Enfin, il y a la phase de retest et de transfert. C'est à ce stade que de nombreux systèmes d'IA révèlent s'ils ont été conçus pour des démonstrations ou pour des opérations. Le système peut-il réexécuter uniquement le chemin de la preuve ? Peut-il vous dire ce qui a changé entre la tentative ratée et la tentative réussie ? Peut-il distinguer le "paramètre potentiellement vulnérable" de la "condition d'exploitation vérifiée" ? Peut-il produire un enregistrement que les équipes d'ingénierie ou de conformité peuvent utiliser sans avoir à lire tout l'historique de la session ? Il s'agit là de questions relatives à la conception du flux de travail, et non de questions relatives au modèle. Les produits et les cadres les plus solides dans ce domaine le reconnaissent de plus en plus. (penligent.ai)

Utilisation de la CAI avec MCP et Burp, une surface de contrôle pratique

C'est l'une des parties les plus intéressantes de la documentation publique de la CAI, car elle montre comment Cybersecurity AI commence à se connecter aux outils auxquels les pentesters font déjà confiance. Le README de la CAI documente la prise en charge du Model Context Protocol avec les transports SSE et STDIO, et fournit un exemple de chargement d'un serveur MCP et d'attachement des outils résultants à un agent. L'exemple utilise Burp, ce qui n'est pas un hasard. Burp est utile parce qu'il se trouve directement à l'endroit où de nombreuses découvertes sur le web deviennent réelles : requêtes interceptées, manipulation de paramètres, soumissions répétées, vérification des questions et séquençage des requêtes. (GitHub)

Le chemin d'installation est simple dans les documents publics.

python3.12 -m venv cai_env
source cai_env/bin/activate
pip install cai-framework

cat > .env <<'EOF'
OPENAI_API_KEY="sk-1234"
ANTHROPIC_API_KEY=""
OLLAMA=""
PROMPT_TOOLKIT_NO_CPR=1
CAI_STREAM=false
EOF

cai

Cet exemple public est utile pour une raison plus qu'une autre : il montre que le système ne prétend pas être une boîte noire. Il s'agit d'un cadre qui s'attend à une configuration explicite, à un soutien explicite du modèle et à un démarrage explicite de l'opérateur. (GitHub)

L'exemple le plus important d'un point de vue opérationnel est le modèle de connexion MCP.

CAI>/mcp load http://localhost:9876/sse burp
CAI>/mcp add burp redteam_agent

Dans l'exemple du référentiel, l'IPE expose ensuite des outils connectés à Burp tels que send_http_request, create_repeater_tab, send_to_intruderet les fonctions connexes d'historique du proxy à l'agent sélectionné. Cela est important car la documentation de PortSwigger définit Repeater comme l'outil permettant de modifier et de renvoyer des requêtes intéressantes et de vérifier manuellement les problèmes signalés, tandis qu'Intruder est conçu pour des attaques répétées configurables avec insertion de charges utiles. C'est exactement le type d'actions contrôlées et à haut niveau de signal qui rend l'assistance de l'IA utile dans les tests web lorsque l'opérateur a encore besoin d'une surface de vérification solide. (GitHub)

Ce n'est pas le fait que l'agent puisse "utiliser Burp" qui fait la force de ce système. Les humains le peuvent déjà. La puissance réside dans une répartition plus disciplinée du travail. Le modèle peut décider ce qu'il faut inspecter ensuite, regrouper les branches, ébaucher les mutations des paramètres candidats et assurer la cohérence de la narration locale. Burp reste la surface de test concrète où l'opérateur peut voir, rejouer, contraindre et vérifier. C'est une bien meilleure conception que de demander à un modèle d'exploiter le web à main levée à partir de la mémoire et de la chance. (portswigger.net)

Le piège est cependant évident. Chaque fois qu'un modèle obtient l'accès à un outil, les limites de l'outil deviennent une partie de votre modèle de menace. La spécification MCP elle-même traite la sécurité et la confiance comme une préoccupation de premier ordre, et son projet d'autorisation note que l'autorisation est facultative pour les implémentations MCP, avec des attentes différentes pour les transports basés sur HTTP et STDIO. Il s'agit là d'une flexibilité utile pour les développeurs, mais cela signifie également que les équipes ne peuvent pas supposer que le protocole lui-même les protégera d'une surexposition. Un serveur faible, une politique client négligente ou un environnement trop permissif peuvent toujours transformer une "intégration utile" en un pont de privilèges. (modelcontextprotocol.io)

Un modèle de politique minimal pour les outils liés à des agents devrait ressembler davantage à ceci qu'à une autorisation générale.

champ d'application :
  allowed_hosts :
    - app.example.com
    - api.example.com
  blocked_hosts :
    - "*.corp.internal"
    - metadata.google.internal
outils :
  allow :
    - burp_repeater
    - burp_proxy_history_read
    - web_fetch
  requiert l'approbation de l'homme :
    - burp_intruder
    - shell_exec
    - ssh_tunnel
preuves :
  save_raw_http : true
  save_tool_output : true
  require_finding_id_before_export : true
exécution :
  destructive_actions : deny
  max_parallel_requests : 5

Il ne s'agit pas d'un format spécifique à un fournisseur. Il s'agit d'une forme de politique. Ce qu'il faut retenir, c'est qu'une bonne IA en matière de cybersécurité ne se limite pas à ce que l'agent peut faire. Il s'agit de ce que le système refuse de laisser faire à l'agent sans le consentement explicite de l'homme.

Les preuves d'abord, la différence entre une démonstration de sécurité de l'IA et un engagement réel

Les écrits publics les plus convaincants des fournisseurs de tests d'IA pratiques convergent vers la même idée. Le pipeline d'artefacts est aussi important que le routeur de modèles. La page d'accueil publique de Penligent met l'accent sur les flux de travail contrôlés par l'opérateur et le contrôle humain dans la boucle, tandis que son blog technique affirme à plusieurs reprises qu'un rapport de pentest d'IA n'est utile que s'il survit à un nouveau test et qu'un flux de travail doit conserver suffisamment de matière première pour rejouer une découverte plus tard. Il ne s'agit pas de petits détails. Ils constituent la ligne de démarcation entre un système qui génère de la confiance et un système qui génère du théâtre. (penligent.ai)

C'est ce même principe qui permet d'évaluer la CAI et les cadres similaires. Supposons qu'un agent déclare avoir trouvé un IDOR. Que doit-il y avoir avant que cette déclaration ne devienne un produit livrable ? Au minimum, le contexte de l'identité cible, la requête exacte, la mutation effectuée, le delta de la réponse, les conditions préalables, le modèle de privilège, la description de l'impact et un chemin de relecture qu'un autre testeur peut suivre. La plupart des systèmes d'intelligence artificielle sont très doués pour transformer des preuves peu convaincantes en un texte soigné. Très peu d'entre eux sont naturellement disciplinés pour refuser d'escalader une réclamation jusqu'à ce que les preuves dépassent un certain seuil. Cette discipline doit venir du flux de travail. (penligent.ai)

C'est également à ce niveau que la distinction entre "agent d'IA et plateforme de pentest" devient utile. Public Penligent material, par exemple, fait une distinction nette entre la capacité brute d'un agent et le flux de travail d'un pentest fini, en faisant valoir que le plus difficile n'est pas de produire la prochaine commande, mais de préserver la direction, les preuves et le contrôle. C'est la bonne distinction à appliquer à l'ensemble de la catégorie. Un agent de codage peut être excellent dans la génération d'hypothèses. Un système natif de flux de travail peut être moins flexible mais bien meilleur pour transformer le signal en résultats vérifiés et les résultats vérifiés en artefacts pouvant faire l'objet d'un rapport. Les équipes matures utiliseront de plus en plus les deux, mais seulement si elles séparent ces rôles. (penligent.ai)

Une règle opérationnelle utile est simple : chaque phrase importante doit pouvoir être tracée soit à partir de preuves brutes, soit à partir d'un jugement de l'examinateur explicitement documenté, soit à partir d'une référence externe reproductible. Si un flux de travail ne peut pas vous dire lequel de ces trois éléments soutient une affirmation donnée, il n'est pas prêt pour une sortie de sécurité de haute confiance. Cette règle semble élémentaire. En pratique, c'est là que la plupart des systèmes de sécurité assistés par l'IA s'effondrent. (penligent.ai)

Pourquoi l'IA en cybersécurité échoue, l'injection d'invites, l'abus d'outils et les bogues classiques de l'AppSec

L'erreur la plus dangereuse sur ce marché est de penser que l'IA en matière de cybersécurité n'échoue que de manière exotique et nouvelle. Il est vrai qu'elle échoue de façon nouvelle, mais la plupart des échecs les plus horribles sont anciens. L'injection rapide est l'exemple le plus connu de l'IA native. Le Top 10 LLM 2025 de l'OWASP place l'injection rapide en LLM01, et le profil Cyber AI du NIST traite à plusieurs reprises l'injection rapide, l'empoisonnement des données, les intrants adverses et les problèmes connexes comme des risques organisationnels concrets plutôt que comme des curiosités abstraites de la recherche. Le NIST note même que des techniques telles que le jailbreaking et l'injection rapide peuvent émerger des publications sur l'IA et devraient être incorporées dans les renseignements sur les menaces et la formation. (Projet de sécurité Gen AI de l'OWASP)

Mais l'étape la plus importante est celle qui suit. L'injection d'invites devient un problème beaucoup plus grave lorsqu'elle franchit la frontière entre le langage et l'action. La définition de l'OWASP est utile ici parce qu'elle met l'accent sur la concaténation d'entrées non fiables avec des instructions plus fiables. Une fois que cette pile d'instructions de confiance est attachée à une couche d'outils, le contenu hostile ne se contente pas de déformer la sortie du texte. Il peut influencer les recherches du système, les fichiers qu'il ouvre, les commandes qu'il exécute ou les cibles qu'il touche. Il ne s'agit pas d'un problème d'"hallucination de l'IA". Il s'agit d'un problème de plan de contrôle. (csrc.nist.gov)

Les travaux du NIST de janvier 2025 sur le détournement d'agents disent tout haut ce qui est tout bas : de nombreux agents d'intelligence artificielle sont vulnérables au détournement par l'injection indirecte d'invites, lorsque des instructions malveillantes sont cachées dans le contenu ingéré et que l'agent est poussé à des actions involontaires. Dans un flux de travail de sécurité, ce risque s'aggrave car l'agent peut déjà disposer d'outils privilégiés, d'un accès au réseau, d'un accès au système de fichiers ou de la possibilité d'appeler des fonctions personnalisées. Le problème n'est plus seulement que "le modèle a cru à quelque chose de stupide". Le problème est que le système a fait confiance au modèle à la mauvaise limite. (NIST)

L'historique des avis publics de la CAI nous rappelle utilement que les cadres d'IA de cybersécurité héritent également des modes d'échec ordinaires en matière de sécurité des applications. En janvier 2026, un avis revu par GitHub a révélé l'injection de commandes par l'intermédiaire de l'injection d'arguments dans l'application find_file() de l'agent de sécurité. Le résumé indique que les données d'entrée contrôlées par l'utilisateur ont été transmises directement aux commandes de l'interpréteur de commandes par l'intermédiaire de l'outil sous-processus.Popen() avec shell=Truepermettant l'exécution de commandes arbitraires sur le système hôte. Il ne s'agit pas d'un nouveau modèle de pathologie. Il s'agit d'une injection classique dans une enveloppe d'outil, rendue plus dangereuse parce que l'enveloppe se trouve derrière une couche d'agent qui peut consommer un contenu non fiable. (GitHub)

Les CVE de Langflow soulèvent la même question sous un autre angle. La CVE-2025-3248 affectait le système /api/v1/validate/code dans Langflow, où un attaquant distant non authentifié pouvait exécuter un code arbitraire. Cette vulnérabilité était importante non seulement parce qu'elle était grave, mais aussi parce qu'elle montrait comment une plateforme d'agent et de flux de travail pouvait devenir une cible directe d'exécution à distance. La CISA l'a ensuite ajoutée au catalogue des vulnérabilités connues et exploitées, ce qui signifie que la vulnérabilité est passée du risque théorique à la pertinence d'une exploitation active. (nvd.nist.gov)

La CVE-2026-27966 est encore plus pertinente pour les flux de travail de l'IA en matière de cybersécurité. NVD le décrit comme un problème de Langflow dans lequel le nœud de l'agent CSV code en dur allow_dangerous_code=Trueexposant l'outil Python REPL de LangChain et permettant l'exécution arbitraire de commandes Python et OS sur le serveur via l'injection d'invite. Il s'agit de l'un des exemples publics les plus clairs de la raison pour laquelle l'"injection d'invite" ne peut pas être traitée comme un simple bogue bizarre de génération de texte. Une fois que l'exécution dangereuse est intégrée dans le flux de travail, l'injection d'invite devient un moyen de compromettre complètement l'hôte. La solution consistait à passer à la version 1.8.0. La leçon de conception est plus importante que le correctif : les outils dangereux ne devraient jamais être connectés de manière occasionnelle ou silencieuse à des canaux d'invite non fiables. (nvd.nist.gov)

CVE-2026-33017 prolonge la même leçon. L'avis public de Langflow décrit un chemin RCE non authentifié dans un point d'extrémité de construction "flux public" où les données de flux contrôlées par l'attaquant et contenant un code Python arbitraire pourraient être exécutées côté serveur sans sandboxing. Le catalogue KEV de la CISA inclut désormais également cette vulnérabilité. Là encore, la pertinence pour l'IA en matière de cybersécurité est directe. Les fonctions pratiques des plateformes d'agents créent souvent les surfaces les plus dangereuses parce qu'elles normalisent l'idée que l'entrée structurée de l'utilisateur est sûre et peut être interprétée en profondeur. Si votre système de flux de travail gère du code, des outils ou des définitions de nœuds, chaque point de terminaison public "utile" devient un élément de votre histoire RCE. (GitHub)

L'audit pratique le plus rapide pour cette catégorie de problèmes reste l'ennuyeux examen statique.

# Recherche de raccourcis d'exécution de l'interpréteur de commandes
grep -R "shell=True" -n .

# Recherchez des outils d'agent qui passent des arguments contrôlés par l'utilisateur dans les commandes
grep -R "subprocess.Popen" -n .
grep -R "os.system" -n .

# Recherche de drapeaux d'exécution dangereuse dans les nœuds d'agent ou de flux de travail
grep -R "allow_dangerous_code=True" -n .
grep -R "exec(" -n .
grep -R "eval(" -n .

Ce n'est pas suffisant pour un véritable audit. Il suffit de savoir si un projet traite le risque d'exécution des outils comme une préoccupation d'ingénierie de premier ordre ou comme une réflexion après coup.

Les CVE qui comptent pour les équipes de cybersécurité et d'intelligence artificielle

Il est utile de ralentir et de se demander pourquoi ces vulnérabilités particulières sont plus instructives qu'une liste aléatoire de bogues graves.

CVE-2025-3248 est important car il rappelle aux équipes que les plateformes de flux de travail d'IA sont toujours des plateformes logicielles. Si elles exposent des fonctionnalités de validation ou d'exécution de code via des points de terminaison Web sans authentification ni isolation appropriées, les attaquants n'ont pas besoin de "battre le modèle". Ils peuvent attaquer directement l'application. Pour les défenseurs, la voie de l'atténuation est conventionnelle : patcher vers une version corrigée, supprimer l'exposition inutile à l'internet, mettre en avant le service avec une authentification appropriée, et surveiller l'abus du point de terminaison vulnérable. L'enseignement organisationnel le plus important est que les plates-formes d'agents doivent faire l'objet d'un inventaire des actifs, d'un renforcement et d'un processus d'examen de l'exposition au même titre que n'importe quel autre plan de gestion sensible. (nvd.nist.gov)

La CVE-2026-27966 est importante parce qu'elle montre la passerelle la plus courte entre le langage de risque spécifique à l'IA et la compromission d'un système ordinaire. L'expression "injection d'invite" semble abstraite jusqu'à ce qu'elle atteigne un outil Python REPL ou un shell. Il s'agit alors d'un problème d'exécution de commande avec un rayon d'action très familier. Les mesures d'atténuation sont également pratiques et ennuyeuses : mise à niveau, désactivation des fonctions d'exécution dangereuses à moins qu'elles ne soient explicitement nécessaires, exécution du flux de travail dans un environnement contraint et conception du système de sorte que le contenu non fiable ne puisse pas approuver silencieusement l'utilisation de son propre outil. (nvd.nist.gov)

CVE-2026-33017 est important parce qu'il met en évidence une tentation récurrente dans la conception des outils d'IA : les surfaces de construction publiques, les points de terminaison "temporaires" ou les API de commodité qui sont supposés être inoffensifs parce qu'ils sont destinés à la configuration plutôt qu'aux opérations de production. Dans les systèmes agentiques, la configuration est souvent une exécution. Une définition de nœud, un graphique de flux ou une description d'outil peuvent être à un pas de parse du code. Les hypothèses classiques sur les interfaces publiques et privées deviennent donc beaucoup plus dangereuses. La gestion des correctifs est toujours importante, mais l'architecture l'est tout autant : il faut éviter de placer les plans de contrôle du flux de travail des agents directement sur l'internet, appliquer l'authentification de manière cohérente et mettre en bac à sable chaque limite d'exécution, même lorsque l'entrée semble "structurée". (GitHub)

L'avis de la CAI est important parce qu'il met fin au mythe selon lequel les logiciels d'IA axés sur la sécurité sont naturellement moins susceptibles de répéter de vieilles erreurs. Un cadre d'IA pour la cybersécurité peut toujours concaténer des données utilisateur en chaînes de caractères shell. Un agent de pentest peut toujours devenir un gadget d'injection de commandes. Un "assistant de l'équipe rouge" peut encore être un chemin RCE local faiblement renforcé si ses enveloppes d'outils sont négligées. Les équipes qui évaluent l'IA de cybersécurité doivent traiter ces projets avec le même sérieux qu'elles traitent tout autre logiciel à privilèges élevés : modéliser les menaces dans les enveloppes d'outils, inspecter la manière dont les paramètres sont transmis, examiner les limites du bac à sable et supposer qu'une entrée hostile finira par atteindre le système. (GitHub)

La leçon qui en découle est brutale. Le danger n'est pas seulement que les systèmes d'IA deviennent plus performants en matière de sécurité offensive. Le danger réside également dans le fait que les outils de sécurité de l'IA deviennent eux-mêmes une riche surface d'attaque. Les équipes solides devront mener de front les deux types d'activités : utiliser l'IA pour tester les systèmes et tester les systèmes basés sur l'IA qu'elles adoptent.

Comment les défenseurs devraient évaluer les plateformes d'IA de cybersécurité

Le moyen le plus rapide de gaspiller de l'argent dans cette catégorie est de poser la mauvaise question. La question "Quelle plateforme semble la plus autonome ?" n'est généralement pas la bonne. "La question "Quelle plateforme transforme une observation en un résultat vérifié avec le moins de bruit possible et le contrôle le plus fort ? La rédaction de Public Penligent formule le choix presque exactement dans les mêmes termes lorsqu'elle discute des copilotes de pentest d'IA : la question de l'achat utile concerne les preuves, la portée, la validation et le bruit opérationnel, et non pas l'histoire d'autonomie la plus impressionnante. Ce cadre fonctionne bien au-delà d'un seul fournisseur. Il devrait être l'objectif d'achat par défaut pour l'ensemble de la catégorie. (penligent.ai)

Une équipe de sécurité qui évalue une CAI, un produit de pentest natif du flux de travail ou un agent interne devrait se poser au moins dix questions.

Question d'évaluation	Pourquoi c'est important	Mauvais modèle de réponse
Puis-je interrompre ou approuver l'utilisation d'un outil à risque ?	Prévient les dérives du champ d'application et les actions destructrices	"L'agent se comporte généralement bien
Puis-je rejouer chaque constatation de gravité élevée ?	Séparer la preuve de la prose soignée	"Nous gardons une transcription de la discussion"
Le système conserve-t-il les demandes, les commandes et les réponses brutes ?	Permet le retest et le transfert d'ingénierie	"Nous résumons les éléments importants
Comment le champ d'application de l'objectif est-il appliqué ?	Arrêt de l'exécution accidentelle hors du champ d'application	"L'opérateur lui indique simplement le champ d'application
Que se passe-t-il lorsqu'il lit une entrée hostile ?	L'injection rapide est un risque primaire	"Notre système d'alerte est très solide
Quels sont les outils disponibles par défaut ?	Réduction de l'exposition aux exécutions cachées	"Tout est prévu pour la commodité"
Existe-t-il un modèle d'autorisation pour les intégrations externes ?	Le MCP et les passerelles similaires élargissent les frontières de la confiance	"Les intégrations héritent d'un accès complet"
Les affirmations relatives aux critères de référence sont-elles fondées sur des connaissances, des actions ou des environnements réels ?	Évite l'achat d'optiques pour le classement	"Nous avons obtenu d'excellents résultats en matière de sécurité.
Est-il possible d'échanger des modèles ou des versions d'épingles ?	Modéliser les changements de comportement au fil du temps	"La plateforme gère cela pour vous"
Le produit fait-il la distinction entre une hypothèse et une preuve vérifiée ?	Réduction des faux positifs et de l'érosion de la confiance	"L'agent vous dit s'il est confiant.

Ce tableau n'est pas spécifique à un fournisseur, mais des recherches publiques récentes en soutiennent chaque ligne. Les résultats de l'analyse comparative montrent que l'échafaudage est important, que la gestion du contexte est importante et que les performances mesurées changent de manière significative en fonction de l'environnement et de la forme de la tâche. Les comparaisons en direct montrent que les faux positifs et les tâches à forte interface graphique restent des points faibles. Les organismes de normalisation et les cadres de sécurité avertissent que l'injection rapide et les risques connexes propres à l'IA doivent être intégrés dans la gestion ordinaire des cyberrisques. Les CVE publics montrent que les plateformes de flux de travail et les outils d'agent eux-mêmes peuvent devenir des points faibles. (arXiv)

Pour les acheteurs, cela signifie que le domaine est désormais suffisamment mûr pour exiger de vraies preuves. Demandez une rediffusion d'un résultat vérifié. Demandez quelles preuves brutes sont conservées. Demandez comment fonctionnent les barrières d'approbation. Demandez ce que fait le produit lorsque le modèle lit un commentaire HTML malveillant, un PDF hostile ou une entrée de connaissance empoisonnée. Demandez si les flux de travail Burp ou proxy sont intégrés de manière à préserver la vérification manuelle. Demandez si la plateforme est forte au milieu du travail, et pas seulement au début et à la fin. Ce sont ces questions qui distinguent un système utile d'un système charismatique. (portswigger.net)

Ce que l'IPE réussit et ce qu'elle ne résout toujours pas

Le point le plus fort de la CAI est la définition de la catégorie. Elle traite l'IA en matière de cybersécurité comme un problème de cadre, et pas seulement comme un problème de modèle. Les documents publics mettent l'accent sur la diversité des modèles, les outils intégrés, le traçage, la connectivité MCP, les opérations basées sur l'interface de programmation et l'interruption par l'homme de la boucle. Il s'agit là d'une architecture plus solide que celle qui consiste à envelopper un modèle de frontière autour d'un scanner ou d'un terminal. Elle s'aligne sur ce que les meilleures recherches disent maintenant être important : la qualité de l'échafaudage, le raisonnement adaptatif sous contraintes, et une mesure pertinente pour le travail plutôt que des tests de connaissances superficiels. (GitHub)

La deuxième chose que l'IPE réussit à faire est sa position de référence, au moins sur un point important. Même si la plupart des affirmations publiques les plus fortes proviennent encore d'articles affiliés au projet, l'orientation générale de la recherche est correcte : Les performances de la FCT de type Jeopardy ne suffisent plus. Les propres documents de l'IPE et les travaux de référence connexes s'orientent vers des formats d'attaque et de défense, des gammes cybernétiques et des catégories d'évaluation plus riches. C'est exactement la direction que doit prendre le domaine s'il veut mesurer quelque chose de plus proche du travail réel. (arXiv)

La troisième chose qu'il réussit à faire est l'intégration pratique. La documentation publique montrant la prise en charge MCP, les exemples orientés Burp et les nombreux modèles sous-jacents pris en charge indique un flux de travail d'opérateur sérieux plutôt qu'un chemin de démonstration scellé. Les équipes de sécurité veulent rarement un autre assistant isolé. Elles veulent des systèmes qui peuvent habiter les endroits où les tests ont déjà lieu. En ce sens, la CAI s'aligne sur la même tendance plus large visible dans MCP lui-même et dans l'outillage agentique moderne plus généralement : le contexte et l'interopérabilité de l'outil deviennent le nouveau centre de gravité. (GitHub)

Ce que l'IPE ne résout pas est tout aussi important. Elle ne supprime pas la nécessité d'un jugement humain. Elle ne transforme pas les victoires du CTF en preuve automatique de la sécurité de l'entreprise. Elle ne protège pas les équipes de l'injection rapide ou de l'utilisation abusive d'outils par défaut. L'historique de ses propres conseils montre que ce serait une utopie. Comme tout autre système sérieux dans cet espace, il vit toujours dans une tension que l'ensemble du domaine n'a pas résolue : les mêmes propriétés qui rendent l'IA de cybersécurité utile pour les défenseurs la rendent également dangereuse lorsque la gouvernance, les limites de l'outil ou la qualité du logiciel sont faibles. (GitHub)

C'est pourquoi la bonne conclusion n'est pas que l'IAO est surestimée ou que l'IA de cybersécurité est un battage médiatique. La bonne conclusion est que la catégorie est réelle, que les capacités évoluent rapidement, que l'histoire des références devient plus honnête et que le goulot d'étranglement opérationnel passe du raisonnement brut à un contrôle digne de confiance. Les équipes qui comprennent ce changement tireront un réel avantage de ces systèmes. Les équipes qui ne le font pas achèteront de la confusion polie. (arXiv)

L'IA en matière de cybersécurité a besoin de plus de contrôle, pas de plus grandes démonstrations

La prochaine phase de ce marché ne sera pas remportée par celui qui semble le plus autonome. Elle sera remportée par celui qui rendra les systèmes autonomes plus faciles à contraindre, à inspecter, à vérifier et à rejouer. Telle est la véritable importance de l'IPE et de la recherche qui l'entoure. Ce n'est pas que l'IA de cybersécurité soit devenue comme par magie "le hacker". C'est que le travail de sécurité est enfin décomposé en morceaux manipulables par la machine avec suffisamment d'état, d'outils et de mesures pour devenir significatif sur le plan opérationnel.

Cela signifie également que le secteur devrait cesser de poser des questions faibles. Cessez de demander si un modèle peut résoudre un CTF. Demandez si le flux de travail peut survivre à une longue session sans perdre le fil. Cessez de demander s'il est capable de rédiger un exploit. Demandez-lui s'il sait faire la différence entre un exploit plausible et un exploit vérifié. Cessez de vous demander s'il s'intègre à Burp. Demander si Burp reste une couche de lisibilité humaine plutôt que de devenir un actionneur aveugle. Cessez de vous demander si le rapport a l'air soigné. Demandez si la conclusion survit à un nouveau test. (news.aliasrobotics.com)

C'est la norme vers laquelle il faut tendre. Il ne s'agit pas d'une offensive autonome en liberté. Pas un chatbot avec accès au shell. Pas un tableau de référence comme raccourci d'achat. L'IA en matière de cybersécurité devient vraiment utile lorsqu'elle se comporte comme une ingénierie de sécurité disciplinée sous contraintes. La CAI est l'un des signes les plus clairs que l'industrie a commencé à s'engager dans cette direction. Le reste du marché devra maintenant prouver qu'il peut faire de même sans sacrifier le contrôle en cours de route. (GitHub)

Lectures complémentaires et références

Page cadre officielle de l'IPE. (aliasrobotics.com)

Dépôt GitHub de l'IPE et documentation publique. (GitHub)

Document de base de l'IPE, CAI : Une IA de cybersécurité ouverte et prête à recevoir un grand nombre de bogues. (arXiv)

Évaluation comparative de l'IA en matière de cybersécurité, CAIBench : Un méta-benchmark pour l'évaluation des agents d'IA de cybersécurité. (arXiv)

Cybersécurité IA : évaluation de la cybersécurité agentique dans les FFC d'attaque et de défense. (arXiv)

Cybersécurité IA : Le meilleur agent IA au monde pour la sécurité Capturez le drapeau. (arXiv)

CyberGym : Évaluation à grande échelle des capacités de cybersécurité des agents d'intelligence artificielle dans le monde réel. (arXiv)

Comparaison des agents d'IA et des professionnels de la cybersécurité dans le cadre de tests de pénétration en situation réelle. (arXiv)

Profil du cadre de cybersécurité du NIST pour l'intelligence artificielle, avant-projet. (nvlpubs.nist.gov)

OWASP LLM01 Prompt Injection et OWASP Top 10 pour les applications LLM. (Projet de sécurité Gen AI de l'OWASP)

Spécification du protocole de contexte de modèle et documents d'autorisation. (modelcontextprotocol.io)

Introduction d'Anthropic à MCP. (anthropic.com)

Documentation de PortSwigger pour Burp Repeater et Burp Intruder. (portswigger.net)

NVD et documents d'information pour CVE-2025-3248, CVE-2026-27966, et CVE-2026-33017. (nvd.nist.gov)

Avis d'injection de commande CAI dans la base de données GitHub. (GitHub)

Page d'accueil négligente. (penligent.ai)

Penligent, Comment obtenir un rapport de pentest sur l'IA. (penligent.ai)

Penligent, Les cyberattaques agentiques ont besoin d'un test d'IA vérifié. (penligent.ai)

Penligent, Pentest AI, ce qui compte vraiment en 2026. (penligent.ai)