Okta AI Agent Security、エンタープライズの混乱に挑む

Oktaは、AIエージェントセキュリティを推進するうえで異例の敵を特定した。それは他のセキュリティベンダーではなく、顧客の混乱だ。社長兼COOのEric Kelleher氏は、2026年9月9日に開催されたGoldman Sachs Communacopia + Technology Conferenceでこの見解を示した。

この主張は、企業が自律型ソフトウェアを求める一方、何を保護すべきかの定義に苦慮している市場を反映している。エージェントはメールの要約、営業記録の更新、返金の承認、あるいは財務ワークフロー全体の運用を担う可能性がある。役割ごとに、異なる権限、リスク、説明責任の要件が生じる。

Oktaは、この混乱を整理するレイヤーとしてアイデンティティを位置付けたい考えだ。同社のフレームワークは、「エージェントはどこにいるか」「何に接続できるか」「何を実行できるか」という3つの問いを投げかける。MicrosoftもEntra Agent IDとAgent 365を通じて類似の目標を追求しており、エンタープライズへの展開力はセキュリティ設計と同じくらい重要になっている。

この競争は、Oktaのメッセージの意味を変える。混乱は独立系アイデンティティプロバイダーに市場機会をもたらし得る一方、購買を遅らせ、バンドル型プラットフォームを有利にする可能性もある。Oktaは緊急性のあるセキュリティの物語を、再現可能な導入、測定可能な採用、そして顧客がベンダー横断で利用できる標準へと転換しなければならない。

Okta AI Agent Securityは3つの問いから始まる

Oktaの当面の取り組みは、広範なセキュリティ課題を、エージェントの発見、接続の制御、認可に集約することだ。

9月のカンファレンスでKelleher氏は、自律型エージェントに関する懸念すべき報道に触れた後、顧客がOktaに支援を求めていると説明した。これらの購入者は、エージェントがリスクをもたらすことを理解しているが、そのリスクを評価するための共通モデルを持たない場合が多い。

Oktaの答えが、Blueprint for the Secure Agentic Enterpriseだ。同社は3月にこのフレームワークを発表し、2026年4月30日にOkta for AI Agentsを一般提供した。この製品は、よく知られたアイデンティティ制御を自律型および半自律型ソフトウェアへと拡張する。

最初の問いである「エージェントはどこにいるか」は、インベントリと所有権に関するものだ。従業員は正式な導入プロセスを経ずにツールを有効化でき、開発者は多数のクラウドプラットフォームでエージェントを作成できる。セキュリティチームは、特定できないエージェントを統制できない。

OktaのAgent Discovery機能は、こうした隠れた導入状況を明らかにするよう設計されている。同社のagent discovery detailsによると、OAuth同意アクティビティを検出し、未承認のエージェントプラットフォームに関わる接続を特定する。

OAuth同意は、ユーザーのパスワードを受け取らずに、アプリケーションが別のサービスへアクセスする権限を付与する仕組みだ。従業員が未知のエージェントにメール、ファイル、カレンダー、顧客記録の読み取りを許可すると、その利便性はリスクになり得る。

Oktaによれば、ブラウザシグナルからクライアントアプリケーション、接続先リソース、要求された権限スコープを把握できる。管理者はその後、エージェントを登録し、人間の所有者を割り当て、ベースラインポリシーを適用できる。

2つ目の問いである「エージェントは何に接続できるか」は、インベントリからアクセス経路へと焦点を移す。エージェントはアプリケーション、API、データベース、ツール、またはModel Context Protocolサーバーと対話する可能性がある。MCPは、AIシステムが外部ツールや情報にアクセスできるようにする標準インターフェースだ。

OktaのBlueprintには、こうした接続を仲介するゲートウェイ、認証情報の保管、APIアクセス管理が含まれる。これらの制御は、広範かつ永続的な認証情報を、アイデンティティ、コンテキスト、リスクに基づく、より限定的な判断へ置き換えることを目的としている。

3つ目の問いである「エージェントは何を実行できるか」は、最も難しいレイヤーに及ぶ。エージェントがシステムに入れることを知っていても、情報の読み取り、書き込み、転送、承認、削除のどれを実行できるかは分からない。

