AWS: identity-aware AI data agents with Lake Formation

AWS has published a reference architecture for AI data agents that query a governed data lake as the person asking the question, not as the agent. The user's identity reaches AWS Lake Formation, so existing data grants decide what the agent can return.

What happened

In an AWS Security Blog post dated October 6, 2026, the authors frame the problem: when an agent runs under its own IAM role, Lake Formation sees the agent's credentials, not the user's. Teams either restrict the agent until it isn't useful, or rebuild access control in application code, outside the data layer.

The proposed pattern uses Trusted Identity Propagation through AWS IAM Identity Center:

• Identity provider: any OIDC provider (the post lists Amazon Cognito, Okta, Auth0, Microsoft Entra ID and Ping) is registered as a trusted token issuer in IAM Identity Center, with an OAuth application set up for CreateTokenWithIAM using the JWT bearer grant.
• Header-only transport: the UI sends the access_token in the Authorization header and the id_token in a custom AgentCore header. Amazon Bedrock AgentCore Runtime is configured with a requestHeaderAllowlist for both, and AgentCore Gateway forwards the id_token header to a Lambda target via metadataConfiguration.allowedRequestHeaders. The tool schema has no token parameter.
• Exchange in Lambda: the Lambda function validates the id_token (signature, expiry, audience, issuer, token type), calls CreateTokenWithIAM, then calls sts:AssumeRole on a "TIP role" with the returned identity context. The resulting short-lived credentials carry the user's identity.
• Authorization stays in Lake Formation: the TIP role has zero Lake Formation data grants. Athena runs the query under the propagated session, and Lake Formation evaluates the user's existing grants.
• Audit: CloudTrail AssumeRole events include an onBehalfOf block naming the Identity Center user.

In the authors' test, a user with a SELECT grant got results and a user without one got access denied, with no code changes. The key design claim:

The id_token never reaches the foundation model: It travels on HTTP headers at every hop, and Lambda reads it from context.client_context.custom. — AWS Security Blog

Why it matters

This is on-behalf-of access applied to agents, and it targets the over-privileged agent service account. In our view, if the agent's role can read everything any user might need, every prompt injection runs with that superset. Here authorization stays with the data platform that already holds the governance policy. It speaks directly to the standing-access problem we covered in the Delinea report.

Keeping the token out of the model context is the second point worth copying. Tokens passed as tool arguments can end up in prompts, memory and traces; in headers, the model never holds a credential to leak.

The design also concentrates trust. In our analysis, the Lambda function becomes the security boundary: its token validation and its ability to assume the TIP role decide whether impersonation is possible. The TIP role in the post also holds broad service permissions (athena:*, glue:*, lakeformation:GetDataAccess and S3 access to the results bucket). Lake Formation limits the data, but our view is that those IAM permissions deserve review before you adopt the pattern as written.

What to check in your environment

• Inventory data agents and their roles. List AI agents that query Athena, Glue or Lake Formation-governed data, and note whether each runs as its own role or as the user.
• Look for application-side filtering. Flag any agent that enforces row or column restrictions in its own code; that governance sits outside Lake Formation and your access reviews.
• Confirm prerequisites. Check that IAM Identity Center has (or can have) your OIDC provider as a trusted token issuer, and that Lake Formation grants are assigned to users and groups, since propagation only helps if grants exist at that level.
• Check tool schemas for tokens. Review agent and MCP tool definitions for any parameter that carries a token or credential. Move those to headers or a server-side exchange.
• Scope the exchange path. If you build this, restrict who can invoke the exchange Lambda and who can assume the TIP role, and trim the role's athena:* and glue:* permissions to what your queries need.
• Verify audit attribution. After a test query, confirm that CloudTrail AssumeRole events show the onBehalfOf user, and that your SIEM parses that field so data access can be tied to a person.

References

• AWS Security Blog: Identity-aware AI data agents with AWS Lake Formation and trusted identity propagation