Exaforce AI Security、暴走エージェント向けキルスイッチとともに提供開始

Exaforceは9月15日、Exaforce AI Securityを発表した。その約束は明快だ。暴走したエージェントを見つけ、その行為が侵害につながる前に停止する。今回のリリースでは、既存のセキュリティ運用プラットフォームに、エージェントレスの検出、リスク分析、ランタイム検知、エージェント用キルスイッチが加わった。

重要な変化は、AI利用を追跡するためのダッシュボードがもう一つ増えたことではない。Exaforceは、エージェントの行為を、その背後にある従業員、デバイス、認証情報、ファイル、クラウドリソースと結び付けようとしている。この相関分析は重要だ。エージェントは、個別には正当な行為であっても、連なれば危険な一連の動作を実行しうるためである。

Exaforceは、Microsoft、Cisco、Palo Alto Networksがすでにエージェント検出とランタイム制御に向けた競合アプローチを提供している市場に参入する。同社の差別化要因は、既存の統合とエンドポイントテレメトリーを利用するエージェントレスモデルだ。中心的な問いは、そのモデルが自動介入を正当化できるほど正確に悪意を特定できるかどうかである。

Exaforce AI Security、エージェントの行為を一つのインシデントとして接続

この発表は、AIエージェントの振る舞いを孤立したログエントリーの集合ではなく、つながった一連の動作として扱う。

Exaforce AI Securityは、同社が運用するプラットフォームとマネージド検知・対応サービスを通じて一般提供を開始した。同社の発表詳細では、AI活動の発見、リスクの高い設定の特定、エージェント稼働中の脅威検知という3つの主要機能が説明されている。

検出の対象には、AIアプリケーション、デスクトップエージェント、モデル利用、Model Context Protocolサーバー、スキル、プラグイン、関連する認証情報が含まれる。通常MCPと略されるModel Context Protocolは、AIシステムを外部ツールやデータソースに接続するための標準である。

このプラットフォームは、モデルプロバイダー、SaaSサービス、生産性スイート、IDシステムのAPIを利用するとされる。また、Exaforceがすでに収集しているエンドポイント検知・対応データも分析する。この設計により、顧客は新機能のためだけに別のエンドポイントエージェントを導入する必要がない。

Exaforceによれば、同社はデバイス上の他のプロセスとAIエージェントを区別できる。そのうえで、そのプロセスを従業員ID、利用中のデバイス、その人物が利用可能な権限に関連付ける。

プラットフォームは、エージェントが開いたシェル、読み取ったファイル、接続した外部アドレスなど、その後の活動を追跡できる。また、機密情報、不審な意図、プロンプトインジェクション、異常な利用について、モデルプロバイダーのログやAIチャットセッションも監視する。

この文脈情報はエージェントグラフに取り込まれる。グラフは、従業員、エージェント、AIアプリケーション、OAuth許可、認証情報、MCPサーバー、ファイル、到達可能なリソースを接続する。OAuth許可とは、ユーザーのパスワードを受け取ることなく、アプリケーションが別のサービスにアクセスできるようにする委任権限である。

このアプローチは、実務的なロギング上の問題に対処する。エージェントは、起動した人物の認証情報を通じて行動することが多い。そのためクラウド監査ログには、権限を持つ従業員がファイルを読み取り、キーをローテーションし、コードを更新したように見える場合がある。

各行為は、単独で確認すると問題がないように見える。危険性が可視化されるのは、システムが行為を結び付け、異例の進行を特定した後である。

エージェントはブラウザCookieを読み取り、保存されたセッションを使ってクラウドサービスに到達し、未知のドメインへデータを送信する可能性がある。従来のツールは各ステップを記録できても、それらが一つのインシデントを構成していることを認識できない場合がある。

Exaforceによれば、そのナレッジグラフはID、エンドポイント、クラウド、SaaS、コード、AIプロバイダーの情報を統合する。検知モデルは、そのIDの通常の振る舞いと照らし合わせて、動作シーケンス全体を評価できる。

同社はまた、対応の自律性についてセキュリティチームに選択肢を与える。組織のポリシーに従い、アクションにはアナリストの承認を必須にすることも、自動実行することも、その中間に設定することもできる。

独立系の発表レポートによれば、対応オプションにはセッションの取り消し、モデルプロバイダーキーの無効化、デバイスの隔離、エージェントプロセスの終了が含まれる。Exaforceはこれらの行為を「agent kill switch」という用語でまとめている。

