Comment fonctionne un agent de pentest IA, étape par étape

Introduction

« Agent de pentest IA » est en train de devenir un argument de vente avant d'être une mécanique comprise. On nous demande souvent ce qu'il y a vraiment sous le mot. Cet article ouvre le capot : la boucle que l'agent suit, les outils qu'on lui donne, les limites qu'on lui impose, et le détail qui sépare un agent d'un scanner dont une IA relit les résultats.

Nous avons déjà posé le cadre général dans l'article sur le pentest IA. Ici, on reste au niveau de la machine.

Un modèle de langage dans une boucle, avec des outils

Un agent de pentest, ce n'est pas un modèle qu'on interroge une fois. C'est un modèle de langage placé dans une boucle, à qui on a donné des outils et des limites. À chaque tour, le modèle reçoit l'état courant (ce qu'il a observé jusqu'ici), choisit une action, un outil l'exécute, et le résultat revient dans le contexte du tour suivant.

Les outils sont le point souvent oublié. Un modèle seul ne fait qu'écrire du texte. Ce qui le rend capable de tester, ce sont les fonctions qu'on branche autour : envoyer une requête HTTP, lire une réponse, extraire les routes d'un bundle JavaScript, décoder un jeton, comparer deux réponses. L'intelligence est dans le choix de l'outil et de ses paramètres, pas dans le modèle pris isolément.

La boucle, en quatre temps

Nous l'affichons telle quelle sur la page d'accueil, parce qu'elle décrit le produit mieux qu'un paragraphe.

1. Observer

L'agent lit ce que la cible renvoie. Les en-têtes de réponse, les formulaires d'une page, les routes d'API référencées dans un fichier JavaScript, un message d'erreur qui laisse filer un chemin de fichier ou un nom de framework. Il part aussi de ce que la couche algorithmique a déjà établi : les services ouverts, les versions, les actifs cartographiés.

Cette étape ressemble à ce que fait un pentester pendant la première heure : il regarde, il prend des notes, il ne touche presque à rien.

2. Supposer

À partir de ces observations, l'agent formule une hypothèse. Pas « testons l'injection SQL partout », mais « ce paramètre page dans une fonction qui lit des documents ressemble à une inclusion de fichier ». L'hypothèse est spécifique à ce qu'il a vu, et c'est l'étape qu'un scanner ne fait pas : le scanner déroule une liste écrite d'avance, l'agent construit une question à partir du contexte.

C'est aussi là que le modèle peut se tromper, et c'est normal. Une hypothèse est faite pour être vérifiée, pas pour être crue.

3. Tester

L'agent envoie la requête qui confirme ou écarte l'hypothèse. La charge est non destructive : elle cherche à prouver un comportement, pas à causer un dégât. Pour une injection de commande, demander l'identifiant de l'utilisateur système (id) suffit à prouver l'exécution ; inutile de lire /etc/shadow. Pour une SSRF, atteindre une adresse interne de test prouve le point d'entrée ; inutile d'aller fouiller les métadonnées de production.

Puis il lit la réponse. Un code de statut, un temps de réponse inhabituel, un fragment de données qui n'aurait pas dû apparaître : c'est le retour qui tranche.

4. Prouver, ou recommencer

Si l'hypothèse tient, l'agent conserve la preuve : la requête envoyée, la réponse obtenue, la donnée atteinte, et de quoi rejouer le test. C'est ce triplet qui ira dans le rapport, et c'est lui qui distingue un constat d'une opinion.

Si l'hypothèse ne tient pas, il revient à l'étape 1, mais avec une information de plus. C'est la grande différence avec un scanner : l'échec d'un test oriente le suivant. Un agent peut passer vingt requêtes sur un seul formulaire parce que la troisième réponse l'a intrigué, exactement comme un humain devant un comportement bizarre.

Un exemple concret d'enchaînement

Prenons un cas qui revient sur nos périmètres, raconté pas à pas.

1. La cartographie trouve un sous-domaine staging.exemple.com, oublié depuis une migration.
2. Le moteur algorithmique y détecte une documentation d'API ouverte.
3. L'agent observe cette doc et repère une route /api/import qui prend un paramètre url.
4. Il suppose une SSRF : le serveur va-t-il aller chercher l'URL qu'on lui donne ?
5. Il teste avec une adresse de contrôle bénigne, et lit dans la réponse que le serveur l'a bien contactée.
6. Il prouve : requête, réponse, et la confirmation que le point d'entrée existe. Il s'arrête là, sans aller plus loin que la preuve.

Aucune règle de scanner ne décrit cette chaîne, parce qu'elle n'existe que sur ce client : le sous-domaine oublié, la doc ouverte, la route d'import, dans cet ordre. C'est l'enchaînement que l'agent sait reconstituer.

Les garde-fous font partie du produit

