Decepticon: autonomer Red-Team-Agent mit Engagement-Paket vor dem ersten Paket

Ein Agent, der vor dem ersten Paket ein Engagement-Paket verlangt

Viele Werkzeuge im Umfeld von KI und Penetrationstests enden dort, wo ein Scanner endet: Sie führen nmap aus und schreiben einen Bericht. Das README von Decepticon grenzt sich mit einem Satz davon ab, der als Zitat im Repository steht: "Another AI hacker? Let us guess - it runs nmap and writes a report." Der Anspruch ist ein anderer. Decepticon soll realistische Angriffsketten ausführen, also Aufklärung, Ausnutzung, Rechteausweitung, laterale Bewegung und Command-and-Control, und zwar in der Reihenfolge, in der ein Angreifer vorgeht, nicht in der Reihenfolge, in der ein Scanner seine Module abarbeitet.

Das eigentliche Unterscheidungsmerkmal liegt aber vor dem Betrieb. Laut README erzeugt Decepticon vor dem ersten Paket ein vollständiges Engagement-Paket: Rules of Engagement, Concept of Operations, einen Deconfliction Plan und einen OPPLAN mit Zuordnung zu MITRE ATT&CK. Jede Aktion läuft anschließend innerhalb dieser definierten Regeln. Zielgruppe sind damit Red-Team-Teams, die ohnehin mit Auftragsdokumenten arbeiten und einen Agenten suchen, der diese Dokumente nicht ignoriert. Wer Decepticon ohne diese Vorarbeit startet, umgeht das zentrale Konstruktionsprinzip des Projekts.

LangGraph als Gerüst, LiteLLM und Neo4j als Rückgrat

Der Default-Start fährt eine Kernverwaltungsebene hoch, die im README namentlich aufgeführt wird: LiteLLM, PostgreSQL, Neo4j, Skillogy, LangGraph und eine Sandbox. LiteLLM sitzt dabei als Proxy zwischen Agent und Modellanbieter, was erklärt, warum das Onboarding nach Anbieter, API-Schlüssel und Modellprofil fragt. Neo4j trägt die Wissensgraph-Werkzeuge für Angriffsketten; das PyPI-Extra decepticon[neo4j] bindet sie ein. PostgreSQL und Skillogy gehören zur Verwaltungsebene, ohne dass das README ihre genaue Rolle ausführt.

Die Aufteilung zwischen Kern und Spezialisten ist bewusst: BloodHound CE, Sliver C2 und Ghidra MCP gehören nicht zum Default-Start. Sie werden bei Bedarf hochgefahren, und zwar laut README über den Orchestrator, der Spezialisten mit Aufrufen wie ops_start("ad") startet. Das Web-Dashboard folgt demselben Muster und wird aus der CLI heraus mit /web gestartet. Der Datenfluss verläuft also nicht linear durch eine Pipeline, sondern über einen Orchestrator, der Arbeitslasten anfordert und die passenden Dienste nachzieht. Wer die Topics des Repositories liest, findet dort LangChain, LangGraph und LLM als Bausteine; die Architektur ist damit als Agentengraph mit externen Werkzeugdiensten zu lesen und nicht als monolithisches Skript.

Installation über curl, dann ein Onboarding-Assistent

Der Einstieg ist auf drei Befehle reduziert. Unter macOS, Linux und WSL2 lautet er: curl -fsSL https://decepticon.red/install | bash, danach decepticon onboard, dann decepticon. Unter Windows gibt es einen eigenen Pfad über PowerShell mit irm https://decepticon.red/install.ps1 | iex, gefolgt von denselben beiden Befehlen. Voraussetzung sind Docker und Docker Compose v2. Unterstützt werden laut README macOS mit Apple Silicon und Intel, Linux auf amd64 und arm64 sowie Windows auf amd64 und arm64, nativ über PowerShell oder über WSL2 mit Ubuntu oder Kali.

decepticon onboard ist ein interaktiver Assistent und fragt Anbieter, API-Schlüssel und Modellprofil ab. Der anschließende Aufruf decepticon startet den Kern-Stack und öffnet die Terminal-CLI. Wer Decepticon als Bibliothek einbinden will, installiert stattdessen pip install decepticon oder pip install "decepticon[neo4j]". Wichtig ist die Einordnung im README: Das Paket ist ein Client-SDK. Es liefert Agent-Factories, Middleware, Werkzeuge und Skills, leitet LLM-Aufrufe und Sandbox-Ausführung aber per HTTP an Laufzeitdienste weiter. Die dafür relevanten Konfigurationsschlüssel sind DECEPTICON_LLM__PROXY_URL und SANDBOX_URL. Ohne diese Dienste laufen die Agenten nicht, auch wenn das Paket installiert ist.