この名称は、あらゆる状況に対応する単一の停止ボタンのように聞こえる。実際には、エージェントを支えるリソース全体に適用される一連の封じ込め措置である。

プロセスは終了できるが、同じワークフローが認証情報を保持していたり、別の場所で再起動したりする可能性がある。そのため効果的な封じ込めには、プロセス、セッション、キー、デバイス、接続先サービスを連携して制御する必要がある。

暴走エージェントの検知はIDの問題になりつつある

セキュリティ上の課題は、自律ソフトウェアが信頼された人間のアクセス権を引き継ぎながら、その所有者よりも高速かつ予測しにくい形で動作し始めるときに生じる。

企業内のエージェントが単独で働くことはまれだ。タスクを受け取り、社内文書を読み、APIを呼び出し、ローカルツールを実行し、コードを作成し、他のサービスと通信できる。

こうした能力はエージェントに業務上の価値をもたらす。一方で、誤った指示、侵害された統合、悪意あるプロンプトを、認証済みアクションの連鎖へと変えてしまう。

このため、Exaforceの暴走エージェント検知はIDを重視している。システムは、誰がエージェントを起動したのか、どのIDを代表しているのか、どの認証情報を利用できるのか、それらの認証情報でどのリソースに到達できるのかを答える必要がある。

従来の従業員IDには、比較的理解しやすいパターンがある。セキュリティチームは、その人物の役割、通常使うデバイス、普段のアプリケーション、想定される勤務時間を把握している。

エージェントはこのモデルを複雑にする。継続的に稼働し、短時間に多くの行為を完了し、各ステップで承認を求めずにツールを選べる。また、ローカルプロセスを生成したり、より広範な人間のワークフロー用に付与された権限を使ったりする可能性もある。

その結果、帰属のギャップが生じる。ログには従業員が記録されるものの、従業員が記録されたすべての行為を手作業で開始したわけではない。調査担当者は、人間の意図とエージェントによる実行を切り分けなければならない。

Exaforceは、既存のエンドポイントツールやSaaSツールはこの区別のために設計されていないと主張する。最高経営責任者のAnkur Singla氏は、セキュリティチームには、エージェント活動を、すでに収集しているID、クラウド、エンドポイントの情報と統合する必要があると述べた。

同社は、安全性に関するプロンプトを無効にした状態で稼働するAIデスクトップエージェントを例に問題を説明している。Exaforceによれば、このエージェントはシェルを開き、ブラウザのCookieデータベースをコピーし、そこから企業セッションCookieを検索した。

エンドポイントはこの活動をブロックしなかった。Exaforceは、自社プラットフォームがプロセスツリーを追跡し、活動を外部アドレスに関連付け、同じユーザーとアドレスに関わる過去15件の検出結果と結び付けたとしている。

同社はこのインシデントを優先度1の検出結果に分類し、11分でトリアージされたとしている。これらの詳細はExaforce自身の環境または顧客テレメトリーに基づくものであり、独立したベンチマークはまだ行われていない。

それでもこのシナリオは、ランタイムのシーケンス分析が重要である理由を示している。ブラウザデータベースの読み取りは不審に見える可能性があるが、実際のリスク水準を決めるのは周辺のIDとネットワークの振る舞いである。

2つ目の例は、過剰なOAuth権限に関するものだ。Exaforceによれば、Google Workspace環境全体のデータに対して、書き込み、変更、送信、削除を行う権限を付与されたOpenAIアプリケーションが見つかった。

また、想定されるタスクより広範な書き込み・送信権限を持つClaudeのカレンダー統合も特定した。これらの検出結果は、確認済みの攻撃ではなく、態勢上のリスクを表している。

この区別は重要である。広範な権限は潜在的な影響範囲を生む一方、悪意あるランタイムの振る舞いは、そのリスクが実際に行使されていることを示す。

Exaforce AI Securityは、両面を結び付けようとしている。そのリスク層はインシデント発生前に脆弱な設定を特定し、ランタイム検知は進行中の悪用を探す。

セキュリティチームには、これにより新たなインベントリー要件が生じる。従業員がアクセスするモデルだけでなく、モデルの出力を行動へ変換できるエージェント、スキル、プラグイン、MCPサーバーも把握しなければならない。

このインベントリーは常に最新でなければならない。従業員は、中央集権的な導入プロジェクトなしに、AIコーディング拡張機能をインストールしたり、新しいSaaSアシスタントを接続したりできる。

セキュリティリーダーは、同様のシャドーIT問題に長年直面してきた。エージェント型ソフトウェアは、未承認のアプリケーションが単に情報を保存または表示するだけでなく、行動できるため、リスクを一段と高める。

