Skip to main content

​
Agent Architecture

Decepticon operates through sixteen specialist agents, each with its own tools, skills, and clean context window. Agents are spawned fresh per objective — no accumulated noise, no degraded reasoning across long engagements. The agents are not a flat list. They are organized by the engagement phase they serve, and routed by the Decepticon orchestrator through the OPPLAN.

​
Orchestration Layer

Decepticon (Orchestrator)

The central red-team coordinator. Owns the OPPLAN, sequences objectives, resolves dependencies, and dispatches specialists (recon, exploit, postexploit, analyst, reverser, contract_auditor, cloud_hunter, ad_operator) via SubAgent middleware. Runs on the most capable model tier.

Vulnresearch (Orchestrator)

Vulnerability research orchestrator — runs the five-stage pipeline (scanner → detector → verifier → patcher → exploiter) with state passed between stages exclusively through the knowledge graph.

Soundwave (Planner)

Engagement planner. Standalone graph (not a sub-agent of Decepticon). Interviews the operator and generates the complete engagement package — RoE, ConOps, Deconfliction Plan, OPPLAN, and threat profile. No bash access; produces documents only.

​
Reconnaissance Phase

Recon

Active and passive recon — port scanning, service enumeration, OSINT, subdomain discovery, certificate-transparency mining. Operates inside the Kali sandbox.

​
Vulnerability Research Pipeline

Sub-agents of the Vulnresearch orchestrator. State flows between stages via the knowledge graph; each stage runs with fresh context.

Scanner

Stage 1 — broad-spectrum scanner. Walks large codebases in parallel and emits CANDIDATE nodes with heuristic suspicion scores. Cheap, fast, no vulnerability reasoning.

Detector

Stage 2 — vulnerability detector. Reads source around each CANDIDATE and promotes real bugs to VULNERABILITY + HYPOTHESIS nodes, or rejects them as false positives. Read-only (no bash).

Verifier

Stage 3 — two-method verification gate. Confirms candidate findings through at least two independent evidence channels before downstream work begins.

Exploiter

Stage 4 — reproducible PoC author. Produces working proof-of-concept exploits for verified vulnerabilities, with reliability notes.

Patcher

Stage 5 — patch generator. Produces a code or configuration change that closes the vulnerability without breaking the application, plus a regression test.

​
Exploitation & Post-Exploitation

Exploit

Initial access and exploitation tactics. Web/AD attacks (SQLi, SSTI, Kerberoasting, ADCS abuse, credential attacks).

Post-Exploit

Privilege escalation, lateral movement, credential harvesting, persistence — often via Sliver C2 sessions once initial access is established.

​
Domain Specialists

AD Operator

Active Directory specialist. Kerberoasting, AS-REP roasting, ADCS ESC1–ESC15, DCSync, ticket forging, ACL abuse, GPO manipulation, BloodHound path analysis.

Cloud Hunter

Cloud infrastructure specialist. IAM privilege escalation, S3/Azure storage exposure, Kubernetes RBAC escapes, metadata-service abuse across AWS/Azure/GCP.

Contract Auditor

Solidity / EVM smart-contract auditor. Reentrancy, oracle manipulation, flash-loan abuse, access-control flaws; Slither static analysis + Foundry PoC harness.

Reverser

Binary reverse-engineering specialist. ELF/PE/Mach-O triage, packer detection, string/symbol extraction, ROP gadget inventories, Ghidra/radare2 scripting.

​
Analysis & Reporting

Analyst

Vulnerability research and reporting specialist. Cross-correlates findings, queries the knowledge graph, and drafts the engagement narrative — source code review, static analysis (semgrep/bandit/gitleaks), dependency CVE sweeps, and multi-hop exploit chain construction.

​
Clean Context Per Objective