Der Benchmark im README und was er nicht belegt

Das Repository nennt Ergebnisse auf den XBOW validation-benchmarks. Angegeben sind 45 von 45 auf Level 1, 50 von 51 auf Level 2, 7 von 8 auf Level 3, zusammen 102 von 104, also 98,08 Prozent. Diese Zahlen stammen aus dem Projekt selbst und aus einer Benchmark-Suite, die im README unter PurpleAILAB/xbow-validation-benchmarks verlinkt ist. Wer die Zahlen als Beleg für Einsatzreife liest, sollte zwei Dinge beachten. Erstens sagt eine Pass-Rate auf validierten Challenges nichts über ein unbekanntes Zielnetz mit eigener Topologie, eigenen Filtern und eigener Erkennung aus. Zweitens liegen die Ergebnisse für Level 3 bei 7 von 8, die schwierigste Kategorie ist also die mit der kleinsten Stichprobe.

Das README verweist für Details auf benchmark/results/README.md mit einem Index pro Challenge, einer Matrix nach Angriffsklassen und LangSmith-Traces sowie auf docs/benchmark-comparison.md mit einem Vergleich zu anderen KI-Pentest-Agenten wie Strix, PentestGPT, MAPTA, Cyber-AutoAgent und dem kommerziellen XBOW. Wer die Zahlen prüfen will, findet dort die Rohdaten. Eine unabhängige Nachstellung ist aus dem Material nicht belegt.

Interaktive Shells: der Punkt, an dem viele Agenten scheitern

Das README benennt ein Problem, das in der Praxis häufig unterschätzt wird: Echte offensive Werkzeuge sind interaktiv. Genannt werden msfconsole, sliver-client und evil-winrm. Ein Agent, der nur einzelne Befehle absetzt und die Ausgabe einsammelt, kommt mit solchen Programmen nicht weit, weil sie eine Sitzung erwarten, auf Eingaben warten und Zustand halten. Decepticon beansprucht laut README, jeden Befehl innerhalb einer solchen Umgebung auszuführen. Der Abschnitt ist im vorliegenden Material an dieser Stelle abgeschnitten, die genaue Umsetzung lässt sich daraus nicht rekonstruieren.

Das ist eine Einschränkung der Quellenlage, keine Aussage über die Qualität. Festhalten lässt sich nur: Das Projekt adressiert das Problem explizit, und die Sandbox ist Teil des Default-Stacks. Ob die Sitzungsverwaltung über einen PTY im Sandbox-Container läuft, über einen eigenen Session-Dienst oder über etwas anderes, geht aus dem Material nicht hervor. Wer das für die eigene Umgebung prüfen muss, sollte die verlinkten Dokumentationsseiten konsultieren, bevor er Decepticon gegen echte Ziele richtet.

Wann Decepticon das falsche Werkzeug ist

Der Betriebsaufwand ist der erste Ausschlussgrund. Decepticon ist kein einzelnes Binary, sondern ein Docker-Compose-Stack mit mehreren Diensten: LiteLLM, PostgreSQL, Neo4j, Skillogy, LangGraph und Sandbox im Kern, dazu auf Abruf BloodHound CE, Sliver C2 und Ghidra MCP. Wer nur gelegentlich ein Netz segmentieren und einen Bericht erzeugen will, trägt hier deutlich mehr Infrastruktur, als die Aufgabe verlangt. Ein klassischer Schwachstellen-Scanner bleibt für diese Fälle die günstigere Wahl.

Der zweite Ausschlussgrund ist prozessual. Das README macht das Engagement-Paket aus RoE, ConOps, Deconfliction Plan und OPPLAN zur Voraussetzung, nicht zur Option. Teams ohne diese Dokumente müssten sie erst einführen, um Decepticon bestimmungsgemäß zu nutzen. Drittens ist der Modellzugang nicht optional: Das SDK leitet LLM-Aufrufe an einen Proxy weiter, der konfiguriert sein muss. Ohne DECEPTICON_LLM__PROXY_URL und SANDBOX_URL passiert nichts. Wer keinen Anbieter anbinden darf oder will, kann Decepticon nicht sinnvoll betreiben. Und wer Ergebnisse ohne eigene Nachprüfung übernimmt, verkennt, dass die Benchmark-Zahlen aus dem Projekt selbst stammen.