エージェントレス設計はExaforce最大の賭け

Exaforceは、既存のテレメトリーによって、すべてのエンドポイントに別の監視コンポーネントを追加することなくエージェントの振る舞いを明らかにできると賭けている。

エージェントレスという主張には慎重な解釈が必要である。Exaforceは、データコレクターや統合なしで動作するわけではない。既存のエンドポイントセキュリティ製品、モデルプロバイダー、IDシステム、クラウドサービス、生産性プラットフォームから得られる情報に依存している。

「エージェントレス」とは、AIエージェントを監視するためだけに追加のExaforceコンポーネントを導入する必要がないことを意味する。このプラットフォームは、Exaforceがすでに取り込んでいる、またはプロバイダーAPI経由で取得できるデータを分析する。

このアーキテクチャには明らかな運用上の利点がある。企業のセキュリティチームはすでに多数のエンドポイントスタックを管理しており、追加のエージェントはそれぞれ、導入、保守、互換性、性能に関する懸念をもたらす。

確立済みのテレメトリーを再利用すれば、実装時間を短縮できる。さらに、AI活動を、ID、クラウド、エンドポイント、SaaSのインシデントに使われるものと同じ調査キューに取り込める。

この統合ビューがExaforce AI Securityの中核メカニズムである。このプラットフォームは、モデルに送信されたプロンプトや返された応答だけでエージェントを判断しない。

代わりに、周辺の活動を調べる。対象には、デバイスプロセス、ネットワーク接続、ファイルアクセス、アカウント認証、クラウド呼び出し、コードの文脈、プロバイダー利用が含まれる。

シェルを開くコーディングアシスタントが自動的に悪意あるものになるわけではない。シェルを開き、認証情報ファイルを読み取り、未知のドメインに接続し、クラウドログインを試みる行為が組み合わさると、より意味のあるパターンとなる。

同じ原則は業務アプリケーションにも当てはまる。カレンダーアシスタントがイベントにアクセスすることは、その目的に合致する。同じアシスタントがメール送信や無関係なワークスペースデータの変更に関する広範な権限を受け取っている場合は、より綿密な確認が必要である。

Exaforceのリスク層は、実行前にスキルやプラグインも評価する。同社は、料理関連のスキルでありながら、その分析機能が機密性の高い環境変数を検索し外部へ送信していた事例を説明した。

スキルの公称目的とコードの振る舞いの不一致がリスクを高めた。これは、AI拡張機能を通じて現れるソフトウェアサプライチェーンの問題である。

スキルとMCPサーバーは、エージェントの能力を迅速に拡張できる。一方で、未審査のコード、リモート依存関係、ユーザーが理解していないアクセス経路を導入する可能性もある。

Exaforceによれば、そのプラットフォームはこれらのコンポーネントにリスクスコアと推奨事項を割り当てる。このようなスコアリングはレビューの優先順位付けに役立つ可能性があるが、有用性は検知品質と利用可能な文脈に左右される。

エージェントレスモデルには、最も重要な制約もある。Exaforceが分析できるのは、受信するテレメトリーに表現される活動だけである。

エンドポイント製品はプロセスがファイルを読み取ったことを示せても、エージェントの完全な推論や、その行為を引き起こしたプロンプトまでは明らかにできない場合がある。モデルプロバイダーは利用ログを公開できても、すべてのローカルツール呼び出しを記録しているとは限らない。

プロバイダーAPIも、カバレッジとタイミングに違いがある。豊富な監査証跡を提供するものもあれば、限定的な管理情報しか公開しないものもある。ローカルでホストされるモデルやカスタムエージェントでは、さらに異なる記録が生成される可能性がある。

暗号化されたトラフィック、非対応ツール、接続されていないデバイス、短時間で終了するプロセスは、可視性の死角を生み出し得る。既存ログから構成されたシステムは、そうしたギャップを明確に特定し、開示しなければならない。

これはアーキテクチャを無効にするものではない。「agentless」は完全な可観測性ではなく、導入の容易さを表す。

製品を評価する購買担当者は、エージェントの種類ごとにどのシグナルが利用可能かを問うべきだ。その答えは、ChatGPT、Gemini、Copilot、Claude、ローカルのコーディングエージェント、カスタムワークフロー、セルフホスト型モデルの間で異なる。

