OktaのAIアイデンティティ戦略はMCPの経済性にかかっている

Oktaは、企業が新たな制御レイヤーに対価を払うかどうかが不透明ななか、具体的なAIアイデンティティ戦略によってGoogle Newsで注目を集めている。同社は、AIエージェント、Model Context Protocol接続、業務アプリケーションをまたぐ委任アクセスを中心に、アイデンティティ基盤を位置付けている。

この戦略により、Oktaの役割はログイン時の従業員保護にとどまらなくなる。企業には、エージェントの登録、権限の制限、下流接続の統制、そして委任された各アクションの背後にいる人間のアイデンティティの保持が求められる。

これは、誰が企業内のAI活動を制御するのかをめぐる、より広範な競争にOktaを引き入れるものだ。Microsoft、クラウドプラットフォーム、セキュリティベンダー、アプリケーションプロバイダーはいずれも有力な立場にある。Oktaの強みは中立性だが、独立したアイデンティティ層がリスクと運用コストを低減することを証明する責任も負う。

見出しの主張には慎重な検討が必要だ。MCPはエージェントによるツールへの接続方法を標準化できるが、プロトコル自体がモデル利用量やインフラ支出を自動的に減らすわけではない。コスト管理は、ツール検出、応答のフィルタリング、権限範囲、可観測性、そして各サーバーを取り巻くアーキテクチャに左右される。

したがって、Oktaには相互に関係する二つの機会がある。エージェントのアクセスを保護すること、そして不要なツール、データ、認証情報がすべてのワークフローに入り込むのを企業が防げるよう支援することだ。前者は同社製品に表れている。後者は、顧客が検証すべきビジネス上の成果にとどまる。

OktaはAIエージェントを統制対象のアイデンティティへと変えつつある

Oktaの中心的な取り組みは、すべての企業向けエージェントを、固有の権限、接続、ライフサイクルを持つアイデンティティとして扱うことだ。

Okta for AI Agentsは、エージェントの検出と登録のためのコントロールプレーンを提供する。また、これらのエージェントを承認済みのアプリケーション、API、認証情報、MCPサーバーに接続する。MCPサーバーとは、標準インターフェースを通じてAIアプリケーションにツールまたはデータを公開するサービスである。

このアーキテクチャは、自律型ソフトウェアによって生まれた問題に対応する。人間の従業員は通常、認識済みのアイデンティティプロバイダーを通じてアプリケーションに入る。一方、エージェントはAPI、サービスアカウント、保存されたシークレット、ユーザー委任トークンの間を移動しうる。

こうした経路では、しばしば記録が断片化する。あるシステムでは人間のユーザーが表示され、別のシステムではアプリケーション認証情報が表示され、さらに別のシステムではサービスアカウントしか記録されない。セキュリティチームは、誰がアクションを開始し、なぜ許可されたのかを再構築するのに苦労することがある。

Oktaは、エージェントを第一級のアイデンティティにしようとしている。そうすることで管理者は、エージェントに所有者を紐付け、許可するリソースを定義し、状況が変化した際にはアクセスを停止できる。

同社のAI agent controlsでは、Salesforce、AWS、Microsoft、ServiceNowなどの環境との統合を説明している。Oktaによれば、エージェントはUniversal Directoryにインポートでき、管理者に一元化されたインベントリを提供する。

このインベントリが重要なのは、企業がエージェントを単一の協調プログラムを通じて展開することはめったにないためだ。開発者は社内アシスタントを構築し、事業部門はベンダー提供のエージェントを導入し、SaaSアプリケーションは自律機能を追加する。その結果、セキュリティチームが一度もレビューしていない承認済みエージェントとシャドーエージェントの両方が含まれうる。

登録だけでは問題は解決しない。インベントリは、ポリシー、アクセスレビュー、監視、終了処理につながる場合に価値を持つ。そうでなければ、更新されなくなる別の資産リストになる。

Oktaのリソース接続モデルは、その強制適用の経路を提供する。管理者は、エージェントが到達可能な下流リソースを定義できる。また、委任トークン、仲介されたサードパーティーアクセス、管理された静的認証情報から選択できる。

同社は、MCPサーバーを一つのリソースタイプとしてサポートしている。Oktaのドキュメントによれば、同社のプラットフォームはサーバー登録、設定、ライフサイクル確認、トークン交換関係を管理する。MCP server architectureでは、Oktaが制御する認可と外部の認可サーバーも区別している。

