ThreatBook RedAgentsのローンチ、複数のAIペンテスターで単一エージェントモデルに挑む

ThreatBookは少なくとも4つのAIペンテストエージェントを備えるRedAgentsをローンチし、1つの自律型テスターだけで完全なセキュリティ評価を提供できるという考えに異を唱えた。ThreatBook RedAgentsのローンチは、競合する攻撃システムを協調的なテストプールへと変える。しかし同社は、統合アプローチがより少ない誤検知で多くの脆弱性を見つけることを示す独立比較を公開していない。

RedAgentsは、XBOWやHorizon3.aiなどの自律型セキュリティプラットフォームによってすでに形成されている市場に参入する。これらの競合企業は主に、1つのプラットフォームとそのテストシステムの性能を売りにしている。ThreatBookは異なる賭けに出ている。セキュリティチームは複数のエージェントを組み合わせ、1つのインターフェースで結果を比較すべきだというものだ。

この違いこそが本質的な論点を生む。エージェントが増えれば異なる攻撃経路を探索できる一方、運用者が統制すべきツール、権限、判断の数も増える。RedAgentsは、運用リスクを増幅させることなく、集約によってカバレッジが向上することを証明しなければならない。

ThreatBook RedAgentsのローンチが競争単位を変える

ThreatBookは、もう1つの自律型スキャナーを提示しているのではない。エージェント群そのものを製品として位置付けている。

ThreatBookは2026年10月16日にRedAgentsを発表した。同社はこれを、同じ認可済みターゲットに対して複数のAIペネトレーションテストエージェントを実行するためのsoftware-as-a-serviceプラットフォームと説明している。

AIペンテストエージェントは、モデル、セキュリティツール、反復的な計画立案を用いて、悪用可能な弱点を特定し、ときには検証する。RedAgentsは、エージェントの選択、ターゲットの設定、出力の確認を行うための統一インターフェースをセキュリティチームに提供する。

初期ラインアップには、Artex Pro、Cyber(YanJi)、Yanxun、CyberStrikeAI Enterprise Editionが含まれる。ThreatBookによれば、評価内容に応じて、これらのシステムを個別または並列で実行できる。

個々のペンテストエージェントが必ずしも同じ方法でターゲットにアプローチするわけではないため、この選択は重要だ。あるエージェントはWebアプリケーションのロジックを優先する一方、別のエージェントは偵察や認証情報の経路により多くの時間を費やす可能性がある。

ThreatBookのCEOであるFeng Xueは、単一プロバイダーモデルを可視性が限定される要因として説明した。彼の主張は、同じターゲットを与えられても、2つのエージェントが異なる脆弱性を発見し得るというものだ。

同社によれば、RedAgentsはテストデータ、ログ、脆弱性の検出結果を1つのビューに統合する。この設計により、別々の製品を運用し、レポートを突き合わせる手作業を減らせるはずだ。

RedAgentsのローンチでは、このオーケストレーション層に関して複数の安全性の主張も示されている。ThreatBookによれば、顧客はホワイトリストを通じてテスト範囲を定義し、エージェントは認可されたパラメーター内にとどまらなければならない。

同社はさらに、テストデータは第三者エージェントへ転送されず、自社環境内に保持されるとしている。また、テストデータの完全削除を顧客が要求できるゼロデータ保持も掲げている。

顧客または独立した評価者が現実的な条件下で検証するまでは、これらはベンダーの主張にとどまる。この発表では、エージェントが予期しないコマンドを生成した場合にRedAgentsがどのように境界を強制するのかは説明されていない。

また、すべてのコマンドが決定論的なポリシーチェックを通過するかどうかも明記されていない。リリースには、緊急停止、レート制限、権限分離、機微な操作に対する人間の承認に関する詳細もない。

それでも、この製品は競争上の問いを変える。購入者はもはや、どの自律型ペンテスターが最も優れているかだけを問われるのではない。

1つのシステムを選ぶこと自体が誤ったアーキテクチャなのかを問われる。ThreatBookは、オーケストレーション層が接続される個々のエージェントよりも価値あるものになることを目指している。

この提案は、複数の検出システムが同じオブジェクトを検査するマルチエンジンのマルウェアスキャンに似ている。ThreatBookは、重複する検出結果と重複しない検出結果の両方がカバレッジを改善し得る理由を説明するため、この考え方を明示的に用いている。

