エージェントIAM設計——スコープ付き短命認証情報で過剰権限を防ぐ

エージェント基盤を大規模展開した後で、全エージェントが共通の長命サービスアカウントを使い回していることに気づく——これは設計上の構造的欠陥であり、インシデント発生時の blast radius を一挙に最大化する。

Kuuのエンタープライズ向けエージェントガバナンス支援（RDE）で頻繁に遭遇するのが「とりあえず動く」優先のIAM設計だ。エージェントが増えるほど権限の粒度と一貫性が崩れ、どのエージェントが何にアクセスできるかを誰も把握できない状態に陥る。

本記事では、AWS Well-Architected Generative AI Lensおよび OpenID Foundation (OIDF) が公開したエージェントID管理ガイダンスをもとに、エージェントIAMの多層設計を解説する。

なぜ長命サービスアカウントがエージェントに危険なのか

長命サービスアカウントをエージェントに渡すとExcessive Agencyが発生し、過剰権限行使を招く。

従来の人間オペレーターを前提としたIAM設計では、「ロールを定義 → ユーザーに割り当て → 必要に応じて更新」というライフサイクルが成立する。しかしAIエージェントはこのモデルを根底から崩す。

エージェントは実行時に新たなコンテキストを取得し、ツールを連鎖的に呼び出す。TTL 90日のサービスアカウントキーを保持するエージェントは、設計者の想定外の経路でデータやAPIに到達できる。これが「Excessive Agency（過剰権限行使）」と呼ばれる問題であり、AWS Well-Architected Generative AI Lensでも「High Risk」に分類されている。

主要なリスクシナリオは3つだ。

横展開リスク: プロンプトインジェクション攻撃が成立すると、そのサービスアカウントが持つすべての権限が攻撃者に渡る
長期窃取リスク: 短命トークンなら数分〜数時間で無効化されるが、90日有効のAPIキーが漏洩した際の対応コストは桁違いに跳ね上がる
権限連鎖リスク: オーケストレーター構成では、オーケストレーターの権限がサブエージェントに継承されやすく、意図しないシステムへのアクセスが連鎖する

長命認証情報を使い続けるアーキテクチャは、エージェントの台数が増えるほどリスクが乗算的に拡大する。

タスクスコープのエフェメラル認証情報設計

タスク開始時に発行し完了時に失効する短命トークンは、漏洩しても被害をそのタスク実行時間内に封じ込められる。

エフェメラル認証情報の設計原則は「発行 → 使用 → 失効」の3ステップを1タスクの単位に収めることだ。

Workload Identity Federationの活用

AWSでは AssumeRoleWithWebIdentity、GCPではWorkload Identity Federationを使い、IdPが発行するOIDCトークンをもとにその場で一時的な認証情報を生成できる。静的なAPIキーを発行・保管・ローテーションする必要がなく、キー漏洩リスクを構造的に排除できる。

``yaml # AWS例：エージェント実行ロールのTrust Policy { "Version": "2012-10-17", "Statement": [{ "Effect": "Allow", "Principal": { "Federated": "arn:aws:iam::ACCOUNT_ID:oidc-provider/PROVIDER_URL" }, "Action": "sts:AssumeRoleWithWebIdentity", "Condition": { "StringEquals": { "PROVIDER_URL:sub": "system:serviceaccount:NAMESPACE:AGENT_SA" } } }] }``

タスク単位のロール引き受け

1タスク＝1IAMロール引き受けを原則とする。sts:AssumeRole でセッショントークンを発行し、タスク完了後に失効させる。セッションのTTLは業務の性質に応じて設定するが、15〜60分が実務的な目安だ。

タスクロールには iam:CreatePolicy や iam:AttachRolePolicy 等の権限管理アクションを含めてはならない。タスクスコープの外にある操作を「できない」ではなく「そもそも権限が存在しない」状態にすることが重要だ。

IAM Permissions Boundaryによる多層制御

IAM Permissions BoundaryはIAMの「権限の天井」だ。エージェントが実行時に権限昇格を試みても、Boundaryが定義した上限を越えることができない。

タスクスコープのトークンだけでは、エージェントが動的に権限を追加しようとする操作（Permission Escalation）に対応しにくい。IAM Permissions Boundaryを組み合わせることで多層防御を実現する。

Permissions Boundaryとは、IAMエンティティ（ユーザー・ロール）に設定できる「許可される権限の最大上限」を定義するマネージドポリシーだ。Boundaryが設定されたロールは、その範囲を超える権限を実際のIAMポリシーで付与されていても行使できない。

