AIペンテストOSSは、スター数で選んでよいか？

AIペンテストのOSSを社内で使ってよいかは、GitHubのスター数では決まりません。見るのは、決めた範囲の外をAIに攻撃させない仕組みがコードにあるか、ライセンスの本文に何が書いてあるか、リポジトリが今も保守されているか、の3点です。どれも、リポジトリの決まった場所を開くか検索すれば確かめられます。

2026-10-10に、AIペンテスト用のOSSから7本（Strix、PentAGI、Decepticon、CAI、PentestAgent、HexStrike AI、ARTEX）のリポジトリを使い捨てのコンテナへ取得し、取れたものはソースとライセンスを開いて、どこに何が書いてあるかを確かめました。

AIペンテストOSSはスター数が多くても、止まるとは限らない

「このツール、使っていいですか」と聞かれたとき、スター数と機能の多さで答えていませんか？ 10-10時点の数字を並べると、スター数とAIを止める仕組みは連動していません。

いちばん多いStrixは67,554ありますが、攻撃先の範囲をコードで絞る処理は、検索した範囲では見つかりませんでした。一方、5,763のDecepticonは、設定を書けばコードで止めます。9,846のCAIは、すでにアーカイブされています。

GitHub - usestrix/strix: Open-source AI penetration testing tool to find and fix your app’s vulnerabilities.

Open-source AI penetration testing tool to find and fix your app’s vulnerabilities. - usestrix/strix

github.com

GitHub - BitterSecurity/Decepticon: Autonomous Hacking Agent for Red Team

Autonomous Hacking Agent for Red Team. Contribute to BitterSecurity/Decepticon development by creating an account on GitHub.

github.com

GitHub - aliasrobotics/cai: Cybersecurity AI (CAI), the framework for AI Security

Cybersecurity AI (CAI), the framework for AI Security - aliasrobotics/cai

github.com

スター数が多いのは、使われているという意味です。止まるという意味ではありません。

AIペンテストのガードレールは、どこで止めるかで4つの型に分かれる

ソースを開くと、AIを止める仕組みは4つの型に分かれました。表の右の2列が、確かめる場所と、そこで見つかったものです。

ツールの外に止め具がある例もあります。ShannonのREADMEには、AnthropicやOpenAIのモデルでは提供元のサイバー検証を済ませないと、スキャン中に拒否・中断されることがあると書かれています。

GitHub - KeygraphHQ/shannon: Shannon is an AI pentester for web applications and APIs. It analyzes your source code, identifies attack vectors, and executes real exploits to prove vulnerabilities before they reach production.

Shannon is an AI pentester for web applications and APIs. It analyzes your source code, identifies attack vectors, and executes real exploits to prove vulnerabilities before they reach production. ...

github.com

設定すれば範囲をコードで止めるもの

Decepticonは、作業範囲のルール（RoE）を3つのモードで扱います。auditは記録だけ、warnは警告して実行、enforceは実行前に [ROE_REFUSED] を返して止めます。本当の境界はサンドボックスの外向き通信だと roe.py の説明にあり、enforceのときは sandbox_kernel/egress.py がnftablesのルールで通信先を絞ります。

ただし roe.json の machine_enforcement は任意の項目で、書かなければauditのまま、記録するだけで通信にも触りません。設定したあとでも、DECEPTICON_EGRESS_DISABLE で外向き通信の制限は外せます。導入しただけでは止まらないので、申請ではこの設定ファイルも一緒に確かめる対象になります。

GitHub - GH05TCREW/pentestagent: PentestAgent is an AI agent framework for black-box security testing, supporting bug bounty, red-team, and penetration testing workflows.

PentestAgent is an AI agent framework for black-box security testing, supporting bug bounty, red-team, and penetration testing workflows. - GH05TCREW/pentestagent

github.com

PentestAgentは、プロンプトの pa_crew.jinja に All targets are in scope. Proceed with testing. とあります。ここだけ読むと止める気のないツールに見えますが、コードは別に範囲を確かめていました。ツールを呼ぶ前に引数から対象を拾い、ワークスペースに登録した対象と照らして、外れていれば実行せずに確認を求めます。

