HexStrike AI MCP Agents: 150 Sicherheitstools hinter einem MCP-Server

Ein MCP-Server als Brücke zwischen Chatfenster und Kali-Toolchain

Das Problem, das HexStrike AI adressiert, ist organisatorischer Natur. Ein Sprachmodell kann einen nmap-Scan vorschlagen, aber es kann ihn nicht ausführen. Bisher endet jeder Pentest-Workflow mit einem LLM an der Stelle, an der ein Kommando auf einer Maschine laufen müsste. HexStrike setzt genau dort an: Der Server läuft lokal, spricht das MCP-Protokoll und stellt dem Agenten die installierten Werkzeuge als aufrufbare Funktionen bereit. Die Zielgruppe sind Security-Forscher, Bug-Bounty-Jäger und CTF-Teilnehmer, die bereits eine Kali-Umgebung oder eine vergleichbare Toolchain betreiben und diese nicht manuell bedienen wollen. Das README nennt als unterstützte Clients 5ire, VS Code Copilot, Roo Code, Cursor und Claude Desktop, außerdem jeden weiteren MCP-kompatiblen Agenten. Wer keinen dieser Clients verwendet, hat keinen Einstiegspunkt.

Entscheidungsengine, Agenten und die 150 Tools als drei getrennte Schichten

Das Architekturdiagramm im README zeigt drei Zweige, die vom MCP-Server abgehen: eine Intelligent Decision Engine, die 12+ autonomen Agenten und die Modern Visual Engine. Die Decision Engine unterteilt sich laut Diagramm in Tool Selection AI, Parameter Optimization und Attack Chain Discovery. Von den Agenten werden namentlich vier genannt: BugBounty Agent, CTF Solver Agent, CVE Intelligence Agent und Exploit Generator Agent. Die 150+ Tools sind nach Kategorien gruppiert, darunter 25+ Netzwerk-, 40+ Web-Applikations-, 20+ Cloud-, 25+ Binary-, 20+ CTF- und 20+ OSINT-Werkzeuge. Daneben steht ein Block namens Advanced Process Management mit Smart Caching, Resource Optimization und Error Recovery. Was das Diagramm nicht zeigt, ist der Datenfluss zwischen Decision Engine und Agenten. Ob die Agenten eigenständig Tool-Aufrufe planen oder ob die Decision Engine die Auswahl trifft und die Agenten nur ausführen, lässt sich aus dem Material nicht beantworten. Diese Unterscheidung ist praktisch relevant, weil sie bestimmt, wie viel Kontrolle der Bediener über die Reihenfolge der ausgeführten Kommandos behält.

Installation: virtuelle Umgebung, requirements.txt, dann die Tools einzeln nachziehen

Der im README dokumentierte Weg ist knapp. Zuerst wird das Repository geklont, dann eine virtuelle Umgebung mit python3 -m venv hexstrike-env angelegt und aktiviert, anschließend pip3 install -r requirements.txt ausgeführt. Der Server startet mit python3 hexstrike_server.py, optional mit --debug oder mit --port 8888. Die Standardportangabe in den Beispielen ist 8888, was nahelegt, dass dies auch der Vorgabewert ist. Die Sicherheitswerkzeuge selbst sind nicht Teil der Python-Abhängigkeiten. Das README listet sie als apt-Pakete auf, gruppiert nach Kategorien: nmap, masscan, rustscan, amass, subfinder, nuclei und weitere für Netzwerk und Reconnaissance; gobuster, feroxbuster, ffuf, nikto, sqlmap, wpscan und dalfox für Web; hydra, john, hashcat, medusa und crackmapexec für Passwörter; gdb, radare2, binwalk, ghidra, checksec und volatility3 für Binäranalyse. Für Cloud kommen prowler, scout-suite, trivy, kube-hunter, kube-bench und docker-bench-security dazu. Der Browser Agent benötigt zusätzlich chromium-browser und chromium-chromedriver oder Google Chrome. Wer diese Liste nicht abarbeitet, bekommt einen laufenden Server mit einem Bruchteil der beworbenen Funktionalität. Das ist der eigentliche Installationsaufwand, nicht die Python-Seite.

Health-Check und der Intelligence-Endpunkt als erste Prüfsteine

Zur Verifikation nennt das README zwei Aufrufe. Der erste ist ein GET auf http://localhost:8888/health. Der zweite ist ein POST auf http://localhost:8888/api/intelligence/analyze-target mit dem Content-Type application/json und einem Rumpf der Form {"target": "example.com", "analysis_type": "comprehensive"}. Damit existiert neben dem MCP-Protokoll offenbar auch eine HTTP-JSON-Schnittstelle, was für Skripte und zum Debuggen nützlich ist. Auffällig ist, dass beide Beispiele ohne Authentifizierung auskommen. Das README beschreibt keinen Token, keinen API-Key und keine Zugriffsbeschränkung. Ein Server, der auf einem Port lauscht und Kommandos wie nmap oder sqlmap ausführt, ist damit in erster Linie ein lokales Werkzeug. Wer ihn auf einer öffentlich erreichbaren Adresse bindet, schafft eine Fernsteuerung für offensive Werkzeuge. Ob eine Bindung an 127.0.0.1 voreingestellt ist, geht aus dem Material nicht hervor und sollte vor dem ersten Start im Quelltext geprüft werden.

