AWS moves agent authorization out of the agent and into the plumbing

Amazon Web Services has published a reference pattern for propagating user authorization context through AI agents built on Amazon Bedrock AgentCore, with the stated goal that access control is enforced by infrastructure and downstream services rather than by agent code ^[1]. The premise is unglamorous and correct: an agent that has no awareness of who is asking can return data the user should not see ^[2].

The worked example is a CRM chat application where Sales and Finance employees use the same interface and the same agent but need isolated data ^[3]. Sales gets contracts, pricing strategies and pipeline data; Finance gets invoices, payment records and financial reports ^[4]. The agent reaches three places: customer records in DynamoDB partitioned by department, department-specific documents in Bedrock Knowledge Bases backed by S3, and external CRM data in Salesforce ^[5]. AWS is explicit about the threat model. Enforcement has to sit outside the agent so that a prompt injection or an application bug cannot reach unauthorized data ^[6].

The mechanics are where the claim gets tested. A user authenticates against an Amazon Cognito user pool acting as the identity provider ^[7], and a pre token generation Lambda trigger (V2) enriches the JWT with a custom claim and AWS session tag metadata ^[8]. AgentCore Runtime validates the inbound JWT and, via AgentCore Identity, issues a workload access token binding user and agent identity before invoking the agent ^[9]. From there each data source is handled differently: Knowledge Bases are queried using the agent's own IAM role with metadata filtering, DynamoDB with user-scoped session-tagged credentials ^[10], and Salesforce through an on-behalf-of token exchange (RFC 8693) using credentials pulled from AWS Secrets Manager, after which Salesforce applies its own sharing rules ^[11][12]. Three sources, three distinct enforcement mechanisms ^[13].

That asymmetry matters. The DynamoDB and Salesforce paths carry a user-bound credential, so a compromised agent is constrained by the token it holds. The Knowledge Bases path uses the agent's role plus a metadata filter, which means the boundary is a query parameter rather than a credential ^[14]. It is still outside the agent's reasoning loop, but it is a weaker form of the same idea, and worth understanding before you copy the diagram.

Two principles carry the design: the agent orchestrates tool calls but does not control access to data, and the agent stores no credentials to data stores, receiving temporary user-bound tokens per request instead ^[15][16]. AWS maps the approach to AGENTSEC03 in its Well-Architected Agentic AI Lens ^[17]. The department scoping is illustrative; AWS says the pattern generalizes to any custom claim, including role, business unit, region or project ^[18]. Cognito is the example IdP, with Entra ID and Okta named as alternatives ^[19].

Worth watching: whether the pre token generation trigger becomes the de facto policy surface for these deployments, since a custom claim minted at login is now the thing every downstream filter trusts ^[8]. Also watch how far the RFC 8693 exchange travels beyond Salesforce, which has mature sharing rules to fall back on ^[11][12]. AWS says per-source deep dives follow in the same post ^[20]; the DynamoDB session tag details are where this pattern will either hold up or get fiddly.