こんにちは、IdentityチームのTamaduです。
最近、「社内のAIエージェントをどう統制・管理するか」というテーマが、少しずつ注目を集めるようになってきたと感じています。
ユーザーやサービスアカウントの管理にはそれなりに慣れてきた（ほんと？）一方で、「AIエージェントを、どこまで人と同じように扱うべきか？」という問いに、まだ自信を持って答えられない方も多いのではないでしょうか。
そんな中で気になっていたのが、Oktaが提供する「Okta for AI Agents」というプロダクトです。公式ドキュメントやニュースをひと通り確認してみると、「AIエージェントを人と同等のアイデンティティとして管理する」というコンセプトが打ち出されていたので、今回はその概要を、自分の理解と視点も交えながら整理してみたいと思います。
参考：https://www.okta.com/blog/ai/okta-for-ai-agents-general-availability/
1. AIエージェントが増えると何が起きるのか
まず前提として、ここ数ヶ月で「チャットボットに聞く」から「AIエージェントに任せる」へのシフトが進んでいると感じています。AIが単にテキストを生成するだけでなく、SaaSや社内システムのAPIを叩き、チケットを起票し、ドキュメントを更新し、場合によっては決済処理まで自動で動かすものも出始めています。
そして、こうしたエージェントが増えてくると、例によって、現場では「誰も全体像を把握できていない利用」が広がっていきます。以下3つのパターンが考えられます。
- データの持ち出し：個人が業務効率化のために、会社が把握していない外部の生成AIサービスへ、ブラウザ拡張やプラグイン経由で社内データを渡している
- 認証情報の管理漏れ：検証用に発行したAPIキーやトークンをエージェントに渡したまま、棚卸しされることなく本番環境でも動き続けている
- SaaS標準AIの過剰権限：SaaSに組み込まれたAI機能（SalesforceのAgentforce等）が、有効化された時点で想定以上に広い権限を持ったまま動いている
いずれも入り口は違いますが、結局は「誰の責任で」「どのエージェントが」「どのデータに」「どの権限で」アクセスしているのかが見えなくなる、という同じ問題に行き着きます。
人やサービスアカウントを前提に組み立ててきた運用フレームを、そのままエージェントに当てはめるには、限界があるという問題意識が、Okta for AI Agentsの背景にあるように思いました。
2. Oktaが提示する「Agentic AIフレームワーク」
Oktaは、こうした状況を「Agentic Enterprise への移行」と表現し、そのための考え方として「Agentic AIフレームワーク」を公開しています。
参考：https://www.okta.com/newsroom/press-releases/showcase-2026/
以下の3つの問いに「答えられます」と言える状態を目指そう、というのがこのフレームワークだと理解しています。
- AIエージェントはどこに存在しているのか
- AIエージェントは何に接続できるのか
- AIエージェントは何ができるのか
ここでポイントだと感じたのは、「どこにいるか」「何に繋がるか」「何ができるか」の3層を、人間と同じ「アイデンティティの問題」として扱っているところです。
セッション単位やアプリ単位ではなく、「エージェント」という新しい主体に対して、検出・登録・保護・ガバナンスを一気通貫でやろうとしているのが、Okta for AI Agentsの役割になります。
3. Okta for AI Agentsとは何か
公式の説明を自分なりに一言でまとめると、Okta for AI Agentsは「AIエージェント専用のID基盤」です。
参考：https://www.okta.com/products/govern-ai-agent-identity/
人と同じように、AIエージェントにも固有のアイデンティティを与え、「誰がこのエージェントのオーナーで、どのシステムにどの権限でアクセスしているのか」を管理するためのプロダクト、というイメージです。
機能としては以下の4つです。
- Discover（検出）
- Onboard（登録）
- Protect（保護）
- Govern（ガバナンス）
言い換えると、「管理できていないAIエージェントを見つけて」「正規のIDとしてオンボードして」「最小権限とアクセスレビューを効かせながら運用する」ための仕組みを提供する、という流れになっていると理解しています。
4. Discover（検出）：管理できていないAIエージェントをどう見つけるか
ブラウザ経由の利用を可視化する
まず「どこにエージェントがあるのか」を知る必要があります。
ここで登場するのが、Oktaの Identity Security Posture Management（ISPM）と、Secure Access Monitor（SAM）というブラウザプラグインです。
SAMは管理対象のChrome向け拡張機能で、ブラウザ上で発生したOAuthグラント（同意）の情報を収集し、ISPMに連携します。ISPM側ではそのグラントを分析し、「これはAIエージェントを動かすために使われていそうだ」というものを自動でAIラベル付けして、棚卸しできるようにしてくれます。
つまり、「ブラウザ操作をすべて記録する」というよりは、「どんなOAuth同意が、誰のアカウントから、どのアプリに対して与えられたか」を起点に、未管理のAIエージェントをあぶり出すアプローチになります。
※このブラウザ検出（SAMプラグインによるOAuthグラント検出）は、2026年4月29日のリリースで一般提供（GA）になりました。利用には Okta for AI Agents のライセンスが必要です。導入時は最新の公式ドキュメントで提供ステータスをご確認ください。
参考：
- https://help.okta.com/ispm/en-us/content/topics/releasenotes/ispm/ispm-rn.htm
- https://help.okta.com/oie/en-us/content/topics/ai-agents/ai-agent-identify-with-oauth.htm
- https://help.okta.com/oie/en-us/content/topics/ai-agents/ai-agent-configure-sam-plugin.htm
管理しているSaaS内のAI機能も検出する
次に、すでに管理しているSaaSの中で動いているAIエージェントを検出します。
Salesforceのような「正規環境」とISPMを連携すると、そのプラットフォーム上で動いているAIエージェントを列挙し、オーナーや権限、対象データを評価できます。
このあたりは、「SaaSそのものの統制はそこそこできているけれど、その中で動いているAIまでは追えていない」という現場に刺さるところだと思いました。
過剰な権限を洗い出す
AIエージェントに付与されているOAuthスコープや権限の分析も行います。
「とりあえず全部入りのスコープでトークンを渡してしまったエージェント」や、「本来Readだけで足りるのにWrite権限まで付与されているエージェント」を一覧できるのは、正規の権限を持つエージェントが、外部から渡された悪意ある指示に従わされ、その権限を悪用されてしまうリスクへの対策の観点でも重要だと感じました。
5. Onboard（登録）：AIエージェントを「正規のID」にする
エージェントをOkta上のアイデンティティとして登録する
Onboard（登録）では、検出したAIエージェント（やMCPサーバー）を、Okta org内の専用ディレクトリに「AIエージェント」のアイデンティティとして登録します。
このとき、次のような情報をメタデータとして持たせることができます。
- エージェントのオーナー（人間の責任者）
- 所属部門やプロジェクト
- 利用目的や利用範囲
- 関連するシステムやデータの種別
ユーザーの属性管理に近い感覚ですが、主体がエージェントである点が違いです。
「このエージェントが問題を起こしたら誰が責任を持つのか」「どの部署の業務として動いているのか」といったトレーサビリティを、アイデンティティのレイヤーで担保しようとしているのがポイントだと思います。
既存IdPを置き換えなくてもよい
個人的に面白いと感じたのが、Okta for AI Agentsは、既存のIdPをOktaに統一していなくても導入できる点です。
つまり、「普段 Entra IDで認証しているけれど、AIエージェントのアイデンティティ管理だけOkta for AI Agentsを使う」といった構成が、実際公式に想定されています。OIDCやSAMLといった標準的なフェデレーションをベースに、既存IdPに足す形で導入できる、という設計思想です。
参考：https://www.okta.com/blog/ai/agent-idp-identity-stack/
既に別のIdPがしっかり根付いている企業でも、「AIエージェント専用のIDレイヤー」としてOktaを追加しやすいという意味で、検討しやすいポイントだと感じました。
6. Protect（保護）：エージェントの権限とアクセスをどう絞るか
Onboard（登録）まで進むと「どのエージェントが何者か」は見えるようになりますが、次の課題は「何ができるかをどう制御するか」です。
リソースタイプとスコープの設計
Okta for AI Agentsでは、エージェントがアクセスする対象を「リソースタイプ」として定義し、その上で発行するトークンのスコープを細かく決めていきます。
公式ドキュメントには、ユースケースに応じたリソースタイプの選び方や、付与すべき最小スコープの考え方が整理されており、AIエージェント向けの「最小権限設計ガイド」として参考になりそうです。
参考：https://help.okta.com/oie/en-us/content/topics/ai-agents/ai-agent-resource-comparison.htm
ユーザーのロールベースアクセス制御や、サービスアカウントのスコープ設計と似ている一方で、「エージェントが複数システムにまたがってオーケストレーションする」前提で設計する必要があるのが違いだな、と感じました。
異常時に止められる
運用上嬉しいのが、エージェントを一括で止める「無効化（agent deactivation／キルスイッチ）」の仕組みです。
特定のAIエージェントが不審な振る舞いをしていることが分かったとき、ワンクリックでそのエージェントを無効化し、新しいトークンの発行や以後の認可をまとめて遮断できます。
トークンが複数のSaaSやAPIにまたがって発行されている状況で、「どこで何を止めればいいか」を個別に追いかけるのは現実的ではないので、エージェント単位で一括で止められるのは、インシデント対応の観点でも良いと感じました。
7. Govern（ガバナンス）：ログと監査
Protect（保護）で日常的なアクセス制御を行いつつ、さらにガバナンスのレイヤーとして効いてくるのが監査の機能です。
ログと外部監視基盤との連携
AIエージェントのアクティビティ（ツール呼び出し、アクセス試行、認可判断など）は、OktaのSystem Logにイベントとして記録され、既存のSIEMや監視基盤にストリーミング連携できます。
人、サービスアカウント、AIエージェントをまたいで、「誰（どの主体）が、どの経路で、どのリソースにアクセスしたか」を追跡できるのは、インシデント調査やコンプライアンス対応の面でも大きなメリットです。
8. 機能のまとめ
ここまでの内容を整理すると、Okta for AI Agentsは次の要素で構成されていると理解しました。
| 項目 | 役割・機能の概要 |
|---|---|
| Discover（ISPM / SAM） | SAMプラグインによるブラウザOAuthグラント分析や、SaaS連携を通じて、既知・未知のAIエージェントを検出し、所有者・権限・接続先を見える化する。 |
| AI Agent Identity（Directory） | 検出したエージェントやMCPサーバーを、Okta上の専用ディレクトリにアイデンティティとして登録し、オーナーやメタデータを紐づける。 |
| Resource Types & Scopes | エージェントがアクセスするリソースタイプとトークンスコープを定義し、短命な資格情報＋最小権限でのアクセスを実現する。 |
| Agent Deactivation（キルスイッチ） | 異常検知時に、対象エージェントを無効化し、新規トークン発行・以後の認可を一括で遮断する。 |
| System Log & SIEM連携 | AIエージェントのアクティビティをログとして出力し、既存の監視・分析基盤と連携する。 |
9. AIプラットフォーム連携とIdP非依存な設計
各種AIプラットフォームとの統合
Okta for AI Agentsは、外部プラットフォーム上で作られたエージェントを取り込むためのプレビルト連携を備えています。確認できた範囲では、Salesforce Agentforce、Amazon Bedrock AgentCore、ServiceNow AI Platformとの連携が挙げられていました。
特にAmazon Bedrock AgentCoreとの連携では、Bedrock上で構築したエージェントについて、オーナー割り当て・ライフサイクル管理・不正なエージェントの無効化などを、プラットフォームをまたいでOkta側で統一的に扱う方向性が示されています。
参考：https://www.okta.com/newsroom/articles/okta-expands-ai-agent-security-to-any-idp/
「AIプラットフォームごとにバラバラにエージェントを作っているうちに、権限管理や棚卸しが追えなくなってきた」というタイミングで、このあたりの連携は良さそうと思いました。
他IdPとの併用を前提にしたアーキテクチャ
先ほども少し触れましたが、Okta for AI Agentsは、既存の人間向けIdPを置き換えずに導入できるのが特徴です。
「ユーザーはEntra ID、AIエージェントはOkta for AI Agents」というような分担も、公式に想定されているパターンのひとつになっています。
10. まとめ
ここまで、公式情報をベースにOkta for AI Agentsの全体像を整理してきました。最後に、ポイントを振り返ります。
- AIエージェントを「人と同等のアイデンティティ」として扱うプロダクトであり、Discover（検出）→ Onboard（登録）→ Protect（保護）→ Govern（ガバナンス）というライフサイクルで一気通貫に管理する設計になっている
- 特に、管理されていないAIエージェントの検出と最小権限によるアクセス制御、そして即時遮断できる機能は、増え続けるエージェントを安全に運用するうえで有用
- 既存のIdP（Entra IDなど）を置き換えずに足す形で導入できるため、「まずはAIエージェントのIDレイヤーから」という段階的な始め方がしやすい
最後までお読みいただき、ありがとうございました。
※本記事は確認時点の公式情報に基づく個人的な整理であり、提供機能・名称・ステータスは今後変わる可能性があります。導入検討時は最新の公式ドキュメントをご確認ください。