照合が働くのは、有効なワークスペースがあるときだけで、対象は /target で登録する作りです。プロンプトの一文だけで判断すると、逆の結論を出すところでした。

AIの試行回数と費用だけをコードで抑えるもの

GitHub - vxcontrol/pentagi: Fully autonomous AI Agents system capable of performing complex penetration testing tasks

Fully autonomous AI Agents system capable of performing complex penetration testing tasks - vxcontrol/pentagi

github.com

PentAGIは、同じツール呼び出しが3回続くと検知して、別のツールを試すよう返します。コードで歯止めをかけているのは確かですが、抑えているのは堂々巡りです。攻撃先の範囲を絞る処理は、backend を検索した範囲では見つかりませんでした。

Strixのシステムプロンプトには NEVER ask for permission or confirmation - you already have complete testing authorization とあり、すぐ後に REFUSAL AVOIDANCE: という節が続きます。迷ったら断らずに続ける方向の文面です。実行ごとの対象一覧を差し込む scope.jinja には The list below is the starting scope, not a ceiling. とあり、一覧は出発点で上限ではないと書かれています。止める文言があるかだけでなく、断らせない文言、範囲を広げる文言がないかも、審査では読む対象になります。

strix --help に出るコード側の上限は、--max-budget USD と --max-turns N（既定500）です。上限があるのは費用と、エージェントごとの試行回数で、どこを攻撃するかではありません。--scope-mode や scope_rules という名前のものもありますが、前者はコードを対象にしたときにPRの差分だけを見るかの設定、後者はAI自身が呼んでプロキシで見る通信を絞る道具でした。

では「範囲外を叩かない」ことを、あなたの環境では何が保証していますか？ この2本は、検索した範囲では、答えがツールの中に見当たりませんでした。使う人が渡す対象と、外に出られないネットワークの側で決めることになります。

安全装置が既定で切れているもの

CAIはガードレールの実装を持っていますが、環境変数 CAI_GUARDRAILS を明示的に true にしなければ動きません。

リクエストの認証が見当たらないもの

GitHub - 0x4m4/hexstrike-ai: HexStrike AI MCP Agents is an advanced MCP server that lets AI agents (Claude, GPT, Copilot, etc.) autonomously run 150+ cybersecurity tools for automated pentesting, vulnerability discovery, bug bounty automation, and security research. Seamlessly bridge LLMs with real-world offensive security capabilities.

HexStrike AI MCP Agents is an advanced MCP server that lets AI agents (Claude, GPT, Copilot, etc.) autonomously run 150+ cybersecurity tools for automated pentesting, vulnerability discovery, bug b...

github.com

HexStrike AIは、/api/command が受け取ったコマンドをそのまま実行します。before_request やAPIキーの検査を探しましたが、リクエストを認証する処理は見当たりませんでした。127.0.0.1 を既定にした変数を用意しているのに、起動の app.run は host="0.0.0.0" です。ホストの側で閉じない限り、同じネットワークから届く状態で待ち受けると見ています。

AIペンテストのライセンスは、表示でなく本文で確かめる

GitHubのライセンス欄の表示だけでは分からない条件が、今回の中に2本ありました。

CAIの欄は NOASSERTION で、MITとも何とも出ません。LICENSE の冒頭を開くと、MITの部品と proprietary additions licensed for research purposes only、つまり研究目的に限った独自の追加部分の組み合わせだと書かれています。

PentAGIは LICENSE がMITですが、別に EULA.md があります。合法的なペネトレーションテストの目的に限って使用を許諾し、ダウンロードした時点で同意したものとする内容です。ソースコードについてはMITが優先すると書かれている一方、DockerイメージやWeb画面を含む利用全体にはEULAがかかります。

Shannonは LICENSE の冒頭からAGPL-3.0です。社内で使うだけか、改変して外部に提供するかで、法務に確かめる項目が変わります。利用形態を書き添えて聞くところです。

StrixとDecepticonはApache-2.0、PentestAgentとHexStrike AIはMITでした。ライセンスが緩いことと、止める仕組みがあることは別の話です。

自律型ペンテストAIのうち、リポジトリの状況で候補から外れるのは？

