ExtraHopのAgentic SOC Alliance、AIサイバー防衛の共通ルール策定を目指す
ExtraHopは15社の創設メンバーとともにAgentic SOC Allianceを立ち上げ、自律的な対応をめぐる未解決の疑問を抱えながらも、共通のAI防衛アーキテクチャをGoogle Newsに打ち出した。この連合は、セキュリティエージェントがコンテキストを共有し、共通の統制に従い、AIモデルを切り替えられるようにすることを目指している。より困難なのは、競合ベンダーがこうした構想を信頼できる運用へと落とし込めることを証明する点だ。
このアライアンスの登場は、セキュリティチームがアラートの調査、システムへの問い合わせ、封じ込め措置の推奨を行えるエージェントを試験している時期と重なる。ExtraHopは、従来のセキュリティオペレーションセンターが、依然として人間のアナリスト向けに設計されたキューを介して動いていると主張する。同社が提案する代替案では、はるかに高速に作業できるAIモデルを、継続的に更新される証拠とポリシー統制で囲む。
この期待が中心的な対立を生む。ベンダーはマシン速度での調査と対応を望む一方、セキュリティ責任者はそのマシンが誤った判断をした場合も説明責任を負う。NIST、MITRE、OWASPによる既存の取り組みは、すでに重要なAIリスクを示している。このアライアンスは、さらに重複するフレームワークを増やすのではなく、なぜ新たな業界ブループリントが相互運用性を改善するのかを示さなければならない。
Agentic SOC Allianceは3層のブループリントを提案している
この発表が重要なのは、ExtraHopが単一のモデルや製品ではなく、セキュリティエージェントを取り巻く運用環境の標準化を試みているからだ。
ExtraHopは2026年7月22日、Agentic SOC Allianceを発表した。この取り組みは、ネットワーク検知、エンドポイントセキュリティ、調査、自動化、エージェント開発にまたがる15社で始まった。
創設グループには、AuthMind、Armadin、Command Zero、CrowdStrike、Dropzone AI、Exaforce、ExtraHop、Fig、Intezer、Kindo、LangChain、Prophet Security、ReversingLabs、TENEX.AI、Torqが名を連ねる。これらの企業が参加することで、このプロジェクトは緊密に統合された2製品間の提携よりも広い領域をカバーする。
アライアンスの3層提案では、自律型セキュリティオペレーションセンターをContext、Harness、Modelの各層に分ける。各層は、エージェント型サイバー防衛を支える異なる依存関係に対応する。
Contextは、エージェントが組織を理解するために利用する証拠である。ExtraHopはこれを、デバイス、ID、ワークロード、接続、行動を対象とする、継続的に更新される運用ナレッジグラフと説明している。
ナレッジグラフは、エンティティとその関係性を構造化して表現するものだ。この設計では、個別のログエントリからインシデントを再構築することなく、エージェントが関連する証拠を見つける助けとなるはずだ。
Harnessは、エージェントの作業方法を統括する。オーケストレーション、状態、メモリ、ツールアクセス、権限、承認ポイント、監査記録を管理する。
この層は安全性の責任の大部分を担う。たとえばモデルがエンドポイントの隔離を提案しても、そのアクションを自動実行できるかどうかを決めるのはHarnessだ。
Modelは、トリアージ、調査、対応における推論を担う。アライアンスはこのコンポーネントを交換可能なものと位置付け、組織が周辺の統制やデータ接続を再構築することなくモデルを変更できるようにする。
この分離は戦略的に重要だ。モデルの性能は急速に変化する一方で、セキュリティ統合、アクセス方針、監査要件は通常、はるかに長く存続する。
そのためExtraHopは、Context層とHarness層は持続可能であるべきだとしている。購入者は、確立済みの証拠とガバナンスを維持しながら、新しいモデルを導入したり、複数の専門モデルを利用したりできる。
これはアーキテクチャの提案であり、完成した標準ではない。創設時の発表では、独立した認証プログラム、公開された適合性テスト、または加盟企業の製品全体にわたる測定済みの本番成果は提示されていない。
ExtraHopのCEOであるGreg Clarkは、この取り組みを出発点と表現し、より幅広い業界の参加を呼びかけた。この留保は重要だ。アライアンスには、ベンダー主導の設計を共有の技術成果物へと変換する必要が依然としてあるためだ。
この違いは、Google Newsの短い要約では見えなくなることがある。この連合は方向性には合意しているが、自律型サイバー防衛に関する普遍的に受け入れられたルールをまだ確立していない。
Google Newsで注目されても標準になるわけではない
可視性は貢献者やエンタープライズ購入者を引きつけ得るが、ニュースフィードで繰り返し取り上げられることは、アーキテクチャ、安全性、相互運用性を検証するものではない。
元のForbes記事は、AI規制とセキュリティのフィードを通じてGoogle Newsの読者に届いた。この配信は、アライアンスが依然として民間の業界イニシアチブであるにもかかわらず、提案に政策志向の枠組みを与えた。
標準には通常、共有図以上のものが必要となる。実装者には、正確なインターフェース、共通の用語、テストケース、失敗の定義、バージョニングのルール、意見の相違を解決するためのガバナンスプロセスが必要だ。
アライアンスの現行の表現は、要件、ベストプラクティス、実装ブループリントを重視している。これらの成果物は有用になり得るが、その価値は加盟企業がどの程度オープンに公開し、検証するかにかかっている。
このプロジェクトは、成熟した公開フレームワークとも並行して存在する。NISTのAIリスクフレームワークは、AIガバナンスをリスクの測定、マッピング、管理、統治を軸に整理している。
NISTは単一のセキュリティ運用アーキテクチャを規定していない。代わりに、組織が自らのシステム、責任、害への許容度に応じて適用できる成果を示している。
MITRE ATLASは異なる目的を果たす。そのエージェント脅威カタログは、演習や実際のインシデントから得られた観察を用い、AI対応システムを標的とする敵対的な戦術と技術を記録している。
OWASPも、モデル、ツール、メモリ、外部データを中心に構築されたアプリケーションにおけるリスクを扱っている。これらのリソースは、AIシステム自体がどのように操作され得るかに強く焦点を当てている。
Agentic SOC Allianceは別の層を対象としている。エンタープライズを防御する際に、複数のセキュリティ製品とエージェントがどのように協働すべきかを問うものだ。
この焦点は公開フレームワークを補完し得る。Context、Harness、Modelはシステム構造を表し、NISTとMITREはチームがガバナンス上の成果と脅威パターンを特定する助けとなる。
ただし、重複は実務上の負担を生む。セキュリティ責任者はすでに、規制上の義務、NISTのガイダンス、MITRE ATT&CK、MITRE ATLAS、ベンダー固有のプラットフォームにまたがって統制を対応付けている。
別のフレームワークが注目を集めるのは、統合作業を減らす場合に限られる。加盟企業が同じラベルを用いても、互換性のない権限や証拠形式を実装するなら、そのアーキテクチャはマーケティング用の語彙になってしまう。
したがって、ベンダーの多様性はアライアンスの強みであると同時に試練でもある。CrowdStrikeはエンドポイントとクラウドのテレメトリを通じてSOCに取り組む一方、ExtraHopはネットワーク由来のコンテキストを重視している。
AIネイティブの調査企業は、メモリ、推論、自動化ワークフローについて別の前提を持ち込む。オーケストレーションベンダーも、承認、アクション、ロールバックの表現方法で異なる。
信頼できるブループリントは、こうした違いを維持しながら、それらの境界を定義しなければならない。各境界を越えてどのデータが移動するのか、誰がその移動を承認するのか、別の製品がそれをどのように検証するのかを説明すべきだ。
公開時点の発表は、まだプロトコルレベルではこれらの疑問に答えていない。購入者はGoogle Newsでの可視性を、作業を注視するための招待と捉えるべきであり、作業が完了した証拠とみなすべきではない。
真の争点は自律的な速度と説明責任ある統制の両立だ
アライアンスは、エージェントを高速化しつつ、その行動を人間の権限、証拠、組織的責任から切り離さないようにしなければならない。
ExtraHopは、一般的なキュー処理・エンリッチメント・トリアージ・調査・エスカレーションのワークフローは、人間の速度で動く脅威のために設計されたものだと主張する。同社によれば、攻撃者は現在、偵察、エクスプロイト開発、横展開を数分以内に自動化できる。
これらの主張は現実の運用上の圧力を示しているが、同時に同社のアーキテクチャを支持する論拠の一部でもある。アライアンスは、自らのモデルが確立されたSOCワークフローを上回ることを示す比較測定値を公開していない。
それでも速度は重要だ。対応が遅れれば、攻撃者は認証情報を盗み、追加のシステムに到達し、データを損なう時間をより多く得る。
セキュリティチームは大量のアラートにも直面している。エージェントは、関連する証拠を収集し、明白な誤検知を除外し、攻撃経路を要約し、アナリストがケースを開く前にアクションを提案できる可能性がある。
たとえば、侵害された従業員IDが未知のワークロードに接続している状況を考えてみよう。エージェントは、IDイベント、エンドポイント活動、ネットワークセッション、資産所有情報、脅威インテリジェンスを1件の調査に統合できるかもしれない。
Context層は、その証拠を構造化された形で提供する。Modelが考えられる説明について推論し、Harnessがエージェントが呼び出せるツールを制御する。
この一連の流れは設計の魅力を示している。同時に、すべてのコンポーネントが前段を信頼するとき、誤った判断がいかに迅速に伝播し得るかも示している。
コンテキストには、古い資産所有情報や不完全なIDデータが含まれる可能性がある。攻撃者がエージェントの取得するコンテンツを操作し、モデルが誤解を招く指示に従うよう仕向けることもあり得る。
モデルは弱い指標に過度の確信を与える可能性がある。その場合、Harnessはアクションが誤って構成された承認しきい値を下回るという理由で、封じ込めを許可するかもしれない。
人間のアナリストも同様のミスを犯し得るが、自律型システムでは速度と規模が変わる。欠陥のあるルールが1つあるだけで、レビュー担当者がそのパターンを認識する前に、多くの調査へ影響を及ぼし得る。
このため、無制限の自律性よりも、統制された自律性の方が有用だ。影響の小さいアクションは自動で進められる一方、破壊的な手順や事業上重要な手順にはより強い承認が必要となる。
エージェントは、承認なしにテレメトリを検索し、証拠を相関付け、ケースの草案を作成できる。IDの無効化、本番サーバーの隔離、クラウドリソースの削除には、より厳格な統制が必要だ。
アライアンスのHarness層は、この区別を支援することを意図しているように見える。しかし有用なブループリントには、製品がアクションリスク、ID、対象範囲、承認状況をどのように表現するかを定義する必要がある。
また、エージェント間で見解が分かれた場合に何が起こるかも規定しなければならない。あるモデルは行動を悪意あるものと分類する一方、別のモデルは承認済みの保守作業の証拠を見つけるかもしれない。
組織には、この対立を解決するためのポリシーが必要だ。また、各観察、推論、ツール呼び出し、承認、最終アクションを示す永続的な記録も必要となる。
NISTのフレームワークは、組織が人間とAIの構成に関する責任を定義すべきだとしている。このガイダンスはアライアンスのガバナンス目標を支える一方、説明責任の基準を引き上げる。
マシン速度の防衛は、追跡不能な判断の言い訳になってはならない。対応者が正当なサービスをなぜ中断したのか説明できないなら、最速のシステムでもより安全とはいえない。
交換可能なモデルは信頼できるコンテキストに依存する
モデルを置き換え可能なものとして扱うのは合理的だが、推論エンジンが変わってもコンテキストと統制が一貫している場合に限られる。
アライアンスが下した最も重要な選択は、長期的な価値をモデルの外部に置くことだ。これは、セキュリティワークフローを単一の独自モデルに密接に結び付ける戦略に挑戦するものだ。
モデルは、ツール利用、指示への追従、コンテキストの処理、レイテンシー、エラーパターンにおいて異なる。そのため、1つのコンポーネントを更新するだけでも、エージェントが同じ証拠を解釈する方法は変わり得る。
Harnessは、こうした違いを吸収する必要がある。ツールを一貫した形で提示し、引数を制約し、出力を検証し、ポリシーを超えるアクションを阻止しなければならない。
Contextレイヤーも同様に厳しい役割を担う。セキュリティの証拠は、スキーマ、タイムスタンプ、識別子、保持ポリシー、信頼度が異なる製品からもたらされる。
エンドポイントツールは、1つのデバイスレコードによってノートPCを識別するかもしれない。ネットワークプラットフォームは変化するアドレスを通じて同じマシンを観測し、IDシステムはそのユーザーを別途追跡する可能性がある。
ナレッジグラフは、不確実性を隠すことなく、これらのレコードを照合しなければならない。2つの資産を誤って統合すれば、エージェントは誤ったデバイスを基に説得力のある調査を組み立ててしまう可能性がある。
そのため、プロベナンスは不可欠だ。重要な事実にはすべて、情報源、観測時点、エンティティへの対応付けに関する信頼度の情報を保持すべきである。
鮮度も重要である。先月記録されたデバイス所有者が、現在の利用者とは限らない。とりわけ共有環境や頻繁に再イメージ化される環境ではそうだ。
セマンティックな詳細はエージェントの推論を助ける一方、誤った確信を生む可能性もある。上流コネクターが不完全なデータを供給していても、構造化情報は権威的に見える。
アライアンスのメンバーは、欠落している、争いのある、期限切れの証拠をシステムがどのように表現するかを定義すべきである。空白の値が、否定的な検出結果へと暗黙に変換されてはならない。
Modelレイヤーは、さらに別の複雑さを加える。セキュリティチームは、性能向上の検証、ポリシー変更、ライセンス上の懸念、新たに発見された脆弱性を理由に、モデルを置き換える可能性がある。
置き換え後のモデルが自動的に信頼を引き継ぐべきではない。組織のツール、データ、攻撃パターン、禁止アクションに照らした評価が必要である。
Harnessは権限を維持できるが、権限だけでは同等の振る舞いは保証されない。2つのモデルは、同一のアクセス境界内で動作していても、曖昧な指示を異なる形で解釈し得る。
だからこそ、適合性テストでは接続だけでなく結果を測定しなければならない。テストには、プロンプトインジェクション、汚染されたコンテキスト、矛盾する証拠、利用不能なツール、不完全なテレメトリーを含めるべきである。
また、システムが安全に停止するかも測定すべきだ。資産の識別を確立できないエージェントは、封じ込め対象を即興で決めるのではなく、不確実性をエスカレーションしなければならない。
MITREは、エージェント型AIおよび大規模言語モデルの脅威に関するATLASのカバレッジを拡大している。これらのシナリオは、アライアンスの3レイヤーにまたがる敵対的テストの有用な基盤となる。
NISTは別途、agent security inquiryに関する意見を募集している。この照会は、エージェントが実環境に影響する計画立案やアクションを実行できることを明確に認識している。
アライアンスは、これらのリスクをSOC固有の相互運用性テストへと翻訳することで価値を加えられる。この取り組みは、マシン速度の防御に関する大まかな主張よりも説得力があるだろう。
ベンダー協力はベンダーのインセンティブをなくさない
ベンダー連合は有用な慣行を生み出せるが、買い手には、創設メンバーが自社製品の強みに合わせてオープン性を定義することを防ぐガバナンスが必要だ。
ExtraHopはネットワークインテリジェンスを提供し、構造化されたリアルタイムコンテキストをアーキテクチャの基盤として位置付けている。この立場は当然ながら、設計図をExtraHopの商業的強みと整合させる。
CrowdStrikeはエンドポイントおよびクラウドのコンテキストを提供する。他のメンバーは、調査エージェント、オーケストレーション、ID分析、マルウェアインテリジェンス、開発フレームワークを提供する。
各参加者は、共有アーキテクチャが自社のカテゴリーを不可欠なものとして扱えば利益を得る。これは取り組みの価値を否定するものではないが、買い手が認識すべきインセンティブを生む。
真にオープンな設計であれば、非加盟者も必要なすべてのインターフェースを実装できるべきである。重要なコンテキスト、ポリシー、テストの仕組みを、アライアンスが管理する製品だけに留保してはならない。
ドキュメントにも利用しやすい変更プロセスが必要だ。定義を承認できるのが創設ベンダーだけなら、このプロジェクトは業界標準ではなくパートナーシップ仕様のままである。
連合は、意思決定の方法、異議の記録方法、組織の参加方法を公開すべきである。また、技術成果物の所有権とライセンスについても明確にすべきだ。
独立した実装も、もう1つの重要なシグナルである。非加盟者が、非公開のエンジニアリング支援なしに、互換性のあるContextプロバイダー、Harness、またはModelを接続できるべきだ。
それにより、アライアンスによる交換可能なコンポーネントという約束を検証できる。また、創設ベンダーが共に統合を構築する際には見えなくなる、隠れた前提も明らかになる。
複数の主要プラットフォームプロバイダーが不在であることは注目に値するが、それだけで直ちに失格となるわけではない。エンタープライズSOCは、多くの場合Microsoft、Google Cloud、Palo Alto Networks、Splunk、その他の幅広いプラットフォームに依存している。
これらの製品はすでに、テレメトリー形式、ID制御、ケース管理、対応ワークフローを形作っている。共有アーキテクチャが影響力を得るのは、こうした既存環境を横断して機能する場合に限られる。
アライアンスのガバナンスには、セキュリティの買い手、インシデント対応担当者、監査人、保険会社も必要である。誤った自律アクションがもたらす運用上の結果を負うのは、ベンダーだけではない。
顧客の参加により、リスク閾値をより現実的にできる。金融機関とソフトウェア開発企業では、同じ技術的指標を観測しても、許容するアクションが異なる可能性がある。
規制対象の組織は、監査や調査のために証拠を保存しなければならない。その要件は、Harnessが説明責任に必要な詳細を十分に記録しているかを明らかにできる。
FiservのCISOであるJason Dewezは、ローンチ発表でリアルタイムのネットワークおよびエンドポイントテレメトリーの必要性を支持した。彼の存在は、この提案にエンタープライズ実務家の視点を与えている。
それでも、支持する顧客の声が1つあるだけでは、幅広い検証の代わりにはならない。アライアンスには、異なるシステム、リスク許容度、法的義務を持つ組織全体での実装が必要である。
独立した研究者も、アーキテクチャの失敗モードをテストすべきである。公開された調査結果は、買い手が文書化された統制と敵対的な圧力に耐える統制を区別する助けとなる。
AIサイバー防御のルールをめぐるForbesの枠組みは、連合の野心を捉えている。直近の現実はより限定的だ。ベンダーは共通の運用モデルを提案し、それを検証することで合意した。
野心と証拠の間にあるその隔たりこそが、この物語である。そして、それこそがこの取り組みを評価すべき基準でもある。
設計図が機能するかを示す3つのシグナル
公開仕様、敵対的な相互運用性テスト、顧客が管理する導入が、アライアンスがインフラストラクチャーになるのか、ベンダーキャンペーンのままなのかを決定する。
第1のシグナルは、詳細な公開仕様である。ID、認可、プロベナンス、エラー処理を含め、Context、Harness、Modelの各コンポーネント間のインターフェースを定義すべきだ。
仕様は、ツールが能力とリスクをどのように宣言するかを説明すべきである。また、承認状態、監査イベント、モデル変更、ポリシー適用についても記述すべきだ。
バージョニングが重要になる。別のベンダーがソフトウェアやデータ表現を更新した後も、コンポーネントが互換性を保つかをセキュリティチームは知る必要がある。
オープンなドキュメントは、アライアンスの主張を強化する。パートナー間だけで共有される非公開の実装ガイドでは、その主張を弱めることになる。
第2のシグナルは、複数のメンバー製品にまたがる敵対的テストである。アライアンスは、侵害されたコンテキスト、プロンプトインジェクション、過剰な権限、エージェントの結論の矛盾を対象とする、再現可能な評価を公開すべきだ。
テストには通常の運用障害も含めるべきである。テレメトリーの欠落、期限切れの認証情報、遅延したコネクター、重複した資産レコードは、攻撃者が能動的に関与していなくても調査を妨げる可能性がある。
結果には測定可能なアウトカムが必要だ。検知速度は重要だが、誤った封じ込め率、裏付けのない結論、エスカレーションの品質、失敗したアクションからの復旧も重要である。
有用な評価では、同じContextとHarnessの下で複数のモデル選択肢を比較する。これにより、Modelレイヤーが本当に交換可能かを検証できる。
また、1つのContextプロバイダーまたはオーケストレーションコンポーネントを置き換えるべきである。アーキテクチャが優先された組み合わせでしか機能しないなら、モジュール性の主張は弱くなる。
第3のシグナルは、顧客が管理する本番導入である。組織は、自らの自律性レベル、アクションポリシー、証拠要件、承認チェーンを設定できるべきだ。
初期導入では、助言にとどまるアクションと自動実行できるアクションを明らかにすべきである。自律運用に関する広範な主張は、こうした境界がなければほとんど意味を持たない。
買い手は、エージェントがエンドポイントを隔離し、IDを無効化し、ファイアウォールを変更し、トークンを取り消し、クラウド設定を変更できるかを問うべきである。各権限は、エラーがもたらし得る影響を変える。
また、システムがロールバックをどのように処理するかも問うべきだ。アクションを阻止することは重要だが、誤ったアクションが本番環境に到達した後は、復旧が不可欠になる。
Google Newsの話題は、これらの疑問に完全な答えが出る前に移り変わるだろう。セキュリティリーダーは、メディアの勢いを購買期限として扱うことに抵抗すべきである。
その代わりに、チームはこの提案を現在のアーキテクチャに照らしてマッピングできる。証拠が断片化されたままの箇所、承認が遅延を生む箇所、エージェントがすでに重要な権限を持つ箇所を特定できる。
エージェント型システムを評価する組織には、ポリシー、インシデント、技術的判断に関する検索可能な社内記録も必要だ。適切に維持されたエンジニアリングナレッジベースはレビューを支援できるが、SOCテレメトリーやアクセス制御の代替にはならない。
Agentic SOC Allianceは、適切なカテゴリーの問題を選んだ。セキュリティエージェントには、共有された証拠、制約されたツール、交換可能な推論、監査可能な意思決定が必要である。
次の段階では、アーキテクチャ上の言葉を検証可能な成果物に置き換えなければならない。メンバーが仕様を公開し、敵対的テストを乗り越え、独立した実装を支援すれば、この取り組みはオープン性の主張を強めるだろう。
そうしたシグナルが届かなければ、3つのレイヤーは強制可能なルールではなく、有用な図のままにとどまる。したがって最も重要な問いは実践的なものだ。セキュリティの買い手は、エージェントに実システムへの権限を与える前に、証拠を求めるだろうか。
