OpenID Japan 「Identity Management for Agentic AI」の翻訳版公開 (2025.11.09)

こんにちは、丸山満彦です。

OpenID Japan が「Identity Management for Agentic AI」の翻訳版公開していますね...はやい...

Agentic AIは、英語のままですかね...原文でもAgentic AIは二箇所しかないですね...表題部分...あとはAI Agentとなっています。

● OpenID Japan

・2025.11.09「Identity Management for Agentic AI」の翻訳版公開

・・[PDF]

目次...

---

1 AIエージェントは、これまでのエージェントと何が異なるのか？
1.1 AIエージェントの定義
1.2 エージェントは特定の認証と認可を必要とする
1.3 対象の読者層

2 現在のユースケースに対応可能な解決策
2.1 エージェントとそのリソース
2.2 エージェント・プロトコル
2.3 MCP
2.4 認証
2.5 動的クライアント登録
2.6 認可
2.7 エージェントの非同期認証
2.8 AIエージェントのアイデンティティ
2.9 SSOとプロビジョニング
2.10 エージェントのアイデンティティと認可の運用
2.11 監査可能性のギャップを埋める
2.12 ガードレールの設置
2.13 エージェント－エージェント間通信
2.14 当面の解決策のまとめ

3 自律エージェントのアイデンティティと認可の将来的な問題点
3.1 エージェントアイデンティティのアーキテクチャ思想
3.2 認可の委任と信頼の連鎖
3.3 レジストリと外部ツールへの動的接続
3.4 拡張性の高いヒューマン・ガバナンスと同意
3.5 先進的な課題と広範な影響
3.6 経済層：アイデンティティ、ペイメント、金融取引
3.7 パート3 結論

