- AWS Security describes a pattern where an AI data agent queries lakehouse data as the real user, so existing Lake Formation grants apply unchanged.
- The user's identity token travels on HTTP headers, outside the model's prompts and tool arguments. CloudTrail then records the human behind each query.
- Leaders should ask whether their agents query under a shared role, and whether the model can see user credentials.
An AI agent should work like a courier, not a decision-maker. It carries the request to the right place, but it should not hold the keys or rule on who gets in. A new AWS Security post shows what that looks like for data agents.
The problem: the data layer sees the agent, not the person
Picture a team building a data agent that lets business users ask questions of lakehouse data in plain language. The agent turns each question into a query. AWS Security points to a common flaw. The query tool uses its own IAM role. So when AWS Lake Formation checks access, it sees the tool, not the human who asked.
That leaves two weak options, according to the post. Restrict the tool and limit self-service analytics. Or rebuild access rules in application code and move governance out of the data layer.
Both options cost something. The first slows the business. The second creates a second rulebook that has to match the first.
How the pattern works
AWS proposes carrying each user's identity through every step, so Lake Formation judges the user's own grants. The user signs in with an OpenID Connect identity provider. The post uses Amazon Cognito, and says Okta or any similar provider also works.
Two tokens then travel. An access token proves the request is allowed at each boundary. An identity token (id_token) says who the person is. The identity token rides in a custom HTTP header, and the request body holds only the user's prompt.
The post names three Amazon Bedrock AgentCore settings that pass the token along. The runtime needs an allow list for headers, because it does not forward them by default. The gateway needs a setting, metadataConfiguration.allowedRequestHeaders, to pass the header to its Lambda target. Lambda then reads it from the client context, not from the tool's inputs.
The key design choice is what the tool schema leaves out. No tool has a token parameter. AWS says that if the token were a tool argument, the model would be responsible for passing it. The token could then land in prompts, traces, memory and logs.
Inside Lambda, the token is validated and swapped for an identity context. Lambda then takes on a role carrying that context, and Athena runs the query with the user's identity attached. The post says the context is created and used within a single invocation and is not returned to the agent, gateway or UI.
Why the role holds no grants
The role Lambda takes on is a plain service account for calling APIs. Its permissions cover Athena, the Glue catalog, a Lake Formation data-access call and the S3 output bucket. It carries no data grants. Lake Formation weighs only the propagated user. AWS calls the role a session vehicle, not an authorization subject.
That is the reverse of the common setup, where the role carries the grants. In that setup, per-user governance breaks, because every user shares the agent's access.
AWS shows two users asking the same question. User A has SELECT on a table called trip_details and gets five records. User B has no grant and is refused. The post says no code changed between the two requests.
What it means for an organisation
The main gain is that governance stays in one place. Teams that already grant data access to people can reuse those grants as they are, the post says. Column-level and row-level filters attach to the same users and groups.
The audit trail improves too. The CloudTrail AssumeRole record carries an onBehalfOf entry naming the human. After an incident, that is the difference between knowing a service role ran a query and knowing which person it served.
Limits to keep in view
This is AWS describing its own reference design. The post gives no independent test results.
The three settings are specific to Amazon Bedrock AgentCore. The post says everything after Lambda is standard IAM Identity Center and Lake Formation. It also assumes you already run IAM Identity Center with a trusted token issuer, plus Lake Formation grants for users or groups.
The agent code still reads the token from the request headers and forwards it. The protection is that the model has no path to it. It is not that the token is absent from the agent's process.
Questions to put to your team
Does any AI agent that reads company data run under a shared service role? If so, who can see what that role can see?
Can the model see user credentials in prompts, tool arguments, traces or logs? Ask for the answer to be checked, not assumed.
Do query logs name the person or only the agent's role? Could you answer an auditor's question about one user's access?
The lesson is to treat the agent as a carrier of identity, never its owner. The user's identity should reach the data layer intact, and the model should not need to know it exists.
Produced by the WebPulse Newsroom with AI assistance from the original reporting credited below, and checked against that source by our editorial review. How we use AI.
Original reporting: AWS Security.
