PentestAgent: LLM-Agenten für Black-Box-Tests, ohne Orchestrierung von außen

Welche Lücke PentestAgent für wen schließt

Ein LLM weiß nicht, was auf einem Ziel läuft. Es kann aber eine Shell bedienen, Ausgaben lesen und entscheiden, welcher Befehl als nächster sinnvoll ist. Genau an dieser Stelle setzt PentestAgent an: Das Projekt ist laut README ein Agenten-Framework für Black-Box-Sicherheitstests, das Bug-Bounty-, Red-Team- und Penetrationstest-Abläufe abbilden soll. Angesprochen sind Menschen, die bereits wissen, was ein Port-Scan ist, und die wiederkehrende Arbeit automatisieren wollen, statt sie durch einen Orchestrierungsdienst zu schicken.

Die Zielgruppe ist enger als die Themenliste im Repository vermuten lässt. Wer eine fertige Plattform mit Rollen, Freigaben und Audit-Trail sucht, wird hier nichts finden. Wer dagegen ein lokales Werkzeug möchte, das ein Modell an ein Terminal und einen Browser anschließt und die Sitzung als Notizen und Bericht festhält, bekommt genau das. Die vier TUI-Modi (/assist, /agent, /crew, /interact) unterscheiden sich vor allem darin, wie viel Autonomie der Agent bekommt. /assist führt eine einzelne Anweisung aus, /agent arbeitet eine Aufgabe eigenständig ab, /crew verteilt sie an spezialisierte Worker, /interact bleibt im Dialog.

Der Selbst-Spawning-Mechanismus und was er wirklich kostet

Das interessanteste Bauteil ist das eingebaute Tool spawn_mcp_agent. Ein laufender Agent startet damit eine Kindkopie seiner selbst als untergeordneten MCP-Server, verbunden über stdio. Das Kind bekommt laut README einen eigenen Runtime-Kontext, einen eigenen LLM-Client, eigene Konversationshistorie und einen eigenen Notizspeicher. Nach dem Start werden die Werkzeuge des Kindes in die Werkzeugliste des Elternagenten injiziert, allerdings erst beim nächsten Tool-Aufruf. Der Server-Name wird automatisch vergeben, etwa child_agent_1, und im Ergebnis zurückgegeben.

Das ersetzt externe Orchestrierung. Kein Scheduler, keine Warteschlange, kein Koordinationsdienst. Der Elternagent delegiert Teilaufgaben an Kinder, die er bei Bedarf erzeugt. Das README zeigt als Beispiel einen Orchestrator, der in Runde eins zwei Kinder für 10.0.1.0/24 und 10.0.2.0/24 startet und in Runde zwei deren Werkzeuge wie run_task, run_task_async und await_tasks nutzt. Die Argumente sind target, scope, model, no_rag und no_mcp. no_mcp steht standardmäßig auf true und wird im README ausdrücklich empfohlen, damit Kinder keine weiteren externen MCP-Server anschließen.

Der Preis für diese Architektur ist weniger sichtbar als der Nutzen. Jedes Kind ist ein eigener Prozess mit eigenem Modellkontext. Bei mehreren Kindern parallel summieren sich Token-Verbrauch und Laufzeit, ohne dass eine zentrale Stelle das Budget begrenzt. Wer /spawn mit --model M aufruft, kann pro Kind ein anderes Modell wählen, was die Kostensteuerung etwas erleichtert. Ein harter Deckel pro Sitzung ist im Material nicht erkennbar.

Installation und die Konfigurationsschlüssel, die zählen

Das Repository liefert zwei Setup-Skripte: scripts/setup.ps1 für Windows und scripts/setup.sh für Linux und macOS. Beide legen eine virtuelle Umgebung an und installieren die Abhängigkeiten. Manuell entspricht das python -m venv venv, Aktivierung über venv\Scripts\Activate.ps1 beziehungsweise source venv/bin/activate, danach pip install -e ".[all]". Der Browser-Werkzeugkasten braucht zusätzlich playwright install chromium. Ohne diesen Schritt bleibt das browser-Tool funktionslos.

