TL;DR
- AI Agent 時代の認可は「user × agent / agent × tool / agent × agent / agent × data」の 4 境界モデルで設計するのが現実解（経験則）。
- 従来の RBAC / ABAC は人間ユーザー前提。AI Agent の transient な権限には Capability token + OAuth 2.1 + MCP scope を組み合わせる必要がある[公式値]。
- 本記事は ai-coding-security シリーズの child として、認証・認可設計のやり直しガイド と MCP権限設計の判断軸 を補完する Agent 認可 の中核 hub。
はじめに
AI コーディングが普及して、開発現場の認可境界は 「人間 + Agent + Tool」の 3 者間 に拡張されました。従来の Web Auth（user × resource の 2 者間）の枠組みでは、Agent が一時的に持つ権限・複数 Agent 間の委譲・Agent から Tool への呼び出しといった新しい境界をカバーできません（経験則）。
本記事は 4 つの境界モデル をベースに、各モデルで採用すべき実装パターンを整理し、ai-coding-security シリーズの中核 child として位置づけます。基礎は 認証・認可設計のやり直しガイド、MCP 個別の権限設計は MCP権限設計の判断軸 を併読してください。
1. なぜ AI Agent 認可は従来 RBAC で破綻するか
3 つの理由（経験則）。
理由 1: Agent 権限は transient
Agent タスクは「数秒-数分」の単位で起動・終了します。長期保持の RBAC ロールでは、タスク終了後に権限を回収するメカニズムが弱く、流出時の被害が大きくなります。
理由 2: 委譲チェーンが長い
「user → parent agent → sub-agent → tool → data」の 5 段階で権限が委譲されます。各段階で least privilege を維持しないと、末端 tool が想定外の権限で動作する事故が起きます（OWASP LLM Top 10 の LLM06 Excessive Agency が直接該当）[公式値]（OWASP LLM Top 10）。
理由 3: Tool 側の信頼境界が複雑
MCP server / function calling tool は agent の identity ではなく tool の権限 で動作します。tool 側のセキュリティ実装が甘いと、agent からの呼び出しが認可境界を越える事故が起きます。
2. 4 つの境界モデル
境界 1: user × agent
人間ユーザーが agent を起動する権限。OIDC / SAML 等の従来 SSO で十分（OpenID Connect Core 1.0）[公式値]。Delegation token（OAuth 2.1 の on-behalf-of flow）で agent に短命権限を渡すのが現実解。
[user] -- OIDC --> [agent runtime]
↓
delegation token (15 min, scope=task:execute)
境界 2: agent × tool
最重要境界。MCP scope + Capability token で タスクごと最小権限を渡します。MCP scope の粒度設計は MCP権限設計の判断軸 allowlist粒度とscope命名から組織導入まで を参照[公式値]（MCP 仕様）。
[agent] -- capability token (5 min, scope=mcp:github:read:repo) --> [MCP tool]
実装パターン:
- OAuth 2.1 + RAR (Rich Authorization Requests) で詳細な authorization details を渡す[公式値]（RFC 9396）
- Token exchange で agent ID と tool ID を分離（RFC 8693）
- 詳細な実装は MCPサーバー設計パターン集 の §4 auth と監査ログ章
境界 3: agent × agent
親 agent が child sub-agent を呼ぶ。Codex MultiAgentV2 では path-based scope（/root/agent_a）で構造化されます[公式値]（OpenAI Codex Subagents）。Claude Code は /agents + Hook + permission profile で子の権限を制限[公式値]（Claude Code Subagents 公式）。
実装ポイント:
- 権限の継承を禁止: 親の権限がそのまま子に流れない設計（
max_depth=1がデフォルトの理由）[公式値] - path-based scope で sub-agent ごとの境界を明示
- 並列実行は MCP context propagation で agent identity を保持
境界 4: agent × data
agent が DB / API を読み書きする権限。RBAC + ABAC の従来設計を delegation 経由 で適用します。
- RBAC: agent ID にロールを割り当てる
- ABAC: agent task の context（時刻・リクエスト元・対象リソース属性）で動的判定
- ReBAC: 「user が owner であるリソースだけ agent が読める」のようなグラフ型条件
ReBAC 実装の選択肢:
- Google Zanzibar — 原典
- OpenFGA — オープンソース（[公式値]）
- SpiceDB — マネージド
3. 実装パターン: 4 モデル別 token / scope 設計
| 境界 | 推奨 token 種別 | 寿命 | scope 例 |
|---|---|---|---|
| user × agent | OIDC ID token + access token | 15-60 分 | task:execute |
| agent × tool | Capability token (OAuth 2.1 + RAR) | 2-15 分 | mcp:github:write:repo:owner/name |
| agent × agent | Delegation token (path-scoped) | 親と同じ or 短く | /root/agent_a:read |
| agent × data | DB role / API key + ABAC policy | 起動中のみ | db:readonly:tenant_x |
Capability token の設計原則
3 原則（経験則）:
- 最小スコープ: タスクに必要な scope だけ
- 短命: タスク完了で失効
- revocable: 親 agent から取り消し可能（OAuth 2.1 token revocation endpoint）[公式値]
4. 失敗パターン Top 3 と対策
パターン 1: Agent に長命 token を持たせる
OAuth 2.1 で PKCE 必須・implicit 廃止[公式値]（OAuth 2.1 draft）が標準ですが、agent 用 token を長命にすると流出時の被害が増大。短命 + refresh token rotation で運用するのが現実解。
パターン 2: Tool 側で agent identity を verify しない
MCP tool が token の sub (subject) を確認せず、scope だけで認可すると、別 agent の token を流用された時に検知できません。actor + on-behalf-of の chain を全部記録するのが現実解（RFC 8693 Token Exchange [公式値]）。
パターン 3: Sub-agent が親と同じ権限を継承
max_depth=1 を解除して再帰的に sub-agent を起動すると、権限が transitively に伝播して暴走しやすい[公式値]（Codex Multi-Agents 通信構造 参照）。Hook で深度制限を強制するのが現実解（PlanGate v8.6 Hook Enforcement）。
5. ガバナンス hub への接続
Audit log の必須項目
5 項目（経験則）: (1) actor（user → agent ID チェーン）、(2) action、(3) resource、(4) decision（allow / deny）、(5) reason（policy ID + matched rule）。詳細は AIエージェントの可観測性と障害解析 と AIコーディング運用の可観測性スタック2026。
NIST AI RMF / OWASP LLM Top 10 との対応
- NIST AI Risk Management Framework: agent 認可境界は GOVERN / MAP / MEASURE / MANAGE の各機能に直結[公式値]（NIST AI RMF）
- OWASP LLM06 Excessive Agency: 過剰な agent 権限が直接の対策対象[公式値]
- OWASP LLM02 Sensitive Information Disclosure: 認可境界の漏れで情報漏洩
👉 シリーズ全体像: AIコーディングセキュリティ設計の全体像
FAQ
Q1. 4 つの境界モデルすべてを最初から実装すべきですか？
不要です（経験則）。まず agent × tool（境界 2）から始めるのが現実解。MCP scope + Capability token の最小実装で 80% のリスクをカバーできます。残り 3 境界はチームと利用規模に応じて段階導入。
Q2. OAuth 2.1 と OAuth 2.0 の違いは？
OAuth 2.1 は PKCE 必須・implicit flow 廃止・refresh token rotation 推奨[公式値]（OAuth 2.1 draft）。AI Agent の delegation token を発行する場合は OAuth 2.1 準拠が必須水準です。
Q3. Capability token と JWT は何が違いますか？
JWT は token のフォーマット、Capability token は 権限のモデルです。実装上は JWT で Capability token を表現することが多いですが、設計思想として「最小スコープ・短命・revocable」を満たすかが本質。詳細は 認証・認可設計のやり直しガイド を参照。
Q4. ReBAC（OpenFGA / Zanzibar）は AI Agent でも使えますか？
使えます（経験則）。「user が owner であるリソースだけ agent が読める」のようなグラフ型条件を、agent ID をノードとして扱えば自然に表現できます。詳細は OpenFGA 公式[公式値] を参照。
Q5. Hook と認可境界はどう連動しますか？
Hook で deterministic に認可境界を強制します（Claude Code hooks の実践パターン集）。例: PreToolUse hook で「agent ID が許可リストに含まれているか」「scope が要求された tool に対して有効か」を実行前検証。承認境界の運用例は PlanGate v8.6 Hook Enforcement。
References
- OAuth 2.1 draft — PKCE 必須・implicit 廃止
- RFC 9396 OAuth 2.0 Rich Authorization Requests — 詳細スコープ表現
- RFC 8693 OAuth 2.0 Token Exchange — Token chaining
- OpenID Connect Core 1.0 — OIDC 公式仕様
- MCP 仕様 — Model Context Protocol scope
- OWASP LLM Top 10 (2025-26) — LLM02 / LLM06
- OWASP ASVS 5.0 — 認証認可検証要件
- NIST AI RMF — AI リスク管理フレームワーク
- OpenFGA 公式 — オープンソース ReBAC
- Google Zanzibar Paper — ReBAC 原典