エージェント実行ロールには必ずPermissions Boundaryを適用し、「エージェント基盤全体として許容されるアクション」の上限を定義する。個別のタスクポリシーはそのBoundary内でさらに絞る、という2層構造を取る。

``json { "Version": "2012-10-17", "Statement": [ { "Sid": "AllowedServices", "Effect": "Allow", "Action": [ "s3:GetObject", "s3:PutObject", "dynamodb:GetItem", "dynamodb:PutItem", "bedrock:InvokeModel" ], "Resource": "*" }, { "Sid": "DenyIAMManagement", "Effect": "Deny", "Action": "iam:*", "Resource": "*" } ] }``

AWS Organizationsを使う大規模環境では、SCPをOrganization単位でエージェント専用アカウントに適用し、Permissions BoundaryはロールごとのIAMレイヤーで使う2段構えが推奨される。SCPはアカウント全体の防衛線、Permissions Boundaryは個別ロールの権限天井という位置付けだ。

エージェントアイデンティティとWorkload Identity Federation

エージェントIDは継承型と独立ワークロード型の2モデルがある。いずれもOIDCで静的APIキーを不要にできる。

OpenID Foundation（OIDF）が公開した「Identity Management for Agentic AI」によると、エージェントのアイデンティティモデルは2つに大別される。

モデル1：ユーザー権限継承型（Delegated User Identity）

エージェントが「ユーザーAの代理人」として動作する。OAuth 2.0の委譲フロー（Authorization Code Grant + Refresh Token）を用いて、ユーザーのスコープを引き継いだアクセストークンをエージェントに渡す。ユーザーが明示的に承認した範囲のみエージェントが操作できるため、権限境界が人間の意思決定に紐付く。

適合ユースケース：エンドユーザー向けのアシスタント型エージェント（承認者の権限でドキュメントを作成・送信する等）

モデル2：独立ワークロードID型（Independent Workload Identity）

エージェント自体が独自のサービスプリンシパルを持つ。KubernetesのService Account TokenやAzure Managed Identityがその実装例で、エージェントの起動コンテキストからIdPが自動的にトークンを発行する。ユーザー関与なしに自律実行するバックグラウンドエージェントに適する。

適合ユースケース：定期バッチ処理・モニタリングエージェント・オーケストレーター型エージェント

MCPとOAuth 2.0の統合

MCP（Model Context Protocol）はOAuth 2.0ベースの認証サポートを正式導入している。MCPサーバーをリソースサーバーとして登録し、エージェントがアクセストークンを提示してツールを呼び出す設計により、既存のIAM・IdP基盤を流用しながらエージェントのツールアクセスを制御できる。MCPの実装詳細も合わせて参照されたい。

大規模運用での設計ポイント

エージェントIAM運用はロールのNaming Convention・IaC化・IAM Access Analyzerの三本柱で体系化できる。

Naming ConventionとタグによるTracability

エージェントロールには agent-{チーム}-{用途}-{環境} のNaming Conventionと、AgentType・TeamOwner・CreatedBy タグを必須化する。これにより、IAM Access Analyzerで検出された未使用権限を特定のエージェントに帰属させ、権限棚卸しを自動化しやすくなる。

IaCによる権限境界テンプレートの管理

Permissions Boundary PolicyはTerraform/CloudFormationで定義し、エージェント実行ロール生成のテンプレートに組み込む。「承認済みBoundaryテンプレートを適用せよ」というポリシーをCI/CDに組み込めば、Boundaryなしのエージェントロールがデプロイされることをゲートで防げる。

IAM Access Analyzerによる継続的監視

タスクスコープのエフェメラルトークンでも、権限定義が実際の使用パターンと乖離していれば過剰権限が潜在する。IAM Access Analyzerの「未使用アクセス分析」を定期実行し、「定義されているが90日間一度も使われていないアクション」を自動で検出・削除するサイクルを回す。

エージェントの可観測性設計と組み合わせることで、IAMログとエージェントトレースを突き合わせた権限ドリフト検知が可能になる。

参考

まとめ

エージェントIAM設計の要点は3点に集約される。長命認証情報を廃してタスクスコープのエフェメラルトークンに移行すること、IAM Permissions Boundaryで権限の上限を構造的に設定すること、そしてWorkload Identity FederationでAPIキー発行そのものをなくすことだ。エージェント台数が増えるほど、これらの仕組みをIaC化・自動化していないとIAM管理が手作業の限界を超える。

Kuuのエンタープライズ向けエージェントガバナンス支援（RDE）では、IAM設計・権限境界の定義・継続的監視体制の構築をトータルで支援している。エージェント基盤のIAM設計に課題を感じている場合はお問い合わせください。