Decepticon: An Autonomous Red Team Agent That Plans Before It Attacks
Autonomous Hacking Agent for Red Team
At a glance
- What is it?
- Decepticon is an open-source, Python-based autonomous hacking agent for red teams. It builds an engagement package with rules of engagement and attack plans before running any tool, then executes kill chains through interactive shells.
- Who is it for?
- Adopt Decepticon if you run authorized red team engagements and need an agent that can chain real attack techniques within a defined rule set, not just scan ports. Skip it if you lack Docker or a dedicated LLM proxy, or if your work requires a purely manual, non-autonomous process.
- Can I use it commercially?
- Yes. Apache-2.0 is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 17 days ago.
- What is it written in?
- Mainly Python, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
What Decepticon Actually Solves
Most AI pentest tools run nmap, print a report, and stop. Decepticon aims at a different problem: executing realistic attack chains that include reconnaissance, exploitation, privilege escalation, lateral movement, and command and control. The README is blunt about this distinction. It targets professional red teams who need an agent that behaves like an adversary, not a scanner. The core value is not automation of a single scan but orchestration of a full engagement where the agent adapts to whatever path opens up. That is a meaningful gap in the current tooling space, and Decepticon positions itself squarely there.
The Engagement Package Mechanism
The distinguishing mechanism is that Decepticon generates a complete engagement package before any packet leaves the wire. This package includes Rules of Engagement (RoE), a Concept of Operations (ConOps), a Deconfliction Plan, and an Operational Plan (OPPLAN) with MITRE ATT&CK mapping. Every action the agent takes runs inside those defined rules. This is not a post-hoc report; it is a pre-execution constraint. The README claims this discipline separates red teamers from script kiddies. Architecturally, this means the agent first reads the OPPLAN and then pursues objectives through whatever path opens up, pivoting and chaining techniques as it goes. The design forces planning before action, which is a deliberate contrast to tools that simply react to scan results.
How It Runs: Docker Stack and On-Demand Specialists
Installation is Docker-centric. The documented path on macOS, Linux, or WSL2 is a curl pipe to bash, followed by two commands: decepticon onboard for an interactive setup wizard that asks for provider, API key, and model profile, and then decepticon to start the core stack and drop into a terminal CLI. The default start brings up a management plane that includes LiteLLM, PostgreSQL, Neo4j, Skillogy, LangGraph, and a sandbox. Specialist workloads such as BloodHound CE, Sliver C2, and Ghidra MCP do not start by default. The orchestrator spawns them on demand via commands like ops_start("ad"). The web dashboard is also on demand, launched from inside the CLI with /web. This modular approach keeps the base footprint smaller and lets the agent pull in heavy tools only when a specific phase of the attack chain requires them.
Using Decepticon as a Python Library
Beyond the Docker stack, Decepticon ships as a client SDK on PyPI. Installing decepticon gives you agent factories, middleware, tools, and skills. The optional extra decepticon[neo4j] adds knowledge-graph attack-chain tools. The SDK routes LLM calls and sandbox execution to runtime services over HTTP, using environment variables like DECEPTICON_LLM__PROXY_URL and SANDBOX_URL. This means the SDK alone is not sufficient to run agents; you still need the runtime services, either from the Docker stack or from your own equivalents. The README points to a library usage doc that covers factory overrides, declarative PluginBundle plugins, and a safety gate. For engineers who want to build a custom orchestrator or integrate agents into a product, this client design is useful, but it also means the SDK is not a standalone package.
Benchmark Results and Their Limits
The README reports benchmark results against the XBOW validation-benchmarks. The claimed pass rates are 45 out of 45 on easy tasks, 50 out of 51 on medium, 7 out of 8 on hard, and 102 out of 104 overall, which is 98.08 percent. These numbers are presented as a single donut chart and a table. There is a link to per-challenge indexes, attack-class matrices, and LangSmith traces, plus a comparison against other agents like Strix, PentestGPT, MAPTA, Cyber-AutoAgent, and XBOW commercial. I cannot verify these numbers independently, and the README does not describe the test environment, target setup, or whether the benchmarks ran in the same Docker configuration that a user would deploy. Treat the 98 percent figure as a vendor claim. The hard-level sample size of eight challenges is small, so the 87.5 percent pass rate carries wide uncertainty.
Genuine Limitations and Wrong Use Cases
The most obvious limitation is that Decepticon is not a tool for casual or unauthorized use. Autonomous execution of attack chains, even within defined RoE, requires a legal authorization boundary. The README emphasizes that every action runs inside the engagement rules, but that assumes the user configures those rules correctly. A second limitation is the operational overhead. The full stack requires Docker, Docker Compose v2, and a model provider with an API key. The default stack includes Neo4j, PostgreSQL, LiteLLM, and a sandbox, which is a heavy footprint for a simple pentest. If you only need to run a few scans against a small target, a traditional tool like nmap or a scripted Metasploit resource file is faster and cheaper. Decepticon is the wrong choice when you lack the infrastructure to run the stack or when your engagement is too small to justify the orchestration overhead.
A Real Alternative: XBOW and Manual Orchestration
The README itself names XBOW as a commercial alternative, along with research agents like PentestGPT and MAPTA. The key difference in approach is that XBOW is a closed commercial product, while Decepticon is Apache-2.0 and self-hostable. XBOW likely provides a managed service with its own infrastructure, so you do not handle Docker or model proxies. Decepticon gives you control over the entire stack, including the LLM proxy via LiteLLM, which means you can swap in different models or point to an internal gateway. That flexibility is valuable for organizations that cannot send engagement data to a third-party cloud. But it also means you bear the maintenance cost of the stack. If you prefer a fully manual red team process, no agent is a direct substitute, but Decepticon's OPPLAN-driven approach is closer to how a human team operates than a simple scanner.
Maintenance, Licensing, and Upgrade Cost
The repository is licensed under Apache-2.0, which permits commercial use, modification, and distribution with attribution. The project is not archived, and the last push was August 2026, with releases v1.1.38 through v1.1.40 in July 2026. That indicates active maintenance. The upgrade cost is tied to the Docker stack: pulling new images and restarting the core stack is likely straightforward, but any changes to the Neo4j schema or the LangGraph state machine could require migration. The README does not document an upgrade path or migration notes, so you should check the release notes before updating. The SDK route means you must keep the client library in sync with the runtime services, since they communicate over HTTP and version mismatches could break tool calls. This is a real operational cost that the README does not fully address.
Who Should Adopt It and What to Verify
Decepticon is for professional red teams that have a legal mandate to simulate adversaries and that can run a Docker-based stack with a configured LLM backend. It is not for hobbyists or for unauthorized security testing. Before adopting it, verify that your target environment matches the benchmark conditions, if you care about the pass rate. Confirm that your chosen model provider works with LiteLLM and that you can set the DECEPTICON_LLM__PROXY_URL and SANDBOX_URL correctly. Test the engagement package generation on a non-production range to see if the RoE and deconfliction plan match your operational constraints. The project is young but actively developed, and the architecture is serious about planning. The final judgement is this: Decepticon is a credible attempt to move AI pentesting from scanning to autonomous operations, but its success depends on your willingness to run a heavy stack and to trust an agent with real attack tools.
Editorial conclusion
Adopt Decepticon if you run authorized red team engagements and need an agent that can chain real attack techniques within a defined rule set, not just scan ports. Skip it if you lack Docker or a dedicated LLM proxy, or if your work requires a purely manual, non-autonomous process. Before use, verify the benchmark environment matches your targets, confirm your API provider and model profile during onboarding, and review the safety gate and engagement package generation to ensure they align with your legal authorization scope. The project is actively maintained with frequent releases, but its value depends on your ability to run the full Docker stack and accept that autonomous actions carry inherent risk.
Community notes