Previously, AI‑driven data agents executed under a single IAM role, so AWS Lake Formation evaluated the tool’s credentials rather than the individual who asked the question. The new pattern introduces trusted identity propagation, letting each user’s identity travel through the agent, a Lambda token‑exchange, and finally to Lake Formation, so existing governance policies and CloudTrail audit logs apply per‑user without code changes.
Why Trusted Identity Propagation Matters
For AI engineers and platform teams, the change removes the need to duplicate Lake Formation policies in application logic. Cloud and security operators gain full auditability because CloudTrail records the actual requester, not a generic service account. DevOps and SRE staff can keep the agent’s runtime permissions static while still enforcing fine‑grained data access.
Core Architecture
The flow consists of three distinct tokens. An access_token authenticates each hop – the Bedrock AgentCore runtime, the AgentCore gateway, and the downstream tool. A second token, issued by AWS IAM Identity Center, carries the user’s identity. A Lambda function performs a server‑side token exchange, converting the identity token into temporary Lake Formation credentials scoped to the real user. Lake Formation then evaluates its existing grants, and CloudTrail logs the query with the user’s identity.
Implementation Steps
- Configure Amazon Bedrock AgentCore to forward the user’s identity token through its trusted identity propagation (TIP) settings, ensuring the token is passed on the HTTP transport layer and never exposed to the foundation model’s reasoning layer.
- Deploy an AWS Lambda function that receives the forwarded token, validates it against IAM Identity Center, and calls the Lake Formation STS endpoint to obtain user‑scoped credentials.
- Update the data‑agent code to invoke the Lambda exchange before constructing the Lake Formation query, then execute the query using the returned credentials.
- Validate the end‑to‑end flow by testing with multiple IAM Identity Center users, confirming that query results respect each user’s Lake Formation grants and that CloudTrail entries show the correct principal.
Operational and Security Considerations
Because the agent no longer needs broad data permissions, its IAM role can be locked down to only invoke the Lambda function. Token handling in Lambda must follow best practices for secret management and validation to avoid token replay. Monitoring should include Lambda error rates, token exchange latency, and CloudTrail audit trails for unexpected principals. Scaling the Lambda function may be required as query volume grows, but the pattern does not introduce additional stateful components.
Related CloudNinjas coverage: AWS.
What This Means For Practitioners
Adopting trusted identity propagation lets you enforce existing Lake Formation policies on AI‑driven queries without rewriting access controls, provides per‑user audit logs, and isolates the agent’s runtime permissions. Evaluate token lifetimes, Lambda scaling, and continuous monitoring to ensure the pattern remains secure and performant as usage expands.