AIエージェントのアイデンティティ管理に関するホワイトペーパー「Identity Management for Agentic AI」が OpenID Foundation から公開されている。
https://openid.net/wp-content/uploads/2025/10/Identity-Management-for-Agentic-AI.pdf
このホワイトペーパーでは、AIエージェントの認証・認可における課題と、既存の OAuth/OIDC では対応しきれないケースについて詳しく解説されている。本記事では、その内容を紹介する。
AIエージェントとは
ホワイトペーパーでは、AIエージェントを以下のように定義している。
the ability for the AI-based system to take 'action' based on 'decisions' made at model inference time to achieve specific goals
つまり、モデル推論時に「決定」を行い、特定の目標を達成するために「アクション」を取るシステムのこと。単にテキストを出力するチャットボットとは違い、外部サービスに対して自律的にアクションを実行するのが特徴。
具体例としては以下が挙げられている：
従来ソフトウェアとの根本的な違い
AIエージェントと従来のソフトウェアには、認証・認可の観点から重要な違いがあるとホワイトペーパーでは述べられている。
動作の違い
従来のソフトウェアは事前に定義されたルールと命令に従って動作する。一方、AIエージェントは非決定的で柔軟な振る舞いを示し、リアルタイムで適応するとのこと。
Unlike traditional software, which follows predefined rules and instructions, AI agents can learn from context, adapt to new situations, and make decisions autonomously.
入力の違い
従来のソフトウェアクライアントは、ボタンクリックやフォーム送信など、構造化された明確なユーザー入力を受け取る。これらは明確で監査可能な意図の付与を表している。
一方、AIエージェントはテキスト、ドキュメント、画像、音声など非構造化でマルチモーダルな入力を解釈するよう設計されている。ホワイトペーパーでは、この曖昧さが新しい認証・認可モデルが必要とされる主な理由の一つだと指摘されている。
既存OAuth/OIDCで対応できるケース
既存の OAuth 2.1 フレームワークについて、以下のようなケースでは十分に機能すると記載されている。
work well within single trust domains with synchronous agent operations (e.g., enterprise agents accessing internal tools, consumers accessing their services through AI tools)
単一のトラストドメイン内で、同期的にエージェントが操作を行うケース。例えば：
- エンタープライズエージェントが内部ツールにアクセス
- 消費者が AI ツール経由で自身のサービスにアクセス
このような場合、OAuth 2.1 + PKCE + MCP の組み合わせで堅牢なセキュリティを提供できるとされている。共有の IdP、一貫した認可ポリシー、集中化された同意管理の恩恵を受けられる。
既存OAuth/OIDCでは不十分な6つの課題
しかし、エージェントがトラストドメインをまたいで操作する場合や、高度に自律的・非同期的な場合には、現在のフレームワークでは不十分だとホワイトペーパーでは指摘されている。主に以下の6つの課題が挙げられている。
課題①：エージェントのアイデンティティ不在
現状、エージェントのアイデンティティは単なる Client ID であることが多く、従来のワークロードと区別がつかないと述べられている。
Today, an agent's identity is often just a client ID, which is uninformative, undifferentiated for traditional workloads, and insufficient for a scalable, secure ecosystem.
ベンダーが独自のエージェントアイデンティティシステムを開発すると、開発者は繰り返し個別統合を強いられるし、複数のセキュリティモデルが生まれてそれぞれ異なるリスクと脆弱性を持つことになる。
ホワイトペーパーでは、エージェントのアイデンティティにはモデル、バージョン、機能などのメタデータを含め、リスクベースのアクセス制御を可能にする必要があると提言されている。
課題②：真の「権限委譲」が表現できない
現在、エージェントはユーザーと区別できない形で動作することが多く、アカウンタビリティのギャップとセキュリティリスクを生んでいると指摘されている。
Currently, agents often act indistinguishably from users, creating accountability gaps and security risks.
ホワイトペーパーでは、必要なのは「なりすまし（Impersonation）」ではなく、明示的な「委任（Delegation）」だと述べられている。
真の On-Behalf-Of（OBO）フローでは、アクセストークンに2つの異なるアイデンティティが含まれる：
- 権限を委任したユーザー（例：sub クレーム）
- 行動を許可されたエージェント（例：act または azp クレーム）
これにより、誰が認可し、どの AIエージェントが実行したかを明確に記録できるようになる。
課題③：同意疲れ（Consent Fatigue）
エージェントが増えると、ユーザーは数千の認可リクエストに直面することになると警告されている。
Users will face thousands of authorization requests as agents proliferate, creating security risks from reflexive approval.
例えば、広告予算を最適化するエンタープライズエージェントが「クリック率を最大化するように予算を再配分して」という指示を受けると、数秒で数百の API コールが発生する可能性がある。従来の「アクションごとに同意を求める」モデルでは到底対応できない。
解決策として、ホワイトペーパーでは以下のアプローチが提案されている：
- Policy-as-Code：ユーザーが高レベルのポリシー（予算上限、データアクセス階層など）を定義し、システムがプログラム的に適用
- Intent-Based Authorization：ユーザーが自然言語で意図を承認し、システムが最小権限の具体的なパーミッションに変換
- Risk-Based Dynamic Authorization：低リスクの操作は自動的に許可し、異常なリクエストのみ CIBA フローで明示的な承認を要求
課題④：再帰的委任とエージェント連鎖のリスク
エージェントがサブエージェントを生成したり、他のエージェントにタスクを委任したりすると、複雑な認可チェーンが生まれると指摘されている。
Agents spawning sub-agents or communicating tasks to other agents create complex authorization chains without clear scope attenuation mechanisms.
チェーンの終端にあるリソースサーバーは、最終的なサブエージェントだけでなく、元のユーザーまでの委任パス全体を暗号的に検証できる必要がある。
これには Scope Attenuation（スコープの段階的縮小）が必要とされている。委任チェーンの各ステップで、権限を段階的かつ検証可能に狭めていく仕組み。
アプローチとしては以下が挙げられている：
- OAuth 2.0 Token Exchange (RFC 8693)：認可サーバーを介してダウンスコープされたトークンを取得（集中管理向け）
- Biscuits / Macaroons：トークン保持者が発行者に連絡せずにより制限されたトークンを作成可能（分散型向け）
課題⑤：非同期・長時間実行への非対応
多くの AI エージェントワークフローは非同期で、初期の認可グラントでカバーされていない操作に対するユーザー承認の取得が難しくなると述べられている。
When an agent operates autonomously–potentially executing tasks hours or days after initial user instruction–requiring real-time authorization for sensitive operations becomes impractical.
例えば、新入社員のオンボーディングを担当するエージェントは、数日〜数週間にわたって IT、HR、福利厚生などの複数システムと連携する必要がある。短寿命でユーザーセッションに紐づくアクセストークンでは対応できない。
解決策として CIBA（Client Initiated Backchannel Authentication） が有効だとホワイトペーパーでは記載されている。CIBA はクライアントがアウトオブバンドで認可リクエストを開始できるため、エージェントはユーザー承認を待ちながら処理を継続できる。
CIBA は3つの配信モードをサポートしている：
課題⑥：動的クライアント登録の運用課題
MCP プロトコルは Dynamic Client Registration を活用してスケーラビリティを実現しているが、これには重大なセキュリティ上の欠陥があると指摘されている。
An unauthenticated, public registration endpoint allows clients to be created without any link to a real developer, organization, or accountable party.
未認証のパブリック登録エンドポイントだと、追跡可能な記録がなく、大量登録による DoS 攻撃の可能性もあり、堅牢なクライアント識別と証明が不可能。エンタープライズや高セキュリティ環境では高リスク。
解決策として、Client ID Metadata Document など、クライアントをより堅牢なアイデンティティに紐づけるアプローチが提案されている。
まとめ
ホワイトペーパーに記載のあった課題とそれの解決策を簡単にまとめてみた。
既存の OAuth/OIDC は単一トラストドメイン内での同期的なエージェント操作には十分使えるものの、クロスドメインでの操作や、高度に自律的なエージェント、非同期・長時間実行タスクといったケースでは既存の仕組みだけでは厳しいというのが現状のよう。
今後の方向性としては、「なりすまし」から「委任」へ、「都度同意」から「ポリシーベース」へ、という流れが重要になってきそう。エージェントが増えれば増えるほど、人間が全部のリクエストを承認するのは現実的じゃないとはいえ、セキュリティを緩められないのも事実。
これからその辺りがどうなっていくのか楽しみ。