OktaのオープンソースMCPサーバーは、管理自動化に対して関連するアプローチを取る。OAuthスコープを使って利用可能なツールを制限しながら、自然言語のリクエストを構造化されたOkta API操作に変換する。

このサーバーは、付与されたスコープに応じてツールをフィルタリングする。また、API呼び出し前にスコープを再度確認する。この二度目の確認は、セッション中に認証情報が変わった場合や、更新されたトークンの権限が少ない場合に重要となる。

実践例はその違いを示す。ITアシスタントはロックされたアカウントの一覧表示を必要とする一方、ユーザーを無効化すべきではない。スコープベースのツール読み込みなら、モデルにそのポリシーを記憶させるのではなく、無効化操作を隠せる。

このモデルは、エージェントに提示される危険な選択肢の数を減らす。また、認可をモデルの推論の外へ移すため、プロンプトインジェクションや誤った計画によって簡単に上書きされることもない。

直接的な変化は、Oktaがエージェント認証を発明したことではない。OAuth、サービスアイデンティティ、特権アクセス制御はすでに存在する。Oktaは、各接続を孤立した統合として扱うのではなく、統制対象のオブジェクトとしてのエージェントを中心に、これらの要素をパッケージ化している。

このパッケージ化により、Oktaは時機を捉えた製品ストーリーを得る。ただし、それが顧客の導入、統合、あるいは関連支出の拡大にどの程度つながるかは、まだ示されていない。

Google Newsで注目される本質は企業統制にある

より深いGoogle Newsの論点は、また一つのAI機能の発表ではなく、企業のエージェントポリシーをどこに置くかをめぐる競争である。

AIエージェントは、アプリケーション内部でマシンが開始するアクションの数を増やす。記録の取得、文書の作成、設定変更、アカウント作成、ワークフローの起動などが可能だ。各アクションは、インテリジェンスの問題になる前に認可の問題を生む。

誰がそのアクションを要求したのかが重要である。エージェント自身のアイデンティティも重要だ。対象アプリケーションも重要である。要求された操作と、人間ユーザーが既に持つ権限も同様に重要となる。

従来のシングルサインオンは、多くの場合、最初の問い、すなわち誰がログインしたかにしか答えない。自律型ワークフローでは、特にエージェントがアプリケーションの境界をまたぐ際、ログイン後も継続する認可が必要になる。

OktaのCross App Access、すなわちXAAは、その状況を想定して設計されている。制御されたトークン交換を通じて、エージェントがアイデンティティと認可コンテキストを下流アプリケーションへ持ち込めるようにする。

再利用可能なシークレットをエージェントに渡す代わりに、アイデンティティプロバイダーがリクエストを評価する。その後、特定のリソースと承認済みスコープに対するトークンを発行できる。

Oktaは当初、XAAをエージェントとアプリケーションを接続するオープンプロトコルとして提示した。同社の最初のCross App Access planは、よく知られた弱点を指摘している。つまり、ユーザーは統合ごとに個別に認証し、同意を与えることが多いという点だ。

エージェントがより多くのサービスに接続するにつれ、この方法は統制が難しくなる。同意画面は意思決定を従業員に分散させる一方、静的認証情報はそれを作成した人やプロジェクトより長く残る可能性がある。

XAAは、より多くの権限をアイデンティティプロバイダーと企業管理者に移す。ポリシーはエージェントがアクセスを要求する前に設定でき、下流アプリケーションは結果として得られるアイデンティティアサーションを検証できる。

このモデルは、AnthropicによるEnterprise-Managed Authorizationの取り組みを通じて実用的な支援を得ている。2026年6月のOktaベータガイドでは、Claudeをリクエスト元アプリケーション、Oktaをアイデンティティプロバイダー、参加するMCPサービスをリソースアプリケーションとして説明している。

Oktaが文書化したフローでは、ID-JAGと略されるIdentity Assertion JWT Authorization Grantを使用する。Claudeは認証済みユーザーのOktaトークンを送信し、要求された接続に対する別個のアサーションを受け取る。

このメカニズムは、一般的なサービス認証情報よりも多くのコンテキストを保持する。リソースは、どの企業、エージェント、ユーザーがリクエストに関与したのかを把握できる。

