Une architecture commune pour les tests offensifs agentiques

Le paysage actuel est composé d’outils hétérogènes aux stratégies produit et cas d’usage très variés : tests de sécurité web externe, revues d’infrastructure interne et Active Directory, évaluations de sécurité cloud, ou analyse de code source proche du pipeline CI/CD.

Dans leurs meilleures configurations, les systèmes les plus aboutis sont aujourd’hui capables de mener des revues de sécurité statiques et dynamiques autonomes avec de fortes capacités de raisonnement, et un workflow qui ressemble souvent à la posture analytique d’un pentesteur humain.

L’efficacité de beaucoup de ces outils est évaluée en interne ou via des environnements de capture-the-flag, les CTF offrant un moyen objectif de comparer la profondeur de raisonnement, les capacités d’exploitation et l’usage des outils. Malgré la diversité des architectures, on retrouve les composants essentiels suivants dans la plupart des solutions :

• Un orchestrateur : Cette couche coordonne les agents et leur parallélisme, gère les blocages et timeout, orchestre les workflows préconfigurés, et relie les composants en une chaîne d’exécution cohérente.
• Un LLM sous-jacent : Le modèle constitue le noyau cognitif du système, alternant boucles de raisonnement, invocation d’outils et création de sous-agents selon les besoins. La capacité à utiliser des outils est indispensable et les LLM « state-of-the-art » donnent généralement de meilleurs résultats.
• Une boîte à outils offensive : La plupart des plateformes s’appuient sur un kit d’outils conteneurisé globalement aligné sur un standard de type Kali. Le contenu exact varie selon les cas d’usage, mais l’outillage typiquement requis pour des tests web reste par exemple assez standard et limité. De nombreuses solutions permettent également à l’agent de télécharger des outils supplémentaires ou de cloner des dépôts GitHub à la demande.
• Un ensemble de « skills » ou packs de connaissance : Ces bibliothèques locales formalisent une expertise réutilisable, incluant des techniques d’attaque spécifiques à certaines technologies, des cheatsheet de pentesteurs, des workflows d’exploitation standards, ou bien des détails sur les vulnérabilités ou scénarios d’attaque récents

Cette dernière couche est souvent celle où les éditeurs peuvent se différencier le plus clairement. Des capacités solides de veille cyber, de Threat Hunting et de Cyber Threat Intelligence permettent d’actualiser en continu cette base de connaissances et d’améliorer la confiance dans la couverture réelle assurée par ces agents automatisés.

Ces agents étant capables d’exécuter des actions offensives en environnements de production, l’observabilité et la supervision sont essentielles. La plupart des implémentations incluent donc journalisation, télémétrie, et rejeu de session, ainsi que des mécanismes d’approbation humaine pour certaines actions, ou des garde-fous distinguant les modules à faible risque des commandes ou chemins d’exploitation plus dangereux.

Il est également important de distinguer les systèmes pleinement agentiques des produits qui n’utilisent l’IA que de façon sélective. En pratique, de nombreuses plateformes éditeurs reposent sur des workflows majoritairement déterministes, parfois orchestrés par des modèles plus petits et spécialisés, avant de déléguer uniquement les étapes d’exploitation les plus ambiguës à un modèle généraliste plus capable.

Étude de cas : efficacité

Étude de cas : CTF

Pour évaluer l’efficacité actuelle du pentest agentique, nous avons réalisé des tests d’une telle solution (Strix) avec plusieurs modèles différents sur un ensemble interne de challenges CTF Wavestone pour lesquels aucun write-up public n’était disponible. L’objectif n’était pas de comparer des produits entre eux, mais de comprendre comment la qualité du modèle influence les résultats, sur un cas d’usage web.

Le choix de l’exploitation web est pertinent, combinant une large couverture thématique avec des niveaux de difficulté variés. Toutefois, l’exercice ne doit pas être sur-généralisé : il ne représente pas fidèlement d’autres contextes spécifiques tels que les tests internes ou les évaluations Active Directory.

Plusieurs conclusions ont émergé de cet exercice :

• Les résultats ne deviennent véritablement impressionnants que lorsque le système est associé à un modèle LLM de pointe.
• À l’inverse, les modèles pouvant réaliste​ment tourner sur un poste de travail haut de gamme tendent encore à produire des performances médiocres en test offensif, ce qui fait des fournisseurs IA SaaS la seule solution effective aujourd’hui.
• Des modèles puissants peuvent toutefois manquer des vulnérabilités exploitables, tandis que certains modèles de grande taille, mais moins optimisés, peuvent sous-performer, potentiellement car Strix n’a pas été conçu et calibré pour eux.
• Des modèles plus petits font parfois preuve d’éclairs de génie, résolvant des challenges qui résistent aux modèles plus puissants.
• Sans surprise, on observe une tendance persistante à l’hallucination de chemins d’exploitation, notamment lorsque les LLM atteignent une impasse (dans les CTF, cela se manifeste souvent par des flags inventés).
• Pour ne pas polluer leur contexte avec de grands volumes de données, les agents ont tendance à tronquer massivement les données (pages web, fichiers de code, …) et à être trop spécifiques dans leurs recherches (“grep” ou “find”). Dans les deux cas, ce comportement peut limiter leur couverture du périmètre et leur efficacité globale.

