Decepticon : un agent de red team autonome qui écrit d'abord ses propres règles d'engagement
Autonomous Hacking Agent for Red Team
En bref
- De quoi s’agit-il ?
- Decepticon est un agent offensif Python sous Apache-2.0, distribué en pile Docker et en SDK PyPI. Sa particularité n'est pas la chaîne d'attaque mais le fait qu'il produit RoE, ConOps, plan de déconfliction et OPPLAN avant d'émettre le premier paquet.
- À qui s’adresse-t-il ?
- Adoptez Decepticon si vous avez déjà un périmètre d'engagement écrit et que vous voulez déléguer l'exécution de chaînes kill chain à un agent qui trace ses actions dans LangSmith, en acceptant de faire tourner LiteLLM, PostgreSQL, Neo4j et un sandbox sur vos machines. Ne l'adoptez pas si vous cherchez un scanner de surface ou si votre cible sort du cadre d'un test d'intrusion autorisé.
- Puis-je l’utiliser commercialement ?
- Oui. Apache-2.0 est une licence permissive : vous pouvez utiliser, modifier et vendre un logiciel qui en dépend, à condition de conserver les mentions de droit d’auteur et de licence.
- Est-il encore maintenu ?
- Oui. Les derniers commits datent d’il y a 16 jours.
- En quel langage est-il écrit ?
- Principalement Python, d’après les statistiques de langage de GitHub.
Ces réponses reposent sur les données GitHub du projet (dernière synchronisation le 15 septembre 2026) et sur notre analyse. Elles ne constituent pas un avis juridique.
ANALYSE OPEN SOURCE APPROFONDIE
Le problème visé : la discipline d'engagement, pas la charge utile
La plupart des projets qui accrochent un LLM à des outils offensifs produisent ce que le README résume d'une phrase : un nmap suivi d'un rapport. Decepticon prend le problème par l'autre bout. Le README annonce qu'avant qu'un paquet ne quitte l'interface réseau, l'agent génère un ensemble d'engagement complet : RoE (rules of engagement), ConOps, plan de déconfliction et OPPLAN avec correspondance MITRE ATT&CK. Chaque action s'exécute ensuite à l'intérieur de ces règles.
Le public visé est donc une équipe rouge qui a déjà un cadre contractuel et qui veut automatiser l'exécution, pas une équipe qui cherche un outil pour découvrir ce qu'elle a le droit de tester. C'est une distinction importante : Decepticon ne remplace pas la phase de cadrage, il la formalise en artefacts que l'agent peut relire. Le README renvoie à docs/engagement-workflow.md pour le détail de ce flux, ce qui suggère que la logique de génération de ces documents est décrite là et non dans la page d'accueil.
Ce que la pile Docker démarre réellement
L'installation par défaut ne lance pas tout. Le README précise que la commande de démarrage amène le plan de gestion central : LiteLLM, PostgreSQL, Neo4j, Skillogy, LangGraph et un sandbox, puis ouvre le CLI terminal. Les charges spécialisées (BloodHound CE, Sliver C2, Ghidra MCP) et le tableau de bord web montent à la demande. L'orchestrateur convoque un spécialiste via un appel du type ops_start("ad"), et le tableau de bord s'ouvre depuis le CLI avec la commande /web.
Ce découpage a une conséquence pratique : la surface de ressources au repos est plus petite que ce que la liste des intégrations laisse imaginer. Le corollaire est moins agréable. Si un spécialiste ne démarre pas, la cause se trouve probablement dans la couche d'orchestration ou dans l'image du service concerné, pas dans l'agent lui-même. Le README ne documente pas de commande de diagnostic pour ce cas, seulement le point d'entrée /web pour le tableau de bord. C'est un manque réel quand on opère la pile en continu.
Les commandes d'installation, telles que documentées
Sur macOS, Linux et WSL2, le README donne trois étapes : le script d'installation récupéré par curl, puis decepticon onboard, puis decepticon. La deuxième commande est un assistant interactif qui demande le fournisseur, la clé d'API et le profil de modèle. La troisième démarre la pile et ouvre le CLI.
Sous Windows natif, la même séquence passe par PowerShell avec irm https://decepticon.red/install.ps1 | iex, suivie de decepticon onboard et decepticon. Les prérequis annoncés sont Docker et Docker Compose v2, sur macOS Apple Silicon et Intel, Linux amd64 et arm64, Windows amd64 et arm64 via PowerShell ou WSL2 (Ubuntu ou Kali).
Pour un usage en bibliothèque, le paquet s'installe depuis PyPI : pip install decepticon pour le SDK de base, ou pip install "decepticon[neo4j]" pour ajouter les outils de chaîne d'attaque liés au graphe de connaissances. Le README est explicite sur un point qui surprend souvent : il s'agit d'un SDK client. Il embarque les fabriques d'agents, les middlewares, les outils et les compétences, mais il route les appels LLM et l'exécution en sandbox vers des services distants via HTTP. Les variables citées sont DECEPTICON_LLM__PROXY_URL et SANDBOX_URL. Faire tourner un agent avec le seul paquet pip ne suffit donc pas : il faut soit la pile Docker, soit des services équivalents aux mêmes URL.
Le graphe de connaissances comme mémoire d'attaque
Parmi les services du plan de gestion, Neo4j occupe une place à part. L'extra [neo4j] du SDK est présenté comme l'ajout des outils de chaîne d'attaque liés au graphe de connaissances. Autrement dit, les chemins d'exploitation ne vivent pas seulement dans la fenêtre de contexte du modèle : ils sont modélisés comme des relations entre hôtes, services et techniques, interrogeables.
C'est une architecture défendable pour un agent offensif, parce que la fenêtre de contexte est le principal facteur de dérive sur un engagement long. Elle a un coût : Neo4j devient une dépendance d'exécution, pas un simple journal. Le README ne décrit pas de mode dégradé si la base est indisponible, ni de schéma de migration entre versions du graphe. Sur un engagement qui s'étale sur plusieurs jours, cette omission mérite d'être vérifiée avant de s'engager, en particulier lors d'une mise à jour de v1.1.39 vers v1.1.40.
Les benchmarks XBOW : ce qu'ils mesurent et ce qu'ils ne mesurent pas
Le README affiche une table de résultats sur les XBOW validation-benchmarks : 45 sur 45 en difficulté facile (niveau 1), 50 sur 51 en moyen (niveau 2), 7 sur 8 en difficile (niveau 3), soit 102 sur 104 toutes catégories confondues, 98,08 %. Les liens pointent vers un index par challenge, une matrice par classe d'attaque et des traces LangSmith, ainsi que vers docs/benchmark-comparison.md qui compare Decepticon à Strix, PentestGPT, MAPTA, Cyber-AutoAgent et XBOW commercial.
Ces chiffres sont ceux annoncés par le projet et je ne les ai pas reproduits. Le point méthodologique à retenir est ailleurs : le dépôt des benchmarks est hébergé sous PurpleAILAB, la même organisation que Decepticon. Un jeu de validation maintenu par l'éditeur de l'agent mesure la capacité de l'agent à passer ce jeu, pas sa performance sur un périmètre inconnu. La matrice par classe d'attaque et les traces LangSmith sont plus informatives que le taux global, parce qu'elles montrent où l'agent échoue. Le challenge difficile manquant sur huit est le seul écart visible dans la table, et le README n'explique pas lequel c'est.
Shells interactifs : le détail qui casse les agents naïfs
Le README insiste sur un point technique précis : les vrais outils offensifs sont interactifs, et il cite msfconsole, sliver-client et evil-winrm. Un agent qui exécute une commande et lit sa sortie en une passe ne pilote pas ces programmes. Le README indique que Decepticon exécute chaque commande dans un environnement adapté à ce mode, mais le texte fourni s'interrompt au milieu de cette phrase.
Je ne peux donc pas décrire le mécanisme exact de gestion des sessions interactives : ni la manière dont les invites sont détectées, ni comment l'agent décide que la sortie est complète. C'est la zone la plus intéressante du projet et la moins documentée dans le matériel dont je dispose. Si votre cas d'usage repose sur Sliver ou Metasploit, c'est le premier point à valider dans docs/setup-guide.md avant d'investir du temps sur la pile.
Alternatives et rythme de publication
La comparaison la plus utile n'est pas entre agents mais entre philosophies. Un scanner avec assistance LLM produit un inventaire de vulnérabilités classées, reproductible, et l'opérateur décide quoi en faire. Decepticon produit une chaîne d'attaque exécutée et un OPPLAN qui la justifie. Le premier est auditable ligne par ligne, le second raconte une intrusion. Le choix dépend de ce que vous devez livrer : une liste de correctifs ou une démonstration d'impact. Le README renvoie à docs/benchmark-comparison.md pour les écarts chiffrés face à Strix, PentestGPT, MAPTA, Cyber-AutoAgent et XBOW commercial.
Sur la maintenance, les données disponibles montrent une cadence serrée : v1.1.38 le 12 juillet 2026, puis v1.1.39 et v1.1.40 le 27 juillet 2026, à cinq heures d'intervalle. Deux versions le même jour signalent soit des correctifs rapides, soit une publication automatique. Dans les deux cas, prévoyez de figer une version plutôt que de suivre le dernier tag. La licence est Apache-2.0, ce qui autorise l'usage commercial et la modification, avec les obligations habituelles de conservation des mentions et d'état des modifications ; je ne donne pas d'avis juridique et un déploiement en produit mérite une relecture du fichier LICENSE et du NOTICE. Le README mentionne aussi une application hébergée sur app.decepticon.red, sans préciser les conditions contractuelles ni la localisation des données d'engagement.
Conclusion éditoriale
Adoptez Decepticon si vous avez déjà un périmètre d'engagement écrit et que vous voulez déléguer l'exécution de chaînes kill chain à un agent qui trace ses actions dans LangSmith, en acceptant de faire tourner LiteLLM, PostgreSQL, Neo4j et un sandbox sur vos machines. Ne l'adoptez pas si vous cherchez un scanner de surface ou si votre cible sort du cadre d'un test d'intrusion autorisé. Avant toute installation, lisez docs/engagement-workflow.md et docs/library-usage.md, puis vérifiez dans le dépôt la version du fichier de composition et les valeurs attendues de DECEPTICON_LLM__PROXY_URL et SANDBOX_URL pour votre déploiement.
Notes de la communauté