古い一覧や紹介に載ったスター数は、リポジトリがアーカイブされても、移転しても、元が開けなくなっても、そのまま残ります。

CAIは2026-08-22を最後に更新がなく、アーカイブ済みです。READMEにも、今後はリリースもバグ修正もセキュリティパッチも出さないと書かれています。

ARTEXは、ペンテスト用途の候補として挙がることがあるのに、元リポジトリの Autumn-27/ARTEX が10-10時点で404でした。取得にも失敗したので、ソースを確かめられたのは7本中6本です。元のソースを示せない以上、申請の段階で何を審査すればよいかが決まりません。

Decepticonは PurpleAILAB/Decepticon から BitterSecurity/Decepticon へ移転していました。古いURLで紹介されていることがあるので、申請書のURLは移転先に直しておくと後で迷いません。

AIペンテストツールを比較すると、候補はどこまで絞れるか？

用途別に分けて紹介されている例では、脆弱性診断ならStrix、ペンテストならPentAGIとARTEX、レッドチーム演習ならDecepticonが挙がります。止める仕組み、ライセンス、状況の3つに通すと、次のように分かれます。

1. Strix: 範囲を決めるのは人と環境の側です。外に出られないテスト用の環境に閉じて使う前提なら候補に残ります
2. PentAGI: EULAの条件に同意できるなら候補です。範囲の制限は別に用意する必要があります
3. ARTEX: 元が開けない今は、申請の段階で保留です
4. Decepticon: machine_enforcement を書く前提なら、ここに挙げたStrix・PentAGIと比べて、いちばん止める側に寄ります

ほかの4本も、同じ3つで見ると扱いが決まります。

1. CAI: アーカイブ済みで、追加部分は研究目的に限られます。業務での申請なら候補から外します
2. HexStrike AI: 認証の処理が見当たらず、受け取ったコマンドをそのまま実行し、0.0.0.0 で待ち受けます。ホストの側で閉じられないなら保留です。閉じられても、攻撃の足場にならない環境に置く前提です
3. PentestAgent: ワークスペースに対象を登録して使う前提なら候補です
4. Shannon: AGPL-3.0なので、利用形態を書き添えて法務に確かめてから決めます

あなたが通したいのは、どの用途ですか？ レッドチーム演習なら roe.json の中身を、脆弱性診断なら閉じた環境の構成を申請書に添えると、審査の話が早いと見ています。

OSSの利用申請や導入判断の前に、自分で開く5か所

申請書を書く前に、候補のリポジトリで次の5か所を順に開きます。

1. LICENSE の本文と、EULA.md のような別の利用条件の有無
2. リポジトリの状況。アーカイブの有無、最終更新の日付、URLの移転
3. 安全装置の設定の既定値。CAI_GUARDRAILS のように、既定で切れていないか
4. システムプロンプト。permission や scope で検索する。止める文言と、断らせない文言の両方を探す。ツールの言語に合わせて、拡張子は *.go なども足す
5. 外向き通信と待ち受けアドレス。0.0.0.0、nftables、egress で検索する

4と5は、手元に取得して検索します。今回の取得は6本で約59秒でした。

git clone --depth 1 <リポジトリのURL> && cd <リポジトリ名>
grep -rn -i -E "permission|scope" --exclude-dir=.git --include=*.jinja --include=*.py --include=*.go --include=*.tmpl .
grep -rn -E "0\.0\.0\.0|nftables|egress" --exclude-dir=.git .

ヒットしたら、プロンプトの文面だけで判断せず、その対象を照合しているコードがないかも続けて開きます。

ここまでの確認は2026-10-10時点のもので、実際のスキャンは試していません。Strixは pip install strix-agent で入り --help までは動きましたが、起動すると docker CLIが見つからないと出て止まりました。その先は、LLMのAPIキーも要ります。

ソースを取得できた6本では、書かれている記述は該当のファイルを開けば見つかりました。範囲を絞る処理が「ない」ことの確認だけは、StrixとPentAGIで検索が必要でした。スター数を見る前にこの5か所を開いておけば、「使っていいか」に根拠を付けて答えられます。まずは候補の1本で、1番の LICENSE から開いてみてください。