Oktaは、個々のツール呼び出しと認可判断を記録することを提案している。また、接続済みシステム全体でエージェントのアクセストークンを失効させるキルスイッチとして、Universal Logoutを推進している。

この枠組みが重要なのは、エージェントが単なる従業員アカウントではないためだ。短時間に多くのアクションを実行し、システム横断で情報を組み合わせ、周囲のコンテキストが変化すると挙動も変え得る。

また通常、予測可能な自動タスクを実行する従来型サービスアカウントとも異なる。AIエージェントはツールを選択し、中間計画を生成し、ユーザーから委任された権限を通じて行動できる。

したがって、Oktaの3つの問いは有用な購買構造を生み出す。すべての基盤制御があらゆるエージェントプラットフォームで機能することを証明するものではないが、セキュリティリーダーに、何を検証すべきか判断するための共通語彙を与える。

この語彙が同社戦略の基盤だ。Oktaは、企業がエージェントセキュリティを孤立したAI監視のカテゴリーではなく、アイデンティティガバナンスの拡張として捉えることを目指している。

混乱は需要と遅延の両方を生んでいる

顧客をOktaへ導く不確実性は同時に、評価期間を長引かせ、エージェントセキュリティが予測可能なビジネスになることを妨げる可能性もある。

Kelleher氏は、エージェント型アイデンティティにおける同社最大の現在の競合相手は混乱だと述べた。購入者は、セキュリティベンダー、クラウドプロバイダー、AI開発者、ガバナンスプラットフォームから相反する主張を受けている。多くの製品は似た言葉を使いながら、異なるレイヤーを保護している。

あるベンダーは悪意ある指示を検出するためにプロンプトをスキャンするかもしれない。別のベンダーはマシンアイデンティティや露出した認証情報を発見する可能性がある。3社目がネットワークトラフィックを制御する一方、アイデンティティプロバイダーはどのエージェントが特定のアプリケーションにアクセスできるかを決定する。

これらの機能は相互補完できるが、企業はなお所有権を確立する必要がある。セキュリティチームがアクセスポリシーを管理する一方で、開発者がエージェントを所有し、事業部門が許容可能なアクションを定義する場合がある。

組織が自社の導入について基本的な質問に答えられない場合、調達はより難しくなる。企業は従業員がAIアシスタントを使用していることを知っていても、どのアシスタントが永続的なアプリケーション権限を持つかを把握していない可能性がある。

エージェントの定義も依然として一貫していない。アクションを推奨するチャットインターフェースもあれば、人間の承認後にワークフローを実行するシステムもあり、自律型エージェントは各ステップを確認せずに行動できる。

この曖昧さは、ライセンスと製品測定にも影響する。Kelleher氏は、Oktaが現在、エージェント型製品をユーザー単位価格への追加料金として提供していると述べた。同氏は、このモデルがエージェントアーキテクチャには完全ではないと認めつつ、顧客にとって購入しやすいと説明した。

カンファレンスでの発言によると、初期取引の大半は1年契約だ。Oktaは、更新前に両者がエージェント利用状況と運用コストについて、より良い情報を得られると見込んでいる。

このアプローチは、当面の購買摩擦を低減する。同時に、市場がいかに初期段階にあるかも示している。成熟したセキュリティカテゴリーには通常、ユーザー、デバイス、ワークロード、トランザクション、保護対象データ量といった、より明確な単位がある。

エージェントの活動は、それらすべての単位を横断し得る。1人の従業員が複数のエージェントを使用する一方、1つのエージェントが一時的なワーカーを生成したり、数千回のツール呼び出しを実行したりすることもある。ユーザー単位モデルは、保護対象となるワークロードから乖離する可能性がある。

Oktaの強みは、エンタープライズのアイデンティティチームとの既存関係にある。Kelleher氏によれば、すでに20,000社超が人間および非人間のアイデンティティをOktaに託している。この導入基盤は、セキュリティに関する議論への直接的な入口を提供する。

ただし、信頼が実装作業を不要にするわけではない。顧客はエージェントを発見し、目的を分類し、所有者を特定し、過剰な権限を削減し、関連するアプリケーションを執行ポイントに接続しなければならない。