Enterprise-Managed Authorizationの安定版は、その後MCPエコシステムに導入された。authorization extensionにより、組織はユーザーに個別のOAuthフローを完了させる代わりに、アイデンティティプロバイダーを通じて対応サーバー接続をプロビジョニングできる。

この進展はOktaの戦略に重みを与える。独自機能ではエコシステムの参加を集めにくい場合がある。エージェントクライアントとリソースプロバイダーに支持されるプロトコルは、インフラになる可能性がより高い。

Oktaは2026年6月に、XAAパートナーグループの拡大を発表した。リストには、エージェントプラットフォーム、企業向けアプリケーション、MCPインフラに取り組む企業が含まれていた。こうした関係が意味を持つのは実運用の接続につながる場合に限られるが、Oktaがこの仕組みを孤立して構築しているわけではないことを示している。

圧力は複数のグループにかかる。アプリケーションベンダーは、企業管理型のアイデンティティアサーションを受け入れるか判断しなければならない。AIプラットフォームは、ツール呼び出しをまたいで委任アイデンティティを保持する必要がある。セキュリティチームは、既存のアイデンティティプロバイダーでエージェントを統制すべきかを選択しなければならない。

Microsoftは最も明確な構造的課題を提示する。同社は主要な企業向けアイデンティティプラットフォーム、生産性アプリケーション、クラウドサービス、そして拡大するエージェント環境を掌握している。この統合により、すでに同社のスタックに集中している顧客にとって、Microsoft Entraが標準的な選択肢となりうる。

クラウドプラットフォームもワークロードアイデンティティとサービス権限を管理する。SaaSベンダーは自社アプリケーション内で認可を強制できる。APIゲートウェイや専用のAIセキュリティ製品は、実行により近い場所でエージェントトラフィックを検査できる。

Oktaの反論は独立性にある。中立的なアイデンティティ層は、一つのクラウドで構築されたエージェントが複数の他社ベンダーのアプリケーションにアクセスする際も統制できる。単一のプラットフォームがワークフロー全体を支配していない場合、これは有用だ。

統合が浅いままであれば、中立性の価値は低下する。企業は、競合製品の上に位置するという理由だけでコントロールプレーンを導入しない。必要なのは、一貫したポリシーの強制、使いやすい監査証跡、そしてエージェントが実際に呼び出すアプリケーションへの対応だ。

MCPのコスト管理はツールの削減と応答の小型化から始まる

アイデンティティポリシーはMCPコストに影響を与えうるが、認可だけでエージェントが低コストになるわけではない。

MCPは、モデルがツールを検出し、呼び出すための共通の方法を提供する。この一貫性により、カスタム統合作業を減らせる。一方で、デプロイメントが多すぎるツールを公開したり、過剰なデータを返したりすると、新たなトークン、レイテンシー、可観測性のコストを生む可能性もある。

モデルは、ツール名、説明、パラメーター、応答スキーマをコンテキストとして受け取る場合がある。ツールカタログが大きくなるほど入力トークンを消費し、ツール選択も難しくなる。大きな結果は、呼び出し後にさらに多くのコンテキストを消費しかねない。

ここで、OktaのMCPセキュリティとコスト管理が交わりうる。権限を狭く絞ったエージェントには、その役割に必要なツールだけが表示されるべきだ。未認可のツールを除外することは、攻撃対象領域とコンテキストのオーバーヘッドの両方を減らす。

Oktaのオープンソースサーバーは、管理アプリケーションに付与されたOAuthスコープに基づいてツールを動的に登録する。認証情報にユーザー管理の権限がない場合、対応するツールはモデルの利用可能なセットに表示する必要がない。

これは有用なアーキテクチャ上の特性です。モデルの作業環境を外部ポリシーに準拠させます。「危険なツールを使わないでください」と指示するシステムプロンプトには依存しません。

ログイン障害を調査するサポートエージェントを考えてみましょう。ユーザー情報の取得、システムログの確認、認証要素のレビューが必要になるかもしれません。一方で、ブランディング設定、グループの削除、アプリケーションの削除にアクセスする必要はありません。

スコープを限定したサーバーであれば、こうした無関係な機能を提供せずに済みます。モデルが処理するカタログは小さくなり、管理者はその用途の境界をより明確に把握できます。

レスポンス設計も同様に重要です。すべてのユーザーを一覧表示するリクエストでは、数千件のレコードが返される可能性があります。結果全体をモデルに渡すと、トークンコスト、レイテンシー、不要なデータ露出が発生します。