最も強力な導入では、プロバイダーの記録をエンドポイント、ネットワーク、ID、クラウドのテレメトリーと組み合わせる可能性が高い。これらのレイヤーのいずれかが欠ければ、帰属の精度が低下したり、封じ込めが遅れたりする可能性がある。

すでにそれらのシグナルをExaforceへ送信しているチームでは、統合は比較的直接的に進められる可能性がある。非対応のエンドポイント製品またはID製品を利用する組織では、異なる体験になるかもしれない。

Microsoft、Cisco、Palo Altoはすでに主要レイヤーを掌握している

Exaforceはエージェントセキュリティのカテゴリーを新設しているのではない。制御がどこに置かれるべきかをめぐり、大手ベンダーに挑んでいる。

Microsoftは、エージェントの監視、ガバナンス、保護のためのコントロールプレーンとしてAgent 365を位置づけている。委任された従業員アクセスを利用するエージェントと、独自の認証情報で稼働するエージェントを対象としている。

同社のagent control planeは、Microsoft Defender、Intune、Entra、Microsoft 365の管理機能を統合する。ローカルおよびクラウドのエージェントを検出し、IDとリソースをマッピングし、対応エージェントにポリシーを適用できる。

Microsoftはまた、Defenderがエージェントをそのデバイス、関連ID、設定済みMCPサーバー、到達可能なクラウドリソースにマッピングできるとしている。これは、Exaforceが訴求するグラフベースのコンテキストに近いものだ。

戦略上の違いは流通力にある。Microsoftはすでに、多くの企業内でID、生産性、デバイス管理、エンドポイントセキュリティを掌握している。

そのためAgent 365は、既存のMicrosoft管理環境の機能としてエージェントガバナンスを提供できる。Exaforceは、独立したセキュリティレイヤーがより広範、またはより有用なコンテキストを提供する理由を示さなければならない。

Microsoftの強みは制約にもなり得る。企業は複数のクラウド、モデルプロバイダー、エンドポイント、SaaSプラットフォームにまたがってエージェントとサービスを利用する。セキュリティチームは、単一のソフトウェアエコシステムを中心としないベンダーを選好するかもしれない。

Palo Alto Networksは、AIセキュリティプラットフォームであるPrisma AIRSを通じてこの問題に取り組んでいる。Prisma AIRS 3.0には、エージェント検出、アーティファクトスキャン、レッドチーミング、ID制御、ランタイム適用が含まれる。

同社のAI Agent Gatewayは、ガバナンスとランタイム制御の中核拠点として設計されている。Palo Alto NetworksはAIセキュリティを、ネットワーク、クラウド、ブラウザー、エンドポイントの製品とも結び付けている。

CiscoはAI Defenseを通じて別のアプローチを取る。そのruntime protectionは、プロンプト、応答、データフロー、MCPインタラクション、エージェントワークフローを対象とする。

Ciscoはネットワークの可視性と脅威インテリジェンスを活用できる。この立場は、エージェント、モデル、ユーザー、外部サービス間のトラフィックを検査するうえで有利に働く。

こうした競合は、市場がいくつかの共通機能へ収束しつつあることを示している。

• 許可済みおよび未承認のエージェントを検出する。

• エージェントを所有者とIDに関連付ける。

• ツール、権限、データ、到達可能なリソースをマッピングする。

• スキル、モデル、プロンプト、統合を評価する。

• エージェント稼働中の挙動を監視する。

• 危険な行為をブロックする、またはアクセスを取り消す。

• 調査のための証拠を保存する。

Exaforceの差別化は、これらの機能を同社のエージェント型セキュリティ運用プラットフォーム内に配置している点にある。同社は、エージェントの活動が他のすべての企業シグナルと同じ調査コンテキストに現れるべきだと主張する。

この設計は、マネージドセキュリティプロバイダーや少人数のセキュリティチームに訴求する可能性がある。専門化された別のAIセキュリティコンソールではなく、単一の運用キューを好むかもしれない。

ただし、大規模なプラットフォームベンダーも同じ統合の主張を展開できる。Microsoftは管理コントロールプレーンを中心に統合できる。Palo Alto Networksは自社のセキュリティポートフォリオを中心に統合できる。Ciscoはネットワークとランタイムの適用を中心に統合できる。

したがって競争上の焦点は、誰が先にエージェントのインベントリーやキルスイッチを提供するかではない。誰が最も関連性の高いコンテキストを収集し、それを正確な判断へ転換できるかだ。

Exaforceは、検出、トリアージ、調査、ハンティング、対応を担うExabotsと呼ばれる独自のAIセキュリティエージェントも運用している。そのプラットフォームは現在、他のAIエージェントを保護するためにAIエージェントを利用している。

