hexstrike-ai : un serveur MCP qui branche un agent sur 150 outils offensifs

Le problème concret : un agent qui ne peut pas lancer nmap

Un agent conversationnel branché sur un serveur MCP générique sait lire un fichier, interroger une API, exécuter du code isolé. Il ne sait pas appeler nmap avec les bons drapeaux, enchaîner un scan de ports puis une énumération web, ni interpréter la sortie XML d'un outil qui n'a pas été conçu pour être consommé par un modèle. hexstrike-ai comble cet écart en se présentant comme un serveur MCP unique derrière lequel sont regroupés plus de 150 outils de sécurité. Le README annonce une répartition par domaine : environ 25 outils réseau, 40 pour les applications web, 20 cloud, 25 binaires, 20 CTF et 20 OSINT. La cible est claire : quelqu'un qui possède déjà ces outils sur une machine de test et qui veut les piloter depuis Claude Desktop, Cursor, VS Code Copilot, Roo Code ou 5ire, tous cités comme clients compatibles. Le projet est développé par OTT Cybersecurity LLC et publié sous licence MIT.

Ce qui se passe entre l'agent et le binaire

Le schéma d'architecture du README décrit une chaîne en quatre temps. L'agent se connecte au serveur HexStrike via le protocole MCP, présenté comme reposant sur FastMCP. Le serveur abrite un Intelligent Decision Engine qui se décompose en trois fonctions nommées : sélection d'outil, optimisation des paramètres, découverte de chaînes d'attaque. Viennent ensuite plus de douze agents autonomes, dont les noms apparaissent dans le diagramme : BugBounty Agent, CTF Solver Agent, CVE Intelligence Agent, Exploit Generator Agent. Enfin, une couche de gestion des processus prend en charge le cache, l'optimisation des ressources et la reprise sur erreur. Il faut le dire franchement : cette description reste au niveau des étiquettes. Le README ne documente nulle part comment l'optimisation des paramètres est calculée, ni sur quelle base l'agent choisit entre feroxbuster et ffuf pour une même cible. Le diagramme Mermaid est un plan d'intention, pas une spécification. Un lecteur qui a besoin de savoir pourquoi un outil a été préféré à un autre ne trouvera pas la réponse dans le dépôt tel qu'il est présenté ici.

Mise en route : trois commandes et une liste de binaires

L'installation se fait en trois étapes classiques. On clone le dépôt, on crée un environnement virtuel nommé hexstrike-env, on active ce dernier, puis on installe les dépendances Python avec pip3 install -r requirements.txt. Le lancement tient en une ligne : python3 hexstrike_server.py, avec deux options documentées, --debug et --port. Le README montre un exemple sur le port 8888, ce qui suggère que ce n'est pas le port par défaut, mais la valeur par défaut n'est pas indiquée. La vérification passe par deux requêtes : un GET sur http://localhost:8888/health, et un POST sur /api/intelligence/analyze-target avec un corps JSON contenant target et analysis_type. Point important : le serveur MCP n'embarque pas les outils de sécurité. Il faut les installer séparément, et le README fournit des listes explicites par catégorie, de nmap, masscan, rustscan, amass, subfinder et nuclei jusqu'à hydra, john, hashcat, gdb, radare2, binwalk, ghidra, volatility3, en passant par prowler, trivy, kube-hunter et kube-bench. Pour le Browser Agent, il faut en plus chromium-browser et chromium-chromedriver, ou Google Chrome. C'est la vraie charge de travail : le dépôt Python n'est que la couche de liaison au-dessus d'un système déjà chargé.

La dépendance invisible : votre distribution, pas ce dépôt

C'est la limite la plus sérieuse, et elle n'est pas présentée comme telle. hexstrike-ai est un orchestrateur. La qualité, la précision et la sécurité de ses résultats dépendent entièrement des binaires installés sur la machine, de leur version et de leur configuration. Le README ne mentionne aucun mécanisme de verrouillage de versions, aucun fichier de type lock, aucun contrôle de compatibilité au démarrage. Un nmap ancien et un nmap récent ne produisent pas les mêmes sorties, et rien n'indique que le serveur normalise ces différences. Deux conséquences pratiques. D'abord, la reproductibilité d'un scan dépend de l'image système, pas du dépôt Git. Ensuite, la surface d'attaque du déploiement est celle de l'ensemble des outils installés, pas seulement du code Python sous licence MIT. Ajoutez à cela le point le plus visible : donner à un agent le droit de lancer sqlmap, hydra ou responder sur une cible est une opération à haut risque si le périmètre n'est pas strictement encadré. Le README ne décrit ni liste blanche de cibles, ni journal d'audit, ni garde-fou d'exécution. Ce n'est pas un défaut de conception en soi, mais c'est une absence qu'il faut combler soi-même.