サーバー側のフィルタリングにより、ロックされたユーザーのみ、あるいはポリシー別に集計した件数だけを返せます。データの近くでコードを実行すれば、コンパクトな結果をモデルに提示する前に答えを算出することもできます。

独立した研究も、より広範なコスト上の懸念を裏付けています。エージェント型コーディングタスクを対象とした2026年の研究では、入力トークンが費用の大きな部分を占め、繰り返し実行時には総使用量が大幅に変動し得ることが示されました。著者らはまた、トークン消費量が多いほど精度が高くなるとは一貫して言えないことも明らかにしています。

これらの知見はOktaの製品を測定したものではありません。標準化されたツール接続によって支出が削減されると安易に想定するのではなく、購入者がワークロード単位の証拠を求めるべき理由を示しています。

したがって、MCPのコスト制御には複数の層が必要です。

• IDポリシーにより、各エージェントが到達できるサーバーを制限する。

• OAuthスコープにより、サーバーが公開する操作を制限する。

• ツール探索により、すべてのリクエストにすべてのスキーマを読み込むことを回避する。

• サーバー側フィルタリングにより、返却データのサイズを削減する。

• 使用状況テレメトリーにより、モデルとツールの消費量をエージェントまたはチームに帰属させる。

• 予算とレート制限により、制御不能なアクティビティを生む前にループを停止する。

• 人間による承認により、破壊的な操作や異常に高コストな操作を中断する。

Oktaは最初の2層に直接対応し、最後の承認層にも寄与しています。同社の2026年MCPリリースノートでは、破壊的なアクションの前に人間による監督を要求できるMCP Elicitation APIのサポートが説明されています。

同社が経済性全体をコントロールするわけではありません。モデルプロバイダーがトークンの挙動を決定し、エージェントプラットフォームがツールをどのようにコンテキストへ取り込むかを決め、MCPサーバー開発者がレスポンスサイズを決定します。企業チームはスコープと承認ポリシーを設定します。

このため、「MCPのコスト制御」は単一のOkta機能ではなく、共有されたシステム上の課題です。Oktaは、エージェントが認可されたアクセスのみを受け取るようにすることで、その前提条件を改善できます。しかし、アクセスが許可された後の推論効率を保証することはできません。

セキュリティとコストは乖離する場合もあります。厳格に認可されたエージェントでも、計画が失敗すれば承認済みツールを繰り返し呼び出す可能性があります。低コストのワークフローでも、過剰な権限を持つ認証情報を使用していれば安全ではありません。

企業は両方の側面を測定すべきです。セキュリティ指標には、拒否されたリクエスト、未使用の権限、休眠中のエージェント、認証情報の経過年数、特権操作が含まれます。コスト指標には、入力トークン、出力トークン、ツール呼び出し、リトライ、レスポンスサイズ、レイテンシーが含まれます。

最も説得力のある顧客成果は、この2つを結び付けるものです。たとえば、エージェントに認可されたツールセットを削減すれば、スキーマ用トークンを減らすと同時に、攻撃者が利用できる特権経路の数も減らせる可能性があります。

顧客がその証拠を公表するまでは、コストに関する主張は最小権限のもっともらしい帰結にとどまります。Okta自身が実証した節約として提示すべきではありません。

Okta AI Agentsは依然として導入と実証のギャップに直面している

Oktaは一貫性のある制御モデルを構築していますが、商業的な論拠は、デモンストレーションやパートナー発表を超えた本番導入に左右されます。

最初の不確実性は顧客の緊急性です。企業がエージェントのアクセスを明確に懸念している一方で、多くの導入は限定的なパイロットにとどまっています。社内アシスタントが数個しかない企業であれば、既存のクラウドロールやアプリケーションOAuth設定を通じて権限を管理できるかもしれません。

Oktaの価値は、エージェントが部門やベンダーをまたいで増加する際に高まります。その段階では、別々のインベントリー、認証情報、承認プロセスが運用上の摩擦を生み出します。

同社は、顧客がその閾値に到達していることを示す必要があります。登録済みエージェント、アクティブなリソース接続、統制対象のMCPサーバー、継続的なポリシー評価は、関心に関する大まかな声明以上のことを明らかにするでしょう。