Ces résultats doivent être interprétés avec prudence. Pour chaque modèle et chaque challenge, le benchmark a été limité à au plus deux exécutions. Dans plusieurs cas, un modèle pouvait être très proche de la solution avant d’halluciner la dernière étape, ou nécessiter une intervention humaine pour clore l’investigation. Typiquement, ces cas pourraient être rattrapés par une revue humain.

Il est clair que les meilleurs résultats du benchmark ont été obtenus avec des modèles propriétaires de pointe. D’après nos observations, ces modèles peuvent résoudre une part substantielle des tâches offensives tout en restant opérationnellement abordables; du moins tant que les sessions convergent rapidement.

Ce que cela nous montre :

• Le coût par challenge peut rester relativement modeste, de l’ordre de quelques euros lorsque l’agent converge efficacement.
• L’exécution peut être étonnamment rapide, avec de nombreux CTF résolus en moins de cinq minutes lorsque le modèle identifie le bon chemin tôt dans son investigation.
• Les échecs peuvent se révéler coûteux. Sans garde-fous stricts sur la durée et le budget, la consommation de tokens peut augmenter considérablement, et ce sur quelques heures.
• Dans notre configuration, le taux de réussite des modèles commerciaux de pointe étaient identiques, mais l’efficacité variait substantiellement en termes de temps, de consommation de tokens et de nombre d’invocations d’outils. De façon surprenante, dans ce contexte CTF, malgré un prix au token plus élevé pour Sonnet 4.6, le coût total des sessions tend à s’équilibrer avec GPT-5, le modèle d’Anthropic compensant par une meilleure efficacité en tokens. 

Étude de cas : application web réelle

Pour compléter les benchmarks CTF, nous avons également testé l’une de nos applications web développées en interne (utilisée pour la gestion des RH et des performances). Le système a été évalué avec plusieurs approches, notamment des modes authentifiés dans lesquels l’agent se voit fournir des identifiants ou des jetons d’authentification.

Au cours d’une session représentative, 25 agents et sous-agents ont été déployés, 366 appels d’outils ont été exécutés, pour un coût total d’environ 5 USD, la session ayant duré environ une heure. Le rapport généré automatiquement affichait une synthèse managériale, une section méthodologique orientée OWASP, des conclusions techniques avec scoring CVSS v3, ainsi qu’une feuille de route de remédiation priorisée.

Les résultats sont mitigés, mais globalement instructifs après revue humaine et re-test :

• L’agent a identifié plusieurs axes d’amélioration mineurs mais pertinents, bien que les conclusions n’aient pas toujours été bien contextualisées et aient pu devenir excessivement alarmistes.
• Lacune critique : l’agent a complètement manqué une interface d’administration exposée avec des identifiants par défaut; une vulnérabilité qu’aucun pentesteur humain n’aurait ignorée. C’est l’illustration la plus nette du plafond de fiabilité actuel de ces systèmes.
• De plus, le rapport présentait également une vulnérabilité inexistante (confusion d’algorithme JWT) relevée comme critique, accompagné de scripts Proof-of-Exploitation ne fonctionnant logiquement pas. Cela illustre le risque persistant de faux positifs au sein des LLM.

Plusieurs remarques complémentaires :

• Comme pour les benchmarks CTF, la qualité de la revue s’améliore significativement avec un modèle SaaS de pointe.
• La nature non déterministe des LLM reste visible : deux exécutions peuvent produire des conclusions et des rapports substantiellement différents pour une même cible.
• Si les contrôles de périmètre sont insuffisants, certains modèles ont une tendance à élargir le périmètre du pentest, sondant des ports, applications ou sous-domaines adjacents.
• La couverture et la pertinence s’améliorent nettement en modes boîte blanche ou hybride boîte blanche/boîte grise, où l’agent peut inspecter le code source, identifier des faiblesses candidates, puis tenter de les valider dynamiquement sur l’application en production. Même dans ce cas, certains agents peuvent encore se focaliser sur des problèmes inexistants. De plus, en boîte blanche, de très grandes bases de code peuvent saturer le système et réduire l’efficacité globale.
• Les capacités de ces solutions à émuler un comportement humain a nettement progressé, notamment les interactions pilotées avec les navigateurs web. Toutefois, certains types d’applications restent difficiles à évaluer de manière autonome, notamment des cas de figures « multi-fenêtres » ou les clients lourds, pour lesquels une interaction navigateur en mode headless peut ne pas suffire.
• Ces systèmes construisent rarement une compréhension approfondie de la logique métier. Leurs résultats restent fortement alignés sur des patterns génériques de type OWASP et ne challengent pas les risques métier réels ou les scénarios d’attaque de manière suffisamment contextuelle.

