一般的に社員が業務アプリケーションを操作する際は、担当者ごとに権限が細かく定められており、できることとできないことが明確に制御されています。ところがAIエージェントを経由した場合、その制御がまったく及ばないケースがあります。AIエージェントが誰に代わって何にアクセスできるのか、適切に管理されていないためです。
この問題に対するOktaの答えが、2026年4月30日に一般提供（GA）を開始した「Okta for AI Agents」です。本稿では、この製品が生まれた背景にある課題と、その解決策としてOktaが取り組む考え方を詳しく見ていきます。
AIエージェントの権限管理が課題に
かつてのAIといえば、質問に答えるチャットボットのようなものが主流でした。しかし今日のAIエージェントは、人間の代わりに自律的に振る舞う存在へと大きく進化しています。見積もりの作成、在庫の確認、出荷の調整、外部SaaSを使ったスケジュール調整など、複数のシステムをまたいで実際のビジネスタスクをこなすことが可能になりました。
この進化が新たなセキュリティリスクをもたらしています。タスクが複雑になるほど、AIエージェントが接続するアプリケーションの数と必要な権限は増加します。また、現在多くの企業でAIエージェントを動かす際には、シークレット（秘密の文字列）、特権アカウント、APIキーといった強力な権限が使われています。これはAIエージェントを構築する人間が、必ずしも一社員が持つべき権限の範囲を意識して実装するわけではないためです。
こうしたことで起こりうる極端なリスクの例を挙げましょう。人事・給与システムにアクセスする場合、通常は自分自身の給与明細しか閲覧できません。しかし、AIエージェントが本人に対応しない過剰な権限を持っていた場合、AIエージェントへの依頼の仕方次第では、本来参照できないはずの他人の給与情報を取得できてしまう可能性もあるのです。
より日常的なシーンでも同様の問題は起こります。営業担当者であれば、自分が担当する顧客への見積もり作成や在庫確認の権限は適正に持っている一方で、他の担当者の顧客情報を編集したり、在庫数を書き換えたり、価格マスターを変更したりすることは、通常の業務アプリケーション操作では決してできない行為です。ところがAIエージェントを構築する側は、「この社員が通常できること」を正確に把握して実装するとは限らないため、AIエージェント経由で依頼すると在庫が書き換わってしまうといったことが起こりうるのです。
AIエージェントも「ひとつのアイデンティティ」として扱うOkta
人間の社員がアプリケーションにログインして業務を行う際、Oktaは認証と認可の機能を通じて「誰が」「何にアクセスできるか」を制御してきました。Okta for AI Agentsでは、この仕組みをAIエージェントにも適用します。ユーザーがAIエージェントに指示を出すと、エージェントはOktaにクレデンシャルをリクエストします。Oktaはそのユーザーが誰であるかを特定し、その人に対応した適切な権限の範囲でのみエージェントが動けるよう管理します。つまり、AIエージェントができることは、そのエージェントを動かしているユーザーが通常できることと必ず対応していなければならない、という原則を仕組みとして実現するのです。（このことをOn-Behalf-Ofフローと一般的に呼びます。）
この仕組みにはもうひとつ重要なメリットがあります。AIエージェントが意図しない動きをした場合や、ユーザーが退職などの理由でそのAIエージェントを使うべきでなくなった場合でも、Oktaがクレデンシャルの発行元として介在しているため、AIエージェントのアクセスをその場で止めることができます。アプリケーション側でなくOktaが認可を管理しているからこそ、確実に制御できるのです。
AIエージェントのライフサイクル全体を守る
Okta for AI Agentsは、AIエージェントの管理を「可視化」「登録」「制御」「統制」という4段階のライフサイクル全体でカバーします。
管理の出発点は、企業内にどんなAIエージェントが存在するかを把握することです。Oktaでは、AIエージェントを2つのアプローチで検出します。ひとつは、Oktaの提供するブラウザ・プラグインでトラフィックを監視し、AIエージェントがリソースへの接続を試みる際に発生するOAuthの同意画面を検知する方法です。もうひとつは、企業が利用するAIプラットフォームに対し、APIを用いてAIエージェントを検出する方法です。
存在が確認されたAIエージェントは、人間のユーザー管理と同様、OktaのUniversal Directoryに登録します。登録されたAIエージェントに対しては、どのリソースに、どの権限範囲で接続できるかをOktaが制御します。そのアクセス状況を定期的に棚卸しして不要な権限を整理していくことで、AIエージェントの管理が継続的なサイクルとして機能します。
2026年4月30日の一般提供開始に合わせ、このサイクルをより実践的に運用するための機能を新たに追加しました。まず、登録のハードルを大きく下げる機能として、AIエージェントを作成した環境からUniversal Directoryへの一括インポートが可能になりました。現在対応しているのはAmazon Bedrock AgentsおよびAmazon Bedrock AgentCore、Salesforce Agentforce、ServiceNow AI Agent Studioの3つで、近日中にはWorkdayやGoogleといったグローバルプレイヤーとの連携も予定しています。
この機能は、特定のサービスに依存せず、企業がどの環境を使っていても中立な立場から一元管理できるというOktaのポジションを体現するものです。
また、AIエージェントが企業リソースにアクセスするための接続方式（Resource Connection）に、新たにアプリケーションおよびMCPサーバーへの対応を追加しました。
Oktaが最も推奨する接続方式は、Cross App Access（XAA）と呼ばれる新たなプロトコルを使った認可サーバー方式です。OktaがユーザーとAIエージェントの間に立ち、きめ細かな認可制御を実現するこのモデルは、ユーザー同意画面を必要とせず、ガバナンスの観点からも最も価値が高いものです。ただし、XAAはOktaが主導してIETF OAuthワーキンググループで標準化を進めている途上の技術であり、対応するにはアプリケーション側の対応も必要です。自社開発アプリケーションへのきめ細かな認可制御が必要な場面ではXAAが最適解ですが、AIエージェント活用の爆発的な広がりの中で、すべてのシステムがすぐにXAAに対応できるわけではないのも現実です。
これまでOktaが対応してきたもうひとつの方式が、シークレットやサービスアカウントの管理です。これはOAuth 2.0に対応していないレガシーなシステムや、ユーザー名とパスワードで制御するタイプのSaaSに対して、Oktaがその認証情報を安全に保管し、必要に応じてAIエージェントに提供するとともに定期的にパスワードをローテーションするものです。
そして今回新たに追加したのが、アプリケーションおよびMCPサーバーへの接続方式です。これは、XAAには対応していないがOAuth 2.0には対応しているサードパーティアプリケーションやMCPサーバーを対象に、OktaがSecure Token Service（STS）として仲介し、AIエージェントのアクセスを制御するものです。ユーザーは初回に一度だけ同意画面でOktaに認可を付与すれば、それ以降はOktaが仲介するかたちで接続するアプリケーションに必要なトークンを管理します。これにより、管理されていない中で、ユーザーは何も考えずに承認してしまうような「同意疲れ」のリスクを抑えながら、ユーザーコンテキストに紐づいた制御、管理者による統制を実現できます。GitHub、Jira、Microsoft Office 365、ServiceNow、Slackなどとの接続検証も社内で完了しており、OktaのアプリケーションカタログであるOkta Integration Network（OIN）を通じて順次対応を広げていきます。
IdPの種類を問わない中立な基盤
重要なポイントとして、Okta for AI AgentsはOktaをIdP（アイデンティティプロバイダー）として利用していない企業でも活用できます。例えばMicrosoft Entra IDで社内インフラをまとめている企業においても、ユーザーの認証ポイントはそのままに、AIエージェントの認可部分だけをOktaが担う構成が可能です。正社員をEntra IDで認証しながら、外部スタッフはOktaが担当するという使い分けは、実際に多くの企業で採用されてきた実績のある構成でもあります。AIエージェントの管理においても同じことが言えます。特定のIdPやサービスに縛られず、企業が現在使っている環境を活かしながらガバナンスを整備できる。この中立性がOktaの強みであり、今後の技術変化にも対応できる基盤でもあります。
Okta for AI Agentsは、「すべてのアイデンティティを安全に管理する」というOktaが長年取り組んできたテーマの延長線上にあります。従業員、顧客、パートナー、そしてサービスアカウントやAPIキーといった非人間アイデンティティ（NHI）と同様に、AIエージェントもひとつのアイデンティティとして管理する。それがこの製品の本質です。
AIエージェントの活用は今後もさらに加速していきます。その導入・活用計画の早い段階から、アイデンティティ管理の視点を組み込んでおくことが、将来のリスクを最小化するうえで重要な一手となるでしょう。
