第10章: AIエージェント時代の認可設計と未来展望

AIエージェントが変えるアクセス制御の常識

第1章から第9章まで、私たちはDAC・MAC・RBAC・ABAC・ReBAC・Zero Trustと、 半世紀以上にわたるアクセス制御モデルの進化を追いかけてきました。 これらのモデルはすべて暗黙的に一つの前提を共有していました。「アクセスを要求するのは人間である」という前提です。

2025年以降、その前提が崩壊しつつあります。 AIエージェントは自律的にコードを書き、データベースを検索し、外部APIを呼び出し、 メールを送信し、ファイルを削除します。それも24時間、人間の監視なしに。 Okta の2025年調査によると、88%の組織がAIエージェントによるセキュリティインシデントを経験しています。 しかし、AIエージェントを独立したアイデンティティとして扱う組織はわずか22%に過ぎません。

非人間アイデンティティ（NHI）とは何か

非人間アイデンティティ（Non-Human Identity, NHI）とは、人間ユーザーではなく システムやソフトウェアを表すアイデンティティの総称です。 具体的にはサービスアカウント・APIキー・OAuthトークン・AIエージェントが含まれます。 NHIはすでに現代の企業環境でユーザーアカウント数を大幅に上回っており、 適切に管理されなければ攻撃の足掛かりになります。

AIエージェントが NHI として特に危険なのは、ツールを通じて実際の副作用を持つ操作を実行するからです。 ファイルの削除、メールの送信、コードのデプロイ、データベースのレコード更新。 これらはいずれも取り消しが困難または不可能な操作です。 しかも最小権限の適用が人間以上に難しい——エージェントが実行時に何をするかは事前に完全には予測できないからです。

MCP（Model Context Protocol）とOAuth 2.1

MCPとは何か

MCP（Model Context Protocol）は、2025年にAnthropicが策定し業界標準として普及しつつある AIエージェントとツール間の通信プロトコルです。 AIモデル（Claude・GPT・Gemini等）が外部ツール（データベース・ファイルシステム・外部API等）に 安全にアクセスするための標準インターフェースを定義します。 認可基盤にはOAuth 2.1を採用しており、最新のセキュリティプラクティスを取り込んでいます。

OAuth 2.1 の主要変更点

OAuth 2.1（draft-ietf-oauth-v2-1-15、2026年3月現在）は OAuth 2.0 の BCP（ベストカレントプラクティス）を 一本化した改訂版です。後方互換を維持しながら、過去10年間の教訓から危険な機能を削除・強化しています。

• PKCEの全クライアント必須化: S256 アルゴリズムのみ許可。 plain は脆弱なため禁止。パブリッククライアント限定だった PKCE が コンフィデンシャルクライアントにも必須化されました。
• Implicit フロー削除: アクセストークンをフラグメントでブラウザに返すフローは 履歴漏洩リスクから廃止。PKCE 付き認可コードフローに一本化。
• ROPC（Resource Owner Password Credentials）削除: ユーザー名/パスワードを直接渡すフローも廃止。フィッシングリスクを根絶します。
• RFC 8707（リソースインジケーター）の必須化: すべてのトークンリクエストで対象リソースを明示する必要があり、 トークンの流用（Confused Deputy 攻撃）を防ぎます。
• RFC 8414（認可サーバーメタデータ発見）の組み込み: クライアントが設定不要でエンドポイントを自動発見できる仕組みを標準化。

MCPでのスコープ設計

MCPのアクセス制御において最も重要なのはスコープ設計です。 第5章でABACの属性設計が権限爆発を防ぐ鍵だと学びましたが、 MCPでも同様にスコープの粒度設計がセキュリティの根幹を決めます。 読み取りと書き込み/削除を必ず分離し、エージェントには最小限のスコープのみを付与します。

# MCPサーバー設定: OAuth 2.1スコープ設計例
{
  "mcpServers": {
    "file-system": {
      "transport": "http",
      "url": "https://mcp.example.com/filesystem",
      "auth": {
        "type": "oauth2",
        "client_id": "agent-fs-client",
        "scope": "filesystem:read",
        "resource": "https://mcp.example.com/filesystem"
      }
    },
    "database": {
      "transport": "http",
      "url": "https://mcp.example.com/db",
      "auth": {
        "type": "oauth2",
        "client_id": "agent-db-client",
        "scope": "db:query",
        "resource": "https://mcp.example.com/db"
      }
    }
  }
}

