7月7日、AWSが「Enforce least-privilege authorization in multi-agent AI chains using Cedar」と題した記事を公開した。マルチエージェントAIシステムでは、エージェントがタスクを別のエージェントに委譲するたびに認可スコープが暗黙的に拡大するリスクがある。OWASPはこのリスクをASI03: Identity & Privilege Abuseとして分類しており、RBACポリシーが存在していてもチェーンの末端エージェントが元のユーザーの意図を超えた操作を実行できてしまうという問題は、MCPの普及によってエージェント連携が一般化するにつれて深刻度を増している。この問題に対してAWSは、Cedar（オープンソースの認可ポリシー言語）とAmazon Verified Permissionsを組み合わせた3層ポリシーモデルという具体的な回答を示した。

なぜ今マルチエージェント認可が注目されるのか

MCP（Model Context Protocol）の普及により、AIエージェントが外部ツールやAPIを呼び出す構造が急速に標準化されつつある。MCPクライアントとは、MCPサーバーが公開するツールをLLMエージェントが呼び出すための仲介層であり、単一エージェントが複数のMCPサーバーを束ねる構成では、エージェント→エージェント→ツールという多段委譲が自然に発生する。

このアーキテクチャの問題は、委譲の連鎖が深くなるほど「誰の権限で動いているか」が曖昧になる点にある。ユーザーAが読み取り操作を意図して起動したオーケストレーターエージェントが、下流の専門エージェントに委譲する際に書き込み権限まで受け渡してしまうケースは、既存のRBACモデルでは検知しにくい。Verified PermissionsはCedar言語を評価エンジンとして採用しており、このような多段委譲を含む複雑な認可ロジックを宣言的かつ監査可能な形で記述できる点が特徴だ。

3層ポリシーモデルの構造

評価は順番に実行され、最初のDenyで即座に停止する。

L1：エージェントがツールを呼び出せる条件

// L1-001: Finance agent can invoke payment tools
permit(
  principal == AgentAuthz::Agent::"finance-agent",
  action == AgentAuthz::Action::"invoke_tool",
  resource == AgentAuthz::Tool::"process_payment"
) when {
  principal.trust_level >= 3 &&
  principal.namespace == "payments" &&
  principal.lifecycle_stage == "production"
};

trust_levelは1〜5の整数スケールで、エージェントの成熟度を表す。1が新規未検証、3が統合テスト・セキュリティレビュー通過済み、5が本番実績あり。自己申告ではなく、エージェントのプロモーションパイプラインで組織が付与する。lifecycle_stage（development / staging / production）は、開発中エージェントが本番ツールを呼べないようにするガード。

L2：委譲チェーンの深さとcapabilityを制約

// L2-002: Orchestrator can delegate to data agent
permit(
  principal == AgentAuthz::Agent::"orchestrator",
  action == AgentAuthz::Action::"delegate_task",
  resource == AgentAuthz::Agent::"data-bot"
) when {
  context.delegation_depth <= 3 &&
  context.target_capabilities.containsAll(context.requested_capabilities)
};

別途forbidポリシー（L2-004）でシステム全体のハード上限として5ホップを強制する。

L3：ここが最も重要なレイヤー

// L3-001: High-risk tool (delete_records) requires admin + MFA
permit(
  principal == AgentAuthz::Agent::"data-bot",
  action == AgentAuthz::Action::"invoke_tool",
  resource == AgentAuthz::Tool::"delete_records"
) when {
  context.originating_user.role == "admin" &&
  context.originating_user.mfa_verified == true &&
  context.delegation_depth <= 2
};

principalはあくまでエージェントのまま、context.originating_userを通じて人間ユーザーを検証する点が設計上のポイントだ。このレイヤーがなければ、適切なcapabilityを持つエージェントが誰のリクエストに基づいているかに関わらず、delete_recordsのような破壊的ツールを呼べてしまう。

アーキテクチャの全体像

認証（steps 1–3）と認可（steps 4–10）は明確に分離されている。

認証フロー：

1. ユーザーがOIDC準拠のIdP（本実装ではTOTP MFA付きAmazon Cognito）で認証
2. Cognitoが署名済みJWT（sub、role、amr、session_idを含む）を発行
3. ユーザーがJWTとタスクリクエストをAIエージェント（MCPクライアント）に渡す

認可パイプライン：

• AWS WAF：CommonRuleSet・SQLiRuleSet・レート制限・ボディサイズ制約でフィルタリング
• Amazon API Gateway（Cognitoオーソライザー）：JWT署名を検証、不正・期限切れトークンを拒否
• MCPアダプター Lambda：JWTクレームをCedarコンテキスト属性にマッピングし、AWS Secrets ManagerのキーでHMAC-SHA256署名を計算
• Cedar評価器 Lambda：HMAC署名を検証し、Verified PermissionsのポリシーストアからL2・L3ポリシーを取得して3層評価を実行
• 監査ログ：OCSF 99001形式でCloudWatch Logsに送出。送出失敗時はSQS DLQにフォールバック

コンテキスト完全性の保護：HMACとOAuthトークン交換の併用

委譲ホップをまたいでユーザーコンテキストを守る仕組みが2つある。

• HMAC-SHA256：user_id、role、mfa_verified、authentication_method、session_idの正規順でHMACを計算。下流の評価器は全てこの署名を検証してからコンテキストを信頼する
• OAuth 2.0 Token Exchange（RFC 8693）：On-Behalf-Of（OBO）パターンで委譲スコープを制限。元のフルトークンをそのまま渡すのではなく、委譲タスクのスコープに絞ったOBOトークンに交換する

エンタープライズ環境では両方を併用することが推奨されている。OAuthは「誰が誰の代わりにどの権限で動いているか」を追跡し、HMACは「コンテキストが信頼できるソースから来ており改ざんされていない」ことを検証する、という役割分担だ。

デプロイ手順の概要

参照実装はGitHubリポジトリで公開されており、AWS CDKでデプロイできる。前提条件として、対象リージョンでCDKブートストラップ済みのAWSアカウント、Python 3.12以降、Node.js 20以降、および Lambda・API Gateway・Verified Permissions・Secrets Manager・VPC・CloudWatchへの権限を持つIAMクレデンシャルが必要だ。

注意点

記事内で明示されている重要な警告がある。参照実装ではエージェント属性（trust_level等）をリクエストペイロードから受け取る実装になっているが、本番環境ではVerified Permissionsのエンティティストアのような権威ある情報源に対して検証する必要がある。侵害されたエージェントが自身の信頼スコアを詐称できてしまうためだ。

詳細はEnforce least-privilege authorization in multi-agent AI chains using Cedarを参照していただきたい。