PentestAgent : un agent LLM qui s'auto-invoque pour le test d'intrusion en boîte noire

Le problème : orchestrer un LLM sur une cible qu'on ne connaît pas

Un modèle de langage seul ne fait pas de reconnaissance. Il lui faut un shell, un navigateur, un moyen de noter ce qu'il trouve, et surtout une façon de découper un périmètre en tâches exécutables. PentestAgent se présente comme le cadre qui fournit ces briques pour le test en boîte noire, c'est-à-dire sans accès préalable au code ni à la configuration de la cible. Les cas d'usage annoncés dans le README sont le bug bounty, le red team et le pentest classique.

Le public visé n'est pas l'analyste qui tape ses commandes nmap à la main. C'est plutôt celui qui veut déléguer une phase de reconnaissance ou d'exploration à un agent, tout en gardant la main sur le périmètre. Le mode Interact illustre cette posture : le README le décrit comme un mode où l'on discute avec l'agent et où celui-ci guide pendant la procédure. L'outil suppose donc un opérateur présent, pas une exécution nocturne sans surveillance.

Un point de vocabulaire, parce qu'il prête à confusion. Le README parle de sécurité en boîte noire, mais rien n'indique que l'agent soit empêché de sortir du périmètre déclaré. La notion de scope apparaît comme un argument de l'outil spawn_mcp_agent, pas comme un contrôle d'exécution documenté.

Quatre modes, une seule interface en terminal

L'interface est une TUI lancée par la commande pentestagent. Le README documente quatre modes, appelés par des commandes préfixées d'un slash. /assist exécute une instruction unique avec exécution d'outils. /agent lance une exécution autonome sur une tâche unique. /crew active un mode multi-agents où, selon le README, un orchestrateur engendre des workers spécialisés. /interact ouvre le mode conversationnel.

La distinction entre /assist et /agent n'est pas explicitée au-delà de cette phrase. Un utilisateur qui cherche à comprendre quand l'un vaut mieux que l'autre devra lire le code. C'est une lacune de documentation réelle, pas une nuance cosmétique : le nom des modes suggère des degrés d'autonomie différents, mais rien ne dit ce qui borne cette autonomie.

Le reste des commandes relève de la mécanique de session. /target définit la cible, /tools liste les outils disponibles, /notes affiche les notes enregistrées, /report génère un rapport à partir de la session, /memory montre l'usage de tokens et de mémoire, /conversations permet de parcourir et restaurer des conversations sauvegardées. Esc interrompt un agent en cours, Ctrl+Q quitte. La persistance des conversations est donc prévue, ce qui est cohérent avec des sessions de reconnaissance longues.

L'auto-invocation : le mécanisme à comprendre avant d'adopter

C'est ici que PentestAgent se distingue d'un simple wrapper autour d'un modèle. L'outil intégré spawn_mcp_agent permet à un agent en cours d'exécution de lancer une copie enfant de lui-même, exposée comme un serveur MCP subordonné et connecté via stdio. Le README précise que l'enfant est entièrement isolé : son propre runtime, son propre client LLM, son propre historique de conversation, son propre magasin de notes. Une fois lancé, l'ensemble de ses outils est injecté dans les outils disponibles du parent.

La conséquence pratique est que l'agent s'organise seul, sans orchestrateur externe. Il délègue des sous-tâches à des enfants qu'il crée à la demande. Le README donne l'exemple d'un orchestrateur qui lance deux enfants sur 10.0.1.0/24 et 10.0.2.0/24, puis délègue le travail au tour suivant, parce que les outils de l'enfant ne deviennent disponibles qu'à l'appel d'outil suivant. Ce délai d'un tour est un détail d'implémentation qui change la façon d'écrire les invites.

Les arguments documentés sont target, scope (liste de cibles ou de CIDR), model (qui remplace PENTESTAGENT_MODEL pour l'enfant), no_rag (vrai pour ignorer l'initialisation du moteur RAG chez l'enfant) et no_mcp (vrai par défaut, pour ignorer les connexions aux serveurs MCP externes chez l'enfant, ce que le README recommande). Le nom du serveur enfant est attribué automatiquement, par exemple child_agent_1, et renvoyé dans le résultat.