しかし、ペンテストではより難しい協調の問題が生じる。マルウェアエンジンがアーティファクトを評価するのに対し、ペンテストエージェントは稼働中のサービス、アカウント、データベース、ネットワーク制御と相互作用できる。

したがって、エージェントの統合には結果の収集以上のことが求められる。プラットフォームは操作を調整し、干渉を防ぎ、証拠を標準化し、有意な差異を隠さずに重複した検出結果を特定しなければならない。

こうした要件により、RedAgentsは単なる製品バンドルから運用管理プレーンへと変わる。この役割を信頼性高く果たせるかどうかが、アグリゲーターモデルが実質的な価値を提供するかを決める。

マルチエージェントAIペンテストが今登場する理由

そのタイミングは、予定されたセキュリティ評価から継続的かつ機械速度の検証への移行を反映している。

従来のペネトレーションテストは、希少な人間の専門家、固定された作業期間、手作業で作成されるレポートに依存することが多い。この構造は詳細なスナップショットを提供するが、テスト終了後まもなく環境が変わる可能性がある。

現在ではアプリケーションが頻繁にリリースされ、クラウド資産が動的に出現し、公開されたサービスも次の評価を待たずに変化する。そのため、テスト間の空白期間は管理されていないリスクウィンドウになり得る。

ThreatBookは、AIエージェントによってより短いテストサイクルが現実的になると主張する。RedAgentsは、ペンテストを年次の業務として扱うのではなく、セキュリティチームが毎日、毎週、または毎月評価を実行できるよう設計されている。

この考え方はThreatBook固有のものではない。自律型テストベンダーはすでに、継続的な評価、再テスト、攻撃経路の検証を、単発のコンサルティング案件に代わる選択肢として売り込んでいる。

XBOWは、証拠を生成しながらWeb脆弱性を自律的に発見・悪用するとしている。同社は2025年、HackerOneの米国リーダーボードで首位に到達したと報告した。

同社が公開した説明によると、その取り組みでシステムは約1,060件の脆弱性を報告した。人間のレビュアーはプログラム準拠を確認したが、XBOWによれば、発見や悪用には関与していない。

これらの数値はXBOWによるものであり、RedAgentsとの直接比較の基準として扱うべきではない。それでも、自律型ペンテストが実験室での実証を超えた理由を示している。

XBOWのベンチマーク履歴は、進歩の測定が難しいことも示している。同社はまず既存のトレーニング課題を用い、その後に新規シナリオを作成し、本番のバグバウンティターゲットへと移行した。

ThreatBookは、RedAgentsプラットフォーム全体に関する同等の評価を公開していない。代わりに、ラインアップ内の個々のエージェントに関連する実績を挙げている。

同社によれば、Cyber(YanJi)はTencent Cloudのハッカソンで対象となった54件の問題を54件すべて解決した。また、Artexのオープンソース版は2026年9月にBaiduのAgent+ Offensive and Defensive Challengeで優勝したとしている。

CyberStrikeAIは、ThreatBookが2026年9月に買収する前にGitHubスターを7,800件以上獲得していたとされる。人気は開発者の関心を示すことがあるが、エンタープライズテストの精度や安全な実行を測るものではない。

こうしたエージェント単位のシグナルは、集約が魅力的に見える理由を説明する。購入者は、どのエージェントがあらゆるアプリケーション、脆弱性クラス、インフラ環境で優位になるかを予測せずとも、複数のアプローチを利用できる。

このモデルは、ThreatBookに将来のシステムを取り込む手段も与える。同社の製品ページでは、商用、学術、オープンソースのエージェントを継続的に追加するとしている。

これは、新しい手法ごとに1つの独自エージェントを再構築するよりも、より速い更新経路を生み出す可能性がある。プラットフォームは、明確に異なる能力を持つ専門家を追加できる。

しかし、同じ設計は評価とガバナンスの責任を移す。ThreatBookは、どのエージェントが適格か、どの権限を与えるか、顧客がその挙動をどのように比較できるかを決めなければならない。