セキュリティリーダーは、どのアクションに人間の承認が必要かも判断する必要がある。要約エージェントと見積から回収までを担うエージェントは、同じアイデンティティプラットフォームを使っていても、同一の制御を受けるべきではない。

後者は価格設定、契約、請求システム、収益記録に触れる可能性がある。ミスは不便な回答にとどまらず、財務またはコンプライアンス上の事象となり得る。

この違いにより、Oktaが導入を支援できる場合にのみ、混乱は製品機会へと変わる。Blueprintは顧客がより良い質問をする助けになるが、運用テンプレートと統合が答えを提供しなければならない。

この要件は、Oktaの営業およびプロフェッショナルサービスの取り組みに圧力をかける。購入者は、抽象的なアイデンティティフレームワークを実際のワークフロー向け制御へ変換することを同社に期待するだろう。

開発者も関連する課題に直面する。顧客ごとのアイデンティティシステムに合わせてすべてのエージェントを作り直さずに済む、安全なアクセスパターンが必要だ。これが、Oktaの標準戦略が製品論の中心近くに位置する理由である。

Cross App Accessはオープンな制御レイヤーを目指すOktaの賭け

Oktaは、オープンな認可標準によってエージェントアクセスをポータブルにしつつ、アイデンティティプロバイダーを中央のポリシー執行者として維持できると見込んでいる。

Cross App Access、すなわちXAAは、標準化された認可を通じてエージェントをアプリケーションへ接続するためのOktaの提案手法だ。OAuthの概念を拡張し、エージェントがツールを発見して呼び出す共通の方法を提供するMCPと連携する。

この区別は重要だ。MCPは利用可能なツールを記述し、対話を支援できるが、企業はなお、特定のエージェントがそのツールを使用してよいかを決定する必要がある。XAAは、アイデンティティと認可のコンテキストをその接続に持ち込むことを意図している。

Kelleher氏は、OktaがCross App Accessを独自のOkta形式ではなく、オープン標準として提案したと述べた。また、MCPの拡張として受け入れられ、業界全体から幅広い関心を集めているとも語った。

Oktaは2026年8月にAgent SSOを一般提供した。Agent SSOにより、管理者はエージェントをワークロードプリンシパル、すなわち独立して管理される非人間アイデンティティとして登録できる。

対応するエージェントがアプリケーションに接続すると、Oktaは他の統制対象アイデンティティと並べてUniversal Directoryに配置できる。管理者は既存のアイデンティティプロセスを通じて、所有権、接続、適用可能なポリシーを確認できる。

このアプローチは、エージェント導入で繰り返し見られる弱点の解消を試みるものだ。初期のエージェントの多くは、ユーザーのアクセストークンを借用するか、ワークフロー内に保存された静的な認証情報に依存している。

借用したアクセスでは、帰属が不明確になる可能性がある。エージェントが従業員のアイデンティティを用いて記録を変更した場合、監査ログはソフトウェアの操作と人間による直接操作を区別できないかもしれない。

静的な認証情報は別の問題を生む。必要以上に長く有効なまま残り、設定ファイル、ログ、開発環境に現れる可能性がある。露出したシークレットは、攻撃者に永続的なアクセスを与え得る。

専用のエージェントアイデンティティは、行為者をスポンサーから分離する。ビジネス上の所有者は説明責任を負う一方、セキュリティシステムはエージェントと人に異なるポリシーを適用できる。

この分離は、割り当てられたタスクに必要な最小限のアクセスにアイデンティティを制限する最小権限を支援する。また、短命なトークンや、エージェントの廃止時におけるより明確な無効化も支援できる。

Oktaによれば、Auth0 for AI Agentsは開発者によるXAA対応エージェントの構築を支援できる。これらのエージェントは、Okta専用の環境を必要とせず、異なるアイデンティティプロバイダーと認証情報を保存できる。

オープン性は、プラットフォームロックインを懸念する顧客に対するOktaの訴求力を高める。1つのエンタープライズ環境では、Microsoft、Google、Salesforce、社内開発チーム、小規模ベンダーのエージェントが混在する可能性がある。

