AIエージェントが「エージェント自身のIAMロール」でデータにアクセスする問題をAWSが解決 — ユーザーIDをUI→エージェント→データ層まで伝播させ、既存のアクセス制御ポリシーをそのまま適用する

10月7日、AWSが「Identity-aware AI data agents with AWS Lake Formation and Trusted Identity Propagation」と題した記事を公開した。この記事では、Amazon Bedrock AgentCoreとAWS Lake Formationを組み合わせ、AIデータエージェントがクエリを実行する際にリクエスト元のユーザーIDを透過的に伝播させることで、既存のアクセス制御ポリシーをそのまま適用しながら完全な監査証跡を実現するアーキテクチャパターンについて詳しく紹介されている。

AIエージェントの業務利用が広がるにつれ、「エージェントが誰の権限でデータにアクセスするか」はエンタープライズ全体のガバナンス課題になりつつある。個々のシステムではなく、データ基盤レベルで制御を統一できるかどうかが、エンタープライズへの本格導入の可否を左右する。

解決する課題：エージェントが「自分のIAMロール」で動く問題

自然言語でデータを問い合わせるAIエージェントを構築するとき、根本的な問題がある。エージェントはツールを呼び出す際、エージェント自身のIAMロールでAWSサービスにアクセスする。Lake Formationからすれば、アクセスしているのはエージェントであって、その背後にいる実際のユーザーではない。

これを解決しようとすると、従来は2択しかなかった。

ツールのアクセス権を絞る → セルフサービス分析ができなくなる
アプリケーションコードにアクセス制御ロジックを書く → ガバナンスがデータ層から外れる

この記事が示すのは第3の選択肢だ。ユーザーのIDをUI→エージェント→ツール→データ層まで全ホップで伝播させることで、Lake Formationが「誰が実行したか」を評価できるようにする。アプリケーションコードに認可ロジックは不要で、既存のLake Formationポリシーも変更不要。CloudTrailには実際のユーザー名が記録される。

セキュリティ上の最重要ポイント：IDトークンをFMに触れさせない

このパターンで最も工夫が凝らされているのが、FoundationModel（FM）のレイヤーをIDトークンが通過しない設計だ。

AIエージェントにおいて、FM（モデル本体）はどのツールを呼ぶかを決定し、その引数を生成する。プロンプト、ツールスキーマ、引数はすべてFMのコンテキスト内に入る。ここにIDトークンが紛れ込むと、プロンプトのトレース、ログ、メモリに記録される危険がある。

そこでこのパターンでは、**id_tokenをツール引数ではなく、HTTPトランスポートのカスタムヘッダー**で運ぶ。

X-Amzn-Bedrock-AgentCore-Runtime-Custom-IdToken: <id_token>

FMはこのヘッダーを見ない。ツールスキーマにid_tokenパラメーターは存在しない。トークンはHTTP接続層を並走し、Lambdaだけが読み取る。

3つのBedrock AgentCore設定

Amazon Bedrock AgentCoreは2025年にAWSがプレビュー提供を開始したマネージドサービスで、AIエージェントの実行基盤・ゲートウェイ・メモリ管理などをフルマネージドで提供する。この伝播チェーンは、Bedrock AgentCoreの3つの設定で実現される。

1. ランタイムのリクエストヘッダー許可リスト

デフォルトではAgentCore Runtimeはリクエストヘッダーをエージェントコンテナに転送しない。明示的なオプトインが必要だ。

# .bedrock_agentcore.yaml
request_header_configuration:
  requestHeaderAllowlist:
    - Authorization
    - X-Amzn-Bedrock-AgentCore-Runtime-Custom-IdToken

エージェントコンテナ内のPythonコードはcontext.request_headersからトークンを読み取る。

2. AgentCore GatewayのメタデータでLambdaへのヘッダー転送を設定

エージェントはMCP（Model Context Protocol）経由でAgentCore Gatewayと通信する。MCPはAnthropicが策定したオープンプロトコルで、AIモデルと外部ツール・データソースとのインターフェースを標準化するものだ。GatewayからLambdaへヘッダーを伝播するにはmetadataConfiguration.allowedRequestHeadersを設定する。

metadata_configuration=agentcore.CfnGatewayTarget.MetadataConfigurationProperty(
    allowed_request_headers=["X-Amzn-Bedrock-AgentCore-Runtime-Custom-IdToken"],
)

繰り返しになるが、ツールスキーマにid_tokenパラメーターは存在しない。FMはこの設定を知らない。

3. Lambda側でのヘッダー読み取り

Lambda側では、伝播されたヘッダーはイベントボディではなくクライアントコンテキストに格納されている。

def lambda_handler(event, context):
    client_ctx = getattr(context.client_context, "custom", {}) or {}
    propagated_headers = client_ctx.get("bedrockAgentCorePropagatedHeaders", {})
    id_token = propagated_headers.get(ID_TOKEN_HEADER)

eventにはツールの宣言パラメーター（クエリ文字列やデータベース名など）のみが含まれ、id_tokenはここに現れない。

サーバーサイドのトークン交換

Lambdaがid_tokenを受け取った後の処理が肝だ。IAM Identity CenterのTrusted Identity Propagation（TIP）を使い、以下の3ステップでLake FormationがユーザーIDを認識できる認証情報を生成する。

# 1. id_tokenをOIDC IdPのJWKSで検証
claims = validate_id_token(id_token)

# 2. IAM Identity CenterでidentityContextに交換
resp = sso_oidc.create_token_with_iam(
    clientId=OAUTH_APPLICATION_ARN,
    grantType="urn:ietf:params:oauth:grant-type:jwt-bearer",
    assertion=id_token,
)
identity_context = resp["awsAdditionalDetails"]["identityContext"]

# 3. ProvidedContextsでAssumeRole
assumed = sts.assume_role(
    RoleArn=TIP_ROLE_ARN,
    RoleSessionName=f"agent-tip-{user_sub[:8]}-{int(time.time())}",
    ProvidedContexts=[{
        "ProviderArn": "arn:aws:iam::aws:contextProvider/IdentityCenter",
        "ContextAssertion": identity_context,
    }],
)

identityContextは単一のLambda実行内で生成・消費される。エージェント、ゲートウェイ、UIには返らない。この結果得られるboto3.Sessionの短期クレデンシャルでAthenaクエリを実行すると、Lake FormationはユーザーIDでアクセス評価を行う。

Lake Formation側で必要な設定はシンプルで、IAM Identity Centerのユーザーまたはグループへの通常のグラント1つだけ。既存ポリシーの変更は不要だ。

前提条件

このパターンを実装するには以下が必要だ。

IAM Identity Centerのインスタンス（Trusted Token Issuer設定済み）
CreateTokenWithIAM（JWTベアラーグラント）を使うOAuthアプリケーション
Lake Formationで管理されたGlue Data Catalog（ユーザー/グループへのグラント設定済み）
Athenaワークグループ（Amazon AthenaクエリはAthenaワークグループ単位で実行される）とS3バケット
OIDCプロバイダー（Amazon Cognito、Auth0、Okta、Microsoft Entra IDなど何でも可）

記事ではCognitoをデモ用に使っているが、パターン自体はIdP非依存で、任意のOIDC準拠プロバイダーで動作すると明記されている。また、エージェントフレームワークとしてStrands、LangGraphなどを使っている場合でも、このパターンはBedrock AgentCore上でデプロイ可能だ。

詳細はIdentity-aware AI data agents with AWS Lake Formation and Trusted Identity Propagationを参照していただきたい。