Wo das Modell die Kontrolle abgibt und wo das Projekt an Grenzen stößt

Der zentrale Trade-off liegt in der Autonomie. Das README bewirbt ausdrücklich, dass Agenten Sicherheitsbewertungen autonom ausführen und sich in Echtzeit an gefundene Schwachstellen anpassen. Genau das ist das Risiko. Ein Agent, der aus einem Scan-Ergebnis selbstständig die nächste Aktion ableitet, kann in einem Produktivnetz Schaden anrichten, den niemand beabsichtigt hat. Die Error-Recovery-Komponente aus dem Architekturdiagramm verstärkt das, denn sie sorgt dafür, dass ein fehlgeschlagener Schritt nicht zum Abbruch führt. Für ein gescanntes Ziel bedeutet das unter Umständen mehr Anfragen als geplant. Ein zweiter Punkt ist die fehlende Trennung der Umgebung. Die Installation sieht eine virtuelle Python-Umgebung vor, aber die Security-Tools werden systemweit über apt installiert. Es gibt im Material keinen Hinweis auf Container, Netzwerk-Namespaces oder eine eingeschränkte Ausführungsumgebung. Der Server erbt damit die Rechte des Benutzers, unter dem er läuft. Wer ihn als root startet, weil einzelne Tools das verlangen, gibt dem Agenten root-Rechte auf dem eigenen System. Ein dritter Punkt betrifft die Aktualität: Das README vermerkt ausdrücklich, dass 5ire in Version 0.14.0 derzeit nicht unterstützt wird. Solche Aussagen altern schnell, und das Repository enthält laut den vorliegenden Angaben keine Release-Einträge, an denen sich ein Änderungsverlauf ablesen ließe.

Der Unterschied zu einem klassischen Pentest-Framework

Die naheliegende Alternative ist ein etabliertes Framework wie Metasploit oder ein Orchestrierungswerkzeug wie Autorecon, das das README selbst in der Werkzeugliste führt. Der Unterschied liegt in der Steuerungsschicht. Metasploit bringt eigene Module mit und führt Exploits über eine Ruby-Laufzeit aus, die Exploit-Auswahl ist an die verfügbaren Module gebunden. HexStrike bringt keine eigenen Exploits mit. Es ruft vorhandene Kommandozeilenwerkzeuge auf und überlässt die Auswahl einem Sprachmodell. Das ist der eigentliche Unterschied: nicht die Zahl der Tools, sondern wer entscheidet, welches davon wann läuft. Bei Autorecon ist der Ablauf in Konfigurationsdateien festgeschrieben und damit reproduzierbar. Bei HexStrike entsteht der Ablauf zur Laufzeit aus dem Modellkontext. Reproduzierbarkeit ist damit nicht gegeben, was für Bug-Bounty-Berichte und für dokumentationspflichtige Audits ein Problem darstellt. Wer nachvollziehbare Läufe braucht, ist mit einer skriptgesteuerten Pipeline besser bedient. Wer explorativ arbeitet und die Reihenfolge ohnehin ständig anpasst, gewinnt durch die Modellsteuerung Zeit.

Lizenz, Wartung und was ein Upgrade kostet

Das Projekt steht unter der MIT-Lizenz. Das ist die permissivste gängige Variante: Nutzung, Änderung und Weitergabe sind erlaubt, solange der Lizenztext und der Urheberrechtshinweis beibehalten werden. Für eine kommerzielle Nutzung innerhalb eines Unternehmens entstehen daraus keine Copyleft-Pflichten. Zu beachten ist allerdings, dass die MIT-Lizenz nur den Code von HexStrike selbst abdeckt. Die 150 Werkzeuge, die der Server aufruft, haben eigene Lizenzen, und einige davon sind nicht permissiv. Wer HexStrike in ein Produkt einbettet, muss die Lizenz jedes tatsächlich aufgerufenen Werkzeugs separat prüfen. Das ist keine Rechtsberatung, sondern ein Hinweis auf den Prüfbedarf. Zum Wartungsaufwand lässt sich aus dem Material wenig Belastbares sagen. Es gibt keine abgerufenen Release-Einträge, und das README selbst dokumentiert eine Inkompatibilität mit einer bestimmten Client-Version. Das deutet darauf hin, dass die Pflege der Client-Integrationen laufende Arbeit erfordert. Dazu kommt der Aufwand für die Tool-Seite: Jede Änderung an der Kommandozeilenschnittstelle eines der 150 Werkzeuge kann die Parameterübergabe brechen. Ob das Projekt dafür Tests bereitstellt, geht aus dem Material nicht hervor.

Redaktionelles Fazit

Wer eine MCP-Brücke zu lokal installierten Pentest-Tools sucht und die Rechteverwaltung selbst übernimmt, findet hier eine MIT-lizenzierte Basis. Wer eine fertige Plattform mit Sandbox und Audit-Trail erwartet, sollte zuerst prüfen, ob hexstrike_server.py eine Authentifizierungsschicht mitbringt, ob die Portbindung konfigurierbar ist und ob das Repository eine CI-Konfiguration enthält. Ohne diese drei Punkte bleibt der Server ein Werkzeug für kontrollierte Laborumgebungen.

Offizielle Quellen

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