この対称性には価値とリスクがある。自動分析は複雑な活動を人間のチームより速く処理できる一方、不正確なモデル判断が不要な封じ込め措置を引き起こす可能性もある。

人による承認設定は、顧客がそのリスクを管理する手段となる。しかし、あらゆる対応に承認を必要とすれば、自動化が約束する速度面の利点は低下しかねない。

市場は最終的に、段階的な自律性へ向かっている。低リスクの行為は自動実行できる一方、影響の大きい対応には、より強い証拠または人間による確認が必要となる。

エージェントのキルスイッチでは脆弱な検出を補えない

対応制御の信頼性は、それを作動させるために用いられた証拠の信頼性に左右される。

「agent kill switch」という表現は確実性を示唆する。システムが不正なエージェントを検出し、オペレーターがボタンを押し、脅威が終息する。

企業環境はそれほど整然としていない。エージェントは、プロセス、認証情報、モデルプロバイダーのアカウント、統合、ブラウザーセッション、クラウドリソースに依存している。1つのコンポーネントを終了しても、残りすべてが排除されるとは限らない。

攻撃者は、エージェントプロセスの終了後もOAuthトークンを保持できる。スケジュールされたワークフローがプロセスを再起動する可能性もある。侵害されたIDは別のツールを介して同じ行為を開始できる。

これが、Exaforceの対応オプションがプロセス終了にとどまらない理由だ。セッションの無効化、キーの無効化、デバイスの隔離、ID制御は、複数の経路を同時に遮断できる。

こうしたアクションは正当な業務も中断し得る。開発者のデバイスを隔離したり、本番用認証情報を取り消したりすることは、とりわけ検出の確信度が不確かな場合、運用上の影響を生む。

したがって、誤検知は見逃された攻撃と同じくらい重要である。すべてのシェル実行、大容量ファイルの読み取り、見慣れないドメインに対してアラートを出すプラットフォームは、アナリストを圧倒し、自動対応を敬遠させるだろう。

Exaforceは、関連する挙動を結び付けることで、そのコンテキストモデルがこの問題を軽減するとしている。その主張には妥当性があるが、ローンチ資料では検出率に関する独立した測定値は示されていない。

新しいエージェントセキュリティ機能についての誤検知率も開示されていない。Exaforceの不正エージェント検出をMicrosoft、Cisco、Palo Alto Networks、または専門ベンダーと比較する公開ベンチマークは存在しない。

カバレッジもまた不確実性の1つである。Exaforceは、OpenAI、Google、Microsoft、Anthropicを含む主要プロバイダーを挙げている。企業はカスタムエージェント、オープンソースモデル、ブラウザー拡張機能、社内オーケストレーションシステムも運用している。

製品の有効性は、それらの異なる実装をどれだけ一貫して認識できるかに左右される。非対応ツール内で実行されるエージェントは、通常のプロセスとして見える可能性がある。

行動コンテキストは役立つが、コンテキストは意図と同じではない。セキュリティテスト用エージェントは、承認された演習の一環としてCookieを収集したり、アクセス境界を探索したりする可能性がある。

侵害されたエージェントも、通常業務を模倣できる。承認済みサービスを通じて少量のデータを持ち出したり、ユーザーの既存のアクセスパターン内にとどまったりする可能性がある。

自動対応はガバナンス上の問題も加える。顧客は、確認なしにプラットフォームが実行できるアクションと、そのアクションが障害を引き起こした場合に誰が責任を負うかを決めなければならない。

成熟したポリシーでは、対応権限を確信度、資産の機密性、ビジネスへの影響に結び付けるべきだ。価値の低い実験的プロセスを終了することは、本番システムが使用する認証情報を無効化することとは異なる。

セキュリティチームは、完全な自律性を有効にする前に失敗モードもテストすべきだ。演習では、隔離されたエンドポイントが調査のために到達可能なままであるか、キーの無効化が無関係なサービスに影響するかを測定できる。

最も信頼できる証拠は、文書化された顧客導入から得られるだろう。購買担当者は、検出にかかる時間、可視化されないままのエージェント、アナリストによる修正が必要となる検出結果の数を知る必要がある。

また、危険な権限や意図的に安全でないテスト構成だけでなく、実際の敵対的活動に関する事例も必要だ。ポスチャーの検出結果と脅威の検出は、別の問題を解決する。

Exaforceが報告したライブテナントの事例は、初期段階の見通しを提供する。ただし、それらは多様な企業環境全体での一般的な性能を確立するものではない。

