Identity Management for Agentic AI 解説

OpenID BizDay #18 ~ AIdentity × Security CollabDayで使った資料です。
https://openid.connpass.com/event/376275/

OpenID Foundationが発行したホワイトペーパー「Identity Management for Agentic AI」に関する解説です。

Transcript

1. Identity Management for Agentic AI 解説 2025/12/19 一般社団法人 OpenID ファウンデーション・ジャパン/代表理事 米国OpenID Foundation/共同議長 eKYC&IDA WG 富士榮 尚寛（ふじえ なおひろ） 1
2. 2025/4よりスタンフォード大学のTobin SouthとOpenID Foundationメンバー （AIIM CG）により執筆開始（IIWの ワークショップで発表あり） 2025/10/7 英語版がOpenID Foundationより発出 2025/11/9 日本語版がOpenIDファウン デーションジャパンより発出 ドキュメントの概要 2 Copyright © 2025, Naohiro Fujie, All Rights Reserved AIIM CG：https://openid.net/cg/artificial-intelligence-identity- management-community-group/
3. AIエージェントの急速な台頭は、認証、認可、アイデンティティ 管理において緊急の課題を提示している。現在のエージェント 中心のプロトコル（MCPなど）は、認証と認可におけるベスト プラクティスの明確化の必要性を浮き彫りにしている 高度に自律的なエージェントへの野心は、スケーラブルなアクセ ス制御、エージェント中心のアイデンティティ、AIワークロードの差 別化、委任された権限に関する複雑な長期的問題を提起す る。本ホワイトペーパーは、AIエージェントとアクセス管理の交差 点にいる関係者のためのものである エグゼクティブサマリーのまとめ（by ChatGPT） 3 Copyright © 2025, Naohiro Fujie, All Rights Reserved
4. 従来のソフトウェア 事前定義されたルールと指示に従う 新しいシナリオには手動更新が必要 構造化された明確なユーザー入力 決定論的な動作 AIエージェント コンテキストから学習し適応する 新しい状況に自律的に対応 非構造化マルチモーダル入力を解釈 非決定論的で柔軟な性質 従来のソフトウェアとAIエージェントの違い 4 Copyright © 2025, Naohiro Fujie, All Rights Reserved
5. AIエージェントの特性と課題 5 Copyright © 2025, Naohiro Fujie, All Rights Reserved 特性 自律性・非決定性 外部リソースとの 能動的な相互作用 課題 エージェントのアイデン ティティ不在・断片化 真の「権限委譲」が表現 できない 同意疲れと人間のガバナ ンス限界 再帰的委任・エージェン ト連鎖のリスク 課題概要 クライアントIDではエージェントの 実態を適切に表現できない 既存OAuth/OIDCモデルの 限界 エージェントの増加により同意要求 が爆発的に増加、全てに関与不可 非同期実行、長時間実行、クロスド メイン、複数委任に弱い サブエージェント生成により認可 チェーンが不透明化、暴走リスク 誰の代理で何を実行したかの表現が 困難。ログ上でユーザと区別困難 人間の代理として 行動 動的・大規模・ 再帰的な振る舞い 監査可能性・説明可能性 の欠如 「誰が許可し」「どのエージェント が実行したか」を区別できない
6. 解決の方向性 6 Copyright © 2025, Naohiro Fujie, All Rights Reserved 「On-Behalf-Of」を前提とし た委譲モデル 非同期・人間関与を可能にす る認可 ガードレールと行動レベルの 統制 エージェントのアイデンティ ティ再考 認可ロジックの外部化 （PEP/PDP） ライフサイクル管理とデプロ ビジョニング 解決の方向性 解決の方向性 関連テクノロジ・キーワード ②OBO（委譲） ④非同期認可 ⑤ガードレール ①Agent ID ③PEP/PDP ⑥ライフサイクル トークンの設計（移譲元、エージェン ト、委譲スコープ、監査用クレーム） CIBA、MCP Elicitation（URL Mode） IGAとの統合、AIガードレール SPIFFE / SPIRE、Agent専用IAM、クラ イアントID拡張（CIMD） NIST SP800-162（ABAC）、AuthZEN、 API Gateway SCIM拡張、Agentic Schema
7. 課題と解決の方向性の対応 7 Copyright © 2025, Naohiro Fujie, All Rights Reserved 課題・対応策 OAuth/OIDC 限界 ID断片化 権限委譲不在 同意疲れ 再帰的委任 監査不能 ①Agent ID ◎ ◎ ◦ △ ◦ ◎ ②OBO（委譲） ◎ ◦ ◎ ◦ ◎ ◎ ③PEP/PDP ◎ △ ◎ ◦ ◎ ◎ ④非同期認可 ◎ △ ◦ ◎ △ ◦ ⑤ガードレール △ △ △ ◎ ◦ ◦ ⑥ライフサイクル △ ◎ △ △ △ ◦
8. 多数・複数ドメインにまたがるAIエージェントの信頼 クライアントIDを事前に登録する運用では回らない エージェントが複数ドメイン（認可サーバ）に登録されるケースへの対応が必要 場合によっては一定の統制をかける必要がある（トラストフレームワークの実装） →動的クライアント登録（DCR）では不十分、CIMD/OpenID Federationの検討が必要 →その他、OAuth 2.0 Token Exchangeの活用によるクロスドメインシナリオへの対応 エージェントのアイデンティティの確立 単なるクライアントとして識別以上のことが必要 エージェントの機能や役割、誰の代理なのか、など →OpenID Connect for Agentsなど、拡張クレームの定義 →メタデータを利用した情報提供 ①Agent ID：エージェントのアイデンティティ再考 8 Copyright © 2025, Naohiro Fujie, All Rights Reserved
9. 2025/04/28 提案 https://subramanya.ai/2025/04/28/oidc-a-proposal/ OpenID Connect Core 1.0を拡張、OAuth 2.0エコシステム 内でLLMベースのエージェントを表現、認証、認可するためのフ レームワークを提供。エージェントのIDの確立、エージェントのアテ ステーション検証、委任チェーンの表現、そしてエージェント属性 に基づくきめ細かな認可を実現するための標準的なクレーム、 エンドポイント、プロトコルを定義 エージェント情報を含むIDトークンを発行、RPが検証する OpenID Connect for Agents 9 Copyright © 2025, Naohiro Fujie, All Rights Reserved
10. エージェントのID、委任、および機能を表すための標準クレーム エージェントのアテステーションのメカニズムと形式（RFC9711 Entity Attestation Tokenを推奨） 委任チェーンを表現および検証するためのプロトコル エージェント機能とアテステーションをサポートするための検出メカ ニズム エージェント固有のユースケースに適した認可フレームワーク アテステーション検証と機能検出のためのエンドポイント OpenID Connectを拡張 10 Copyright © 2025, Naohiro Fujie, All Rights Reserved
11. エージェントのアイデンティティに関するクレーム agent_type, agent_mode, agent_version, agent_provider, agent_instance_id 委任と権限に関するクレーム delegator_sub, delegation_chain, delegation_purpose, delegation_constraints 能力、信頼とアテステーションに関するクレーム agent_capabilities, agent_trust_level, agent_attestation, agenct_context_id エージェントに対応した標準クレーム 11 Copyright © 2025, Naohiro Fujie, All Rights Reserved
12. { "iss": "https://auth.example.com", "sub": "agent_instance_789", "aud": "client_123", "exp": 1714435200, "iat": 1714348800, "auth_time": 1714348800, "nonce": "n-0S6_WzA2Mj", "agent_type": "assistant", "agent_model": "gpt-4", "agent_version": "2025-03", "agent_provider": "openai.com", "agent_instance_id": "agent_instance_789", "delegator_sub": "user_456", "delegation_purpose": "Email management assistant", エージェント情報を含むIDトークンの例 12 Copyright © 2025, Naohiro Fujie, All Rights Reserved "agent_capabilities": ["email:read", "email:draft", "calendar:view"], "agent_trust_level": "verified", "agent_context_id": "conversation_123", "agent_attestation": { "format": "urn:ietf:params:oauth:token-type:eat", "token": "eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9...", "timestamp": 1714348800 }, "delegation_chain": [ { "iss": "https://auth.example.com", "sub": "user_456", "aud": "agent_instance_789", "delegated_at": 1714348700, "scope": "email profile calendar" }
13. OAuth Client ID Metadata Document OAuth クライアントが事前登録なしで認可サーバーに自身を認識させる仕組みを定義する仕様。クライアント 自身が公開URLをclient_idとして使い、そのURL上にクライアントのメタデータ（JSON）を置く https://datatracker.ietf.org/doc/draft-ietf-oauth-client-id-metadata-document/ 主なポイント クライアントIDとしてメタデータドキュメントのURLを使用する 認可サーバは認可リクエストを受けてメタデータを取得しに行き、クライアントに関する情報を取得する 事前登録なしでクライアント情報を認可サーバーに認識させることができる OpenID FederationのMetadata Policyでクライアントメタデータを制限する案も 川崎さんのBlog：https://qiita.com/TakahikoKawasaki/items/e4898a31f3ae52be3eff MCPはDCRよりもCIMDの利用を推奨 Client ID Metadata（CIMD） 13 Copyright © 2025, Naohiro Fujie, All Rights Reserved
14. OpenID Federation 1.0 複数の異なる組織・サービス間で相互に信頼関係を形成し、メタデータを安全に共有する仕組みを定義。動 的で拡張可能なフェデレーションモデルの構築を可能とする ポイント フェデレーションを構成するEntityの識別子としてメタデータドキュメントのURLを使用する 当然Relying Party（クライアント）も含むので、CIMDを一部包含する エンティティの信頼関係を階層的に表現することができる メタデータ内のauthority_hintsクレームでトラストアンカー、中間認証機関との関係を記述する エンティティは相手方のメタデータを取得することで相手方エンティティに関する情報を取得する 結果、CIMDと同じく事前登録なしでクライアント情報を認可サーバーに認識させることができる Metadata Policyでガバナンスを効かせることができる OpenID Federation 14 Copyright © 2025, Naohiro Fujie, All Rights Reserved
15. 単一のエージェントが複数の認可サーバと連携するシナリオに対 応するドメインを跨いだ識別子が必要 CIMDやOpenID Federationではhttps://スキームでエンティティを識別 類似の識別子として以下も検討可能 DID（Decentralized Identifiers） did:<method>:<method specific identifier> SPIFFE（Secure Production Identity Framework For Everyone） spiffe://<authority>/<path> 同じくメタデータへのロケータとして機能も必要 メタデータを利用したエージェントのアイデンティティ情報提供 識別子の話 15 Copyright © 2025, Naohiro Fujie, All Rights Reserved
16. OAuth 2.0 Extension: On-Behalf-Of User Authorization for AI Agents 従来の OAuth 2.0 の認可コードフローやトークン交換では、AI エージェントの明確な識別・ ユーザーの意図の反映・エージェント自身の認証まで標準的に扱う仕組みが十分ではないた め、それらをサポートする仕組みを追加 https://datatracker.ietf.org/doc/draft-oauth-ai-agents-on-behalf-of-user/ 主な提案 authorization request に requested_actor パラメータを追加 token request に actor_token を含める アクセストークンにエージェント情報を含める ②「On-Behalf-Of」を前提とした委譲モデル 16 Copyright © 2025, Naohiro Fujie, All Rights Reserved
17. GET /authorize?response_type=code& client_id=<client_id>& redirect_uri=<redirect_uri>& scope=<scope>& state=<state>& code_challenge=<code_challenge>& code_challenge_method=S256& requested_actor=<actor_id> HTTP/1.1 requested_actor: REQUIRED. The unique identifier of the actor for which the client is requesting delegated access on behalf of the user. This identifier MUST uniquely identify the actor within the system and MUST be understood by the Authorization Server. 認可リクエスト 17 Copyright © 2025, Naohiro Fujie, All Rights Reserved
18. POST /token HTTP/1.1 Host: authorization-server.com Content-Type: application/x-www-form-urlencoded grant_type=authorization_code& client_id=<client_id>& code=<authorization_code>& code_verifier=<code_verifier>& redirect_uri=<redirect_uri>& actor_token=<actor_token> actor_token: REQUIRED. The actor token is used to authenticate the actor. This token MUST be a valid token issued to the actor and MUST include the sub claim identifying the actor. トークンリクエスト 18 Copyright © 2025, Naohiro Fujie, All Rights Reserved
19. The Access Token SHOULD be a JWT Profile for OAuth 2.0 Access Tokens[RFC9068]. It SHOULD carry claims that explicitly document the delegation chain. act: REQUIRED. Actor - represents the party acting on behalf of the subject (Section 4.1 of [RFC8693]). In an Access Token issued via this flow, this claim MUST contain a JSON object with at least the following member: * sub: REQUIRED. The unique identifier of the actor that is acting on behalf of the user. * Additional members MAY be included in the act claim. アクセストークン 19 Copyright © 2025, Naohiro Fujie, All Rights Reserved
20. { "iss": "https://authorization-server.com/oauth2/token", "aud": "resource_server", "sub": "user-456", "azp": "s6BhdRkqt3", "scope": "read:email write:calendar", "exp": 1746009896, "iat": 1746006296, "jti": "unique-token-id", "act": { "sub": "actor-finance-v1" }, "aut": "APPLICATION_USER" } アクセストークンのサンプル 20 Copyright © 2025, Naohiro Fujie, All Rights Reserved
21. エージェントエコシステムにおいては、1つのエージェントが複雑なタスクを 分解し、サブタスクを他の専門エージェントに委任する場合もある 元のユーザー 最初の認可を付与 プライマリエージェント ユーザーから権限を受け取る サブエージェント 制限された権限を受け取る リソースサーバー 委任チェーン全体を検証 再帰的委任とスコープ減衰 21 Copyright © 2025, Naohiro Fujie, All Rights Reserved
22. Policy Enforcement Point（PEP） エージェントからのリクエストを受け、認可決定を強制するコンポーネント Policy Decision Point（PDP） 定義されたポリシーに基づいて認可決定を行うコンポーネント NIST SP800-162 Guide to Attribute Based Access Control (ABAC) Definition and Considerations ③PEP/PDPの外部化 22 Copyright © 2025, Naohiro Fujie, All Rights Reserved
23. CIBA（Client Initiated Backchannel Authentication） エージェントが非同期的にジョブを実行 するパターン バックエンドがユーザ認可（同意）を 後から求める場合への対応 MCP Eliciation（URL Mode） エージェントとの対話UIから外部URLを起動し、センシティブな情報（IDやパス ワードなど）がMCPクライアントを通過しない様にする ④非同期認可 23 Copyright © 2025, Naohiro Fujie, All Rights Reserved ジョブ投入 ジョブ実行 非同期で通知、同意 （CIBA）
24. 自律的に行動するAIを、意図・権限・ルール・責任の枠内に留めるため の多層的制御機構 機密データへのアクセス制限 機密データへのアクセスを制限し、使用ポリシーを強制する技術的制御 PIIのマスキング 個人識別情報がLLMに送信される前に自動的にマスキング 出力の監視 有害なコンテンツの出力を監視し、意図しない動作を防止 リソース消費の制限 レート制限とリソースクォータを設定してシステム過負荷を防止 ⑤ガードレール 24 Copyright © 2025, Naohiro Fujie, All Rights Reserved
25. 失効 Shared Signals Framework（SSF）、OpenID Provider Commandsによる 認可取り消し デプロビジョニングとオフボーディング エージェントのアイデンティティと関連する権限を恒久的・完全に削除する。SCIM （System for Cross-domain Identity Management）による停止・削除 包括的なセキュリティプロファイル IPSIE（Interoperability Profiling for Secure Identity in Enterprise） WG が開発するプロファイルの活用 ⑥ライフサイクル 25 Copyright © 2025, Naohiro Fujie, All Rights Reserved
26. AIエージェントの単純なツールから自律的アクターへの急速な進化は、デジタルアイデ ンティティにとって重要な転換点。既存のフレームワークを活用しつつエージェントを保 護するための堅牢で適用可能なソリューションの探索が重要 開発者とアーキテクト向け 既存の標準の安全な基盤の上に構築し、委任された権限とエージェントネイティブのアイデンティティモデルを組み込み、柔軟性を持つシ ステムを設計する 標準化団体向け これらの新しい概念を形式化するプロトコルの開発を加速し、将来のエコシステムが独自の断片化されたアイデンティティシステムのパッチ ワークではなく、相互運用性の基盤の上に構築されることを保証する 企業向け エージェントをIAMインフラストラクチャ内の一つのアクターとして扱い、プロビジョニングから安全で検証可能なデプロビジョニング、ガバナンス ポリシー、明確な説明責任のラインまで、堅牢なライフサイクル管理を確立する 単純なクライアントの認証から自律エージェントの信頼できるアイデンティティの確立は、単なる技術的アップグレードではなく、オンラインで 信頼を管理する方法の根本的な進化である まとめと提言 26 Copyright © 2025, Naohiro Fujie, All Rights Reserved