HexStrike AI MCP Agents v6.0: 150超の攻撃ツールをMCP経由でLLMに渡す構成を読む

MCPサーバーという立ち位置、攻撃ツールそのものではない

HexStrike AI は攻撃ツールを自作しているわけではない。README のアーキテクチャ図では、AI エージェントが MCP Protocol 経由で HexStrike MCP Server v6.0 に接続し、そのサーバーが 150+ Security Tools を呼び出す構造になっている。つまり本体はオーケストレーション層であり、nmap、sqlmap、hydra、gobuster といった実体は別途インストールする外部コマンドだ。README のインストール節にはこれらが apt などで入れる前提のコマンド一覧として並んでいる。

この分担は重要で、HexStrike AI を入れただけでは何もスキャンできない。サーバーは「どのツールをどの引数で起動するか」を決めて実行し、出力をエージェントに返す役割を担う。対象はペネトレーションテスト、脆弱性探索、バグバウンティ、CTF、セキュリティ研究と README に列挙されている。利用者として想定されているのは、これらの作業を日常的に行い、LLM に調査の段取りを任せたい実務者だ。

12体のエージェントと Decision Engine の分業

README の図では、サーバー内部が Intelligent Decision Engine、12+ Autonomous AI Agents、Modern Visual Engine の3つに分かれている。Decision Engine は Tool Selection AI、Parameter Optimization、Attack Chain Discovery を担当し、エージェント側には BugBounty Agent、CTF Solver Agent、CVE Intelligence Agent、Exploit Generator Agent などが並ぶ。Visual Engine はリアルタイムダッシュボードや脆弱性カードの表示を担う。

ここで注意したいのは、図に名前はあっても各エージェントの判断ロジックやプロンプト構成は README からは読み取れない点だ。「自律的に動く」と書かれているが、何をもって次のツールへ進むのか、失敗時にどう再試行するのかは本文では説明されていない。提供された資料の範囲では、これらは実装を読むまで評価できない部分になる。

起動までの手順と、サーバーが応答しているかの確認

導入手順は README に具体的に書かれている。リポジトリを clone し、python3 -m venv hexstrike-env で仮想環境を作り、source hexstrike-env/bin/activate で有効化したうえで pip3 install -r requirements.txt を実行する。サーバーは python3 hexstrike_server.py で起動し、--debug と --port 8888 のオプションが用意されている。

起動確認は curl http://localhost:8888/health で行う。エージェント側の機能を試すなら、/api/intelligence/analyze-target に対して target と analysis_type を JSON で POST する例が README に載っている。クライアント側は Claude Desktop、Cursor、VS Code Copilot、Roo Code、5ire などが挙げられているが、5ire については v0.14.0 が現時点で未対応と明記されている。バージョンを固定して使う場合はこの注記に従う必要がある。

依存の重さはこのプロジェクト最大の制約

README のツール一覧は、ネットワーク系だけで nmap、masscan、rustscan、amass、subfinder、nuclei、fierce、dnsenum、autorecon、theharvester、responder、netexec、enum4linux-ng と続く。Web 系では gobuster、feroxbuster、dirsearch、ffuf、dirb、httpx、katana、nikto、sqlmap、wpscan、arjun、paramspider、dalfox、wafw00f。パスワード系に hydra、john、hashcat、medusa、patator、crackmapexec、evil-winrm、hash-identifier、ophcrack。バイナリ解析系に gdb、radare2、binwalk、ghidra、checksec、strings、objdump、volatility3、foremost、steghide、exiftool。クラウド系に prowler、scout-suite、trivy、kube-hunter、kube-bench、docker-bench-security。

これらはすべて外部依存であり、欠けているツールを呼べば当然失敗する。README は「150+ tools」と繰り返すが、その数字は同梱物ではなくインストール前提の集合だ。Browser Agent を使う場合は chromium-browser と chromium-chromedriver、あるいは Google Chrome の導入まで求められる。コンテナで完結させたい場合、この依存群を自分で詰める作業が導入コストの大半を占める。

攻撃ツールをLLMに渡すという設計上のリスク

この構成の性質上、LLM の出力がそのまま実際のコマンド実行につながる。README には実行前の承認ステップやサンドボックスに関する記述が見当たらない。つまり「AI が選んだツールとパラメータを、そのまま実行する」経路が既定であると読める。対象範囲の制限や許可リストの仕組みが本文で説明されていない以上、本番ネットワークや顧客環境に接続した状態で走らせるのは避けるべきだ。

もう一点、判断の根拠が LLM 側に寄っている。Decision Engine が最適なツールを選ぶと書かれているが、選定理由の検証手段は README には示されていない。結果の再現性や監査ログの扱いを重視する組織では、この不透明さが導入の障壁になる。逆に、CTF や自分が管理するラボのように影響範囲が閉じている環境では、この割り切りは許容できる。

Metasploit や手書きスクリプトとの違い

比較対象として分かりやすいのは Metasploit だ。Metasploit はエクスプロイトとペイロードをモジュールとして内包し、exploit からセッション取得までを一つの枠組みで扱う。HexStrike AI はその逆で、既存の外部コマンドを MCP のツールとして見せることに徹している。新しい攻撃コードを提供するのではなく、すでに手元にあるツール群への呼び出し口を LLM に与える。

もう一つの比較軸は、シェルスクリプトや Makefile で同じコマンド列を組む場合との差だ。静的なスクリプトは決まった順序を再現するが、HexStrike AI は Decision Engine が対象ごとにツール選択とパラメータを変える。この可変性が利点になるのは、対象の構成が事前に分からない探索的な作業だ。逆に、毎回同じ手順を同じ順序で回したい定型業務では、LLM を挟む分だけ不確実性が増える。

MITライセンスと保守コストの読み方

ライセンスは MIT で、README には OTT Cybersecurity LLC が所有・開発していると記載されている。MIT であれば改変や再配布、商用利用の制約は比較的小さい。ただし、同梱していない外部ツール群にはそれぞれ別のライセンスが適用される。nmap や sqlmap、hashcat などをまとめて配布物に含める場合、それらの条件を個別に確認する必要がある。ここは法的判断ではなく、確認事項として挙げておく。

保守の観点では、依存する外部ツールの更新に追随できるかが焦点になる。HexStrike AI 側が変わらなくても、nmap や nuclei の引数が変われば呼び出しが壊れうる。リリースは取得できておらず、バージョン表記は v6.0.0 だが、実際の更新頻度や互換性の保証範囲は提供資料からは判断できない。導入前に自分でタグとコミット履歴を確認することを勧める。

編集部の結論

採用を検討すべきなのは、Kali 系のツール群がすでに手元にあり、MCP 対応クライアントからそれらを呼び出す導線だけを欲している人だ。逆に、ツールを同梱した単体アプリを期待する場合や、実行環境を分離したい本番運用には向かない。導入前に確認するのは、requirements.txt の中身、hexstrike_server.py --port で指定したポートに /health が応答するか、そして呼び出したいツールが実際に PATH 上に存在するかの3点である。

公式情報源

1. 0x4m4/hexstrike-ai on GitHub
2. Issues
3. License: MIT
4. Project website
5. README