こんにちは、ネクストモード株式会社のSaaSおじさん久住です。
今年もラスベガスで開催されているOktaneに参加しています！
今回は、9月23日に行われたセッション「Okta’s AI Roadmap: What's next in AI agent security」の参加レポートをお届けします。
AI エージェントが急速に増えるなか、Okta が「発見」「安全な接続」「リスクの把握」「即時停止」をどのようにつなごうとしているのか、今後のロードマップを中心に紹介します。
⚠️ 本記事は2026年9月23日時点のセッション内容と公開情報に基づきます。セッションで示された提供時期は変更される可能性があり、将来の機能を確約するものではありません。同時点の公式資料で Research Release や Beta と記載されている機能もあるため、最新の提供状況・ライセンスは Okta 公式情報をご確認ください。
セッション冒頭で示されたのは、AI エージェントの規模がこれまでのアプリケーション管理とは比べものにならない速度で増える未来です。
スライドでは、Fortune 500 企業が利用する AI エージェント数は、2025年の平均 15 未満から、2028年には平均 15万超へ拡大するという予測が紹介されました。一方で、適切なガバナンスを整備できていると考える組織は 13% にとどまるとされています。
Okta が課題として挙げたのは、次の4点です。
つまり、AI エージェントを単なるツールとして管理するのではなく、人やサービスアカウントと同じ「第一級のアイデンティティ」として扱うことが重要になります。
今回のロードマップは、AI エージェントを安全に運用するための4つの問いで整理されていました。
| 問い | 主なロードマップ項目 | 目指す状態 |
|---|---|---|
| Where are my agents? | エンドポイント／ネットワークからの発見、インポート範囲の拡大、Universal Agent Identity | 既知・未知を問わず、すべてのエージェントと所有者を把握する |
| What can they do? | MCP リソース接続、Configuration Designer、サードパーティ IdP 対応 | 必要なツールだけへ、統制された方法で接続する |
| What are they doing? | Agent Gateway、Agent Risk Analysis、Okta × Permiso、脅威検知、Intent-based Authorization | 実行時の行動とリスクを把握し、意図から外れた操作を止める |
| How do I respond? | Agent Gateway の Kill Switch、ServiceNow 連携 | 侵害・暴走時にアクセスとセッションを即時停止する |
個別機能がばらばらに並んでいるのではなく、発見から対応までを1つのIdentity Security Fabricでつなぐ構想になっている点が今回の大きなポイントでした。
最初のテーマは「Where are my agents?」です。セッションでは、すべての AI エージェントを把握できると自信を持つ CISO は 47% にとどまるというデータも紹介されました。
これに対して、Okta はエンドポイントとネットワークの両面から Shadow AI Agent Discovery を広げるロードマップを示しました。
EDR、Okta Verify、SASE を利用した AI エージェントの検出
さらに、Salesforce Agentforce、ServiceNow AI Platform、Amazon Bedrock などからのインポート対象を拡大し、Client ID Metadata Document（CIMD）や SPIFFE／SPIRE を使って、エージェント自身がアイデンティティを証明できる方向性も示されました。
「登録されたエージェントだけを見る」のではなく、端末や通信から未知のエージェントを発見し、所有者と接続先を含めて台帳化するところまでを狙っています。
次のテーマは「What can they do?」です。AI エージェントが企業データや業務システムを利用するには MCP サーバーや API への接続が必要ですが、接続ごとに OAuth クライアントや認証情報を手作業で管理すると、運用も監査も複雑になります。
セッションでは、次の4つが紹介されました。
さらに Configuration Designer では、エージェント、接続、委任チェーンを1つの画面とライブグラフで確認し、ホップ単位で追跡する構想が示されました。
Okta の Agent Gateway は、エージェントとツールの間に入り、認証情報をエージェントへ直接持たせず、短時間のトークンを払い出して各ツール呼び出しを記録します。接続を増やしながらも、統制点を増やしすぎない設計です。
接続を許可したあとに重要になるのが「What are they doing?」です。AI エージェントは自律的に複数の処理を連鎖させるため、静的な権限設定だけでは意図しない行動を検知できません。
セッションでは、次の機能がロードマップとして示されました。
AI Agent Identity Threat Detection & Response は、セッションでは 2027年第1四半期の GA 予定として紹介されました。保護対象のエージェントで異常を検知し、Okta Workflows や Kill Switch を起動する流れです。
また、Okta は2026年8月に Permiso Security の買収完了を発表しています。アイデンティティを「登録して権限を付与する」だけでなく、実際の行動を継続的に観測し、逸脱を捉える領域まで広げていることが分かります。
最後の問いは「How do I respond?」です。セッションでは、侵害や暴走を検知しても、AI エージェントのアクセスを数時間以内に取り消せる企業は 55% にとどまり、それでは遅すぎるという問題提起がありました。
そこで紹介されたのが、Agent Gateway を強制ポイントとして使う Kill Switch です。
セッションでは 2026年第4四半期の GA 予定として、次の動作が示されました。
ServiceNow との連携では、インシデント対応の流れからエージェント無効化とグローバルトークン失効を実行し、SaaS 全体へ被害が広がる前に止める構想も紹介されました。
「問題が起きないように権限を絞る」だけでなく、問題が起きた瞬間に止められることを前提に AI 活用を拡大する。この考え方は、AI エージェントを本番業務へ投入するうえで非常に重要だと感じました。
今回のセッションの要点は、次の4つです。
AI エージェントの数が人や従来のアプリケーションを大きく上回るなら、個別ツールごとの管理では追いつきません。Okta のロードマップは、人、非人間アイデンティティ、AI エージェントを同じ Identity Security Fabric の上で管理し、発見から接続、監視、停止までを一続きにする構想でした。
ネクストモードでは、AI エージェントのセキュリティ対策を含む Okta の導入から運用までを支援しています。Okta に関するご相談は、ネクストモードまでお気軽にお問い合わせください。