Die Konfiguration läuft über eine .env im Projektwurzelverzeichnis. Zwei Variablen sind Pflicht: ein API-Schlüssel des Anbieters und PENTESTAGENT_MODEL. Das README zeigt ANTHROPIC_API_KEY zusammen mit claude-sonnet-4-20250514 sowie die OpenAI-Variante mit OPENAI_API_KEY und gpt-5. Grundsätzlich funktioniert jedes von LiteLLM unterstützte Modell. Für Relays oder kompatible Endpunkte gibt es OPENAI_API_BASE und ANTHROPIC_API_BASE; das Modell wird dann als openai/<modellname> eingetragen. Die vollständigen Anbieter-Notizen und Embedding-Optionen stehen laut README in .env.example.

Gestartet wird mit pentestagent für die TUI, pentestagent -t 192.168.1.1 setzt gleich ein Ziel, pentestagent tui --docker lässt die Werkzeuge in einem Container laufen. Playbooks werden separat aufgerufen: pentestagent run -t example.com --playbook thp3_web. Die Namen der mitgelieferten Playbooks lassen sich aus dem Material nicht vollständig ableiten; thp3_web ist das einzige genannte Beispiel.

Was Docker hier tatsächlich absichert

Der Container-Modus ist keine Nebensache. Ohne ihn laufen nmap, netcat und curl auf dem eigenen Rechner, und der Agent entscheidet, welche Befehle ausgeführt werden. Das README beschreibt zwei Wege. Erstens ein fertiges Image ziehen: ghcr.io/gh05tcrew/pentestagent:latest enthält nmap, netcat und curl, das Tag kali zusätzlich Metasploit, sqlmap und hydra. Beide werden mit docker run -it --rm gestartet, die API-Schlüssel per -e übergeben.

Zweitens ein lokaler Build über docker compose build beziehungsweise docker compose --profile kali build, ausgeführt mit docker compose run --rm pentestagent oder pentestagent-kali. Laut README greift der Agent im Container direkt über das terminal-Tool auf die Werkzeuge zu. Docker muss installiert und laufend sein; das ist die einzige dokumentierte Voraussetzung für diesen Modus.

Interessant ist die Rollenverteilung: Der Container isoliert die Werkzeuge, nicht die Daten. Notizen, Konversationsverläufe und Berichte entstehen weiterhin im Arbeitsverzeichnis des Agenten. Wer den Container ohne Volume-Mount startet, verliert den Sitzungsstand beim Entfernen des Containers (--rm). Das ist kein Fehler, aber ein Detail, das man vor einem längeren Lauf kennen sollte.

Grenzen, die im README sichtbar werden

Die ehrlichste Einschränkung steht im Abschnitt zu spawn_mcp_agent selbst: Die Werkzeuge eines Kindes sind erst beim nächsten Tool-Aufruf verfügbar. Der Orchestrator muss also mindestens zwei Runden planen. Ein Modell, das nach dem Spawn sofort delegieren will, läuft ins Leere. Das ist eine Einschränkung des Protokolls, nicht des Modells, und sie prägt jede mehrstufige Aufgabe.

Zweitens ist der Scope eine Frage der Disziplin. spawn_mcp_agent nimmt scope als Liste von Zielen oder CIDR-Blöcken entgegen, und das README empfiehlt no_mcp=true für Kinder, damit diese nicht weitere Server anschließen. Eine technische Durchsetzung des Scope ist aus dem Material nicht belegt. Wer dem Agenten ein /24 übergibt, verlässt sich darauf, dass er sich daran hält.

