# エージェントIAM設計——スコープ付き短命認証情報で過剰権限を防ぐ > エージェントへの長命認証情報付与はExcessive Agencyの温床。タスクスコープのエフェメラルトークンとIAM Permissions Boundaryで制御する多層IAM設計パターンを解説する。 - Canonical: https://kuucorp.com/blog/agent-iam-scoped-credentials-design/ - Date: 2026-06-06 - Last modified: 2026-06-06 - Publisher: Kuu株式会社 (https://kuucorp.com) --- エージェント基盤を大規模展開した後で、全エージェントが共通の長命サービスアカウントを使い回していることに気づく——これは設計上の構造的欠陥であり、インシデント発生時の blast radius を一挙に最大化する。 [Kuuのエンタープライズ向けエージェントガバナンス支援（RDE）](/services/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つだ。 1. **横展開リスク**: プロンプトインジェクション攻撃が成立すると、そのサービスアカウントが持つすべての権限が攻撃者に渡る 2. **長期窃取リスク**: 短命トークンなら数分〜数時間で無効化されるが、90日有効のAPIキーが漏洩した際の対応コストは桁違いに跳ね上がる 3. **権限連鎖リスク**: オーケストレーター構成では、オーケストレーターの権限がサブエージェントに継承されやすく、意図しないシステムへのアクセスが連鎖する 長命認証情報を使い続けるアーキテクチャは、エージェントの台数が増えるほどリスクが乗算的に拡大する。 ## タスクスコープのエフェメラル認証情報設計 > タスク開始時に発行し完了時に失効する短命トークンは、漏洩しても被害をそのタスク実行時間内に封じ込められる。 エフェメラル認証情報の設計原則は「発行 → 使用 → 失効」の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の実装詳細](/blog/mcp-server-implementation-tool-design/)も合わせて参照されたい。 ## 大規模運用での設計ポイント > エージェント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日間一度も使われていないアクション」を自動で検出・削除するサイクルを回す。 [エージェントの可観測性設計](/blog/agent-observability-tracing-instrumentation/)と組み合わせることで、IAMログとエージェントトレースを突き合わせた権限ドリフト検知が可能になる。 ## 参考 - [GENSEC05-BP01 Implement least privilege access and permissions boundaries for agentic workflows — AWS Well-Architected Generative AI Lens](https://docs.aws.amazon.com/wellarchitected/latest/generative-ai-lens/gensec05-bp01.html) - [Identity Management for Agentic AI v1.1 — OpenID Foundation](https://www.openid.or.jp/Identity-Management-for-Agentic-AI-jp_v1.1.pdf) - [Why AI Agents Need Least Privilege Too, and How to Enforce It Automatically — Security Boulevard](https://securityboulevard.com/2026/04/why-ai-agents-need-least-privilege-too-and-how-to-enforce-it-automatically/) - [How we contain Claude across products — Anthropic Engineering](https://www.anthropic.com/engineering/how-we-contain-claude) ## まとめ エージェントIAM設計の要点は3点に集約される。長命認証情報を廃してタスクスコープのエフェメラルトークンに移行すること、IAM Permissions Boundaryで権限の上限を構造的に設定すること、そしてWorkload Identity FederationでAPIキー発行そのものをなくすことだ。エージェント台数が増えるほど、これらの仕組みをIaC化・自動化していないとIAM管理が手作業の限界を超える。 [Kuuのエンタープライズ向けエージェントガバナンス支援（RDE）](https://kuucorp.com/services/rde/)では、IAM設計・権限境界の定義・継続的監視体制の構築をトータルで支援している。エージェント基盤のIAM設計に課題を感じている場合はお問い合わせください。