2つ目の不確実性はエコシステムのカバレッジです。XAAは、リクエスト元アプリケーション、IDプロバイダー、リソースアプリケーションが互換性のあるフローを実装している場合に最も機能します。参加者が1つでも欠けると、ワークフローは静的シークレットや別個の同意プロセスへ戻らざるを得なくなります。

Oktaのパートナー拡大は、特にClaudeおよび参加するMCPプロバイダーをめぐる動きとして心強いものです。しかし、ベータ版ドキュメントは導入上の制約も示しています。管理者は、アプリケーション、認証情報、issuerの詳細、委任された呼び出し元、リソース接続を正しく構成しなければなりません。

このセットアップは明示的であるため、制御を提供します。一方で、管理作業も発生します。購入者はその負担を、より簡素なゲートウェイ構成や、すでにクラウドおよびアプリケーションプラットフォームに含まれているネイティブ制御と比較するでしょう。

3つ目の不確実性はプロトコルの成熟度です。MCPは急速に進化しており、認可サポートもそれに伴って変化してきました。企業は、異なるOAuth前提、未完成のメタデータ、または互換性のない登録動作を用いるサーバーに遭遇する可能性があります。

Oktaの現行ヘルプドキュメントによれば、MCPクライアントは事前登録され、機密性のある認可コードクライアントを使用する必要があります。このワークフローではDynamic Client Registrationはサポートされていません。

事前登録は企業の監督を強化できます。しかし、自動的なクライアントオンボーディングを前提に設計されたツールとの統合を遅らせる可能性もあります。Oktaは中央集権的なガバナンスと、MCPの普及を後押しした開発者体験とのバランスを取る必要があります。

4つ目の問題は人間の委任です。エージェントは正しく認証されていても、ユーザーの意図を超えて行動する可能性があります。有効なトークンは、リクエストが認可フローを満たしたことを証明します。モデルが指示を正しく解釈したことまでは証明しません。

プロンプトインジェクションは関連するギャップを生みます。悪意のあるコンテンツは、認証後にエージェントへ影響を及ぼす可能性があります。最小権限は起こり得る損害を制限しますが、モデルレベルの脆弱性を取り除くものではありません。

継続的な認可は役立つ可能性があります。IDレイヤーは、トークンを発行する前にスコープ、コンテキスト、リスクを評価できます。アプリケーションは、機密性の高い操作により強い検証を要求できます。人間による承認は破壊的な操作を停止できます。

こうした制御は、露出をなくすのではなく低減します。Oktaは、モデル防御、データ制御、ランタイム監視、アプリケーション認可を含む、より広範なエージェントセキュリティ設計の一層として評価されるべきです。

5つ目の不確実性は競合の対応に関するものです。Microsoftは、ID、生産性データ、Copilot、Azure、セキュリティテレメトリーを接続できます。Googleは、Workspace、クラウドID、エージェント開発サービスを組み合わせられます。Cloudflare、API管理企業、セキュリティスタートアップは、ゲートウェイでMCPトラフィックを統制できます。

Oktaの主な防御策はクロスプラットフォームの一貫性です。複数のクラウドとSaaSポートフォリオを持つ企業は、1つの独立したポリシーレイヤーを好むかもしれません。単一のプラットフォームに集中している顧客は、それを追加する理由をあまり見いださない可能性があります。

Oktaの財務基盤はこの機会を追求する余地を与えますが、投資家は現在の事業パフォーマンスと将来のAI収益を分けて考えるべきです。同社は2026年3月に2026年度の業績を報告しましたが、公開リリースではAIエージェント製品による重要な収益を切り分けていませんでした。

fiscal 2026 resultsでは、Oktaのより広い使命をAI、マシン、人間のIDを保護することだと説明しています。この表現は戦略的優先度を確認するものであり、顧客導入や製品の収益貢献を示すものではありません。

擁護可能な投資論には、大きな潜在市場以上のものが必要です。OktaがAIエージェントガバナンスを更新契約に付加し、契約価値を拡大し、バンドル型IDサービスに対して自らの役割を守れることを示す証拠が求められます。

Google Newsでの注目は、物語を増幅させることができます。しかし、開示された利用状況、顧客リファレンス、持続的な商業成果の代わりにはなりません。

OktaのGoogle Newsでの注目後に注視すべきこと

OktaのエージェントID戦略がインフラになりつつあるのか、それとも魅力的な製品ナラティブにとどまるのかを示すシグナルは3つあります。

