Skip to content

Back to the catalog

Identity-aware AI data agents with AWS Lake Formation and Trusted Identity Propagation
aws.amazon.comarticle

Identity-aware AI data agents with AWS Lake Formation and Trusted Identity Propagation

AWS Security Blog walkthrough of an identity-aware AI data agent pattern that propagates a real user's OIDC id_token through Amazon Bedrock AgentCore Runtime and Gateway into a Lambda target, which exchanges it server-side (via IAM Identity Center trusted identity propagation) for Lake Formation-scoped Athena credentials. The design deliberately keeps the id_token off the tool schema and inside HTTP headers only, so the foundation model never sees or handles the user's credential, and CloudTrail records the real human via an onBehalfOf AssumeRole entry, letting existing Lake Formation grants govern AI agent queries without rewriting authorization logic in application code. It details the three AgentCore configuration gates (runtime header allowlist, gateway metadataConfiguration.allowedRequestHeaders, Lambda's bedrockAgentCorePropagatedHeaders) that enforce this separation.

TL;DR AWS shows how to propagate a user's OIDC identity through a Bedrock AgentCore agent into Lake Formation via trusted identity propagation, so the FM never touches the user's token while Athena/Lake Formation enforce per-user grants and CloudTrail logs the real human.
Open original ↗
Also seen from another angle🧠 AI →
Document

What it is

A deployable reference pattern from AWS for identity-aware AI data agents on Amazon Bedrock AgentCore, using Amazon Cognito as the demo OIDC IdP, IAM Identity Center trusted identity propagation (TIP), AWS Lake Formation, Athena, and Lambda.

How it works

Two tokens travel the request path: an access_token authenticates at each trust boundary (Runtime, Gateway) via standard JWT auth; an id_token carries user identity in the custom header X-Amzn-Bedrock-AgentCore-Runtime-Custom-IdToken and is never placed in the HTTP body, a tool argument, or a prompt. Lambda validates the id_token, exchanges it via sso-oidc:CreateTokenWithIAM for an identityContext, then calls sts:AssumeRole with ProvidedContexts to obtain a boto3 session scoped to the real user's identity — all within a single Lambda invocation; the identity context is never returned upstream. The separate TIP role Lambda assumes carries no Lake Formation grants, only service-call permissions (athena:*, glue:*, lakeformation:GetDataAccess, S3 access to the output bucket) — Lake Formation evaluates the propagated user identity, not the role.

flowchart LR
  A[UI: access_token + id_token] --> B[AgentCore Runtime\nheader allowlist]
  B --> C[Agent code\nreads context.request_headers]
  C --> D[AgentCore Gateway\nmetadataConfiguration.allowedRequestHeaders]
  D --> E[Lambda\ncontext.client_context.custom.bedrockAgentCorePropagatedHeaders]
  E --> F[sso-oidc:CreateTokenWithIAM\n+ sts:AssumeRole ProvidedContexts]
  F --> G[Lake Formation evaluates real user]

Preconditions / Affected

Requires: an IAM Identity Center instance with a trusted token issuer (TTI) accepting the OIDC IdP's tokens; an Identity Center OAuth Application configured for CreateTokenWithIAM with JWT Bearer grant; Lake Formation grants already assigned to users/groups; an Athena workgroup and S3 results bucket. The pattern is IdP-agnostic (Cognito, Auth0, Entra ID, Okta, Ping all work if the TTI accepts their tokens).

What to do

Four configuration points, each a named gate:

  1. Runtime: set requestHeaderAllowlist to cover Authorization and the custom id_token header (via agentcore configure or runtime config directly) — without this, the token never reaches agent code.
  2. Gateway: set the Lambda target's metadataConfiguration.allowedRequestHeaders to include the id_token header, and keep the tool schema free of any id_token parameter — this is what keeps the token out of the FM's context.
  3. Lambda: read the token from context.client_context.custom['bedrockAgentCorePropagatedHeaders'], not from the event body.
  4. Lake Formation: add a single grant (with optional column/row filters) to the IAM Identity Center user or group — no AI-specific changes needed to existing governance.

Validation evidence: CloudTrail's AssumeRole event carries an onBehalfOf entry naming the actual human, giving per-query audit trail with no extra instrumentation.

Caveats

The post is a single-vendor walkthrough (AWS blog) built on a specific demo stack (Cognito); it states the pattern is IdP-agnostic but only demonstrates Cognito. No performance, latency, or cost figures are given for the token-exchange hop.

Technologies named here

Techniques named here

  • Trusted Identity Propagation
  • OAuth 2.0 token delegation / JWT Bearer grant
  • Header-based out-of-band token transport
  • Server-side token exchange scoped to a single invocation
  • Least-privilege session role

Related in AI Security