4 堅牢なエージェント認可のユースケース
4.1 高速エージェントと同意疲れ
4.2 非同期実行と永続的権限委譲
4.3 クロスドメイン・フェデレーションと相互運用可能な信頼
4.4 動的エージェントネットワークにおける再帰的委任
4.5 サイバーフィジカル(現実世界と仮想空間が融合した）エージェントの安全システムとしてのIAM
4.6 複数のユーザを代行するエージェント

5 結論

---

● OpenID

・2025.10.07 New whitepaper tackles AI agent identity challenges

[PDF] Identity Management for Agentic AI

---

エグゼクティブサマリー

AIエージェントの急速な普及は、認証、認可、ID管理における早急な対応を要する課題をもたらしている。現在のエージェント中心のプロトコル（MCPなど）は、認証と認可におけるベストプラクティスを明確にする必要性を浮き彫りにしている。将来を見据えると、高度で自律的なエージェントを求める気運は、拡張制の高いアクセス制御、エージェント中心のアイデンティティ、AI が行う作業の分類と整理、権限の委譲など、複雑で長期的な問題を突き付けている。このホワイトペーパーは、AIエージェントとアクセス管理が交差する位置にいる関係者向けである。本稿は、今日のエージェントの安全性を確保するために既に利用可能なリソースの概要と、将来広範囲に稼働するであろう自律システムに極めて重要な、基礎的な認証、認可、アイデンティティの問題に対処するための戦略的アジェンダを提示する。

今日のフレームワークは、シンプルなAIエージェントに対応している：

• AIエージェントは従来のソフトウェアとは根本的に異なる。外部サービスに対して自律的な行動をとり、決められた命令を単に実行するのではなく、リアルタイム、非決定的、柔軟な振る舞いを示す。
• 既存のOAuth 2.1フレームワークは、AIエージェントと共に使用される場合、 同期的なエージェント操作（例えば、企業エージェントが内部ツールにアクセスしたり、利用者がAIツールを介してサービスにアクセスしたりする）を伴う単一の信頼関係にあるドメイン内ではうまく機能するが、クロスドメイン、高度に自律的、または非同期的な状況や、エージェントが同時に複数の人から委譲された権限を実行する必要がある場合は、うまく機能しない可能性がある。
• モデル・コンテキスト・プロトコル（MCP）は 、エージェントを開発する際に、言語モデルを外部のデータソースやツールに接続するための重要なフレームワークとして積極的に採用されている。但し、他にも関数呼び出し（ツールの使用）やエージェント間（A2Aなど）通信プロトコルなどのアプローチがある。これらもサポートするべきである。
• 企業SSOとSCIMプロビジョニングは、エンタープライズエージェントの利用を可能にし、エージェントのライフサイクルの一元管理、及びさまざまなAIエージェントのユースケースに対する権限とアクセスのガバナンスを促進するのに役立つ。
• 企業のセキュリティプロファイルは、AIを安全に導入するためのベースラインを提供する。リスクを緩和するために、本稿では、AIエージェントが既存の アイデンティティ標準仕様の厳格で相互運用可能なプロファイルに準拠することを推奨する。IPSIE（Interoperabilit y Profiling for the Secure Identity in the Enterprise）のようなワーキンググループはこれに関するガイダンスを提供しており、強固な管理が行き届いていることに確証を得られるようにすることで、組織が安心してAIを採用できるようにしている。
• ユーザ中心の同意モデルは、消費者向けエージェントの土台である。サードパーティの消費者サービス（電子メール、ソーシャルメディア、金融データなど）に接続するエージェントにとって、確立されたOAuth 2.1のユーザ同意フローは、権限移譲のための主要なメカニズムである。ユーザの信頼を得るには、透明性と明確なスコープ定義が重要である。

将来に向けての重大な課題：

• エージェントのアイデンティティの断片化は避けるべきである。ベンダーは、独自のエージェント型アイデンティティシステムを開発する可能性があるが、この場合、単発の統合を繰り返さざるを得なくなるため、開発者の速度が低下することになる。また、それぞれ異なるリスクと脆弱性を持つ複数のセキュリティモデルを作ることで、安全性を侵害することにもなる。
• エージェントにユーザのように振舞わせるのではなく、権限を委譲するモデルに置き換えるべきである。現在、エージェントはしばしばユーザと区別がつかないように行動し、説明責任のギャップやセキュリティリスクを生み出している。真の権限委譲は、エージェントがその代理元であるユーザを識別可能なまま、委譲された範囲を証明する、明示的な On behalf ofフロー（代理認証フロー）を必要とする。
• 人に出来るガバナンスと同意の量には限度がある。エージェントの急増に伴い、ユーザは膨大な量の認可リクエストに直面することになり、確かめないで承認してしまうというセキュリティリスクが生じる。柔軟なエージェントの事前承認と範囲設定は、最小特権とは相反する。
• 再帰的委任はリスクを生む。エージェントがサブエージェントを生成したり、他のエージェントにタスクを伝達したりすると、明確な減衰メカニズムがないまま、複雑な認可チェーンが形成される。
• 人間のチームに代わって行動し報告するエージェントにはサポートが不足している。OAuth とOpenID Connectは個々のユーザの認可のために設計されたが、エージェントはグループ内の共有コードベースやチャットチャンネルで採用することができる。このようなマルチユーザ環境では、ユーザごとにさまざまな権限レベルが存在するかもしれないが、単一の設定の中では、すべてのユーザが共通の目的を共有している。共有エージェントをサポートする一般的なプロトコルは存在しない。
• 自律性を信頼するにはまだ、検証を自動化する仕組みが欠けている。ヒューマンインザループ(人間がAIの意思決定プロセスに積極的に関与する）モデルを超えて拡張するには、エージェントの行動が継続的に運用上の目標と制約に合致していることを確認するための、新しいプログラムに従った手法が必要である。
• ブラウザとコンピュータを使用するエージェントは、現在の認可パラダイムを破壊する。視覚インターフェースを直接（またはMCPを経由してブラウザ・オーケストレータに）制御するエージェントは、従来のAPIベースの認可制御をすべて回避する。オープンなウェブをロックダウンから守るには、ウェブボットやウェブエージェントの強固な認証が必要になる。
• エージェントの多面的な行動がアイデンティティを複雑にしている。技術の進歩により、エージェントは独自に行動できるようになり、エージェントは独自の認証情報、権限、監査証跡を持つ必要がある。さらに、エージェントの性質をハイブリッドにすることで、独立した実行とユーザの代行を交互に行うことができる。

---