ポータブルな認可レイヤーがあれば、これらのエージェントは一貫したアクセス判断に従えるようになる。異なるアイデンティティシステムを持つ企業向けに製品を提供する開発者にとって、カスタム統合作業の削減にもつながる可能性がある。

しかし、公表された標準が自動的に相互運用性を生むわけではない。アプリケーションは標準を実装し、エージェントフレームワークは必要なコンテキストを受け渡し、アイデンティティプロバイダーは要求を一貫して解釈しなければならない。

セキュリティチームは、各判断で用いられるメタデータも信頼できなければならない。エージェントが有効なアイデンティティを保有していても、操作された指示を受け取ったり、安全でないアクションを選択したりする可能性はある。

アイデンティティは、誰が、あるいは何がアクセスを要求しているかを示す。それだけで、生成された計画が正確か、倫理的か、あるいは事業上の意図と整合しているかを判断するものではない。

したがって、Oktaの仕組みは重要である一方、その役割には限界がある。XAAは認可をより明示的かつ監査可能にできるが、モデルのセーフガード、データガバナンス、ネットワーク制御、アプリケーションレベルの検証を代替することはできない。

XAAが中立的な接続標準になれば、同社は恩恵を受ける。一方、エージェントプラットフォームが自社の統合コントロールプレーン内にアイデンティティ強制を囲い込む場合、同社への圧力は強まる。

その圧力は、Microsoftが拡大するエージェント・アイデンティティスタックにすでに表れている。

Microsoft、アイデンティティセキュリティを流通競争へと転換

Oktaにとって最大の競争上の課題は、企業がすでに利用しているアプリケーション、クラウドサービス、管理ツールに、Microsoftがエージェント・アイデンティティをバンドルできる点にある。

Microsoft Entra Agent IDは2026年4月に一般提供を開始した。AIエージェント向けに設計されたアイデンティティ構成要素、認証、認可、ガバナンス、セキュリティ制御を提供する。

その根底にある主張はOktaの考え方とよく似ている。エージェントには識別可能な所有者、管理されたライフサイクル、制限されたアクセス、監査可能な活動が必要だ。MicrosoftもOAuth、MCP、エージェント間プロトコルをサポートしている。

違いは流通力にある。Microsoftは、多数の業務アプリケーション、開発者向けサービス、クラウドインフラ、データプラットフォーム、セキュリティ製品を支配している。

Microsoftのagent identity documentationによれば、Agent 365は同社の統合カタログ兼管理レイヤーとして機能し、その下層のアイデンティティ基盤をEntraが提供する。

MicrosoftはエージェントのアイデンティティをConditional Access、Identity Protection、Microsoft Graph、そしてより広範なガバナンス環境に接続できる。すでにこのスタック内で運用している顧客は、統合された管理体験を好む可能性がある。

実用例はMicrosoftのDataverse統合に見られる。営業開発エージェントには専用のアイデンティティと、リードの読み取り、アウトリーチの記録、対象レコードの更新に限定したロールを付与できる。

管理者は無関係なテーブルや機密フィールドを除外できる。アクションは共有の従業員アカウントやアプリケーションアカウントとして表示されるのではなく、エージェントに帰属したままとなる。

このシナリオはOktaにとっての戦略的リスクを示している。Microsoftは、作業が行われるアプリケーション内にガバナンスを組み込めるため、エージェント・アイデンティティを独立したカテゴリーとして販売する必要がない。

Oktaの対応策は独立性だ。企業が複数のクラウド、エージェントビルダー、ソフトウェアエコシステムを利用するほど、その価値は高まる。中立的なアイデンティティレイヤーは、それらの境界をまたいで一貫したポリシーを提供できる。

Kelleherは、エージェント型アイデンティティが人間および非人間アイデンティティの特性を組み合わせるものだと強調した。Oktaはすでに両方のカテゴリーを管理しており、ライフサイクルガバナンス、アプリケーションアクセス、セキュリティシグナルに関する経験を持つ。

同社の統合カタログも、相当な出発点となる。Oktaは3月、同社のネットワークには8,200超の統合が含まれ、Boomi、DataRobot、Google Vertex AIに関するエージェントサポートがあると述べた。

この広がりが意味を持つのは、統合が実質的な強制機能を提供する場合に限られる。エージェントを登録するカタログ項目と、個々のツール呼び出しを認可し、迅速な失効をサポートする項目は異なる。