Every agent spawns with a fresh context window for every objective: 
Objective 1 (Recon)     → New Recon agent instance       → Findings saved to disk + graph
Objective 2 (Exploit)   → New Exploit agent instance     → Reads obj-1 findings explicitly
Objective 3 (Post-Exp)  → New Post-Exploit instance      → Reads obj-1+2 findings explicitly
  • No accumulated noise — Context doesn’t degrade across a 100-objective engagement.
  • Targeted context — Each agent receives only the findings relevant to its objective.
  • Persistent state — Findings live on disk and in Neo4j, not in agent memory.

​
Agent Middleware Stack

Each agent runs with a stack of middleware that provides cross-cutting concerns. The exact stack depends on the agent’s role.
Agent RoleMiddleware Stack
Decepticon (Orchestrator)EngagementContext → Skills → Filesystem → SubAgent → OPPLAN → ModelFallback → Summarization → PromptCaching → PatchToolCalls
Vulnresearch (Orchestrator)Skills → Filesystem → SubAgent → OPPLAN → ModelFallback → Summarization → PromptCaching → PatchToolCalls
Soundwave (Planner)EngagementContext → Skills → Filesystem → ModelFallback → Summarization → PromptCaching → PatchToolCalls
Specialist (Recon, Exploit, …)Skills → Filesystem → ModelFallback → Summarization → PromptCaching → PatchToolCalls

​
What Each Layer Does

  • EngagementContext — Injects engagement metadata (slug, target, RoE summary) into the system prompt so guardrails are evaluated continuously.
  • Skills — Progressive-disclosure skill loading filtered by ATT&CK overlap with the active threat profile. Frontmatter loads at startup (~100 tokens/skill); full body is fetched on-demand via read_file.
  • Filesystem — FilesystemMiddlewareNoExecute — provides read_file, write_file, edit_file, ls, glob, grep against the engagement workspace. Execute is intentionally disabled; specialists use the dedicated bash tool instead.
  • SubAgent — task() tool for orchestrators (Decepticon, Vulnresearch) to dispatch work to specialists.
  • OPPLAN — Five CRUD tools (add_objective, get_objective, list_objectives, update_objective, objective_expand) and dynamic state injection of objectives into every LLM call.
  • OpsControl — Auto-injects workload-lifecycle state transitions (starting → running → exited) into the agent’s next turn, so the orchestrator never polls after calling ops_start(...). See Dynamic Infrastructure.
  • SandboxNotifications — When a bash command launched with run_in_background=true finishes, the captured output is auto-fetched and injected on the next inference turn. The agent doesn’t have to remember to call bash_output().
  • ModelFallback — Provider failover when a model is rate-limited or down. Walks the fallback chain built from the user’s credentials inventory.
  • Summarization — Conversation-window compression for long-running specialists.
  • PromptCaching — AnthropicPromptCachingMiddleware — places prompt-cache boundary markers; silently no-ops on non-Anthropic providers.
  • PatchToolCalls — Sanitizes and normalizes tool-call shapes for cross-provider compatibility (Anthropic, OpenAI, Google, MiniMax, …).

​
Agent–Tool Interaction

Agents interact with offensive tools through persistent tmux sessions inside the Kali sandbox: 
Agent → Docker Socket → Kali Sandbox → tmux session → Tool (sliver-client, msfconsole, evil-winrm, ...)
                                              ↓
                                       Prompt Detection
                                              ↓
                                       Follow-up Commands
When a tool presents an interactive prompt (sliver >, msf6 >, PS C:\>), the agent:
  1. Detects the prompt pattern.
  2. Interprets the tool’s output.
  3. Sends the appropriate follow-up command.
  4. Handles control signals (C-c, C-z) when needed.
Output is tiered:
  • Inline (≤15K) — Returned directly to the agent.
  • Offload (15K–100K) — Written to /workspace/.scratch/ and referenced by path.
  • Watchdog (>5M) — The session is killed and the agent is asked to refine.
This is how real operators work. Decepticon’s specialists do the same.

OPPLAN System

The structured plan that the orchestrator dispatches to these agents.

Infrastructure

The isolated network architecture these agents operate within.