On notera que la majorité de ces reproches peuvent également être applicables à des pentesters humains, ces derniers restant toutefois davantage responsabilisable.

Le problème de passage à l’échelle reste central. Les CTF ne sont que partiellement représentatifs des applications réelles. Un CTF aura généralement tendance à guider le participant vers un chemin d’attaque étroit et délibéré, alors que même une application métier modeste exposera une surface bien plus large. Aujourd’hui, garantir une couverture exhaustive pour des applications réelles reste complexe.

Verdict et limites actuelles

Verdict

Si l’on considère des solutions reposant entièrement sur un LLM pour leur arbre de décision, la conclusion est claire à ce stade : seuls les modèles de pointe des principaux fournisseurs IA produisent systématiquement des résultats à la fois pertinents et raisonnablement vérifiables.

Nous pouvons considérer quatre options de déploiement pratiques :

• Les services LLM SaaS, qui offrent actuellement la meilleure qualité via des LLM avancés (>1T paramètres), sur une base de paiement à l’utilisation.
• Les déploiements en grands datacenters privés, capables de faire tourner des modèles puissants (500b) et pouvant devenir de plus en plus pertinents pour le pentest, mais restant encore sensiblement en deçà des meilleurs systèmes frontier commerciaux.
• Les déploiements en datacenters privés plus modestes, capables de faire tourner des modèles compétents (300b), mais clairement insuffisants pour orchestrer efficacement des pentests autonomes.
• Les postes de travail dédiés, qui, même avec des spécifications très élevées, peinent rapidement au-delà de 100b de paramètres et restent largement insuffisants aujourd’hui.

La dépendance aux fournisseurs SaaS soulève des questions inévitables de souveraineté et de confidentialité. Les tests d’intrusion consolident souvent des informations techniques très sensibles sur les faiblesses cyber d’une organisation. L’externalisation des prompts, traces, conclusions ou hypothèses d’attaque nécessite ainsi une gouvernance rigoureuse. En complément, l’anonymisation des données en amont du LLM n’est pas une solution fiable : elle dégrade les performances de l’agent tout en laissant fuiter des métadonnées potentiellement exploitables vers le fournisseur SaaS.

Dans leur état actuel, même équipés des LLMs les plus capables, ces systèmes présentent également des limitations structurelles qui affectent directement la fiabilité :

• Des phénomènes de “tunnel”, avec une fixation trop prolongée de l’agent sur un unique chemin d’attaque non pertinent.
• Une tendance à lancer des activités de bruteforce chronophages et consommatrice sans appréciation de la complexité ou du coût computationnel.
• La problèmatique des hallucinations, sur laquelle d’immenses progrès ont été réalisés, mais qui peut encore affecter les LLM, y compris les plus complexes.

• La nature non déterministe des LLM, rendant certaines exécutions bien moins efficaces et pertinentes que d’autres, confirmant l’utilité de ces agents dans une approche continue ou régulière.
• Des difficultés de passage à l’échelle liées aux contraintes de fenêtre de contexte : ces outils permettent un passage à l’échelle dans le sens où l’on peut lancer autant de sessions parallèles que de cibles. Cependant, le passage à l’échelle est plus complexe lorsqu’une session unique est lancée contre une unique application hautement complexe. Il devient alors beaucoup plus difficile de maintenir une couverture exhaustive et une continuité de mémoire sur des applications larges et riches en contenu. D’importantes améliorations sont possibles sur ce volet, une gestion efficace de la mémoire à long terme permettant des exécutions plus cohérentes pour les grandes applications et améliorant la confiance dans le couverture.
• Une verbosité élevée et une furtivité limitée, qui rendent ces systèmes peu adaptés dans leur configuration par défaut aux opérations Red Team, qui nécessitent davantage de discrétion. Cela peut toutefois être amélioré par une configuration dédiée, sans toutefois promettre d’égaler les capacités d’un Red Teamer humain.

De manière plus générale, un processus autonome piloté en SaaS et ayant la capacité d’exécuter des commandes à distance dans vos SI pose d’emblée la question de la responsabilité :