Microsoftも自社エコシステム内で同じ試練に直面している。集中型アイデンティティは権限を記述できるが、高速で複数ステップにわたるワークフローの中で、アプリケーションがそれらの権限を正しく強制しなければならない。

ほかのセキュリティベンダーも競争をさらに複雑にしている。特権アクセス企業は機密性の高い認証情報を管理でき、エンドポイントおよびクラウドセキュリティのプロバイダーはエージェント周辺の行動を分析できる。

AIセキュリティの専門企業は、プロンプトインジェクション、安全でないツール選択、データ漏洩、モデルの挙動に焦点を当てる可能性がある。エージェントに専用アイデンティティが付与された後も、こうした脅威は消えない。

想定される企業アーキテクチャには、複数の制御レイヤーが含まれる。争点となるのは、所有権、ポリシー、調査の中核となる場所をどのプラットフォームが担うかだ。

Oktaは、その場所をアイデンティティセキュリティの基盤にしたいと考えている。Microsoftは、特にMicrosoftアプリケーション全体で、Agent 365とEntraによる統合コントロールプレーンの提供を目指している。

顧客は、混在環境を通じてこうした主張を評価する。ネイティブなエージェントだけを統制するプラットフォームでは、セキュリティチームに断片化されたインベントリとポリシーが残される。

Oktaの独立性は、断片化に対する説得力のある回答となる。Microsoftの統合の深さは、運用上の複雑さに対する説得力のある回答となる。

これが本稿における主な競争構図だ。中立的なアイデンティティレイヤーと、アプリケーションおよびクラウドにバンドルされたコントロールプレーンの対決である。混乱はOktaが対話を始める助けになるが、それを誰が主導するかは相互運用性によって決まる。

アイデンティティ制御ではエージェントの意図を判断できない

Oktaはエージェントがアクセスを許可される対象を制限できるが、有効な認証情報が安全な推論や正しい行動を保証するわけではない。

エージェントは認証に成功し、承認済みの権限範囲内にとどまりながらも、害を引き起こす可能性がある。要求を誤解したり、悪意ある指示に従ったり、許可されたアクションを組み合わせて意図しない結果を生じさせたりすることがある。

プロンプトインジェクションはこの隔たりを示す。攻撃者は、エージェントが読むコンテンツ内に隠された、または誤解を招く指示を埋め込める。エージェントはそれらの指示を自身のタスクの一部として扱う可能性がある。

アイデンティティ制御は、結果として生じる影響範囲を限定できる。しかし、エージェントの意思決定プロセスが操作されたことを常に認識できるわけではない。

同じ制約は誤った計画にも当てはまる。認可済みの財務エージェントが誤った口座を選択したり、アクションを重複させたり、誤った取引に承認ルールを適用したりする可能性がある。

キルスイッチは、不審な行動が検出された後に価値を発揮する。しかし、自律エージェントは、人間がパターンを認識してアクセスを失効させるまでに、多くのアクションを実行できる。

実行時認可は、この時間枠を狭めようとする。広範な恒常的アクセスを付与する代わりに、システムはアイデンティティ、コンテキスト、リスク、意図されたアクションを用いて個々の要求を評価する。

この評価の質は、信頼できるコンテキストに依存する。ポリシーは、正当なワークフローを妨げずに、通常の変動と危険な行動を区別しなければならない。

組織には信頼できるログも必要だ。エージェントのツール呼び出しを記録すれば調査担当者は事象を再構築しやすくなるが、ログはエージェント、人間のスポンサー、指示、認可判断、結果としての変更を結び付けなければならない。

成功したAPI呼び出しだけを示す記録では、説明責任は限定的になる。セキュリティチームは、なぜエージェントがAPIを呼び出したのか、どのデータがその判断を形作ったのかを把握する必要がある。

Oktaのシステムログおよびガバナンス機能は、この連鎖の一部に対応する。同社によれば、ツール呼び出し、アクセス試行、認可判断は、セキュリティ情報およびイベント管理システムに流すことができる。