# スコープ命名規則（最小権限原則に基づく分離）
# filesystem:read      — ファイル読み取りのみ
# filesystem:write     — ファイル書き込み（要別途承認）
# filesystem:delete    — ファイル削除（要別途承認 + SoD制約）
# db:query             — SELECT クエリのみ
# db:write             — INSERT/UPDATE（要別途承認）
# email:send           — メール送信（高リスク: 人間レビュー推奨）

また、エージェント間の認可連携には RFC 8693（トークン交換）を使います。 上流エージェントのトークンを下流ツール用トークンに交換することで、 「誰がリクエストしているか」の証明チェーンを維持します。 PKCE だけでは不十分で、このトークン交換による来歴証明が重要です。

Okta for AI Agents — 非人間ID管理の専用基盤

Okta は2025年4月に Okta for AI Agents を発表し、2026年4月に GA（一般公開）しました。 従来の Okta は人間ユーザーの ID 管理に特化していましたが、 AI エージェント時代の NHI 管理という新たなニーズに対応した専用機能群です。

3つのコア機能

• Identity Security Posture Management（ISPM）: すべての NHI（AIエージェント・サービスアカウント・APIキー）を継続的にスキャンし、 過剰権限・長期未更新の認証情報・孤立したアカウントをリアルタイムで検出します。 人間の IAM レビューサイクルを待たず、常時リスク監視を実現します。
• Universal Directory の NHI 拡張: AIエージェントをリスクスコア・オーナー・用途・使用期間で分類し、 人間ユーザーと同じライフサイクル管理（プロビジョニング→更新→デプロビジョニング）を適用します。 第4章で解説した RBAC の職能ロール管理をエージェントにも適用するイメージです。
• Cross App Access（XAA）: エージェント間・エージェントとツール間の接続を標準化された OAuth 2.1 フローで確立します。 アドホックな API キー共有ではなく、一元管理された接続ポリシーでエージェント間通信を制御します。

AIエージェントへの職務分離（SoD）適用

第4章で RBAC の SoD（職務分離）を学びました。「発注と支払承認を同一人物が担ってはならない」という原則です。 AIエージェントにも同様の SoD を適用する必要があります。 例えば「コードを書くエージェント」と「デプロイを実行するエージェント」を分離し、 同一エージェントがコード生成からデプロイまで一貫して実行できないよう制約します。

Okta for AI Agents の NHI 管理では、AIエージェントに対する定期アクセスレビュー（アクセス認定）の自動化も提供します。 人間のアクセスレビューは多くの組織で半年〜年1回実施されますが、 AIエージェントには専用の仕組みがこれまで存在しなかったため、権限が蓄積し続けるリスクがありました。

Amazon Bedrock AgentCoreとCedarの採用

AgentCoreのアーキテクチャ

AWS は2025年末に Amazon Bedrock AgentCore を発表しました。 エージェントとリモート MCP ツールの間に Gateway を配置するアーキテクチャを採用し、 三層の独立した認可制御でエージェントのツールアクセスを制御します。

graph TB
  Agent([AIエージェント])
  Cognito[Amazon Cognito]
  Gateway[AgentCore Gateway]
  Cedar[Cedarポリシーエンジン]
  ToolA[MCPツール: ファイルシステム]
  ToolB[MCPツール: データベース]
  ToolC[MCPツール: 外部API]
  Agent -->|IDトークン| Cognito
  Cognito -->|ID伝播| Gateway
  Gateway -->|ツールアクセス要求| Cedar
  Cedar -->|Allow / Deny| Gateway
  Gateway -->|許可されたツールのみ表示| ToolA
  Gateway -->|許可されたツールのみ表示| ToolB
  Gateway -.->|LLMから不可視| ToolC
  style Agent fill:#8b5cf6,stroke:#6d28d9,color:#fff
  style Cognito fill:#f97316,stroke:#ea580c,color:#fff
  style Gateway fill:#10b981,stroke:#059669,color:#fff
  style Cedar fill:#3b82f6,stroke:#1d4ed8,color:#fff
  style ToolA fill:#374151,stroke:#6b7280,color:#fff
  style ToolB fill:#374151,stroke:#6b7280,color:#fff
  style ToolC fill:#991b1b,stroke:#7f1d1d,color:#fff

Cedarによる認可設計

