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 エージェント活用への第一歩となるでしょう。