これらの機能は、顧客が多様なエージェントフレームワークやアプリケーションで検証するまでは、同社の主張にとどまる。Okta自身の発表も、未リリース機能は遅れて提供される可能性があり、提供されない場合もあると警告している。

企業でのエージェント導入はまだ初期段階にあるため、独立した証拠は限られている。学術研究ではエージェント型システムのアイデンティティ管理の検討が始まっているが、本番環境のベンチマークはなお発展途上だ。

さらなる懸念は、所有権の質にある。人間のスポンサーを割り当てれば書面上の説明責任は生まれるが、その人物はエージェントのデータ、権限、依存関係、廃止条件を理解していなければならない。

組織が管理者によるレビューの速度を上回ってエージェントを導入すると、所有権は形式的なものになり得る。その結果、アクセス認定は十分なコンテキストを欠く別の承認キューとなるリスクがある。

エージェントの乱立は問題を悪化させる。主エージェントは、調査、分析、実行のために一時的なサブエージェントを作成する可能性がある。セキュリティポリシーは、それらの一時的なアイデンティティが権限を継承するかどうかを定めなければならない。

広範な継承は管理しやすいが、露出を増やす。短命なエージェントごとに個別の承認を求めれば、エージェント型ワークフローを魅力的にする速度が損なわれかねない。

これがOktaのAIエージェントセキュリティにおける中心的なトレードオフだ。企業はエージェントがシステムをまたいで迅速に動作することを望む一方、セキュリティチームは各アクションが制限され、帰属可能で、取り消し可能であることを求める。

制御が少なすぎれば、許容できないリスクが生じる。摩擦が大きすぎれば、自律的なワークフローは再び遅い一連の人間による承認に戻ってしまう。

最も強力な導入は、狭いタスクと明示的なデータ境界から始まる。たとえば、サポートエージェントは、クレジットの発行や顧客記録の変更を許可される前に、チケットを分類できる。

チームは、成功したデモだけでなく、失敗時の経路も検証すべきだ。所有権の期限切れ、操作された入力、過剰な権限、利用不能な強制サービスをシステムがどう扱うかを示す証拠が必要になる。

検索可能なナレッジベースは、チームが所有者、ポリシー、インシデント判断を文書化する助けになる。アクセス制御の代替にはならないが、レビュー担当者が必要とするコンテキストを保持できる。

顧客がアイデンティティ判断を、権限の縮小やより迅速なインシデント封じ込めに結び付けられるようになれば、Oktaの戦略はより説得力を増す。製品発表だけでは、その成果を示すことはできない。

Oktaの取り組みが機能しているかを示す3つのシグナル

標準の採用、顧客の拡大、クロスプラットフォームでの強制が、Oktaが混乱を持続的なアイデンティティセキュリティカテゴリーへ転換できるかを左右する。

最初のシグナルは、Okta自身の製品を超えたCross App Accessの採用だ。意味のあるインフラになるには、エージェント開発者、アプリケーションベンダー、競合するアイデンティティプロバイダーがこのプロトコルを実装しなければならない。

Oktaは9月のカンファレンスで、より広範な発表が近づいていると述べた。重要なのは、名前が挙がるパートナーの数ではない。購入者は、各統合が実際にどのアクションを認可できるのかを確認すべきだ。

登録のサポートはインベントリを提供する。スコープ付きでコンテキストに応じた認可のサポートは制御を提供する。迅速な失効のサポートは、エージェントが意図された役割から逸脱した際の封じ込めを提供する。

稼働する統合の増加は、Oktaの中立的プラットフォームという主張を強化する。採用が限定的であれば、XAAは業界の制御レイヤーではなく、Okta環境内の有用な機能にとどまる。

2つ目のシグナルは、顧客の更新と拡大の形だ。Kelleherによれば、初期のエージェント型取引の大半は1年契約であり、顧客とOktaには利用状況を理解する時間が与えられる。

これらの更新は、企業が評価段階を超えるかどうかを示す。購入者は、孤立したデモではなく、複数の業務プロセスにまたがる本番エージェントを統制する導入を探すべきだ。

追加のエージェントプラットフォームへの拡大は、アイデンティティが共通のコントロールプレーンを提供するという主張を裏付ける。実験的なプロジェクトにのみ結び付く成長は、混乱が依然として販売上の障壁であることを示唆する。