セキュリティチームは、2つのエージェントが本当に独立した視点を提供するかも知る必要がある。複数の製品であっても、同じモデルの弱点、トレーニングデータ、ツール、計画パターンを継承している可能性がある。

マルチエージェントという主張が価値を持つのは、多様性が有用なカバレッジを生む場合だけだ。似たエージェントを何度も実行しても、洞察を増やさずに活動量だけを増やす可能性がある。

そのため、RedAgentsにとって最も重要な指標は接続されたツールの数ではない。それらのツールが、強力な単一エージェントのベースラインを超えて、安全に発見する、検証済みで重複のない検出結果の数である。

RedAgentsと単一エージェント型ペンテストモデルの比較

中心となる競争は、ポートフォリオによるカバレッジと、厳密に統制された1つのテストシステムの一貫性との対決だ。

単一プラットフォームのベンダーは、1つのアーキテクチャを軸に評価のあらゆる部分を最適化できる。計画、ツールアクセス、証拠基準、安全ルール、レポート、再テストを制御する。

この垂直統合は説明責任を単純化できる。テストが不適切な挙動を示した場合や、検出結果の信頼性が低いと判明した場合、顧客が調べるべきシステムとベンダーは1つである。

ThreatBookは多様性を得るために、その単純さの一部を手放している。RedAgentsは、異なるチームが作成し、それぞれ異なる強みと技術的経路を持つエージェントを集められる。

そのマルチエージェントプラットフォームは、選択を顧客の判断として提示している。チームは、重点的なタスクに1つのエージェントを展開することも、より広範な相互検証のために複数のエージェントを展開することもできる。

これは、異なる攻撃対象領域の専門家で構成される人間のレッドチームを編成することに似ている。Webアプリケーションの専門家、アイデンティティの専門家、クラウドテスターは、同じ環境でも異なる経路を見出せる。

しかし、人間のチームメンバーは互いにコミュニケーションを取り、対立を解消し、仮定を共に見直す。ソフトウェアエージェントが同じ協調を実現するには、明示的なオーケストレーションが必要となる。

並列実行は干渉も引き起こし得る。あるエージェントがアプリケーションの状態を変え、トークンを消費し、ロックアウトを発生させ、別のエージェントが同じ経路に到達する前に証拠を変更する可能性がある。

ローンチ資料では、RedAgentsがこうした衝突をどのように処理するかは説明されていない。また、危険な操作を直列化するのか、各エージェントを個別のテスト環境に分離するのかも示されていない。

結果の集約には別の課題もある。2つのエージェントが、同じ根本的な脆弱性について、異なる説明、深刻度評価、悪用の証拠を報告する場合がある。

有用なプラットフォームは、異なる攻撃経路を統合してしまうことなく、この重複を認識しなければならない。また、人間のテスターが各検出結果を再現し、優先順位を付けるのに十分な証拠も保持する必要がある。

ThreatBookは、RedAgentsが検出結果を自動的に重複排除し、評価するとしている。このプロセスが初期エージェントラインアップ全体でどれほど正確に機能するかを示すデータは公開していない。

誤検知の削減も中心的な主張の1つだ。複数のエージェントを実行しても、不正確な結果が自動的に消えるわけではない。

エージェントが同じ基盤モデルやセキュリティツールを共有している場合、同じ誤った仮定を繰り返す可能性がある。逆に、ある専門家による正しい検出結果は1回しか現れないかもしれない。

そのため投票システムでは、他のエージェントが再現できなかったという理由で価値ある結果を却下する可能性がある。すべての検出結果の和集合を取れば、逆の問題が生じ、レビュアーを圧倒する恐れがある。

RedAgentsには、単純なコンセンサスより優れた意思決定メカニズムが必要だ。再現された検出結果、独立して発見された検出結果、手動検証を要する専門的な検出結果を区別すべきである。

既存の自律型ペネトレーションテストサービスも競合となる。Horizon3.aiのNodeZeroは自律的な攻撃経路の発見に注力し、XBOWは検証済みのWeb脆弱性と本番環境での証拠を重視している。

これらのシステムは、購入者が何を期待するかを示す基準となる。顧客が求めるのは、再現可能なエクスプロイト、影響を受ける資産の明確化、修復ガイダンス、そして修正後の信頼できる確認だ。

