AIエージェントの普及に伴い、企業のアイデンティティ管理は新たな局面を迎えています。人間のユーザーに加え、さまざまなアプリケーションやシステムと自律的に連携するAIエージェントが増えることで、「どのAIエージェントが」「どこに」「どのような権限で」アクセスしているかを把握し制御することが、IT管理者にとって重要な課題となっています。今回は、こうした認可管理の課題と、その解決策としてOktaが提唱する「Cross App Access」（XAA）について解説します。
生成AIからAIエージェントへの移行で高まるリスク
人間がChatGPTやGeminiといった生成AIを直接利用する段階でも、ハルシネーションや著作権への配慮、個人情報の取り扱い、プロンプトインジェクションなど、AI固有のリスクは存在します。ただし、この段階ではAIが直接できることに限りがあるため、リスクの範囲はまだ限定的といえます。
問題は、その先のステップでAIエージェントを活用し、企業全体の業務を効率化しようとする場合です。AIエージェントは、Salesforce、Slack, Googleをはじめとする外部サービスや自社開発のアプリケーション、社内運用のデータベースなど、複数の企業内リソースと、AIエージェント向けの接続プロトコルMCP（Model Context Protocol）やAPIを通して連携して動作します。アクセス先が増えるほど、リスクも増大します。
また、AIエージェントは、ローコード・ノーコードの開発プラットフォームで容易に開発できるため、組織として把握していないAIエージェントが増殖していくという問題もあります。先進的な企業では、各部門で独自の開発が進んでいるケースも珍しくありません。こうした状況では、どこにAIエージェントが存在するかを把握し、どの企業内リソースにつながっているかを制御し、どのような権限で接続しているかを管理する必要があります。
既存のOAuthに潜む構造的な課題
人間のアクセス管理であれば、Oktaのようなアイデンティティ管理基盤を使って「どのユーザーがどのシステムにアクセス可能か」を一元管理するシングルサインオンの世界を構築できます。ところが、AIエージェントが各アプリケーションと連携する場面では状況が異なります。
現在、システム間連携で最も広く使われているのがOAuthというプロトコルです。OAuthを使った連携では、「このアプリ（またはAIエージェント）がGoogleのファイルにアクセスしますがよろしいですか」といった同意を求める画面がユーザーに表示されます。多くのユーザーは内容を詳しく確認せずに「はい」を押してしまいますが、そもそもこの仕組み自体、企業内利用における構造的な問題があります。
どのユーザーがどのAIエージェントを使ってよいか、そのAIエージェントがどこに接続してよいかという判断は、ユーザーが行うものではなく、組織のポリシーとして管理されるべきものです。それが、接続認可の管理が連携先のアプリケーション側で行われているため、企業内利用においてもユーザーへの同意確認が生じています。
アイデンティティを保存し管理するアイデンティティプロバイダー（IdP）からは、ユーザーがAIエージェントにログインしているところまでは把握できますが、その先のAIエージェントがどこに接続したかについては、AIエージェントとアプリケーション間で完結してしまうためIdP側では把握できません。ユーザーの認証とAIエージェントの認可が分断されてしまうのが、OAuthの構造的な課題です。
もちろんOAuthの同意フローはユースケースによっては有効なものです。例えば、航空会社でチケットを購入した際、「フライト情報をカレンダーに登録しますか」と聞かれ、ユーザーが同意するというケースであれば、ユーザー自身が判断して同意するこのフローは自然です。問題は、このフローがそのまま企業内利用にも適用されている点です。
同意画面はセキュリティリスクとしての側面も持っています。偽の同意画面にユーザーを誘導し、何も考えずに「はい」を押させることでIdPからトークンを不正に発行させるという、同意画面を悪用したフィッシング攻撃が存在します。ユーザーが同意操作に慣れているほど、このリスクは高まります。
Cross App Accessが目指す世界
こうした課題を解決するためにOktaが提唱するのが「Cross App Access（XAA）」です。これは、各連携先アプリケーションが個別に行っていた認可管理をIdP側に委譲することで、ユーザーの認証だけでなくAIエージェントのアクセス権限管理もIdPで一元的にコントロールできるようにするというものです。
Cross App Accessにはさまざまなメリットがあります。まず企業の管理者としてのメリットは、認証と認可コントロールが一元化できることです。これまでユーザーの認証はIdPで管理できていましたが、AIエージェントのアクセス認可は各アプリケーションに依存していました。Cross App Accessにより、この両方をIdPで一元コントロールできるようになります。実際にどのユーザーがどのAIエージェントを利用（認証）し、AIエージェントがどのアプリケーションへのアクセス権を取得したか（認可）のログも一元化されます。
セキュリティ面のメリットとしては、同意画面フィッシングの防止が挙げられます。Cross App Accessの環境では同意画面が出ないため、同意画面が表示されること自体「要注意」です。ユーザーの意識付けも必要ですが、同意画面を悪用したフィッシング攻撃への耐性を高めることができます。
ユーザー側のメリットは、都度の同意操作が不要になることです。ひとつのAIエージェントが在庫管理システム、販売管理システム、ファイルサーバーなど複数のリソースにアクセスする際も、その都度同意画面に対応する必要がなくなります。手間が省けるだけでなく、同意疲れによる不用意な同意を防ぐことにもつながります。
業界標準化の動きと賛同企業の広がり
Cross App AccessはOAuthプロトコルを発展させた仕組みであり、IETFのOAuthワーキンググループに「Identity Assertion JWT Authorization Grant（ID-JAG）」という名称でドラフトとして採択され、標準化の議論が進んでいます。
また、AIエージェントが外部サービスと接続する際のプロトコルとして注目されているMCPの2025年11月アップデートにおいても、「Enterprise-Managed Authorization」という名称でID-JAGの定義が追加されました。標準化の動きが業界全体に広がりつつある状況です。
賛同企業の顔ぶれも広がっており、Automation Anywhere、AWS、Boomi、Box、Glean、Google Cloud、Grammarly、Miro、Salesforce、WRITERなど、エンタープライズ領域における主要なSaaSベンダーが名を連ねています（参照）。アプリケーション提供側においても同様の課題意識があることの表れといえるでしょう。
Cross App Accessの普及まで待たなければならないのか、という疑問も当然あると思います。標準化には時間がかかるため、OktaではCross App Accessに非対応の既存OAuthアプリケーションに対応できる現実解を提供しています。
この仕組みでは、通常AIエージェントとアプリケーション間で行われていたOAuthフローをOktaが代わりに実行します。AIエージェントがアプリケーションへのアクセスを試みる際、Oktaが間に入ってOAuthフローを開始し、トークンの管理を担います。OAuthフローの性質上、途中で同意のステップは発生しますが、認可ポリシーの管理と可視性をIdP側に寄せることができます（Brokered Consent）。
Oktaとしては、Cross App Accessという標準の実現を推進しながら、段階的な移行を支援するこの現実解を同時に提供するという2段構えで対応しています。将来的にアプリケーション側がCross App Accessに対応した時点で、スムーズに移行できる設計になっています。
AIエージェントが普及する前に知っておくべきこと
AIエージェントが組織のあらゆる業務に関わるようになると、リスクを最小化する必要があります。皆様は、以下の3つの質問に答えられますでしょうか（参照）。
AIエージェントはどこにいるのか？
AIエージェントは何に接続できるのか？
AIエージェントは何ができるのか？
Cross App Accessを提唱するOktaは、ユーザーのアイデンティティ管理とAIエージェントの認可管理を統合するための基盤と「Okta for AI Agents」を提供しています。AIエージェントの導入や拡大を検討する企業にとって、こうした認可管理の課題を認識しその解決策を理解しておくことが、安全なAIエージェント活用への第一歩となるでしょう。