価格設定も別の手がかりとなる。Oktaのユーザー当たりの上乗せは初期購入を簡素化するが、エージェントの数と活動量は必ずしも従業員数に連動しない。

モデルは、保護されたエージェント、接続、トランザクション、あるいは認可イベントへと進化する可能性がある。どのような変更も、顧客が何を重視し、どの運用コストが最も重要なのかを明らかにするだろう。

安定していて理解しやすいモデルは、この分野の成熟を後押しする。複雑な従量課金は、Oktaのブループリントが解消しようとしている不確実性を再び持ち込む可能性がある。

3つ目のシグナルは、Microsoftや他のアイデンティティプロバイダーによる競争対応だ。MicrosoftのAgent 365 modelはすでに、統合インベントリとEntraを基盤とするアイデンティティおよびガバナンスを組み合わせている。

Microsoftがサードパーティー製エージェント向けのシンプルなガバナンスを拡充すれば、Oktaの独立性に関する主張は直接的な試練に直面する。Microsoftが自社環境内でのみ最も強力な存在にとどまれば、Oktaには異種混在のエンタープライズ環境で活躍する余地が生まれる。

顧客は、Microsoft 365、Google Workspace、Salesforce、クラウドプラットフォーム、カスタムアプリケーションをまたいだ強制適用を比較すべきだ。勝者に必要なのは、中央集約型のエージェント一覧だけではない。

アプリケーション境界を越えてエージェントのアイデンティティを維持し、最小権限を適用し、所有者を明示し、アクセスを一貫して終了させなければならない。また、セキュリティチームが調査や監査で利用できる証跡も提供する必要がある。

競合各社が共通標準を支持すれば、製品差別化が弱まったとしても、Oktaのより広範な論点は裏付けられる。独自方式が主流になれば、エージェントアイデンティティは新たなプラットフォーム境界となる。

Oktaのカンファレンスでのメッセージは、AIエージェントのセキュリティを単一の検知機能として扱っていない点で注目に値する。同社は、エージェントのライフサイクル全体にわたる説明責任とアクセスを軸に、この問題を位置付けている。

この枠組みは運用上の課題と一致している。エンタープライズは、誰がエージェントを作成したのか、なぜ存在するのか、どのリソースにアクセスできるのか、そしてどのように停止するのかを把握する必要がある。

ただし、アイデンティティは複数あるコントロールプレーンの一つにすぎない。モデルの安全策、アプリケーションの検証、ネットワーク監視、データガバナンス、人によるレビューはいずれも引き続き必要だ。

そのため、セキュリティの購買担当者はOktaのブループリントを検証フレームワークとして扱うべきである。各ベンダーに対し、実際のワークフローを通じて、検出、認可、所有権、ログ記録、取り消しを実証するよう求められる。

最も有力な証明は、意図的に制約を設けた本番導入から得られる。チームは、限られた情報を読み取り、人の承認を前提としたアクションを提案するエージェントから始められる。

次に、過剰な権限要求、ポリシーによる拒否、調査にかかる時間、廃止処理の正確性を測定できる。こうした結果は、洗練された自律型デモンストレーション以上のことを明らかにする。

OktaのAIエージェントセキュリティは、エンタープライズが分散した認証情報や孤立した制御を通じて自律型ソフトウェアを管理しなくなるという賭けでもある。市場は、専用のアイデンティティ、明確な所有権、継続的な認可へと向かっている。

未解決の問いは、混在環境全体にわたってそのレイヤーを誰が提供するのかという点だ。まずXAA統合、次に本番環境での更新、そしてMicrosoftのサードパーティー対応範囲を注視すべきである。

Oktaがこの3点すべてで前進すれば、混乱は持続的なアイデンティティ市場の機会へと変わる。導入が断片化したままであれば、バンドル型プラットフォームが優位性を維持するだろう。

エンタープライズチームにとって次の一歩は実践的だ。エージェントを一つ選び、すべての接続をマッピングし、許可されるすべてのアクションを文書化する。そのうえで、現在のアイデンティティシステムがカスタム作業なしに、そのエージェントを可視化し、制限し、監査し、アクセスを取り消せるかを問うべきだ。