AgentCore の認可エンジンとして採用された Cedar（第5章で解説）の設計で特に重要なのがデフォルト拒否（Default Deny）の原則です。 Cedar ポリシーをGatewayに関連付けると、すべてのツールアクセスはデフォルトでブロックされます。 許可ルールを明示的に記述したツールのみがアクセス可能になります。

さらに画期的なのはツールフィルタリングの仕組みです。 Cedar で許可されていないツールは、LLM（大規模言語モデル）自体から見えません。 つまりエージェントは「存在するが使えないツール」ではなく「そもそも存在しないツール」として扱われます。 これにより、エージェントが誤ってアクセスを試みること自体を防止できます。

// Cedar ポリシー例: 読み取り専用エージェントへのツール制限
permit(
  principal == Agent::"readonly-analyst",
  action == Action::"invoke_tool",
  resource in ToolSet::"read-only-tools"
) when {
  // 許可されるツール: 検索・参照のみ
  resource.toolName in ["search_documents", "read_file", "query_db_readonly"]
};

// 書き込み・削除ツールは明示的拒否（ポリシーなし = 暗黙拒否でも機能するが明示推奨）
forbid(
  principal == Agent::"readonly-analyst",
  action == Action::"invoke_tool",
  resource in ToolSet::"write-tools"
);

// ユーザー別ポリシー: プレミアムユーザーのエージェントのみ外部API呼び出しを許可
permit(
  principal == Agent::"user-agent",
  action == Action::"invoke_tool",
  resource == Tool::"external-api"
) when {
  context.user.subscription == "premium" &&
  context.request.hour >= 9 &&
  context.request.hour < 18
};

AWS が Cedar を OPA より選んだ理由は3点です。 第一に決定論的動作——同じ入力には常に同じ結果を返すことが保証されています。 第二に形式検証可能性——ポリシーに論理的矛盾がないことをツールで検証できます。 第三に人間可読性——Rego より直感的な構文で、非エンジニアもレビューに参加できます。

NGAC — 次世代アクセス制御の可能性

Policy Machineとグラフ構造

NGAC（Next Generation Access Control）は、NISTが開発した グラフベースの統一アクセス制御フレームワークです（ANSI/INCITS 565-2020）。 第1章で紹介したアクセス制御モデルの歴史的系譜の最前線に位置します。 RBAC・ABAC・DAC・MAC を別々のフレームワークとして実装するのではなく、Policy Machine（PM）という単一エンジンで統一的に表現することを目指しています。

NGAC の核心は2種類の DAG（有向非巡回グラフ）と Association 辺の組み合わせです。

• ユーザー DAG: ユーザーと組織階層（ユーザー属性・ロール・部署・組織）を表す
• オブジェクト DAG: リソースとその分類階層（ファイル・フォルダ・プロジェクト・部門）を表す
• Association 辺: ユーザー DAG のノードからオブジェクト DAG のノードへ、操作セットを持つ有向辺。これがアクセス権を表す

Policy Machineの5コンポーネント

Policy Machine は第5章で学んだ XACML アーキテクチャ（PEP/PDP/PIP/PAP）に加えて、EPP（Event Processing Point）を持つ5コンポーネント構成です。 EPP はポリシー関連イベントをキャッチして自動的なアクション（例：アクセス後の通知・権限の自動失効）を実行します。 これにより Zero Trust のコンテキスト適応型制御との統合が自然に表現できます。

NGACとXACMLの比較

NIST SP 800-178 はNGACとXACMLの比較分析を提供しています。最大の差異は管理操作自体へのポリシー適用です。 XACML では「誰がリソースにアクセスできるか」を制御しますが、 NGAC では「誰が誰にアクセス権を付与できるか」というメタレベルの権限制御も同一フレームワークで表現できます。 これは第4章の RBAC における「誰がロールを付与できるか」の問題を根本的に解決します。

2025年の学術研究では、マルチクラウド環境での特権分析においてNGACがABACより54%高速という報告があります（arXiv 2025）。 グラフ構造による権限評価のアルゴリズム的優位性が、大規模環境で顕在化します。 ただし実装の複雑さから、現時点では NISTのリファレンス実装と研究プロジェクトが中心です。

アクセス制御モデル選択の意思決定フレームワーク

本シリーズ全10章で学んだアクセス制御モデルを、実際の設計に活用するための意思決定フレームワークを示します。 重要なのは「どのモデルが正解か」ではなく、「どのモデルをどう組み合わせるか」です。