Un agent sans limites est un outil d'attaque, pas un produit d'audit. Les garde-fous ne sont pas un ajout de confort, ils sont ce qui rend l'outil déployable. Ce sont eux qu'il faut regarder en premier.

• Le périmètre est imposé. L'agent ne teste que les actifs validés par la cartographie et rattachés au domaine du client. Il ne suit pas un lien sortant vers un tiers, même si la logique de test l'y pousserait.
• Les charges sont bornées à la preuve. Prouver, oui ; exploiter à fond, non. La frontière est écrite, pas laissée au jugement du modèle au moment où il est le plus tenté de continuer.
• Le débit est plafonné. Un agent curieux peut vite envoyer beaucoup de requêtes. Le plafond protège la production du client, et les tests qui peuvent dégrader un service sont exclus par défaut.
• Tout est journalisé. Chaque requête envoyée à la cible est tracée, horodatée, consultable. Le client doit pouvoir savoir ce qui a touché sa production, et quand.

Le piège propre aux modèles de langage

Il faut le dire franchement, parce que c'est la faiblesse de la famille : un modèle de langage peut se convaincre d'une faille qui n'existe pas. Il lit une réponse ambiguë, construit une histoire cohérente autour, et la rapporte avec le même aplomb qu'un vrai constat. C'est le faux positif le plus dangereux, parce qu'il est bien rédigé.

La seule parade sérieuse est structurelle : n'accepter dans le rapport que ce qui est accompagné d'une preuve reproductible. Pas de requête, pas de réponse, pas de donnée atteinte ? Alors ce n'est pas un constat, c'est une suggestion de piste, et ça ne remonte pas au même niveau. C'est une règle d'architecture, pas une consigne de prompt : on filtre la sortie de l'agent sur la présence de la preuve, le modèle ne décide pas seul de ce qui est publié.

Où s'arrête l'agent

Un agent ne remplace pas un humain partout. Il ne comprend pas vos règles de gestion, donc il rate la logique métier (valider sa propre note de frais, un prix négatif). Il voit ce que voit un anonyme, donc il ne couvre pas l'espace authentifié tant qu'on ne lui ouvre pas un compte. Et il s'arrête à la frontière d'Internet : le réseau interne est un autre métier. Nous détaillons ces limites dans l'article général sur le pentest IA.

Ce qu'il gagne, en revanche, c'est la fréquence et l'ampleur. Il repasse tous les jours, sur tout le périmètre, et voit la faille le jour où un déploiement l'introduit. C'est ce qu'aucun consultant ne peut offrir sur la durée.

Comment c'est fait chez Flawfence

L'agent ne travaille jamais seul. Un moteur algorithmique reconstruit d'abord le périmètre, identifie les services et passe chaque actif au crible des failles connues, de façon déterministe. L'agent reprend ensuite ses constats, explore, suppose, teste et conserve la preuve. Le moteur est exhaustif, l'agent est sélectif ; les deux se complètent.

L'agent raisonne principalement avec les modèles de Mistral AI, et la plateforme est hébergée à Paris. Ce choix n'est pas qu'une préférence : les réponses de votre production transitent par le modèle, et leur trajet est une question en soi, que nous traitons dans l'article sur le pentest IA souverain.

FAQ

Un agent de pentest IA, c'est quoi techniquement ?

Un modèle de langage placé dans une boucle, avec des outils (envoi de requêtes, lecture de réponses, extraction de routes) et des limites (périmètre, charges bornées, débit plafonné). À chaque tour, il observe, formule une hypothèse, la teste et conserve la preuve si elle tient.

Quelle différence avec un scanner ?

Le scanner applique une liste de tests écrite à l'avance. L'agent choisit ses tests à partir de ce qu'il observe, et l'échec d'un test oriente le suivant. Le scanner est exhaustif et reproductible, l'agent est adaptatif et sélectif.

L'agent peut-il casser quelque chose en production ?

Il peut, s'il n'a pas de limites. Un produit sérieux borne les charges à la preuve, plafonne le débit, exclut par défaut les tests dégradants et journalise chaque requête. Ces garde-fous ne sont pas optionnels.

Comment éviter les faux positifs d'un agent IA ?

En n'acceptant dans le rapport que ce qui est accompagné d'une preuve reproductible : la requête, la réponse, la donnée atteinte. Un constat sans preuve est traité comme une piste, pas comme une vulnérabilité confirmée.

Conclusion

Un agent de pentest IA n'a rien de magique une fois le capot ouvert : un modèle qui observe, suppose, teste et prouve, dans une boucle, avec des outils et des garde-fous. Ce qui fait un bon produit n'est pas la taille du modèle, c'est la rigueur de la boucle et la solidité des limites. Et la preuve au bout, toujours. Demandez à la voir : c'est là que se joue la différence entre un agent et un texte bien tourné.