Decepticon: OPPLAN と RoE を先に作る自律レッドチームエージェント
Autonomous Hacking Agent for Red Team
ひと目でわかる
- これは何？
- Decepticon は LangGraph ベースの自律ペネトレーションテストエージェントで、攻撃前に engagement package を生成し、Docker スタック上で専門ワークロードを必要時に起動する。XBOW ベンチマークの数値と、SDK としての利用条件、そして向かないケースを整理する。
- 誰に向いている？
- 既に RoE や ConOps を運用プロセスとして持つレッドチーム、または検証用ラボで攻撃チェーンの自動化を試したいチームに向く。逆に、スキャナ代わりのワンショット診断を期待する場合や、LiteLLM・PostgreSQL・Neo4j・sandbox を常時運用できない環境では過剰装備になる。
- 商用利用できる？
- できます。Apache-2.0 は寛容なライセンスで、著作権表示とライセンス表示を残せば、使用・改変・販売が可能です。
- 今もメンテナンスされている？
- されています。最後のコミットは 17 日前です。
- 何の言語で書かれている？
- 主に Python です（GitHub の言語統計による）。
回答はプロジェクトの GitHub データ（最終同期：2026年9月15日）と当サイトの分析に基づくもので、法的助言ではありません。
オープンソース詳細解説
スキャナの出力ではなく kill chain を狙う設計
ペネトレーションテストの自動化ツールは、nmap を回して結果を整形するだけのものが少なくない。Decepticon の README はこの種のツールを念頭に置いた一文から始まり、自らを「professional autonomous Red Team agent」と位置づけている。対象読者は、脆弱性診断の反復作業を自動化したい開発者ではなく、レッドチーム演習を回す側の実務者だ。README が挙げる攻撃段階は reconnaissance、exploitation、privilege escalation、lateral movement、C2 で、スキャン結果の一覧ではなく、開いた経路に応じてピボットし技術を連鎖させる挙動を想定している。ここで効くのは攻撃能力そのものより前段の統制で、パケットを送出する前に RoE、ConOps、Deconfliction Plan、MITRE ATT&CK マッピング付きの OPPLAN を含む engagement package を生成し、以降の行動をその範囲内で実行するという建て付けになっている。攻撃の自動化と統制の自動化を同じパイプラインに載せている点が、単機能のエクスプロイトツールとの分かれ目になる。
LangGraph オーケストレータと必要時起動の specialist コンテナ
`decepticon` を実行すると、コアの management plane が立ち上がる。README が列挙する構成要素は LiteLLM、PostgreSQL、Neo4j、Skillogy、LangGraph、sandbox で、ここにターミナル CLI が接続する。LLM 呼び出しは LiteLLM を経由し、コマンド実行は sandbox に隔離される。攻撃対象ごとの専門ツールは常時起動ではなく、オーケストレータが必要に応じて呼び出す。README の例では `ops_start("ad")` が Active Directory 系のワークロードを起動し、BloodHound CE、Sliver C2、Ghidra MCP などが同様に扱われる。Web ダッシュボードも常駐せず、CLI 内から `/web` を叩いて起動する。つまりプロセスのライフサイクルは「コアは常時、専門は都度」という二層構造で、攻撃フェーズの進行に合わせてコンテナが増減する。Neo4j が Knowledge Graph として攻撃チェーンの状態を保持する役割を担い、pip の `decepticon[neo4j]` extra がこのツール群を含むことからも、グラフがチェーン追跡の基盤であることが読み取れる。状態をどこに置くかを最初に決めておかないと、後からチェーンを再現しにくくなる構成だ。
導入は install スクリプトと onboard ウィザードの 2 ステップ
前提は Docker と Docker Compose v2。macOS の Apple Silicon と Intel、Linux の amd64 と arm64、Windows の amd64 と arm64 がサポート対象で、Windows は PowerShell ネイティブか WSL2 上の Ubuntu / Kali のどちらでも動くと README は説明している。macOS、Linux、WSL2 では `curl -fsSL https://decepticon.red/install | bash` を実行し、続けて `decepticon onboard` でプロバイダ、API キー、モデルプロファイルを対話的に設定する。最後に `decepticon` を実行するとコアスタックが起動し、そのままターミナル CLI に入る。Windows ネイティブの場合は `irm https://decepticon.red/install.ps1 | iex` に置き換わるだけで、以降の 2 コマンドは同じだ。ライブラリとして組み込む場合は `pip install decepticon` または `pip install "decepticon[neo4j]"` を使うが、これはクライアント SDK であってランタイムではない。README はエージェントのファクトリ、ミドルウェア、ツール、スキルを同梱しつつ、LLM 呼び出しと sandbox 実行は HTTP 経由で外部サービスに投げると明記しており、参照先は `DECEPTICON_LLM__PROXY_URL` と `SANDBOX_URL` の 2 つの環境変数だ。この 2 つを自前の同等サービスに向けない限り、pip だけでエージェントは動かない。
XBOW ベンチマーク 102/104 が示すものと示さないもの
README は XBOW validation-benchmarks の結果を難易度別に掲載している。Easy（Level 1）が 45/45 で 100%、Medium（Level 2）が 50/51 で 98.0%、Hard（Level 3）が 7/8 で 87.5%、全レベル合計で 102/104、98.08% という数値だ。per-challenge の索引、attack-class マトリクス、LangSmith トレースへのリンクが `benchmark/results/README.md` に用意されており、単に合計値だけを出していない点は評価できる。ただし注意すべきは、これが XBOW の validation-benchmarks という特定の課題セットでの結果だという点で、実環境の Active Directory やクラウド環境での成功率を保証するものではない。README 自身も別ページ `docs/benchmark-comparison.md` で Strix、PentestGPT、MAPTA、Cyber-AutoAgent、XBOW 商用版などとの比較を掲載しており、比較の前提条件はそちらを読む必要がある。ベンチマークの数値は導入判断の材料にはなるが、自組織のネットワーク構成や検知体制の下で同じ挙動が再現するかは別問題として扱うべきだ。
対話型シェルを扱えることと、その代償
README は差別化点として、msfconsole、sliver-client、evil-winrm のような対話型ツールをエージェントが実際に操作できると述べている。コマンドを 1 回投げて出力を読むだけのエージェントでは、プロンプト待ちで止まるツールが多い。Decepticon はコマンドを疑似端末内で実行する前提を取っており、これが kill chain の途中でツールを乗り換える挙動を可能にしている。代償は sandbox の複雑さだ。対話型セッションを維持するには、sandbox 側で状態を持つプロセスを管理する必要があり、単発のコマンド実行を隔離するより遥かに考慮点が多い。README はこの内部実装の詳細までは踏み込んでおらず、sandbox がどうセッションを保持するかは記載からは確認できない。セキュリティ製品として見たとき、攻撃ツールを対話状態付きで動かすコンテナは、それ自体が侵害時の踏み台になり得る。運用側でネットワーク分離とコンテナのライフサイクル管理を設計に入れておかないと、自動化の便益よりリスクが上回る。
クラウド版 app.decepticon.red という選択肢
セルフホストを避けたい場合、README は app.decepticon.red でホスト型のアプリが利用できると案内している。Docker のセットアップを省略し、ブラウザから自律レッドチーム演習を実行する形だ。ここで読者が判断すべきは、攻撃対象の情報とスキャン結果を外部サービスに預けてよいかという点である。レッドチーム演習では、対象ネットワークの構成、認証情報、発見した脆弱性がそのまま機微情報になる。社内規程や契約で外部送信が制限されている組織では、クラウド版は選択肢から外れる。逆に、検証用の使い捨てラボや、そもそも外部に置いても問題ない演習環境であれば、Docker スタックを組む手間を省ける。セルフホストとクラウド版は機能差ではなくデータの所在の違いであり、そこが唯一の判断軸になる。README はこの点についてのデータ取り扱いの説明を本稿の範囲では提示していない。
代替としての PentestGPT と、設計思想の違い
比較対象として README 自身が名前を挙げている PentestGPT を取ると、両者の違いは統制の置き場所にある。PentestGPT は対話的なペネトレーションテスト支援を主目的としたツールで、人間が判断のループに入ることを前提にしている。Decepticon は逆に、OPPLAN と RoE を事前に生成してからエージェントに実行を委ねる。人間の関与は攻撃前の計画策定と、CLI 上での監視に寄る。どちらが優れているかではなく、演習の進め方が違う。人間が逐次判断を下す形式の演習では PentestGPT のほうが自然に収まり、決められた範囲をエージェントに走らせて結果を検証する形式なら Decepticon の建て付けが噛み合う。もう一つの現実的な差は実行基盤で、Decepticon は LiteLLM、PostgreSQL、Neo4j、sandbox を含むスタックの運用を前提とする。軽量に試したい段階では、この構成自体が導入の障壁になる。
ライセンスとメンテナンスの見積もり
ライセンスは Apache-2.0。特許条項を含み、改変物の配布時に変更点を示す必要があり、著作権表示とライセンス全文の同梱が求められる。商用利用を妨げる条項は含まれないが、これは法的助言ではないので、自組織の法務確認は別途必要になる。メンテナンスの面では、リリースが v1.1.38、v1.1.39、v1.1.40 と短期間に連続しており、v1.1.39 と v1.1.40 は同じ日に切られている。更新頻度が高いということは、逆に言えば API や設定キーの変更が比較的短い間隔で入り得るということでもある。`DECEPTICON_LLM__PROXY_URL` や `SANDBOX_URL` のような環境変数を自前のサービスに向けて SDK として組み込む使い方は、こうした変更の影響を直接受けやすい。バージョンを固定して追従するか、Docker スタックごと更新するかを先に決めておきたい。リポジトリはアーカイブされておらず、最終 push は 2026-08-30 時点で記録されている。
編集部の結論
既に RoE や ConOps を運用プロセスとして持つレッドチーム、または検証用ラボで攻撃チェーンの自動化を試したいチームに向く。逆に、スキャナ代わりのワンショット診断を期待する場合や、LiteLLM・PostgreSQL・Neo4j・sandbox を常時運用できない環境では過剰装備になる。導入前に確認すべきは 3 点で、第一に `decepticon onboard` で設定される LLM プロバイダとモデルプロファイルが自組織のポリシーに適合するか、第二に XBOW ベンチマークの再現手順が `benchmark/results/README.md` に記載された LangSmith トレースと一致するか、第三に `ops_start("ad")` などで起動される専門コンテナが社内ネットワーク分離の範囲に収まるかである。`decepticon` パッケージはクライアント SDK であり、`DECEPTICON_LLM__PROXY_URL` と `SANDBOX_URL` の 2 つのエンドポイントを自前で用意しない限り単体では動かない。
コミュニティノート