SecRespond、23の最先端AIモデルがステルス侵入を見逃したと報告
SecRespondは厳しい結果とともにGoogle Newsに掲載された。23の最先端モデルのうち、テスト対象となった侵害済みホストで検知と修復を完遂したモデルは1つもなかった。エージェントは目に見えるアラートにははるかに適切に対応した一方、表面化していない証拠を扱う能力は低く、AI支援型トリアージと自律型インシデント対応の隔たりが浮き彫りになった。
Alibaba Groupの研究者らは、2026年7月29日にSecRespond論文を投稿した。モデルがファイルを調査し、コマンドラインツールを利用できるエージェントハーネスであるOpenCodeを通じ、複数の主要モデルファミリーをテストした。
テストは、攻撃者がすでに侵入に成功した後の時点から始まる。この点が、本研究の中心にある対立を生む。AIエージェントはアラートを追跡できるが、セキュリティオペレーションセンターに必要なのは、誰にもフラグ付けされていない脅威も発見できる調査担当者だ。
そのためSecRespondは、よく語られる自動化の約束に疑問を投げかける。アラートを要約するモデルはアナリストの負担を軽減できるが、それだけで独立したインシデント対応者になるわけではない。ベンチマークは、ディスク上のアーティファクト、永続化の仕組み、不完全なクリーンアップ手順、検証されていない修復計画の中に、その違いを見いだした。
SecRespondベンチマークが実際に変えたもの
SecRespondは、評価対象をアラートの解釈から、すでに侵害されたマシンの調査へと移している。
多くのサイバーセキュリティテストは、侵害が起きる前から始まる。モデルに脆弱性の特定、キャプチャー・ザ・フラッグ課題の解決、マルウェアの分類、選別済みのセキュリティログに基づく推論を求める。こうしたタスクは有用な能力を測定するが、実際の侵害を特徴づける不確実性を減らしてしまう。
SecRespondはより後の段階から始まる。各エージェントには、侵害されたクラウドホストから取得した固定済みのフォレンジックディスクスナップショットが与えられる。さらに、ホスト保護製品によるアラート、脆弱性スキャン、セキュリティベースラインチェックに似せた合成出力も提供される。
フォレンジックディスクスナップショットとは、特定時点におけるシステムのファイルやアーティファクトを保存したコピーである。アラートが触れていない証拠も含まれる可能性があり、変更された起動ファイル、バックドア用アカウント、消去されたログ、スケジュールジョブ、悪意あるバイナリなどが該当する。
エージェントはその資料を調べ、何が起きたのかを再構築しなければならない。続いて、侵入、脆弱性、ベースラインリスク、修復を扱うレポートを作成する。このタスクでは進捗ファイルも必要とされ、洗練された最終回答だけを受け入れるのではなく、調査の記録を残すことが求められる。
ベンチマークには10のサイバーレンジが含まれる。これはセキュリティインシデントを再現するために構築された隔離環境を指す。これらのレンジは4種類の初期侵入経路、MITRE ATT&CKカタログの21の技術、5つのOSをカバーしている。
研究者らはこれらの環境を、52の能力項目と280の詳細チェックポイントに落とし込んだ。チェックポイントでは、エージェントが具体的な証拠を発見したか、それを正しく帰属させたか、適切な対応を推奨したか、必要な検証まで網羅したかを確認する。
検知と修復計画には別々のスコアが与えられる。検知は該当するチェックポイントごとに最大3点、計画は最大2点であり、いずれかの評価軸に該当しないチェックポイントは集計から除外される。
この区別は重要だ。悪意あるファイルを見つけても、対応者が次に何をすべきかは分からない。安全な対応には、ホストの隔離、証拠保全、プロセス終了、永続化の除去、認証情報のローテーション、インフラのブロック、サービス復旧、復旧の検証が必要になる場合がある。
公開されているSecRespondデータセットには、タスクプロンプト、評価資料、チェックリスト、合成セキュリティ出力、フォレンジックアーカイブが含まれる。これにより、この中心的な主張は原著者以外のチームでも検証可能になる。
SecRespondはAIによるインシデント対応に、より厳格な境界も定めている。エージェントは、おそらく何かを確認しただけでは満点を得られない。レポートには発見事項を記し、該当するチェックリストを満たす証拠を示さなければならない。
このルールは、曖昧なセキュリティ表現を測定可能なパフォーマンスへと変える。「不審な活動を調査する」は、特定のプロセス、ファイル、アカウント、エンドポイント、永続化パスを特定することと同義ではない。「サーバーにパッチを適用する」は、完全で順序立てられ、検証済みの復旧計画を意味しない。
Google Newsの報道は、23モデルに共通する見出し上の失敗に焦点を当てた。より深い変化は方法論にある。SecRespondは、エージェントが与えられていない手掛かりを追究し、その発見を正当化可能なクリーンアッププロセスへ結び付けられるかを問う。
Google Newsの注目がAIセキュリティの購買担当者にとって重要な理由
このベンチマークは、ベンダーとセキュリティリーダーに対し、アラート支援と自律型インシデント対応を区別するよう迫っている。
AIはすでに、セキュリティオペレーションセンターにおいて、アラートの要約、インジケーターの拡充、ドキュメント検索、クエリの下書き、ケースノートの作成を支援している。アナリストは断片化された証拠や反復的な管理作業に直面することが多いため、これらのワークフローには依然として価値がある。
しかしSecRespondが測定するのは、より高い水準の自律性だ。自律型の対応者は、どこを調査すべきかを判断し、不足している証拠を認識し、競合する説明を検証し、最も明白なアラートが解決された後も調査を継続しなければならない。
ベンチマークの中心的な結果は、この区別が重要である理由を示している。評価対象の23モデルすべてにおいて、1つのサイバーレンジですら完全な検知と修復を達成したエージェントはいなかった。
報告された実験で総合最高のモデルはClaude Opus 4.7だった。検知ではレンジレベルのチェックポイントスコア平均79.0％、計画では65.7％に達した。
論文では、先頭モデルについて、これらの評価軸を組み合わせた平均72.4％も報告している。それでも、特により長く広範な攻撃チェーンを含むレンジでは、悪意あるアーティファクトが手付かずのまま残り、修復も不完全だった。
その他の上位結果には、Claude Opus 4.6の検知78.2％・計画58.0％が含まれる。GLM-5.1は76.3％・59.2％、Qwen3.7 Plusは75.6％・58.8％に達した。
これらの数値を、基盤となるモデル全般のランキングと見なすべきではない。数値が示すのは、1つのエージェントハーネス、1つのベンチマークバージョン、1つのタスク設計、特定の評価プロセスにおける結果である。
むしろ結果は、共通する失敗パターンを明らかにしている。モデルは既存のアラートに結び付く証拠を比較的確実に見つけたが、ディスクを自発的に探索しなければ発見できない証拠には弱かった。
このパターンは、「AIアナリスト」や「自律型SOC」といった広範な表現を使うセキュリティベンダーに圧力をかける。購入者は、人間が作成した手掛かりなしに、システムが対応ライフサイクルのどの部分を実際に実行できるのかを問う必要がある。
製品はエンドポイントアラートを正確に要約できても、2つ目の永続化メカニズムを見落とすかもしれない。悪意あるバイナリの削除を推奨しても、そのプロセスの終了、ローダーの除去、露出した認証情報のローテーション、サービス復旧の検証を怠る可能性がある。
省かれた各手順は、運用上の結果を変える。攻撃者は、未対処のアカウント、スケジュールタスク、webshell、サービス、レジストリエントリ、シェルフックを通じて戻ってくる可能性がある。そのため、技術的に正しい最初の対応であっても、封じ込めが完了したという誤った安心感を生みかねない。
セキュリティリーダーは、調査の質とレポートの質も分けて考える必要がある。モデルは流暢な説明を生成することが多いが、SecRespondが評価するのは、その説明に必要な証拠と修復の詳細が含まれているかどうかだ。
これは、知識集約型の業務でよく見られる問題である。自信に満ちた説明は、不完全な情報取得を隠すことがある。検索可能なナレッジベースを構築するチームも、関連する要件に直面する。結論はソース資料まで追跡可能でなければならない。
このベンチマークは、インシデント対応においてその追跡可能性を具体化している。エージェントは、どのアーティファクトが各結論を裏付け、どの対応が各特定済みの状態に対処するのかを示さなければならない。
Google Newsでの可視性は、この区別をベンチマーク研究者の枠を超えて広げる可能性がある。調達チーム、CISO、マネージドセキュリティプロバイダー、社内監査グループは今、「アラートを処理する」と「インシデントを処理する」が同等の主張ではない理由を示す公開事例を手にしている。
真の死角は、誘導のない調査にある
インシデントが次のアーティファクトを示す明白なアラートを残さない場合、モデルの弱さが最も顕著に表れる。
SecRespondは、パフォーマンスを5つの能力領域に分類している。対象は、侵入エンティティ、永続化メカニズム、ベースラインリスク、脆弱性リスク、そして調査と対応の総合的な品質だ。
侵入エンティティとは、プロセス、ファイル、ネットワークエンドポイント、改ざんされたアーティファクトなど、具体的な悪意あるオブジェクトを指す。これらのオブジェクトは目に見えるセキュリティシグナルと一致することが多いため、モデルはこのカテゴリで最も良い成績を示した。
モデル全体では、侵入エンティティの平均検知率は75.4％に達した。Qwen3.7 Plusの88.4％、Claude Opus 4.6の86.0％など、複数の上位システムはさらに高い成績を記録した。
永続化メカニズムでは異なる結果となった。永続化とは、再起動や初期クリーンアップ後も攻撃者のアクセスを維持できるようにする変更を指す。例には、スケジュールタスク、サービス、シェルの起動フック、webshell、アカウントバックドア、Windows Management Instrumentationサブスクリプションがある。
永続化の平均検知率は58.8％まで低下した。この低下は重要である。なぜなら、永続化こそ、対応者がホストをクリーンと宣言する前に発見しなければならないものだからだ。
ベンチマークは、モデルがフォレンジック推論をまったくできないことを示しているわけではない。モデルはアラートと関連するプロセスやファイルを結び付けられ、多くの場合、目の前の脅威を正しく説明できる。問題が生じるのは、調査をその出発点より先へ広げなければならないときだ。
侵害されたWebサーバーを考えてみよう。アラートは、悪意あるプロセスや外向き通信を特定するかもしれない。そのシグナルを追えば1つの実行可能ファイルが見つかる可能性があるが、完全な調査では、攻撃者がどう侵入したのか、どの認証情報が露出したのか、終了後も何が残るのかを問わなければならない。
対応者はさらに、起動スクリプト、サービス定義、cronエントリ、ユーザーアカウント、コマンド履歴、アプリケーションディレクトリ、改変されたログを調べる必要があるかもしれない。単一のアラートが、必ずしもこれらの場所を示すわけではない。
これは境界が不確実な探索問題を生む。エージェントは、どの仮説を検証する価値があるか、どれだけ調査を続けるべきかを判断しなければならない。1つのアーティファクトが見つからなかったからといって、他の永続化経路がないとは限らないことも認識する必要がある。
現在の言語モデルエージェントは、すでにコンテキスト内に存在する証拠を中心に最適化されがちだ。アラートは顕著なアンカーを生むため、エージェントは言及されていない証拠を探す代わりに、そのアンカーを説明することに予算を費やしかねない。
より長い攻撃チェーンは、この弱点を増幅させる。追加される技術ごとに、モデルが相関付けなければならない分岐、アーティファクトの種類、タイムスタンプ、アカウント、サービスが増える。
論文は、攻撃が長く広範になるにつれてパフォーマンスが低下したと報告している。この結果は運用上の課題と一致する。インシデント対応は1回の分類判断ではなく、不完全な情報のもとで相互に結び付いた判断を連続して下すプロセスである。
別の2026年の脅威ハンティングベンチマークでも、関連する問題が報告されている。5つの最先端モデルが26の攻撃キャンペーンに由来する生のWindowsイベントログを検索したが、最高性能のモデルでさえ、悪意あるイベントのごく一部しか発見できなかった。
2つの研究は異なるワークフローをテストしているため、スコアを直接比較することはできない。しかしどちらも、事前に選別された証拠に基づく推論より、誘導のない探索のほうが依然として難しいことを示唆している。
これは、このベンチマークが示す核心的な逆転現象だ。エージェントは、従来のセキュリティツールがすでに不確実性を低減している領域で最も能力を発揮するように見える。一方、アラートが明らかにしなかった点を問い直すことで、人間の調査担当者が最も大きな価値を加える領域では信頼性が下がる。
セキュリティチームは、この境界の中でなおAIを有効に活用できる。モデルは証拠を要約し、仮説を提示し、クエリを下書きし、アーティファクトを比較し、調査タイムラインを維持できる。
危険な飛躍は、こうした能力を、モデルがインシデント全体を調査済みである証拠として扱うことだ。SecRespondは、流暢な回答が、未発見の永続化や攻撃者活動に関する不完全な説明と共存しうることを示している。
検知スコアは、より大きな修復ギャップを隠している
より多くの証拠を発見しても、同じ程度に完全なクリーンアップ計画にはつながらず、修復はベンチマークにおける2つ目の大きな失敗領域となった。
評価対象となったすべてのモデルで、検知スコアは計画スコアを上回った。GPT-5.5では、報告された差は34.7ポイントに達した。
研究者らは、このパターンについて、エージェントが明白な最初の対処を実施する一方、残るアクションを省略することに起因するとしている。この挙動はチェックリストの打ち切りに似ている。中心的な悪意あるオブジェクトに対処すると、モデルはインシデントが解決したかのように振る舞う。
実際の修復は、削除や設定変更を1回行えば終わることはめったにない。対応担当者は、依存関係、証拠保全、業務への影響、サービス継続性、認証情報の露出、そして攻撃者の代替アクセス経路を考慮しなければならない。
SecRespondの計画スコアは、アクションが正しいかつ完全かを問う。関連するチェックポイントで必要とされる場合には、検証と副作用も評価する。
検証は儀礼的なものではない。スケジュールされたタスクを削除する計画では、そのタスクが存在しなくなったこと、そしてそのペイロードが別の仕組みを通じて起動できないことを確認すべきだ。
攻撃者のアドレスをブロックする計画では、適切な場合に受信トラフィックと送信トラフィックの両方を扱う必要がある。また、アドレスのブロックによって、ホスト上にすでに存在するマルウェア、盗まれた認証情報、または永続化が取り除かれるかのような印象を与えてはならない。
標準化された設定上の問題は、より容易であることが分かった。Claude Opus 4.7は、ベースラインリスクの計画で74.8パーセント、脆弱性リスクで72.6パーセントに達した。
これらのタスクは多くの場合、設定の強化や影響を受けるソフトウェアの更新といった、馴染みのあるアクションに対応する。エージェントは認識可能な修復パターンを取得し、それを検出事項に適用できる。
調査と対応の品質は、依然として大幅に低かった。このカテゴリーにおける平均の計画性能は31.8パーセントにとどまった。
このカテゴリーは、既知の1つの修正ではなく、統合的な判断に依存する作業を対象とする。攻撃チェーンの再構築、証拠の品質、不確実性に対する誠実さ、完全性、検証、運用上の影響への認識が含まれる。
このカテゴリーで最も高い検知結果は75.5パーセントに達した。論文によれば、計画ではほぼすべてのモデルが50パーセント未満にとどまった。
これらの結果は、単純なスケールアップ戦略に疑問を投げかける。モデルにより多くのアラートを与えても、完全な対応計画が自動的に作られるわけではない。可視化された検出事項が増えることで、かえって分断された推奨事項が増える場合がある。
信頼できる計画には順序付けが必要だ。チームは変更を加える前にマシンを隔離し、プロセスを終了する前に揮発性の証拠を保全し、露出範囲を確定した後で認証情報をローテーションすることがある。
ロールバックとサービスに関する考慮も必要だ。依存関係を理解せずに侵害されたコンポーネントを削除すると、本番環境を中断させたり、帰属判断に必要な証拠を破壊したりする可能性がある。
SecRespondは、本番システム上でのライブ修復ではなく、記述された計画を評価している。この点はベンチマークが確立できる範囲を制限するが、安全性の問題を可視化し続けることにもつながる。
モデルが統制された環境で完全かつ検証済みの修復を一貫して記述できないなら、組織がライブホスト上で無制限の権限を与える根拠はほとんどない。
したがってベンチマークは、より限定的な運用モデルを支持する。AIはアクションを提案し、証拠を整理し、欠落したフィールドを強調できる一方、封じ込めと復旧の手順については人間の対応担当者が承認権限を保持する。
この配置は、SOC自動化の否定ではない。データにおける特定の非対称性への対応である。これらのシステムは、既知のオブジェクトを特定することには比較的優れていたが、すべての影響が安全に処理されることを保証する点では劣っていた。
セキュリティチームは、この非対称性をアクセス制御に反映すべきだ。読み取り専用のフォレンジックアクセスが伴うリスクは、プロセスの終了、ファイルの削除、アカウントの無効化、ネットワークポリシーの変更を許可するリスクとは異なる。
隠れたアーティファクトを見逃すエージェントは、不完全なレポートを作成する。不完全なレポートに基づいて行動するエージェントは、攻撃者の代替経路を残したまま復旧を妨げる可能性がある。
数値が証明していないこと
SecRespondは共通する限界の強力な証拠だが、すべてのモデルや本番SOC構成に対する最終判断ではない。
この論文は、査読を完了した成果ではなくarXivのプレプリントである。著者にはTongyi LabとAlibaba Cloudの研究者が含まれ、このベンチマークは1つの代表的なハーネスを通じてモデルを評価している。
OpenCodeの選択は、システム間のツール利用の標準化に役立つ。同時にこれは、結果がプロンプト、ツール、コンテキスト管理、実行ポリシーから切り離された抽象的なモデル能力ではなく、モデルとハーネスの組み合わせを測定していることも意味する。
異なるスキャフォールディングは性能を変えうる。インシデント対応エージェントは、必須の調査チェックリスト、専用のフォレンジックユーティリティ、社内手順を対象とする検索、多数の協調エージェント、または決定論的な検証スクリプトを使用できる。
SecRespondは、こうした改善を同じレンジに対して検証できるため、依然として有用である。ただし、公開された数値を各モデルファミリーの恒久的な限界として扱うべきではない。
評価にはLLM-as-a-judgeのプロセスも使われており、言語モデルが詳細なチェックリストに照らして生成レポートを採点する。単一の採点者への依存を減らすため、3つのプロプライエタリな評価モデルが独立して使用された。
それらの評価モデルはClaude Opus 4.7、Gemini 3.1 Pro、GPT-5.4 Proだった。複数の評価者は個別のバイアスを減らすが、すべての較正上の問題を取り除くわけではない。
評価者は、不完全な表現を人間のフォレンジック専門家とは異なる形で解釈する可能性がある。また、基礎となる調査プロセスが妥当だったかを完全に解決せずに、明示的なレポート表現を評価する可能性もある。
採点指示はこのリスクの抑制を試みている。評価者は証拠を引用し、レポート内に明示的に存在する内容にのみ点を与えなければならない。
ベンチマークの280のチェックポイントは、追加の構造を提供する。それでも、あらゆるチェックリストには、どのアーティファクト、対応手順、品質に重みを置くべきかという選択が組み込まれている。
10のレンジは、繰り返される挙動を明らかにするには十分な多様性を備えている。しかし、あらゆるオペレーティングシステム、クラウドアーキテクチャ、アイデンティティプラットフォーム、エンドポイント製品、攻撃者の手法を網羅しているわけではない。
環境も統制されている。研究者らはベンチマーク用にホストをプロビジョニングして侵害し、その後、認証情報と個人データをサニタイズした。
この設計は再現性を可能にし、本番情報の露出を避ける。ただし、実際の企業インシデントにおけるノイズ、不完全なテレメトリ、組織上の制約、ビジネス上の依存関係を完全に再現することはできない。
ある結果は、安全性の挙動がベンチマークのカバレッジにどう影響しうるかも示している。Claude Opus 4.7はnpm-wormタスクを拒否したため、論文ではそのモデルを当該レンジの詳細なチェックポイント表から除外した。
正当な防御調査中の拒否は、運用上の有用性を低下させる可能性がある。また、二重用途の支援が有害なガイダンスへ逸脱することを防ごうとするプロバイダーの取り組みを反映している可能性もある。
SecRespondは、このポリシー上のトレードオフを決着させるものではない。安全なデプロイには、認可されたフォレンジック作業と攻撃的な指示を区別するタスク定義が必要であることを示している。
ベンチマークの著者らは、公開された証拠は隔離環境に由来し、実行可能なエクスプロイトチェーンを含まないと述べている。公開資料は防御的な研究を目的としている。
この制約は、「現実世界」の対応に関する主張を解釈する際に重要となる。レンジは実際のネットワークプロトコルを介したエンドツーエンドの侵害を再現しているが、公開パッケージに含まれるのは、アクティブな攻撃ツールではなくサニタイズされたフォレンジック証拠である。
また、SecRespondのスコアが、分析担当者の時間短縮、インシデント深刻度の低下、または封じ込め速度の改善にどう結び付くかを示す独立したフィールド調査もない。これらの成果には、運用チーム内での評価が必要だ。
したがって、購入者にとっての正しい読み方は慎重なものとなる。このベンチマークは、自律的なインシデント対応に関する裏付けのない主張に強く疑問を呈している。一方で、人間主導のSOC内でAI支援に価値がないことを示すものではない。
また、特定の名前が挙げられたモデルが将来のバージョンでも優位を保つことを確立するものでもない。報告されたClaudeシリーズはリリースごとに改善した一方、他のファミリー全体での進歩は普遍的ではなかった。
評価における意味のある単位は、デプロイされたシステムである。そこにはモデル、ツール、プロンプト、権限、検索ソース、レビューゲート、ログ、復旧手順が含まれる。
SecRespondのGoogle Newsサイクル後に注目すべき3つのシグナル
次の試金石は、ベンダーがガイドなしの発見、修復の検証、再現可能な本番評価を改善できるかどうかだ。
第1のシグナルは、独立した再現だ。研究者やセキュリティベンダーは、他のハーネス、プロンプト、ツール、モデルバージョンを用いて、公開されたbenchmark repositoryを実行できる。
再現により、サイレント侵入のギャップがスキャフォールディングの変更後も残るかが分かる。専用のフォレンジックエージェントであってもアラートされていない永続化を見逃すなら、論文の中心的な判断はより強固になる。
決定論的な検索手順で大きな改善が得られるなら、教訓はやや変わる。ボトルネックはモデルの知識よりも、調査設計、ツールルーティング、強制されたカバレッジにあることになる。
それでも、汎用的な自律エージェントに関する主張は弱まる。同時に、より安全なシステムに向けた明確なエンジニアリングの道筋も得られる。
第2のシグナルは、ベンダーが検知結果と修復結果を分けて公開するかどうかだ。単一の「インシデント対応精度」という数値は、SecRespondが明らかにした計画のギャップを隠しかねない。
有用な評価では、システムが何を見つけ、何を見逃し、どのアクションを提案し、完了をどのように検証したかを示すべきだ。また、拒否、ツール障害、人間の介入を必要としたケースも報告すべきである。
特に永続化の仕組みに関するテストに注目したい。アラートに紐付いたマルウェアでの改善は重要だが、ベンチマークの主な盲点には対処していない。
計画がクリーンアップの範囲をカバーしているかも確認すべきだ。より強力なエージェントは、該当する場合に、プロセス、ファイル、アカウント、スケジュール実行、ネットワーク制御、認証情報のローテーション、サービス復旧、修復後の検証を扱うべきである。
第3のシグナルは、監督下にあるSOCデプロイからの証拠だ。ベンダーは、実際のテレメトリ、社内手順、アクセス制御、分析担当者の承認ゲートとともに、自社のエージェントがどのように機能するかを示す必要がある。
最も強力な運用上の証拠は、洗練されたケーススタディだけではない。見逃し率、エスカレーション率、裏付けのない主張、修正頻度、分析担当者が変更なしで承認する推奨事項の割合を含むものになる。
信頼できるデプロイでは、監査証跡を維持すべきだ。レビュー担当者は結論をアーティファクトまで追跡し、エージェントが停止する前にどの検索を完了したかを判断できる必要がある。
組織は権限の境界もテストすべきだ。読み取り専用の調査、推奨アクション、自律的な実行は、それぞれ異なる3つのリスク水準を表す。
SecRespondは最初の2つの水準での導入を支持する一方、3つ目には重い立証責任を課している。その結果は、包括的な発見を実証していないモデルに広範な封じ込め権限を委ねることを正当化しない。
Google Newsの見出しはやがて薄れるだろうが、このベンチマークはセキュリティチームに長く残る調達上の問いを投げかけている。アラートがどこを調べるべきかを示さないとき、エージェントは何を見つけられるのか。
ベンダーには、その問いに再現可能な証拠で答えるよう求めるべきだ。次に、システムが各クリーンアップ手順をどのように検証し、不確実性をどのように人間の対応担当者へ通知するのかを尋ねるべきである。
その答えは、AI SOC製品が調査担当者へと進化しているのか、それとも既存の検知を補う高速なアシスタントにとどまっているのかを明らかにする。現時点でSecRespondは、テスト対象となった23モデルすべてを、その境界線のアシスタント側に位置付けている。