Deux commandes TUI exposent la même mécanique manuellement : /spawn accepte un target, un --scope en CIDR, un --model, ainsi que --no-rag et --no-mcp ; /despawn arrête et retire un agent enfant précédemment lancé. Le fait que no_mcp soit à vrai par défaut pour les enfants est un choix défendable : il évite une prolifération de connexions MCP en cascade. Mais rien dans le README ne décrit de plafond sur le nombre d'enfants, ni de budget de tokens global. Sur un périmètre large, c'est à l'opérateur de surveiller /memory.

Installation, configuration et exécution

Les prérequis annoncés sont Python 3.10 ou plus récent et une clé API pour OpenAI, Anthropic ou tout autre fournisseur compatible LiteLLM. Le dépôt fournit deux scripts d'installation : scripts/setup.ps1 sous Windows, scripts/setup.sh sous Linux et macOS, qui créent l'environnement virtuel et installent les dépendances. En manuel, la séquence du README est python -m venv venv, activation de l'environnement, puis pip install -e ".[all]". Le navigateur intégré exige en plus playwright install chromium.

La configuration passe par un fichier .env à la racine du projet. Deux variables structurent tout : la clé du fournisseur et PENTESTAGENT_MODEL. Le README donne deux exemples, ANTHROPIC_API_KEY avec claude-sonnet-4-20250514 et OPENAI_API_KEY avec gpt-5. Pour un point d'accès compatible OpenAI, on renseigne OPENAI_API_BASE en plus de la clé ; pour un point d'accès compatible Anthropic, c'est ANTHROPIC_API_BASE. Le fichier .env.example contient, selon le README, les notes complètes sur les fournisseurs et les options d'embedding.

Le lancement se fait par pentestagent pour la TUI, pentestagent -t 192.168.1.1 pour démarrer avec une cible, ou pentestagent tui --docker pour exécuter les outils dans un conteneur. Les playbooks, qui définissent une approche structurée pour un type d'évaluation, s'invoquent en ligne de commande : pentestagent run -t example.com --playbook thp3_web. Le README ne détaille pas la liste des playbooks disponibles ni leur contenu, seulement cet exemple.

Côté outils intégrés, la liste documentée est terminal, browser, notes, web_search et spawn_mcp_agent. web_search requiert une variable TAVILY_API_KEY, ce qui ajoute un second fournisseur externe à la chaîne. Les images Docker préconstruites sont ghcr.io/gh05tcrew/pentestagent:latest, décrite comme contenant nmap, netcat et curl, et ghcr.io/gh05tcrew/pentestagent:kali, décrite comme contenant metasploit, sqlmap et hydra. Une construction locale est possible via docker compose build, ou docker compose --profile kali build pour la variante Kali.

Ce que la documentation ne tranche pas

Le README ne dit rien sur la sécurité de l'agent lui-même. Les notes de session, l'historique de conversation et les résultats de reconnaissance transitent par un fournisseur LLM externe, mais aucune section ne décrit de politique de rétention, de chiffrement local ou de purge. Pour un pentest sous contrat, c'est une question à trancher avant la première commande, pas après. Le mode Docker isole les outils dans un conteneur, ce qui limite la portée d'une commande destructrice, mais l'isolation du conteneur ne dit rien du trajet des données vers l'API du modèle.

Autre zone d'ombre : le moteur RAG. Il apparaît par l'option no_rag de spawn_mcp_agent et de /spawn, et .env.example mentionnerait des options d'embedding. Le README ne décrit ni ce qui est indexé, ni où l'index est stocké, ni quel modèle d'embedding est utilisé par défaut. Un utilisateur qui laisse RAG actif sans savoir ce qu'il contient prend une décision qu'il ne peut pas justifier.

Le dépôt n'a pas de releases publiées au moment de la rédaction, alors que le badge du README affiche une version 0.2.0. Il faut donc installer depuis la branche main, sans point de version épinglé. Pour un outil qui exécute des commandes shell sur des cibles distantes, l'absence de release est un vrai sujet : pas de journal de changements à consulter entre deux mises à jour, pas de tag à figer dans un environnement verrouillé.