graph TB
  Start([設計開始])
  Q1{機密分類が厳格か}
  Q2{リソース所有者が権限を決めるか}
  Q3{職能ロールで十分か}
  Q4{ドキュメント共有が中心か}
  Q5{マイクロサービス横断か}
  Q6{AIエージェントが主体か}
  Q7{複数モデルを統合したいか}
  MAC[MAC - SELinux/MLS]
  DAC[DAC - ファイルシステム型]
  RBAC[RBAC - ロール100以下]
  ABAC[ABAC+PBAC - 細粒度条件]
  ReBAC[ReBAC - OpenFGA/SpiceDB]
  OPA[OPA - Policy-as-Code]
  AI[Cedar+MCP+OAuth2.1+NHI管理]
  NGAC[NGAC - Policy Machine]
  Hybrid[多層ハイブリッド設計]
  Start --> Q1
  Q1 -->|Yes: 軍事/政府| MAC
  Q1 -->|No| Q2
  Q2 -->|Yes| DAC
  Q2 -->|No| Q3
  Q3 -->|Yes: ロール安定| RBAC
  Q3 -->|No: ロール爆発| ABAC
  RBAC --> Q4
  ABAC --> Q4
  Q4 -->|Yes| ReBAC
  Q4 -->|No| Q5
  Q5 -->|Yes| OPA
  Q5 -->|No| Q6
  Q6 -->|Yes| AI
  Q6 -->|No| Q7
  Q7 -->|Yes| NGAC
  Q7 -->|No| Hybrid
  style MAC fill:#ef4444,stroke:#dc2626,color:#fff
  style DAC fill:#f97316,stroke:#ea580c,color:#fff
  style RBAC fill:#8b5cf6,stroke:#6d28d9,color:#fff
  style ABAC fill:#3b82f6,stroke:#1d4ed8,color:#fff
  style ReBAC fill:#10b981,stroke:#059669,color:#fff
  style OPA fill:#ec4899,stroke:#db2777,color:#fff
  style AI fill:#f59e0b,stroke:#d97706,color:#fff
  style NGAC fill:#14b8a6,stroke:#0d9488,color:#fff
  style Hybrid fill:#6b7280,stroke:#4b5563,color:#fff

アクセス制御モデル選択早見表

多層ハイブリッドが現実解である理由

本シリーズを通じて一貫して見えてきた真実は、単一のアクセス制御モデルで 現代システムのすべての要件を満たすことはできないということです。 第4章の RBAC は組織の職能階層を自然に表現しますが、細粒度の属性制御が苦手です。 第5章の ABAC は柔軟な条件制御を可能にしますが、ロール管理との統合が複雑です。 第6章の ReBAC はグラフ構造のリソース関係に強力ですが、時間・場所の制御は外部に委ねます。

現実の設計では、これらを層として積み重ねます。 認証レイヤーで OIDC、粗粒度認可でRBAC、細粒度認可でABAC/ReBAC、 ポリシー管理でOPA/Cedar、AIエージェントへのNHI管理——という多層構造が典型的な到達点です。 AIエージェント時代には、この多層の上にさらに「非人間アイデンティティ」レイヤーが加わります。

シリーズ総括 — アクセス制御の本質

第1章で参照モニタの誕生から始まり、第2章の HRU 問題という計算不可能性の壁、 第3章のBell-LaPadulaとBibaによる機密性と完全性の二本柱、 第4章のRBACによる組織的権限管理の標準化、 第5章のXACMLとOPAによる動的ポリシーエンジン、 第6章のGoogle ZanzibarとReBACによるグラフ認可の革命、 第7章のNIST Zero Trustが再定義した「信頼とは何か」、 第8章のクラウドとマイクロサービス時代の実装パターン、 第9章のOWASP A01とセキュリティ検証の方法論。

そして本章で到達したAIエージェント時代の認可設計。 半世紀以上にわたるアクセス制御の進化を俯瞰すると、一本の糸が見えます。「誰が、何を、なぜ必要とするか」という問いへの答えが、 時代とともに複雑化し、きめ細かくなり、動的になり続けているという軌跡です。

モデルは変わっても本質は変わりません。最小権限・デフォルト拒否・継続的検証。 この三原則が、次の技術革新が訪れる時代にも、あなたの設計の基盤であり続けるはずです。