OX Security CNAPP Platformがクラウド態勢とAIエージェントのランタイム防御を統合
OX Securityは9月16日、既存のクラウド制御とAIエージェント向けのリアルタイム監視を組み合わせたCNAPPプラットフォームを発表した。OX Security CNAPP platformはOX Cloudと呼ばれ、自律型ソフトウェアがアイデンティティ、権限、エンタープライズツールへのアクセスを得ることで生じるセキュリティ上の空白を対象とする。
今回の発表は、クラウドセキュリティ機能リストを単に拡張するものではない。OXは、コード、クラウド設定、アイデンティティ、データ、プロンプト、そして実行中のエージェントの行動を結び付ける単一のグラフがセキュリティチームに必要だと主張している。この主張は、従来型のCNAPP製品と、独立したAIセキュリティツールの双方に挑むものだ。
Palo Alto Networksなどの大手セキュリティベンダーは、すでにランタイム保護、AI態勢管理、エージェント制御を提供している。したがってOXは、同社のプロンプトからランタイムまでのコンテキストが、単にダッシュボードの範囲を広げるだけでなく、より良い判断につながることを示す必要がある。
中心となる問いは、こうしたシグナルを組み合わせることで、防御側が到達可能なリスクと危険なエージェント行動を切り分けやすくなるかどうかだ。そうであれば、OX Cloudはクラウドの弱点を発見することと、自律システムがそれをどのように悪用し得るかを理解することの間にある隔たりを縮められる可能性がある。
OX Security CNAPP Platformが実行中のエージェント活動へ可視性を拡張
OX Cloudは、クラウドセキュリティプラットフォームがすでに収集しているインフラ、アイデンティティ、脆弱性、データのシグナルに、エージェントの行動を加える。
クラウドネイティブアプリケーション保護プラットフォーム、すなわちCNAPPは、複数のクラウドセキュリティ機能を単一システムに統合する。一般的には、設定監視、ワークロード保護、権限分析、脆弱性管理、攻撃経路マッピングが含まれる。
OX Cloudには、クラウドセキュリティ態勢管理、Kubernetes態勢管理、データセキュリティ態勢管理、ランタイム脆弱性検出、クラウドインベントリ、グラフベースの攻撃経路分析が含まれる。同社はさらに、AIDRと略すAI Detection and Responseも追加している。
違いは、OXがプラットフォームで観測しようとしている対象にある。従来の態勢管理ツールは、ストレージバケット、コンテナ、アイデンティティ、ネットワーク経路、アクセスポリシーといったリソースを調査する。OX Cloudはそれに加え、その環境内で稼働するエージェント、モデル、プロンプト、Model Context Protocolサーバーの特定も目指している。
MCPは、AIシステムを外部ツールやデータに接続するための標準インターフェースだ。MCPサーバーは、データベース、ファイルシステム、チケット管理サービス、コードリポジトリ、社内APIをエージェントに公開する場合がある。
この接続はエージェントの有用性を高める一方で、モデル出力を行動へと変える。操作されたエージェントは、アクセス制限された記録を取得したり、未承認のツールを呼び出したり、本来のワークフローの範囲外で有効な認証情報を使用したりする可能性がある。
OXは、自社プラットフォームがこうした行動を周囲のクラウドコンテキストと結び付けるとしている。同社のOX Cloud announcementによると、この製品はワークロード、アイデンティティ、データストア、Kubernetesクラスター、稼働中のAIエージェントをインベントリ化できる。
その後、プラットフォームは到達可能性分析を用いて検出結果の優先順位を付ける。到達可能性は、公開されたコンポーネント、脆弱なパッケージ、過剰な権限が、実際に重要なリソースや実行経路へ接続できるかどうかを判断する。
このアプローチが重要なのは、クラウドスキャナーが技術的には有効な検出結果を長いリストとして出力し得るためだ。隔離されたワークロード内の脆弱なパッケージは、顧客記録にアクセスできるインターネット公開サービス内の同じパッケージと、同程度の即時リスクをもたらすわけではない。
OXはこのロジックをエージェントにも適用する。問題のあるプロンプトや異常なツール呼び出しは、担当エージェントが本番データ、管理API、デプロイメントシステムに到達できる場合、より重要になる。
同社はまた、OX Cloudがランタイム活動を、それを開始したプロンプトやコードと関連付けられるとしている。この関連付けにより、調査担当者は単に行動が発生したことを記録するだけでなく、エージェントがなぜその行動を取ったのかを再構築できる可能性がある。
これらは依然としてベンダー側の主張である。OXは機能と製品アーキテクチャを説明しているが、今回の発表について比較検出率、誤検知の測定値、導入時のオーバーヘッド、独立評価は公表していない。
この証拠の不足は、製品を無関係なものにするわけではない。むしろ、企業の購入者が新プラットフォームを統合制御プレーンとして扱う前に検証すべき事項を定義している。
AIエージェントが従来のクラウドセキュリティに圧力をかける理由
エージェントは、推論し、ツールを選択し、変更を開始できる、急速に動く一つのアイデンティティに、いくつもの既知のセキュリティ問題を集約する。
従来のワークロードは通常、エンジニアがデプロイ前にレビューできるコードに従う。その権限が過剰であったり、依存関係に脆弱性が含まれていたりする場合はある。それでも、想定される実行経路は比較的安定している。
エージェントの振る舞いは異なる。エージェントは指示を解釈し、コンテキストを取得し、ツールを選び、ランタイムで一連の行動を組み立てる。プロンプト、取得したドキュメント、モデルバージョン、ツールの説明に小さな変更が加わるだけで、この一連の動きは変化し得る。
この変動性は、エージェントの行動が知り得ないことを意味しない。防御側が、意思決定の経路と、その結果として発生するシステム呼び出しの両方を取り巻くテレメトリーを必要とすることを意味する。
アイデンティティはこの問題の中核を成す。共有サービスアカウントを通じて動作するエージェントは、ログの解釈を困難にし得る。調査担当者はデータベースクエリやファイル変更を確認できても、どのエージェントが開始したのか、なぜ実行したのか、誰がそのワークフローを承認したのかを把握できない場合がある。
Microsoftの最小権限ガイダンスは、すべてのエージェントを独立したプリンシパルとして扱うことを推奨している。各エージェントには、管理対象アイデンティティ、明示的な所有者、限定的なロール、承認済みのツールマニフェストを持たせるべきだとしている。
このモデルは測定可能な境界を生み出す。チームは、エージェントが呼び出すべきツール、アクセスできるリソース、ランタイム活動が割り当てられた目的の範囲内にとどまっているかを判断できる。
MCPサーバーが広範な認証情報を継承する場合、問題はさらに深刻になる。MCPはOAuthを含む認可メカニズムをサポートするが、このプロトコルがすべてのデプロイメントに対して安全なポリシーを自動的に適用するわけではない。
Microsoftは、Defender for Cloudのシグナルを通じて観測されたリモートMCPサーバーの15パーセントが、機密データまたは運用機能への認証なしアクセスを許可していたと報告した。同社のMCP露出に関する調査結果には、チケット管理システム、非公開リポジトリ、人事ツールへの接続が含まれていた。
この数値は、すべてのMCPデプロイメントを表すものではない。ただし、認証と実行の境界が誤設定されている場合、エージェント接続が実際のエンタープライズシステムを露出させ得ることを示している。
態勢スキャンは公開されたサーバーを特定できるかもしれない。アイデンティティ製品はその認証情報を発見できるかもしれない。ランタイムツールは不審な呼び出しを記録できるかもしれない。OXは、アナリストが手作業で連鎖を組み立てる前に、共有グラフがこの3つすべてを結び付けられると見込んでいる。
これが、CNAPPデータとAIエージェントのランタイム防御を組み合わせる最も強い論拠だ。脅威は、完全にアプリケーションの問題でも、完全にクラウドの問題でもない。
サポート要求の解決を担うエージェントを考えてみよう。このエージェントはチケットを読み、社内ドキュメントを検索し、顧客記録を更新できる。チケット内に隠された間接プロンプトが、関係のない記録の取得や外部エンドポイントへのデータ送信をエージェントに指示する可能性がある。
プロンプトフィルターはその指示をフラグ付けするかもしれない。しかし重大度は、エージェントが使用するアイデンティティ、呼び出せるツール、そのツールがアクセス可能な記録によって決まる。
逆に、異常なAPI呼び出しが常に攻撃を示すわけではない。エージェントが通常とは異なる要求に遭遇した後、正当なタスクを完了している可能性もある。防御側には、予期しない行動と未承認の行動を区別するための十分なコンテキストが必要だ。
OX Cloudはこの区別を中心に設計されている。その約束は、奇妙なプロンプトを検出することだけではない。実行中の行動を、到達可能な資産、有効な権限、起点となるソフトウェア経路と結び付けることにある。
OX Cloudは到達可能性を主要な差別化要因に据える
このプラットフォームの中核となる仕組みは、ランタイム行動と攻撃経路に基づいて、どの検出結果に注意を向けるべきかを決める、証拠に結び付いた優先順位付けだ。
クラウドセキュリティチームはすでにアラート量への対応に苦慮している。態勢スキャナーは設定ミスを検出し、脆弱性ツールはパッケージを列挙し、アイデンティティシステムは過剰な権限を特定し、データツールは機密ストアを分類する。
エージェントを加えることで、断片化を解消しないまま、さらに一つのインベントリが生まれる可能性がある。セキュリティチームは、あるエージェントが存在し、特定のモデルを使用し、複数のツールに接続していることを知るかもしれない。それでも、その行動が悪用可能な経路を生むかどうかは分からない。
OXは、識別、優先順位付け、調査、ガバナンスという4段階のワークフローを説明している。これらの段階は、互いに切り離された製品モジュールとして動作するのではなく、同じコンテキストデータを使用する。
識別は、ワークロード、アイデンティティ、エージェント、データストア、クラウド資産を対象とする。OXによれば、これには設定ファイルで宣言されたリソースだけでなく、観測された活動から発見されたリソースも含まれる。
優先順位付けでは、脆弱性、権限、設定ミス、サプライチェーン上の露出に到達可能性を適用する。稼働中のワークロードや重要な資産に接続できない検出結果には、緊急度が低く割り当てられる。
調査では、クラウドグラフを使用してイベントを取り巻く関係を再構築する。アナリストは、どのアイデンティティが行動し、どのリソースに触れ、どの追加システムに到達可能だったかを確認できるべきだ。
ガバナンスは、エージェント活動とAI利用に制限を適用する。ここでOXのAIDRとエージェント型攻撃対象領域の機能は、単なる発見機能を超えるものとなる。
この仕組みは一貫して聞こえるが、その品質はデータの忠実性に依存する。OXは、資産を確実に発見し、権限を解釈し、エージェント呼び出しを追跡し、調査に十分なコンテキストを保持しなければならない。
カバレッジの欠落は、誤った安心感を生み得る。観測されないツール呼び出し、管理されていない認証情報、暗号化されたトラフィック経路、サポート対象外のエージェントフレームワークは、プロンプトと結果を結ぶ連鎖を断ち切る可能性がある。
データ相関も曖昧な結論を生む場合がある。API呼び出しの直前にプロンプトが現れたとしても、それが呼び出しを引き起こしたことを自動的に証明するわけではない。長時間実行されるワークフロー、並列エージェント、再試行、委任されたサブタスクは、帰属を複雑にする。
そのためOXは、インターフェース内で相関関係と因果関係を区別しなければならない。アナリストには、提案された関係を裏付けるタイムスタンプ、呼び出しチェーン、アイデンティティ記録、ポリシー判断、アプリケーショントレースが必要だ。
デプロイメントアーキテクチャも重要である。ランタイム検査は、ネットワーク傍受、ワークロードセンサー、アプリケーションライブラリ、APIゲートウェイ、クラウドログ、エージェントフレームワークとの統合を通じて行える。
各手法は異なる可視性を提供する。ネットワーク制御は宛先とペイロードを観測できる一方、内部の推論を見逃す可能性がある。フレームワークのインストルメンテーションはツール選択を捉えられるが、カスタムアプリケーション全体では不完全なカバレッジしか提供しない場合がある。
OXによると、より広範なAINAPPプラットフォームは、プロンプト、コード、ビルド、デプロイメント、ランタイムの各段階を結び付ける。AINAPPは、AIネイティブアプリケーション保護プラットフォームを指す同社の用語だ。
このコンセプトにより、OXは潜在的に有用な立ち位置を得る。アプリケーションセキュリティ製品はすでにソースコードとソフトウェアサプライチェーンを検査している。OX Cloudはその対象を、デプロイ済みインフラストラクチャと稼働中のエージェント活動へと拡張する。
ただし購入者は、すでにOX製品で管理されていないコードやエージェントについて、この接続がどのように機能するのかを確認すべきだ。最も豊富なコンテキストが厳格に管理されたツールチェーン内でしか得られないなら、統合プラットフォームの価値は限定的になる。
実践的な検証方法は、実際のインシデントを再現することだ。セキュリティチームは不審なツール説明を注入し、未承認アクセスの試行を発生させ、OXがその経路全体を再構築できるか確認すべきである。
この演習では、起点となったコンテンツ、エージェントID、選択されたツール、パラメータ、宛先、有効な権限、影響を受けたデータ、そして適用結果が示されるべきだ。それに満たなければ、アナリストは複数システムにまたがって証拠をつなぎ合わせることになる。
OX Security、既存のCNAPPおよびAIセキュリティプラットフォームと対峙
OXが競合する相手は、AIを完全に無視してきた静的クラウドスキャナーではなく、大手ベンダー主導のプラットフォーム統合である。
市場はすでにライフサイクル全体をカバーする方向へ移行している。主要ベンダーは現在、AI検出、ポスチャー分析、レッドチーミング、ランタイム検査、アイデンティティ制御、ポリシー適用を組み合わせている。
Palo Alto Networksは、AIアプリケーション、モデル、データ、エージェントを対象とするプラットフォームとしてPrisma AIRSを提示している。同社のPrisma AIRS documentationでは、ランタイムファイアウォール、API、レッドチーミング、モデルセキュリティ、ポスチャー管理、エージェント保護が説明されている。
Palo Altoはさらに、AI検出をCortex Cloudと統合している。この接続により、Amazon Web Services、Microsoft Azure、Google Cloud全体にわたるモデル、エンドポイント、データセット、エージェント、依存関係を特定できる。
このため、主要な競争はOX対従来型CNAPPという単純な構図ではない。既存の製品ポートフォリオ全体で類似の制御を構築する既存セキュリティプラットフォームに対し、OXがコンテキスト優先の統合で挑む構図である。
既存ベンダーは、導入済み顧客基盤、クラウドテレメトリー、脅威インテリジェンス、アイデンティティ統合、確立された調達関係を持つ。購入者は、新たなセキュリティプラットフォームを導入するよりも、既存契約を拡張することを選ぶかもしれない。
OXは集中戦略で対抗できる。小規模ベンダーであれば、旧来製品スイートのあらゆるアーキテクチャ上の前提を維持することなく、エージェントのワークフローを中心に設計できる。
コードからランタイムまでを結ぶ同社のストーリーは、アプリケーションセキュリティチームにも訴求し得る。そうしたチームは、開発中に導入された検出事項がデプロイ後も到達可能か、そしてエージェントが脆弱な経路を起動できるかを知りたいと考えている。
この接続は、開発者とセキュリティアナリストの間の認識の隔たりを減らす可能性がある。開発者は、影響を受けるコードが公開されているという証拠なしに、スキャナーの検出結果を受け取ることが多い。ランタイムコンテキストは、どの問題が即時の運用上の重要性を持つかを明らかにできる。
しかし、大手ベンダーも同じ統合論を展開している。Palo Altoは、一般提供開始から1年後のPrisma AIRSの年間経常収益が約1億2,000万ドルに達したと報告した。
同社はまた、2026年度第4四半期のプレゼンテーションで、Prisma AIRSの顧客数が800社を超えたと報告している。これらの数値はPalo Alto独自の収益配分および受注見積もりの定義に基づくものだが、相応の商業需要を示している。
この競争圧力により、OXは具体的な優位性を示す必要がある。クラウドプラットフォームはすでに同じカテゴリーの多くをカバーしているため、より長い機能リストだけでは不十分だ。
OXは、より迅速な調査、より明確な優先順位付け、幅広いフレームワーク対応、あるいはプロンプトからランタイムまでのより明確な帰属追跡によって差別化できる。また、デプロイの柔軟性や運用の複雑さの低さでも競争できる。
顧客はカテゴリー名ではなくワークフローを比較すべきだ。両製品がエージェント検出、ランタイム防御、ポスチャー管理を掲げていても、収集するテレメトリーや、ポリシーを適用する地点は異なる可能性がある。
あるプラットフォームは、モデル処理前に悪意あるプロンプトを遮断するかもしれない。別のプラットフォームは、ツール呼び出しをインターセプトし、アイデンティティ権限を制限し、または不審な活動を検知した後にワークロードを隔離する可能性がある。
これらの制御は補完的だが、配置場所はレイテンシー、カバレッジ、障害モードに影響する。実行経路の外側に置かれた製品は、即時の遮断権限を持たない一方で、より安全に観測できる可能性がある。
インライン制御はアクションを停止できるが、同時にアプリケーションの可用性経路の一部にもなる。購入者は、セキュリティサービスが遅延した場合、接続を失った場合、またはリクエストを分類できない場合に何が起こるのかを理解しなければならない。
OXは、こうした比較を決着させるのに十分なローンチ固有の証拠を公表していない。当面の課題は、信頼できるアーキテクチャを再現可能な顧客成果へと転換することだ。
ランタイム防御はエージェント設計とアクセス制御の代替にならない
アイデンティティを共有し、過剰な権限を与えられ、独立した認可なしに高影響アクションを実行するエージェントを、CNAPPだけで補うことはできない。
ランタイム監視は、静的レビューでは見逃される振る舞いを検出できるため、しばしば注目を集める。その強みは同時に、観測をより安全なアーキテクチャの代替として扱うようチームを促すおそれもある。
監視製品がアクションを記録するからといって、エージェントに広範なアクセスを与えるべきではない。未承認のデータ転送を記録しても、その転送を取り消すことはできない。
OWASPのagentic risk taxonomyには、ツールの不正利用、アイデンティティおよび権限の悪用、メモリポイズニング、連鎖的障害、暴走エージェントの振る舞いが含まれている。これらのリスクは、モデル、アプリケーション、アイデンティティ、インフラストラクチャの境界をまたぐ。
防御側は、エージェントごとに異なるアイデンティティを設定することから始めるべきだ。共有認証情報は所有者を不明確にし、取り消しを困難にする。本番環境の各エージェントには、明確に名前付けされた所有者、文書化された目的、許可されたリソースの限定的なセットが必要である。
ツールアクセスも明示的に設定すべきだ。サポートチケットを要約するために設計されたエージェントに、チケット管理プラットフォームの管理者アクセスを継承させるべきではない。そのタスクに必要な読み取り操作だけを与えるべきだ。
書き込みアクセスには別途判断が必要である。ワークフローがレコード変更へ拡張される場合、チームはレビューなしに既存ロールを拡大するのではなく、新たな権限と承認ルールを作成すべきだ。
高影響アクションには決定論的な適用が必要である。データ削除、本番インフラストラクチャの変更、支払いの実行、外部コンテンツの公開は、自然言語の指示に対するモデルの解釈だけに依存すべきではない。
金銭面、運用面、法的側面で重大な結果を伴うアクションには、人による承認が引き続き適切である。影響の小さいタスクでは、ポリシー条件が限定的で独立して適用される場合に、自動承認が機能し得る。
メモリは別のリスクをもたらす。エージェントは、会話履歴、設定、取得した事実、あるいはセッション間の中間計画を保存する可能性がある。悪意あるコンテンツはそのメモリ内に残存し、後の判断に影響を及ぼすことがある。
ランタイム製品は、可能な場合にはメモリの読み取りと書き込みを可視化すべきだ。また、ツール選択やパラメータ構築の際にエージェントが取得コンテンツを使用したかどうかも示すべきである。
ただし、メモリアクセスはテレメトリーが限定的なフレームワークやモデルサービスの内部で発生する可能性がある。購入者は、OX Cloudが実際のデプロイスタック全体でこうしたやり取りを取得できるかを検証すべきだ。
誤検知は別の課題をもたらす。エージェントのワークフローはユーザーのリクエストに適応するため、自然に通常とは異なるアクションシーケンスを生成する。単純な異常検知は正当な変動を警告し、アナリストを圧倒する可能性がある。
OXは、到達可能性がこのノイズの削減に役立つとしている。この主張には妥当性があるが、到達可能性は悪意を証明するものではない。到達可能な経路は正当なワークフローを支える可能性があり、一方で到達不能なソフトウェア上の欠陥も、設定変更後には重要になる可能性がある。
企業は、管理されたデプロイ中に精度を測定すべきだ。有用な指標には、確認済みインシデント、誤検知、調査時間、正当なタスクの遮断件数、非対応ワークフロー、テレメトリーの欠落が含まれる。
パフォーマンスへの影響も測定すべきである。ランタイム検査では、プロンプト、ツール呼び出し、データフロー、アイデンティティポリシーを同期的に評価する場合、レイテンシーが加わる可能性がある。
OXは、OX Cloudの一般的なレイテンシーやオーバーヘッドの数値を公表していない。結果は、デプロイ方式、トラフィック量、ポリシーの複雑さ、収集するコンテキスト量に左右される可能性が高い。
もう一つの不確実性は、適用の一貫性である。組織は複数のクラウドやSaaSプラットフォームにまたがり、複数のフレームワークで構築されたエージェントを運用することがある。ポリシーは、こうしたアーキテクチャ上の違いを越えて維持されなければならない。
すべてのエージェントを検出する一方で一部しか統制しないダッシュボードは、保護のばらつきを生む。セキュリティチームには、明確な互換性マトリクスと、非対応経路が依然として可視化されているという証拠が必要だ。
適切な結論は、ランタイム防御に価値がないということではない。ランタイム監視は、より大きな制御システムの一層として機能するとき、最も効果を発揮するということだ。
安全なエージェント設計は、限定された権限から始まる。ランタイム防御は、振る舞いがその制限内に収まっているかを検証し、調査担当者が逸脱を理解する助けとなる。
OX Cloudが成果を出すかを示す3つのシグナル
次の検証は、顧客による検証、測定可能なノイズ低減、実際のエージェントスタック全体にわたる幅広い適用を含む運用上の証拠である。
第1のシグナルは、独立した顧客証拠である。OXは、複数クラウド、エージェントフレームワーク、アイデンティティプロバイダー、MCPサーバーを含む本番環境で、プラットフォームがどのように機能するかを示すべきだ。
有用な事例研究では、検出されたエージェントと非人間アイデンティティの数を定量化するだろう。また、確認されたリスク経路、抑制されたアラート数、調査時間の変化も報告すべきである。
第2のシグナルは、比較可能なパフォーマンスである。購入者には、プロンプトインジェクション、ポイズニングされたツール説明、過剰な権限、異常なAPIシーケンス、試行されたデータ流出を対象とする検出・適用テストが必要だ。
こうしたテストには、誤検知を測定するための良性の変動も含めるべきである。珍しいアクションをすべて遮断するシステムは、適応的なワークフローにとってほとんど価値がない。
OXは、適用がどこで行われるかも開示すべきだ。顧客は、制御がワークロード内部、ネットワーク検査、エージェントフレームワーク内、またはクラウドAPIを通じて機能するのかを知る必要がある。
第3のシグナルは、競合各社の対応である。Palo Alto Networks、Microsoft、その他のセキュリティベンダーは、エージェントアイデンティティ、ポスチャー、ランタイム検査、ガバナンスをより大きなプラットフォームに統合している。
これらのベンダーが、コード、プロンプト、アイデンティティ、クラウドリソース、ツール呼び出しを同等の精度で結び付けるなら、OXのアーキテクチャ上の差別化は縮小する。その場合、OXはデプロイ品質、調査速度、カバレッジ、顧客サービスで競争することになる。
既存ベンダーがこうした制御を断片化したままにするなら、OXは単一のコンテキストグラフがより迅速で、より根拠の明確な意思決定を生むと主張できる。どちらが本番環境の現実を反映するかは、顧客評価によって決まる。
OX Security CNAPPプラットフォームを評価するセキュリティリーダーは、限定された1つのエージェントワークフローから始めるべきだ。より広範なカバレッジを有効にする前に、そのアイデンティティ、承認済みツール、到達可能なデータ、想定アクション、エスカレーションルールをマッピングできる。
次に、評価では管理された障害を導入すべきである。公開されたMCPサーバー、過剰な権限を持つアイデンティティ、ポイズニングされたドキュメント、未承認のツール呼び出し、到達可能な脆弱ワークロードをテストする。
プラットフォームは、異常なことが起きたことだけでなく、なぜ重要だったのかも示すべきだ。起点となった指示を、行動したアイデンティティ、選択されたツール、到達可能な資産、ポリシー判断、最終結果と結び付ける必要がある。
この基準はOX以外にも当てはまる。エージェントセキュリティ製品は、複雑なテレメトリーを信頼できる適用と説明可能な調査へ転換しなければならない。
このローンチは、クラウドセキュリティにおける実質的な転換を示している。エージェントは、単に棚卸しすべき資産カテゴリの一つではなく、クラウド上で能動的に活動する参加者になりつつある。
OX Cloudは、ランタイム時の振る舞いをコード、ワークロード、アイデンティティ、データと同じグラフに組み込むことで、この変化に対応する。設計には説得力があるが、最も強い主張については依然として独立した検証が必要だ。
OX Cloudを検討するチームは、洗練された機能デモではなく、本番環境を想定したトライアルを求めるべきだ。プラットフォームはすべてのエージェントを特定し、正当な変動と不正利用を区別し、完全なアクションチェーンを再構築できるのか。通常業務を遅らせたり、新たなアラートキューを生んだりせずに、制限を適用できるのか。これらの結果によって、OX Security CNAPP platformが意味のあるコントロールプレーンとなるのか、それともセキュリティチームがさらに調整しなければならない別のレイヤーになるのかが決まる。