Enfin, la licence MIT est permissive : usage commercial, modification et redistribution sont autorisés, avec conservation du texte de licence et sans garantie. Elle ne dit rien du cadre légal de votre test. L'autorisation écrite du propriétaire de la cible reste votre affaire, et l'agent ne la vérifiera pas pour vous.

Face à un scanner classique, et face à un cadre d'orchestration générique

La comparaison la plus utile n'est pas avec un autre agent LLM, mais avec un scanner de vulnérabilités établi. Un scanner comme Nuclei exécute des modèles de détection versionnés sur une cible et produit une sortie reproductible : même cible, même version, même résultat. PentestAgent fait l'inverse. Le chemin emprunté dépend du modèle, de l'historique de conversation et des décisions de l'agent. Deux exécutions sur la même cible peuvent diverger. Ce n'est pas un défaut en soi, c'est un autre métier : l'exploration ouverte plutôt que la vérification exhaustive. Si vous avez besoin de prouver la couverture d'un périmètre, un scanner déterministe reste l'outil approprié, et PentestAgent ne remplace pas cette preuve.

Face à un cadre d'orchestration multi-agents générique, la différence tient à l'auto-invocation. Un cadre générique vous demande de définir les rôles, de câbler les serveurs MCP et de router les messages entre agents. Ici, l'agent décide lui-même de créer ses subordonnés via spawn_mcp_agent, et leurs outils remontent automatiquement dans son espace d'outils. Le coût de mise en place est plus faible, la lisibilité du graphe d'exécution aussi. Vous ne savez pas à l'avance combien d'enfants seront créés ni sur quels segments. C'est le compromis central du projet : moins de plomberie, moins de visibilité.

Coût de maintenance et de mise à jour

Le dépôt est actif : le dernier push remonte au 7 septembre 2026 et le projet n'est pas archivé. C'est le seul signal de vitalité que ce matériel permet de constater, et il ne dit rien de la qualité du code.

Le coût de mise à jour se lit dans les dépendances. PentestAgent s'appuie sur LiteLLM pour l'accès aux fournisseurs, sur Playwright pour l'outil navigateur et sur MCP pour l'extensibilité. Chacune de ces briques évolue à son rythme : les identifiants de modèles changent, l'API MCP bouge, les binaires Chromium de Playwright doivent être réinstallés après certaines mises à jour. Comme il n'existe pas de release taguée, une mise à jour signifie tirer la branche main et relire les différences vous-même. Prévoyez cette relecture, en particulier autour de spawn_mcp_agent et de la gestion du périmètre.

La variante Kali embarque metasploit, sqlmap et hydra dans l'image. Ces outils ont leurs propres cycles de publication, et l'image devra être reconstruite pour les suivre. Le README ne documente pas de procédure de mise à jour de l'image, seulement les commandes de construction et d'exécution.

Sur le plan juridique, la licence MIT couvre le code. Elle n'accorde aucun droit sur les cibles que vous testez, et elle exclut toute garantie. Le README ne comporte pas de clause d'usage acceptable ni d'avertissement sur l'utilisation non autorisée, ce qui laisse la responsabilité entière à l'opérateur.

Conclusion éditoriale

À adopter par les pentesters et équipes red team qui veulent une orchestration multi-agents sans écrire leur propre glue MCP, et qui acceptent de lire le code source pour comprendre le comportement de l'agent. À éviter si vous cherchez un scanner déterministe avec des résultats reproductibles, ou si votre périmètre interdit l'envoi de données de reconnaissance à un fournisseur LLM externe. Avant de l'installer, vérifiez trois points : la licence MIT autorise la modification et la redistribution, mais elle n'offre aucune garantie sur le comportement de l'agent ; le dépôt n'a pas de releases publiées, donc pas de version épinglée à se procurer ; et la documentation ne précise pas comment les notes de session sont stockées, ce qui conditionne leur confidentialité.

Sources officielles

1. GH05TCREW/pentestagent on GitHub
2. Issues
3. License: MIT
4. README