Face à un agent qui écrit ses propres scripts

L'alternative la plus directe n'est pas un autre serveur MCP, c'est un agent doté d'un accès shell et d'une documentation d'outils. La différence d'approche est nette. Dans le second cas, le modèle compose lui-même la ligne de commande, lit la sortie brute et itère. Cela donne une flexibilité maximale, mais chaque appel est une improvisation : les drapeaux varient, les erreurs de syntaxe se multiplient, et rien ne garantit qu'un scan sera relancé de la même façon. hexstrike-ai déplace cette responsabilité dans le serveur, avec une couche de sélection d'outil et d'optimisation de paramètres. En contrepartie, l'agent hérite d'une boîte noire : il ne sait pas nécessairement quelle commande a été exécutée, et l'utilisateur non plus si le serveur ne l'expose pas. L'autre famille d'alternatives est l'orchestrateur de pentest classique, du type de ceux qui enchaînent reconnaissance, énumération et exploitation selon un graphe prédéfini. Là, la logique est déterministe et auditable, mais rigide : ajouter une étape inédite suppose de modifier le graphe. hexstrike-ai échange cette rigidité contre une adaptabilité pilotée par le modèle, avec la perte de prévisibilité qui va avec.

Maintenance, licence et coût réel de possession

Le dépôt est actif : le dernier push répertorié date du 3 août 2026, et le README porte la mention v6.0. Aucune release n'a été récupérée dans les métadonnées fournies, donc l'historique de version n'est pas vérifiable ici. La licence MIT couvre le code du serveur, ce qui autorise la modification et la redistribution, y compris en contexte commercial, à condition de conserver l'avis de licence. Elle ne couvre évidemment pas les outils tiers appelés : nmap, sqlmap, nuclei, hydra, ghidra et les autres ont leurs propres licences, parfois restrictives pour un usage commercial, et le README ne les récapitule pas. C'est un point à vérifier avant tout déploiement en entreprise. Le coût de maintenance, lui, se situe surtout du côté de l'environnement : mettre à jour une distribution, c'est potentiellement changer le comportement de dix outils à la fois, sans qu'aucun test du dépôt ne signale la régression. Le suivi du projet amont ne suffit donc pas.

Ce qu'il faut vérifier avant de s'engager

Trois vérifications concrètes, toutes traçables dans le README. Premièrement, le démarrage : python3 hexstrike_server.py doit s'exécuter sans erreur d'import, ce qui suppose que requirements.txt couvre bien les dépendances de FastMCP et du reste. Deuxièmement, la santé du service : curl http://localhost:8888/health doit répondre, et il faut noter que le port par défaut n'est pas documenté, donc commencez par confirmer la valeur réelle avec --port. Troisièmement, la présence effective des binaires listés dans Install Security Tools dans le PATH de l'utilisateur qui lance le serveur : un outil manquant ne produira probablement pas d'erreur au démarrage, seulement un échec au moment de l'appel. Enfin, pour un usage en équipe, la question du client MCP compte autant que le serveur : le README précise que 5ire en version 0.14.0 n'est pas pris en charge pour l'instant, ce qui montre que la compatibilité dépend aussi du client et de sa version.

Conclusion éditoriale

Adoptez hexstrike-ai si vous êtes déjà à l'aise avec une chaîne d'outils Kali et que vous voulez donner à un agent MCP un point d'entrée unique vers nmap, sqlmap ou nuclei, dans un cadre de test autorisé. Passez votre chemin si vous cherchez une orchestration déterministe et reproductible : le serveur lance des binaires externes dont la version conditionne les résultats, et rien dans le README ne décrit de verrouillage de versions. Avant tout déploiement, vérifiez trois choses concrètes : que python3 hexstrike_server.py démarre sans erreur d'import, que curl http://localhost:8888/health répond, et que chacun des binaires listés dans la section Install Security Tools est bien présent dans le PATH de l'utilisateur qui exécute le serveur.

Sources officielles

1. 0x4m4/hexstrike-ai on GitHub
2. Issues
3. License: MIT
4. Project website
5. README