同一のエンゲージメント中に複数のエージェントが実質的に異なる弱点を発見できれば、RedAgentsは差別化できる。また、複数の個別契約よりも単一のコントロールプレーンで結果を管理しやすくできれば、優位に立てる。

顧客が矛盾する出力を手作業で調査しなければならない場合、アグリゲーターは優位性を失う。接続されたエージェントが専門プラットフォームと同等の深度を実現できない場合も同様だ。

したがって、最初の有意義な比較では、同一の対象、スコープ、テスト期間を用いるべきである。検証済みの固有の発見、偽陽性、運用上のインシデント、人によるレビュー時間を測定する必要がある。

その証拠がなければ、RedAgentsは実証済みの代替手段ではなく、もっともらしいアーキテクチャにとどまる。このローンチが示すのは製品の方向性であり、優位性ではない。

オーケストレーションがシグナルを加えなければ、この仕組みは機能しない

より多くのエージェントがカバレッジを改善するのは、RedAgentsがその行動を制御し、出力を裏付け可能な証拠へと変換できる場合に限られる。

プラットフォームの最初の役割は、スコープの強制だ。ペネトレーションテストには、定義されたエンゲージメントの外では許可されない行為が含まれる。

米国国立標準技術研究所（NIST）は、交戦規則を、テスト開始前に設定される制約として定義している。これらの規則は、無制限の許可を与えることなく、指定された活動の権限を付与する。

NISTのガイダンスでは、対象、制限対象システム、許容される手法、テスト期間、送信元アドレスを重要なエンゲージメント詳細として挙げている。ソフトウェアが作業を実行する場合でも、testing rulesは依然として重要だ。

ThreatBookによれば、RedAgentsはホワイトリストを用いてテスト範囲を定義する。ホワイトリストで対象アドレスを制限できるが、安全な運用にはさらに細かな制御が必要となる。

チームによっては、サービス拒否手法、破壊的なデータベース操作、パスワード変更、本番の顧客記録へのアクセスを禁止する必要がある。また、メンテナンス時間帯やリクエストレートの上限も必要になる場合がある。

マルチエージェントプラットフォームは、接続されるすべてのシステムにわたり、こうした制約を一貫して適用しなければならない。各エージェントが書面の指示を同じように解釈すると仮定することはできない。

認可は、モデルの推論ループの外部で強制すべきだ。ネットワーク制御、分離された認証情報、コマンドポリシー、対象レベルの権限は、プロンプト単体よりも強い境界を提供する。

これは、言語モデルのエージェントがツールを選択し、行動シーケンスを動的に生成できるため重要である。その柔軟性は未知の環境を探索する助けになる一方、将来のすべての行動を予測しにくくする。

OWASPは、この問題の一形態を過剰なエージェンシーと呼ぶ。これは、AIシステムがタスクに必要な範囲を超える機能、権限、または自律性を与えられた場合に発生する。

OWASPは、利用可能なツールを減らし、権限を制限し、重大な行動には人間の承認を求め、下流システムで認可を強制することを推奨している。excessive agency guidanceでは、マルチエージェント環境における侵害されたピアエージェントについても警告している。

この警告はRedAgentsに直接当てはまる。アグリゲーターは、接続された各エージェントを、セキュリティ能力の源であると同時に障害を起こし得るコンポーネントとして扱わなければならない。

集中ログは役立つ可能性がある。RedAgentsは、参加するエージェントのログと結果を一元的に記録し、レビュー担当者に共通の監査証跡を提供するとしている。

共有される証跡には、どのエージェントが各コマンドを発行したか、どのIDを使用したか、どの対象が応答したか、制御によって要求された操作が変更されたかどうかを示す必要がある。また、検証済みの発見ごとに証拠を保持すべきだ。

データを一切保持しないことには、別の運用上のトレードオフもある。機密性の高いテストデータを削除すれば露出を減らせるが、顧客は修復、監査、インシデントレビューのために選択した証拠を必要とする場合がある。

そのため、プラットフォームは保持ポリシーを正確に定めるべきだ。購入者は、「完全な削除」が何を対象とするのか、いつ削除されるのか、バックアップや診断ログにも同じポリシーが適用されるのかを知る必要がある。

