AWS Wants AI Agents to Carry the User’s Permissions, Not Their Own

An AI agent that is tricked by a malicious prompt should still hit a hard stop before it can expose another department’s data. AWS’s design for Amazon Bedrock AgentCore aims to create that stop by carrying the requester’s identity and permissions through the agent to the systems that hold the data.

The key move is architectural rather than a new instruction for the model: the agent is meant to coordinate a request, while downstream services make the authorization decision. AWS says this preserves access boundaries when an agent is manipulated through prompt injection or affected by an application bug, rather than trusting the agent to correctly filter a broad pool of sensitive material.

The request is checked before the agent runs

In AWS’s example, an employee first authenticates with corporate credentials. Amazon Cognito supplies the identity layer in the demonstration, though Microsoft Entra ID and Okta can also be used. Department information is added to the authentication token, and AgentCore Runtime can validate that token and its authorization context before the request reaches the agent.

That ordering matters in a shared CRM scenario. AWS separates Sales access to contracts, pricing strategies and pipeline information from Finance access to invoices, payment records and financial reports. A Sales employee’s request can therefore be rejected at entry if it fails configured requirements, or constrained later when the agent seeks information from a connected system.

Each data system supplies a different lock

The architecture spans Amazon DynamoDB, Amazon Bedrock Knowledge Bases and Salesforce. It does not present one universal policy engine. Instead, identity propagation reaches systems with different authorization mechanisms, so the protection depends on the relevant control being applied at each destination.

• For DynamoDB, the described route exchanges a user token for scoped credentials through AssumeRoleWithWebIdentity; IAM LeadingKeys conditions then enforce access.
• For Salesforce, it uses an RFC 8693 on-behalf-of token exchange and leaves authorization to Salesforce’s native sharing rules.
• For Bedrock Knowledge Bases, the pattern adds department metadata filters to retrieval requests.

Document retrieval has a stricter-isolation caveat

Knowledge-base filtering is an application-layer control, not the stronger isolation boundary AWS recommends for every case. Metadata filtering can limit retrieved documents by department, but AWS advises separate knowledge bases with IAM policies where tighter separation is required. That distinction makes the design less of a blanket guarantee than a set of controls that must match the sensitivity of the data.

The agent loses the power to overrule the user

The security claim rests on reducing the agent’s independent authority. The described pattern keeps the agent execution role from holding direct data-store permissions, while the user’s identity is propagated to the service that owns the records. A prompt can still influence what an agent asks for, but AWS’s intended boundary means the database, document system or SaaS application should deny requests that exceed the user’s permissions.