Drittens fehlen Releases. Die Abfrage liefert keine Einträge, obwohl das Badge im README Version 0.2.0 nennt und auf eine Releases-Seite verlinkt. Wer auf einen stabilen, versionierten Stand angewiesen ist, muss das vorab prüfen. Der letzte Push liegt laut Repository-Metadaten auf dem 7. September 2026, das Projekt ist nicht archiviert. Für ein Werkzeug, das aktiv Befehle ausführt, ist die fehlende Release-Historie ein realer Faktor bei der Auswahl.

Wann ein Skript die bessere Wahl bleibt

Der naheliegende Vergleich ist ein Shell-Skript mit nmap und einer Handvoll curl-Aufrufen. Der Unterschied liegt nicht in der Geschwindigkeit, sondern in der Entscheidungskette. Ein Skript führt eine feste Sequenz aus; PentestAgent wählt Befehle anhand dessen, was der vorherige Schritt zurückgegeben hat. Genau das ist bei unbekannten Zielen nützlich, weil der nächste sinnvolle Schritt von der Antwort abhängt.

Bei bekannten Zielen kehrt sich das um. Wenn die offenen Ports und Dienste bereits dokumentiert sind, kostet ein Agent nur Token und Wartezeit. Ein Skript ist reproduzierbar, protokolliert exakt dieselbe Ausgabe und lässt sich in eine Pipeline einhängen. PentestAgent bietet dafür keinen Ersatz: Die TUI ist interaktiv, /report erzeugt einen Bericht aus der Sitzung, aber ein nicht-interaktiver Modus für CI ist im README nicht beschrieben.

Ein zweiter Unterschied betrifft die Erweiterbarkeit. PentestAgent unterstützt MCP und bringt terminal, browser, notes, web_search und spawn_mcp_agent mit. web_search verlangt einen TAVILY_API_KEY. Wer eigene Werkzeuge anbinden will, muss den MCP-Weg gehen; ein einfaches Plugin-Verzeichnis wird nicht beschrieben. Ein Skript kennt diese Grenze nicht.

Wartung, Lizenz und der Blick auf die Kosten

Das Projekt steht unter MIT-Lizenz. Das ist die permissivste gängige Variante: Nutzung, Änderung und Weitergabe sind erlaubt, solange Lizenztext und Urheberrechtshinweis erhalten bleiben. Für ein Werkzeug, das fremde Systeme testet, ist das relevant, weil der Code damit auch in interne Werkzeugkästen wandern darf. Eine rechtliche Einschätzung des Einsatzes gegen fremde Ziele ersetzt die Lizenz nicht, und das README gibt dazu keine Hinweise.

Die laufenden Kosten liegen beim Modellanbieter, nicht beim Projekt. Jeder Agentenschritt ist ein LLM-Aufruf, jedes Kind ein eigener Kontext. Das TUI-Kommando /memory zeigt Token- und Speicherverbrauch, und /conversations erlaubt das Wiederaufnehmen gespeicherter Verläufe. Wer die Kosten im Blick behalten will, hat mit /memory ein Werkzeug dafür, aber keinen automatischen Abbruch.

Upgrades sind einfach, solange man dem Hauptzweig folgt: git pull, dann pip install -e ".[all]" erneut ausführen. Ohne Releases gibt es keine Versionsanker, an denen man sich orientieren könnte. Wer reproduzierbare Läufe braucht, sollte den Commit-Hash selbst festhalten. Das ist keine Empfehlung, sondern die Konsequenz aus einer Repository-Struktur ohne veröffentlichte Tags.

Redaktionelles Fazit

Wer wiederkehrende Black-Box-Aufgaben gegen klar abgegrenzte Ziele automatisiert und die Token-Kosten selbst trägt, findet hier ein schlankes Werkzeug mit sauberem Isolationsmodell. Wer einen Einmal-Scan gegen einen einzelnen Host sucht, sollte bei nmap und einem Skript bleiben. Vor dem produktiven Einsatz zuerst /memory nach einem kurzen Recon-Lauf prüfen und danach das Docker-Profil wählen, damit die Werkzeuge nicht auf dem eigenen Rechner landen.

Offizielle Quellen

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