第三者のエージェントがプラットフォームに加わると、データ分離はより複雑になる。ThreatBookは、顧客のテストデータが、それらのプロバイダーに到達するのではなく、自社環境内に留まるとしている。

この主張にはアーキテクチャ面の説明が必要だ。顧客は、エージェントのコードがThreatBook管理下の分離環境で実行されるのか、外部モデルがプロンプトを受け取るのか、秘密情報がどのようにフィルタリングされるのかを理解すべきである。

プラットフォームの価値は、最終的には証拠パイプラインから生まれる。セキュリティチームが発見を信頼し、再現し、優先順位付けできなければ、発見だけでは不十分だ。

信頼できるマルチエージェントのワークフローは、統合された評価を生成しながら、個別の証拠を保持するものとなる。エージェントが合意した時、不一致だった時、そしてプラットフォームが最終的な深刻度を選択した理由を示す必要がある。

RedAgentsは最上位レベルの設計を説明しているが、そのレベルの実装については明らかにしていない。技術文書と管理された顧客評価が、オーケストレーションが本当にシグナルを加えるかを判断することになる。

安全性の問題は製品の一部である

RedAgentsは、防御側にとって有用であり続けながら、制御不能な攻撃インフラにならないようにしなければならない攻撃的能力を組み合わせている。

あらゆる自律型ペネトレーションテスト製品は、デュアルユースの問題に直面する。企業の防御検証を助ける能力は、攻撃者による偵察とエクスプロイトの自動化にも役立ち得る。

ThreatBookの初期ラインアップは、この緊張関係を特に明確にしている。同社によれば、Artexは攻撃での悪用が疑われたことを受け、2026年10月8日にオープンソースからクローズドソースへ移行した。

ThreatBookの発表は、この判断を韓国の金融機関に影響したインシデントと結びつけている。ただし、このリリースは、あらゆる詳細を裏付ける完全な独立インシデント報告書を提示していない。

それでもこの事例は、直接的なガバナンス上の問いを提起する。エージェントが悪用と関連付けられた場合、RedAgentsはデプロイ前にそのコード、モデル、依存関係、運用上の挙動をどのように評価するのか。

同社は、Artex Proがオープンソース版を超える制御性、安定性、追跡可能性を備えるとしている。これらの説明は、ローンチ資料では独立した検証を受けていない。

ツールの取得または商用化は説明責任を生み得るが、それだけでツールが安全になるわけではない。制御は、障害、悪意ある指示、侵害された依存関係、予期しない対象からの応答に対してテストされる必要がある。

エージェントの多様性は、テストプラットフォーム内部の攻撃対象領域を増やす可能性がある。コネクター、ツール統合、モデルエンドポイント、認証情報ストア、レポート経路のすべてが、新たな潜在的弱点を生み出す。

アグリゲーターは、プロンプトインジェクションへの防御も必要となる。敵対的な対象は、エージェントを操り、制限を無視させたり、機密情報を露出させたりするよう設計されたコンテンツを提示する可能性がある。

マルチエージェント通信は別の経路を生む。侵害されたエージェントが、オーケストレーターやピアエージェントの判断に影響する誤解を招くコンテキストを生成する可能性がある。

OWASPは、エージェントの入力と出力を信頼できないものとして扱うことを推奨している。すべての認可判断をモデルに委ねるのではなく、決定的な制御で重大なリクエストを仲介すべきだ。

ThreatBookのホワイトリストと集中データモデルは、この問題の一部に対処している。ただし、個々のコマンドが実行前にポリシーの強制を受けるかどうかには答えていない。

同社はまた、RedAgentsの外部監査、指名された設計パートナー、本番顧客を特定していない。限定的なテストでその証拠を生み出すことは可能だが、初期導入者は明確な境界を求めるべきである。

購入者は、どのシステムがサポートされるのか、どの操作に承認が必要なのか、認証情報がどのようにスコープ設定されるのかを尋ねるべきだ。また、エージェントが割り当てられたワークフローを離れた場合に何が起こるかも確認すべきである。

ロールバックと緊急停止にも同等の注意が必要だ。セキュリティ担当者には、異常なテスト中にすべてのアクティブなエージェントを停止し、認証情報を失効させ、証拠を保全するための信頼できる手段が必要となる。