• Classer les modules comme dangereux ou sûrs peut ne pas suffire, par exemple avec des outils couteaux-suisses, capables d’une reconnaissance anodine et d’exploits agressifs et potentiellement dangereux. Le niveau de menace de chaque commande devrait être évalué dynamiquement, en tenant compte du contexte et des tests précédents.
• S’appuyer sur une approbation humaine peut également avoir ses limites : au même titre que pour les solutions de vibe coding, une « fatigue » humaine peut rapidement s’installer, où les utilisateurs deviennent trop confiants et cessent de remettre en question les conclusions de l’agent.

Et bien entendu, toute vulnérabilité au niveau du LLM, telle qu’une susceptibilité au prompt injection ou à l’empoisonnement, pourrait être exploitée pour détourner l’agent de pentest automatisé. En substance, ces outils autonomes, s’ils sont déployés en interne, doivent être considérés comme des actifs critiques, très interessants pour de potentiels attaquants.

Où l’architecture peut s’améliorer

Au-delà de la qualité du modèle lui-même, une part substantielle des améliorations possibles réside dans la conception globale du système. Plusieurs directions architecturales apparaissent prometteuses :

• Multiplier les sessions et les passes de validation, en utilisant une exploration continue, des phases de zoom ciblées et des boucles de confirmation explicites. La fiabilité s’en voit améliorée, au prix d’une augmentation du coût, de la durée, et de la complexité de la solution.
• Introduire des instances de validation dédiées pour confirmer l’exploitabilité dans un environnement contrôlé avant que les conclusions ne soient intégrées dans un rapport.
• Utiliser des arbres de décision plus légers ou des modules spécialisés en amont de l’exploitation, en réservant les modèles haut de gamme uniquement pour les parties du workflow qui nécessitent vraiment adaptabilité et raisonnement.
• Faire précéder la phase autonome d’une phase préliminaire de tests scriptés, puis alimenter l’agent avec les sorties structurées. C’est approche apparait bien plus rentable que de dépenser du contexte et des tokens LLM sur des tâches déjà faciles à automatiser sans IA. Le principe de base doit être simple : ne pas utiliser l’IA là où l’automatisation conventionnelle fonctionne déjà bien. Déléguer au LLM uniquement les taches véritablement ambiguës, et éviter de surcharger le modèle avec un long historique de commandes.

En pratique, ce dernier point est déjà la direction prise par de nombreuses plateformes éditeurs. Elles ne s’appuient pas entièrement sur l’IA agentique ; elles combinent plutôt une logique déterministe avec une exploitation agentique.

Enfin, une réflexion intéressante : ces solutions automatisées pouvant être utilisées par de vrais attaquants, nous pourrions voir émerger des mécanismes “anti-IA” intégrés dans les applications, tels que des “labyrinthes de liens” et des honeypots draineurs de tokens conçus spécifiquement pour induire en erreur ou épuiser les systèmes de test automatisés.

Avec des modèles suffisamment puissants, les systèmes agentiques peuvent déjà exceller dans des environnements contraints comme les CTF. Leurs performances dans les évaluations d’applications réelles sont plus mitigées : souvent utiles, parfois impressionnantes, mais encore trop incohérentes pour être utilisées sans supervision humaine.

La voie la plus pragmatique aujourd’hui est donc un modèle opérationnel hybride : un système agentique réalisant la majorité des tests et proposant des directions d’investigation, accompagné de pentesters humains arbitrant, validant et prenant le relai dans les cas les plus complexes. On a ainsi une évaluation sécurité bien moins longues, tout en garantissant un degré de couverture et de pertinence des résultats.

L’IA agentique ne s’annonce donc pas comme remplacement à l’humain. À son niveau de maturité actuel, elle est mieux appréhendée comme un multiplicateur de force, capable d’accélérer l’exploration et le tri, mais qui dépend encore de la supervision d’experts pour transformer une activité autonome brute en résultats de sécurité fiables. Dans tous les cas, ces systèmes doivent être considérés comme hautement sensibles en raison de leur nature autonome, et les contraintes actuelles liées aux modèles hébergés en SaaS doivent être prises en compte, en termes de confidentialité des données et de souveraineté numérique.

Sans être encore pleinement matures, ces solutions commencent à laisser une empreinte dans le paysage de la cybersécurité, et modifieront très probablement la trajectoire du marché du pentest, vers un écosystème davantage centré autour d’outils et de ressources de calcul, tout en conservant une approche hybride. Nous pourrions même voir des audits suivre un modèle “Bring Your Own Compute”, où les audités fournissent le LLM, et les auditeurs fournissent les outils et « skills ».

Cet article IA Agentique pour la Sécurité Offensive est apparu en premier sur RiskInsight.