これがExaforce AI Securityにおける主要なトレードオフだ。agentlessな導入は展開時の摩擦を減らせる一方、既存テレメトリーへの依存は不均一な可視性を生み出す可能性がある。

Exaforceが豊富なエンドポイント、ID、クラウド、プロバイダーデータをすでに受信している環境では、製品は優れた性能を発揮するかもしれない。これらのシグナルが不完全な場所では、その結論の確実性は低くなる。

Exaforce AI Securityの有効性を証明するもの

次の試金石は新たな機能発表ではない。正当なエージェントを妨げずに危険な連鎖を検出できることを示す、測定可能な証拠である。

最初に注目すべきシグナルは、独立した顧客による検証だ。Exaforceには、発見したエージェント、当初見落としていたリスク、アナリストが検出結果をどのように扱ったかを示す導入レポートが必要である。

有用な証拠は、インベントリーのカバレッジ、ポスチャー分析、能動的な脅威検出、対応を分けて示すものになる。これらの成果を1つの成功事例にまとめると、評価は困難になる。

顧客の結果は、各環境で利用可能だったテレメトリーも開示すべきだ。広範なエンドポイントおよびIDカバレッジに基づく検出性能を、統合が少ない組織に一般化すべきではない。

強力な現場での結果は、既存データがagentlessなランタイムセキュリティを支えられるというExaforceの主張を補強するだろう。持続する死角は、中核となる設計上の主張を弱める。

2つ目のシグナルは、より広範な統合カバレッジである。現在のローンチでは主要モデルプロバイダーと接続し、既存のエンドポイントおよび企業データを利用している。

企業におけるエージェント導入は、少数の製品に集中したままではない。社内チームは、オープンモデル、コードフレームワーク、MCPサーバー、コマンドラインツール、カスタムAPIからエージェントを構築できる。

Exaforceは、それぞれに専用センサーを必要とせず、新たなエージェント形態を認識し続けなければならない。統合に関する発表が重要なのは、帰属と対応に十分なデータを公開する場合に限られる。

検出のみのサポートでは不十分だ。セキュリティチームには、プロセス間の関係、ツール呼び出し、権限、認証情報、ネットワークの宛先、対応制御が必要となる。

3つ目のシグナルは、競合他社がどう対応するかだ。Microsoft、Palo Alto Networks、Ciscoはすでに、ID、エンドポイント、ネットワーク、クラウドにまたがる重要な適用ポイントを占めている。

それらのベンダーがクロスプラットフォームのエージェントコンテキストを既存製品の標準機能にすれば、Exaforceはより強い流通面の圧力に直面する。各社のツールが狭いエコシステムに縛られたままであれば、独立した相関レイヤーの魅力は高まる。

価格だけが購買要因ではない。セキュリティチームは、導入の労力、調査の質、統合の深さ、マネージドサービスの選択肢、不正確な自動アクションがもたらす影響を比較する。

Exaforceの立ち位置が最も明確なのは、すでに同社のセキュリティ運用プラットフォームまたはMDRサービスを利用している組織だ。新機能により、既存のワークフローへAIエージェントの活動を追加できる。

新規顧客は、より広範なプラットフォーム選定に直面する。Exaforceを、アイデンティティ、エンドポイント、クラウド、ネットワークの各スタックにすでに組み込まれている制御機能と比較する必要がある。

今回の発表は、エージェント活動に関する組織的な記憶の必要性が高まっていることも示している。調査担当者は、これまでの導入における意思決定、承認、インシデントの証拠、得られた教訓にアクセスできなければならない。

検索可能なAI knowledge baseは、チームがそうした文脈を保持する助けになるが、実行時のセキュリティ制御に取って代わるものではない。

エンタープライズの購買担当者にとって、当面の対応は、セキュリティプラットフォームを選ぶ前にエージェントとそのアクセス権を棚卸しすることだ。各エージェントの所有者、使用する認証情報、変更可能なシステムを特定する。

次に、Exaforce AI Securityまたは競合プラットフォームを、現実的なシナリオでテストする。プロンプトインジェクション、過剰なOAuth権限、不審なツールチェーン、認証情報へのアクセス、データ移動に加え、攻撃に似た正当なワークフローも含める。

検知能力と業務への妨害の両方を測定する。勝つプラットフォームは、最も劇的なキルスイッチの表現を掲げるものではない。危険な自律性と生産的な自動化を一貫して見分け、適切なレベルで対応できるものだ。