最初のシグナルは、XAAおよびEnterprise-Managed Authorizationを中心とした本番導入です。パートナーロゴは標準策定の段階では有用ですが、管理者が実際のワークフローを統制できるかどうかはライブ統合によって決まります。

主要なSaaSプロバイダーが、一般提供製品でXAAに支えられたMCPアクセスを有効化する動向を注視してください。また、エンタープライズ顧客が、制御された単一のデモンストレーションではなく、複数ベンダーをまたぐ導入を説明するかどうかも見てください。

幅広い本番サポートは、Oktaの中立性に関する論拠を強化するでしょう。サポートが限定的であれば、顧客は新システムと並行して例外、静的認証情報、別個の同意フローを管理し続けることになります。

2つ目のシグナルは、測定可能な製品利用です。Oktaは最終的に、登録済みエージェント、アクティブな接続、保護されたMCPサーバー、AIエージェントガバナンスを利用する顧客数といった運用指標を提供すべきです。

収益開示はさらに有益です。購入者と投資家は、Okta for AI Agentsが新規購入を促進しているのか、既存導入を拡大しているのか、あるいは主に競争圧力からコアプラットフォームを守っているのかを知る必要があります。

顧客事例にはセキュリティ成果を含めるべきです。常時付与された権限の削減、エージェントのより迅速な廃止、管理されていない認証情報の減少、監査カバレッジの改善は、一般化されたAI需要に頼らず価値を示せます。

コスト成果には独自の証拠が必要です。有用な測定値には、より小さなツールカタログ、入力トークン消費の低下、反復呼び出しの減少、管理作業の削減が含まれます。Oktaは、こうした測定済みの結果を理論上の利点と区別すべきです。

3つ目のシグナルは、競合他社と標準化団体の対応です。Microsoft、クラウドプロバイダー、エージェントプラットフォーム、MCPゲートウェイベンダーは、類似したID交換パターンを採用したり、代替手段を推進したりできます。

相互運用可能なエンタープライズ認可へ収束すれば、Oktaはより大きな市場の中で中立的な実装として競争できます。各プラットフォームが閉鎖的な制御システムを構築すれば、顧客への到達力と流通が決定的になります。

標準の収束はOktaの商業的成功を保証するものではありません。しかし、委任されたエージェントIDに対する根本的な必要性を裏付けます。分断は統合コストを増大させ、統合されたコントロールプレーンという約束を弱めます。

Okta MCP securityを評価するセキュリティチームは、制約された1つのワークフローから始めるべきです。既知のユーザーに代わって機密性の高いアプリケーションへアクセスするエージェントを選びます。狭いツールセットを定義し、明示的なスコープを要求し、すべてのリクエストを測定します。

スコープベースのツールフィルタリングの前後でトークン消費を記録します。サーバーがデータをローカルでフィルタリングする場合のレスポンスサイズを比較します。ユーザー、エージェント、または接続が停止されたときにアクセスが失われるかをテストします。

次に、システムに負荷をかけます。エージェントの役割外のリクエストを導入し、アクティブなセッション中にスコープを取り消し、破壊的な操作には承認を要求します。その結果は、洗練されたデモンストレーション以上のことを明らかにするでしょう。

ナレッジワーカーもこの結果に関わっています。エージェントは、文書、カレンダー、メッセージ、社内ナレッジシステムをまたいで行き来する機会が増えています。明確な委任IDは、どのアシスタントが誰の権限の下でどのリソースにアクセスしたのかを、ユーザーが理解する助けになります。

Google ニュースを通じてこの動向を追っている読者は、3つの主張を分けて考えるべきだ。Oktaは、エージェント向けの重要なアイデンティティ基盤を提供した。MCPのガバナンスは、不必要なアクセスやコンテキストを減らせる。だが、いずれの事実も運用コストの低下や大幅な新規収益を保証するものではない。

戦略的な機会が現実的なのは、エージェントの接続性が認可の問題になりつつあるためだ。Oktaは今後、企業が独立したコントロールプレーンを求めていること、ベンダーがそのフローを支援すること、そして規律あるアクセス管理が測定可能な成果を生むことを証明する必要がある。

その証明は次の見出しではなく、導入実績、利用指標、顧客成果の中に現れる。問われるのは、OktaがGoogle ニュースでの認知度を、競合するエンタープライズプラットフォームをまたいで稼働するエージェントのデフォルトのアイデンティティレイヤーへと転換できるかどうかだ。