独立ベンチマークには、脆弱性件数だけでなく、安全性の結果も含めなければならない。より多くの問題を発見しても、障害を引き起こしたり秘密情報を不適切に扱ったりするシステムは、より良い評価を提供しているとは言えない。

テストでは、トレーニング環境と本番システムも分離すべきだ。成熟した自律プラットフォームであっても、自動化されたセキュリティ評価が影響ゼロを保証できないことを認めている。

複数のエージェントが同時に稼働すると、負担は増える。活動量が増えることで、防御的な制御が作動し、アカウントがロックされ、レートに敏感なサービスに影響が出る可能性がある。

RedAgentsは、同時実行性を可視化し、設定可能にすべきだ。顧客には、テスト期間、リクエストレート、保護対象エンドポイント、同時操作の最大数を制御する手段が必要である。

慎重な展開は、分離されたアプリケーション、非本番のレプリカ、厳密にスコープ設定された外部資産から始めるだろう。チームはその後、アクセスを拡大する前に、人による検証と発見を比較できる。

このアプローチは製品価値を弱めない。むしろ、どのエージェントが自らの環境で優れた性能を発揮するかについて、セキュリティチームに証拠を提供する。

したがって、このローンチは能力とリスクを切り離せない一つの問題として提示している。RedAgentsが成功するのは、そのコントロールプレーンが調整する攻撃的システムと少なくとも同程度に高度である場合に限られる。

RedAgentsが成果を出すかを示す3つのシグナル

次の段階は、比較可能な証拠、強制可能な安全制御、実際の顧客導入によって判断されるべきだ。

第1のシグナルは、強力な単一エージェントのベースラインに対する管理されたベンチマークである。ThreatBookは、同一の対象、認証情報、スコープ、時間制限を使用したテストを公開すべきだ。

有用な結果は、単なるアラート総数ではない。検証済みの固有の脆弱性、重複する発見、偽陽性、深刻度の分布、人による検証時間を示すものとなる。

RedAgentsが個々の参加者すべてが見逃した重要な問題を一貫して発見できれば、このベンチマークはマルチエージェントの主張を強める。運用作業が増えるだけで結果が類似するなら、その主張は弱まる。

第2のシグナルは、詳細な安全性文書である。ThreatBookは、コマンド仲介、エージェント分離、認証情報の制御、承認ゲート、保持動作、緊急停止について説明すべきだ。

独立したテストは、機能チェックリストよりも重みを持つ。購入者には、プロンプトインジェクション、モデルの誤り、侵害されたピア出力によってエージェントがスコープ外に出られないことの証拠が必要だ。

第3のシグナルは、限定的な試行を超えた継続的な導入である。指名された事例研究は、組織がどの程度の頻度でテストを実行するのか、どのエージェントを選ぶのか、発見が検証済みの修正につながるのかを示すべきだ。

導入データは、顧客がエージェントの選択肢を評価しているのか、それとも単に1つのデフォルトシステムを選んでいるのかも明らかにする。大半のユーザーが幅広いラインアップを無視するなら、アグリゲーターの論拠は弱まる。

RedAgentsは、現実の制約に対する一貫した答えを携えて市場に参入する。単一のテストアプローチですべての脆弱性を発見することはできず、頻繁なソフトウェア変更により定期的な評価だけでは不十分になっている。

しかし、エージェントを追加してもセキュリティの向上は保証されない。プラットフォームは、同じくらい多様なリスクを生み出すことなく、オーケストレーションによって多様かつ検証済みの発見を生み出せることを証明しなければならない。

ThreatBook RedAgentsのローンチを評価するセキュリティリーダーは、限定的な比較から始めるべきだ。RedAgentsと既存の代替手段に同じ認可済みの対象を与え、確認済みの発見と運用担当者の負荷を測定する。

重大な操作については人によるレビューを維持し、明示的な交戦規則を要求すべきだ。結果は、再現可能性、修復価値、安全な実行によって判断されるべきである。

次の四半期に問われるのは明確だ。ThreatBookは、統制された複数のエージェントが成熟した自律型ペンテスター1体を上回ることを示す証拠を提示できるのか。マルチエージェントAIペンテストが持続的なカテゴリーとなるかどうかを決めるのは、陣容の規模ではなく、この成果である。