Was ein Wechsel zu einem Skript-basierten Scanner kostet

Die naheliegende Alternative ist kein anderes KI-Produkt, sondern ein klassischer Scanner plus manuelle Auswertung. Der Unterschied liegt im Grad der Automatisierung und in der Rolle des Menschen. Ein Scanner arbeitet eine feste Prüfliste ab und liefert reproduzierbare Ergebnisse; Decepticon liest laut README einen OPPLAN und verfolgt Ziele auf dem Weg, der sich öffnet, mit Pivotieren, Anpassen und Verketten von Techniken. Das ist der Kern des Unterschieds: feste Prüfliste gegen dynamische Zielverfolgung.

Der Preis für die dynamische Variante ist Vorhersagbarkeit. Ein Agent, der seinen Pfad wechselt, ist schwerer zu auditieren als ein Scanner, der dieselben Module in derselben Reihenfolge ausführt. Genau deshalb verlangt Decepticon das Engagement-Paket mit Deconfliction Plan und MITRE-ATT&CK-Zuordnung: Die Zuordnung macht nachvollziehbar, welche Technik zu welchem Zeitpunkt zum Einsatz kam. Ein Team, das diese Nachvollziehbarkeit nicht braucht, gewinnt durch Decepticon wenig. Innerhalb der KI-Agenten wiederum unterscheidet sich Decepticon laut README von Strix, PentestGPT, MAPTA, Cyber-AutoAgent und XBOW kommerziell; die Details stehen in docs/benchmark-comparison.md, nicht im README selbst.

Wartung, Lizenz und der Blick in die Dokumentation

Das Repository steht unter Apache-2.0. Diese Lizenz erlaubt kommerzielle Nutzung, Veränderung und Weitergabe, verlangt aber die Beibehaltung von Copyright-Hinweisen und Lizenztext und enthält eine ausdrückliche Patentgewährung. Wer Decepticon in ein Produkt einbettet, sollte die Bedingungen der Apache-2.0 im eigenen Rechtskontext prüfen; eine rechtliche Bewertung kann dieser Artikel nicht leisten. Für die Nutzung als SDK ist zusätzlich relevant, dass decepticon selbst keine Laufzeitdienste enthält, sondern auf HTTP-Endpunkte zeigt. Die Wartungslast verteilt sich damit auf zwei Seiten: das Paket und die betriebenen Dienste.

Die Release-Historie zeigt kurze Abstände. Zwischen v1.1.38 am 12. Juli 2026 und v1.1.39 am 27. Juli 2026 liegen rund zwei Wochen, v1.1.40 folgte am selben Tag wie v1.1.39. Solche Zyklen bedeuten, dass ein gepinntes Docker-Compose-Setup regelmäßig nachgezogen werden muss, wenn man nicht auf einer älteren Version stehen bleiben will. Das Repository ist nicht archiviert, der letzte Push liegt laut Metadaten auf dem 30. August 2026. Vor einem Einsatz lohnt der Blick in docs/engagement-workflow.md für den Ablauf des Engagements, in docs/library-usage.md für die Factory-Overrides, die deklarativen PluginBundle-Plugins und das Safety Gate sowie in docs/web-dashboard.md, falls das Dashboard aus der CLI mit /web gestartet werden soll. Wer den Agenten als Bibliothek einbinden will, muss außerdem klären, wo die Laufzeitdienste laufen, denn das SDK allein führt keinen Befehl aus.

Redaktionelles Fazit

Decepticon passt zu Red-Team-Teams, die bereit sind, eine Docker-Umgebung mit LiteLLM, PostgreSQL, Neo4j, Skillogy, LangGraph und Sandbox zu betreiben und ihre Engagements vorab über RoE, ConOps, Deconfliction Plan und OPPLAN zu formalisieren. Wer nur einen schnellen Schwachstellen-Scanner sucht, ist hier falsch: Der Agent setzt auf eine vollständige Infrastruktur und auf dokumentierte Regeln, bevor er arbeitet. Vor dem Einsatz sollte man die Datei docs/engagement-workflow.md lesen und den PluginBundle-Pfad sowie das Safety Gate aus docs/library-usage.md prüfen, weil dort die Grenzen der SDK-Nutzung beschrieben sind.

Offizielle Quellen

1. License: Apache-2.0
2. Project website
3. PurpleAILAB/Decepticon on GitHub
4. README
5. Releases