AIエージェントのアイデンティティ管理 — 標準化の現在地（2026）¶
作成日: 2026-06-08 きっかけ: 「AIdentity / IETF / EIC2026 で AIセキュリティの管理方法が議論されているらしい」を一次資料で整理 関連: llm_product_clean_architecture_設計、cloudflare_2026_サプライチェーン攻撃リスク、ai_agent_9社_本番運用アーキテクチャ
0. 要点（3行）¶
- 2026年、AIエージェントが本番で「自分でツールを選び、人手を介さず機密データにアクセスする」ようになり、従来のIAM（人間 or 予測可能なサービスアカウント前提）が崩壊。論点は「誰か（identity）」より「いま、この文脈で何を許すか（authority）」へ移った。
- 議論は3つの場で並走 — EIC 2026（KuppingerCole）＝概念「AIdentity」と運用論、IETF OAuth WG＝具体プロトコル（AAuth / AI Agent Auth / ID-JAG ほか5本以上が同時並走）、NIST AI Agent Standards Initiative ＋ CoSAI＝標準化の旗振り。
- 設計の核は「エージェントを一級のアイデンティティとして扱い（人間にもサービスアカウントにも押し込めない）、短命・タスクスコープの権限を、実行時に継続的に検証する」。鍵は WIMSE/SPIFFE・OAuth 2.0・OIDC・A2A・MCP の合成であって、新プロトコルの乱立ではない。
1. なぜ今「AIアイデンティティ」が問題なのか¶
1-1. agentic AI が従来IAMを壊す理由¶
従来IAMは「主体は人間か、挙動が読めるサービスアカウント」を前提にしてきた。AIエージェントはこの前提を破壊する。
- 非決定的な挙動: 同じ権限・同じエージェントでも、プロンプト・文脈・上流の出力次第で毎回違う行動を取る。「マイクロサービスのAPIキーは毎回ほぼ同じエンドポイントを同じ頻度で叩く。AIエージェントは文脈に応じてどのツールを呼ぶかを推論する」（resilientcyber）。
- 設計時の制御を実行時の問題に当てはめる矛盾: 最小権限は「権限付与時点」の静的制御だが、エージェントが取り得る行動集合は付与時点では完全には知り得ない。
1-2. 「パスポート」対「権限」のギャップ¶
Karl McGuinness の整理が中心的 — エージェントに必要なのは本人確認（who are you）ではなく、いまこの文脈で何ができるかの権限付与（what can you do now）。静的なロールベースアクセス（RBAC）では追いつかない。
この note の問いは3つに集約される: 「そのエージェントは誰か」「誰がその行動を承認したか」「何が許されているか」。
2. 議論が起きている3つの場¶
| 場 | 主体 | 何を議論 |
|---|---|---|
| EIC 2026（European Identity and Cloud Conference, ベルリン） | KuppingerCole（Martin Kuppinger ら、1,500人超） | 概念「AIdentity」、Identity Fabric、非人間アイデンティティの実行時ガバナンス |
| IETF OAuth WG | Okta / AWS / Zscaler / Ping / OpenAI / Defakto ほか | 具体プロトコル草案（5本以上が同時並走）。委任・トークン・認可フロー |
| NIST / CoSAI | NIST（米標準局）、Coalition for Secure AI | 標準化の枠組み（NISTは2026年2月に AI Agent Standards Initiative 始動、4月にlistening session）、CoSAI Workstream 4 が9つの要請 |
3. EIC 2026 の「AIdentity」と Laws of AIdentity¶
AIdentity = 「登録時にエージェントが動いてよいかを評価する」従来ガバナンスから、「実行時にエージェントが実際に何をするかを制御する」へ軸足を移す概念。
EmpowerID CEO の Patrick Parker が基調講演で、Kim Cameron の 2005年「Laws of Identity」（SSO時代の礎）になぞらえて 6つの "Laws of AIdentity" を提唱した（「我々はまた同じ地点にいる」）。
| # | 法則 | 意味 |
|---|---|---|
| 1 | Split Actor（分裂する主体） | principal・model・policy point・vault・executor と役割が分かれ、帰属（誰の行為か）が難しくなる |
| 2 | Generated Intent（生成された意図） | エージェントの行動は元のユーザー意図から大きく逸脱し得る |
| 3 | Bounded Agency（境界づけられた権能） | スコープ付きツールアクセスと関係グラフが必須 |
| 4 | Authorization as Continuous Loop | 認可は一回きりでなく、実行を通じてリアルタイム・粒度細かく検証 |
| 5 | Least Exposure（最小開示） | 効率と安全のため情報開示を最小化 |
| 6 | Justifiable Action（正当化可能な行動） | 暗号署名されたレシートで監査証跡を残し、説明責任を担保 |
4. IETF の具体プロトコル草案（競合と相補）¶
「エージェント専用のアイデンティティが要る」という認識から、OAuth WG で複数の草案が同時並走。多くが孤立して車輪を再発明しがち、という反省も共有されている。
4-1. 主要3草案¶
| 草案 | 提案者 | 一言で |
|---|---|---|
| AAuth（Agentic Authorization, OAuth 2.1拡張） | Jonathan Rosenberg, Patrick White | リダイレクト型OAuthが使えない非伝統的経路でエージェントがユーザー代理のトークンを得る。幻覚による資格情報の捏造にも対処 |
AI Agent Authentication and Authorization（draft-klrc-aiagent-auth, v02, 2026-06-01） |
Pieter Kasselman(Defakto) / Jeff Lombardo(AWS) / Yaroslav Rosomakho(Zscaler) / Brian Campbell(Ping) / Nick Steele(OpenAI) / Aaron Parecki(Okta) | 新プロトコルを作らず合成。WIMSE/SPIFFE で識別子、OAuth 2.0 で委任、OIDC Shared Signals で監視、Transaction Token でリスク低減。AIMS（Agent Identity Management System）を定義 |
| ID-JAG（Identity Assertion JWT Authorization Grant） | 主に Okta（individual draft 2024-03 → 2025-06 にOAuth WG候補へ） | 企業SSOの信頼をアプリ間API・AIエージェントへ拡張。RFC 8693（token exchange）＋ RFC 7523（JWT profile）の合成 |
4-2. ID-JAG のフロー（具体）¶
「信頼は個々のエンドポイント間でなくIdP（企業IdP）を経由して流れる」のが肝。
1. Requesting Agent（AIツール/アプリ）が SSO でログイン
2. Enterprise IdP が組織ポリシーを評価し、IDトークンを ID-JAG に交換
3. 対象サービスの Authorization Server が ID-JAG の暗号署名を検証
4. Resource Server（実API）が認可結果に基づきアクセス許可
解く課題: consent fatigue（承認画面の繰り返し）／ shadow AI（IdPで接続を捕捉し可視化）／ token sprawl（長命APIキーの乱立を動的トークンに置換）／ audit gap（誰が・誰の代理で・どこまで触ったかを記録）。MCP のエンタープライズ認可仕様も ID-JAG を明示参照しており、実運用が動き始めている。
4-3. 土台になる既存標準¶
- WIMSE（Workload Identity in Multi-System Environments）＝エージェント識別子の枠組み、その成熟実装が SPIFFE/SPIRE
- OAuth 2.0 / OpenID Connect ＝委任・認可フロー、Shared Signals Framework で監視
- A2A（Agent2Agent）＝150団体超が支持、Azure AI Foundry / Bedrock / Google Cloud に統合。Agent Card（認証方式・能力・認可要件を宣言するJSON）でP2Pのエージェント識別
- MCP（Model Context Protocol）＝ツール接続のデファクト、13,000+サーバ。2025年6月に OAuth 2.1 を統合したが、仕様に実装が追いついていない（多くのサーバが適切な認証を欠き、OAuth設定ミス、監査ログ未強制）
5. intent-aware / action-based 認可（IBAC・TBAC・pre-action）¶
§3-4 が「誰か・どう委任するか（identity / delegation 層）」なら、ここは「各アクションをいま許すか（authorization 層）」。Law #2（Generated Intent）と #4（Continuous Authorization）に直接対応する、いま最もホットな実装論。
5-1. Intent-Based Access Control（IBAC）¶
「誰が何をできるか（who can do what）」から「どの目的で・どの条件下で・どのリソース横断で（for what purpose, under what conditions, across which resources）」への転換。問いが can this be done? から should this be done now, for this reason, at this level of risk? に変わる。
intent（自然言語 or 構造化JSONで宣言）
│ parse
▼
fine-grained な authorization tuples（細粒度の認可タプル）
│ 各 tool call の"前"に評価
▼
ポリシーエンジン（Cedar / OPA / OpenFGA）× versioned policy
▼
allow / deny —— 決定論的・監査可能・説明可能・ポリシー版に追跡可能
最重要原則: 認可判断は LLMに推論させず、バージョン管理されたポリシーに対して決定論的に計算する。判断はバイナリで、監査可能で、特定のポリシー版に紐づく（llm_product_clean_architecture_設計 の「確率的な縁と決定論的コアの分離」と完全に同じ思想 — 認可は決定論コア側に置く）。
5-2. Task-Based Access Control（TBAC）¶
エージェントが遂行すべき具体タスクに基づいて権限を付与する基盤モデル。intent駆動でエージェントに自然に適合。RBAC（役割）/ABAC（属性）に対し、TBAC（タスク）＋IBAC（意図）がagentic時代の least-privilege の意味的背骨になる。
5-3. Pre-Action Authorization（実行前の決定論的認可）¶
論文 "Before the Tool Call: Deterministic Pre-Action Authorization for Autonomous AI Agents"（Uchi Uchibeke, arXiv:2603.20953, 2026-03）。
- 介入点: 「エージェントの判断」と「ツール呼び出し」の境界で、実行前に認可チェック
- 決定論的: 確率的フィルタでなくルールベース。同じ入力状態には同じ結果（再現可能・テスト可能）
- ハードな強制境界: deny されたら実行は決して進まない → ランタイム悪用の全クラスを排除。事後監視・rate-limit・確率的ガードレール（稀に危険行為を通す）とは対照的
5-4. 業界の実装と指標¶
- Akeyless Agentic Runtime Authority / Token Security（intent-based）/ Cisco Duo IAM（intent-aware monitoring を Secure Access に統合）/ Cerbos（agentic authorization、OPA系ポリシーエンジン）
- identity-first, intent-aware モデル = 3シグナル: identity（何者か・どう統治されるか）／ intent（なぜ動くか）／ context（いつ・どこで・どのリスクか）
- 新指標 MTU（Mean Time to Understand）: エージェントの意図・計画・ツール連鎖・データフローを解釈して安全な認可判断に至るまでの時間
- ギャップ: 「agentic AI のツール呼び出し境界に、標準の認可レイヤがまだ存在しない」（業界調査）
6. 攻撃・課題（具体）¶
- Delegation chain splicing（委任連鎖の差し込み）: 2026年3月の IETF OAuth ML で議論。攻撃者が actor claim の連鎖に自分を正規ホップの間に挿入する。緩和策は「ステップNのaudienceがステップN+1のsubjectと暗号的に一致することを要求」＋短命トークン＋同意撤回時のバックチャネル失効。
- Multi-hop delegation（多段委任）: 一回きりの付与でなく継続的認可が要る（エージェント→エージェント→ツールと権限が伝播）。
- Shadow AI: 未承認のAIツールが個人アカウント・ハードコード資格情報で動き、監視外。
- Token sprawl: 長命APIキーの散在。
- デプロイ現実の遅れ: 標準が成熟する一方、現場は「長命APIキー、ばらばらのアクセス制御、重大インシデント調査に耐えない監査証跡」で運用している。
7. サーベイ論文の gap 分析（arXiv:2604.23280, 2026-04-28）¶
Takumi Otsuka・Kentaroh Toyoda・Alex Leung による survey。OAuth/OIDC・WIMSE・SPIFFE/SPIRE・DID・Verifiable Credentials・mTLS・MCP・A2A・Sigstore・eIDAS/EU AI Act を横断し、7つのギャップを指摘:
- 統一されたAIアイデンティティ標準が無い（プロトコルの断片化）
- 失効メカニズムの欠如（侵害された identity のライフサイクル管理が弱い）
- プライバシー（identity の連結可能性・追跡リスク）
- 説明責任のギャップ（自律行動の監査証跡が不足）
- クロスドメイン相互運用性（cloud / on-prem / edge を橋渡しできない）
- 規制の不整合（EU・日本・中国で要件が割れる）
- 人間×エージェントのハイブリッド（AIが人間判断を補強する時の identity モデルが無い）
提言: 既存標準（OAuth/DID/mTLS）と競合でなく統合する AI 専用仕様、ゼロトラスト、能力とアイデンティティ主張の暗号的バインディング、失効・ライフサイクル管理の研究。
8. 実務の段階導入（3フェーズ）¶
| フェーズ | 内容 |
|---|---|
| ① Visibility | shadow AI・エージェント配備の棚卸し（まず可視化） |
| ② Contextual Access Control | capability-impact マトリクスでリスク階層化したポリシー適用 |
| ③ Full Agentic IAM | 実行時強制＋帰属（attribution）＋委任系譜（delegation lineage）の追跡 |
CoSAI の指針も同方向 — エージェントを一級アイデンティティとして扱い、standing privilege（常時付与）を排し、JIT（just-in-time）・タスクスコープの失効可能なアクセスにする。
9. まとめ — どこを見ておくか¶
| 関心 | 見るべきもの |
|---|---|
| 概念・運用の言語 | EIC 2026「AIdentity」「6 Laws of AIdentity」（実行時認可・署名レシート） |
| 具体プロトコル | IETF ID-JAG（IdP中心の委任）、AI Agent Auth草案（WIMSE/SPIFFE/OAuth合成）、AAuth |
| エージェント間/ツール接続 | A2A（Agent Card）、MCP（OAuth2.1統合だが実装が遅延） |
| 全体像・ギャップ | survey arXiv:2604.23280、NIST AI Agent Standards Initiative、CoSAI WS4 |
| 攻撃面 | delegation chain splicing、multi-hop委任、shadow AI、token sprawl |
結論: AIエージェントのアイデンティティ管理は「identity（誰か）から authority（いま何を許すか）へ」「登録時審査から実行時の継続認可へ」という転換の真っ最中。決定版は未確立だが、方向性は明確 — エージェントを一級アイデンティティとして、短命・タスクスコープ・失効可能な権限を、既存標準（WIMSE/SPIFFE・OAuth・OIDC・A2A・MCP）の合成で、実行時に継続検証する。2026年は EIC・IETF・NIST が同時に動く「標準化の幕開け」の年。
※IETF草案はいずれも individual draft 段階（
draft-klrc-aiagent-authは v02 / 2026-06-01、正式なIETFストリーム指定なし）で、標準化プロセス上の地位は限定的。固まったRFCではない点に注意。
参考リンク¶
- survey: "AI Identity: Standards, Gaps, and Research Directions for AI Agents"（arXiv:2604.23280, 2026-04-28）: https://arxiv.org/pdf/2604.23280
- IETF draft "AI Agent Authentication and Authorization"（draft-klrc-aiagent-auth）: https://datatracker.ietf.org/doc/draft-klrc-aiagent-auth/
- "Identity Is the Agentic AI Problem Nobody Has Solved Yet"（Resilient Cyber）: https://www.resilientcyber.io/p/identity-is-the-agentic-ai-problem
- EIC 2026 "The Laws of AIdentity"（Patrick Parker, KuppingerCole）: https://www.kuppingercole.com/watch/the-laws-of-aidentity-eic26
- EIC 2026 "Agent-Aware IAM": https://www.kuppingercole.com/watch/agent-aware-iam-securing-identity-eic26
- ID-JAG 解説（LY Corporation Tech Blog, 2026-04-17）: https://techblog.lycorp.co.jp/en/20260417a
- AIP: "Agent Identity Protocol for Verifiable Delegation Across MCP and A2A"（arXiv:2603.24775）: https://arxiv.org/pdf/2603.24775
- WorkOS "AI agents and the multi-hop delegation problem": https://workos.com/blog/oauth-multi-hop-delegation-ai-agents
- W3C Agent Identity Registry Protocol Community Group: https://www.w3.org/community/agent-identity/
intent-aware / action-based 認可 - Intent-Based Access Control: Securing Agentic AI（IBAC paper）: https://ibac.dev/ibac-paper.pdf - "Intent-Based Access Control: A Technical Primer"（Ken Huang）: https://kenhuangus.substack.com/p/intentbased-access-control-a-technical - "Before the Tool Call: Deterministic Pre-Action Authorization for Autonomous AI Agents"（arXiv:2603.20953, 2026-03）: https://arxiv.org/pdf/2603.20953 - CSA "Rethinking Authorization for the Age of Agentic AI": https://cloudsecurityalliance.org/blog/2026/03/19/rethinking-authorization-for-the-age-of-agentic-ai - "The role of intent in securing AI agents"（Biometric Update）: https://www.biometricupdate.com/202604/the-role-of-intent-in-securing-ai-agents
作成: 2026-06-08 ／ 最終更新: 2026-06-16