AWS shows how to stop an AI agent searching as the wrong user

Amazon Web Services has published a reference pattern for keeping a shared AI agent from showing one user another user’s documents. The key step: a gateway Lambda overwrites the userContext value the model would otherwise choose.

The model should not choose who it searches as

The problem, as AWS describes it, starts when Amazon Bedrock Managed Knowledge Base is exposed as Model Context Protocol (MCP) tools through Amazon Bedrock AgentCore Gateway. Managed Knowledge Base has an ACL awareness feature: if a search carries a userContext with a userId email, only documents that user may view come back. Through the gateway, however, userContext becomes a tool argument that the LLM fills in. AWS says neither the gateway nor the knowledge base checks that the value belongs to the signed-in user, so a prompt injection or a model error could search as someone else.

The sample is built around one rule: trusted code, not the model, decides identity. It has four layers:

• Request interceptor: a Lambda function on the gateway reads the email from the validated Amazon Cognito access token and overwrites userContext on every tools/call request. It rejects batches and malformed bodies.
• ACL awareness: the knowledge base returns only chunks the named user is allowed to view.
• Policy in AgentCore: a Cedar policy denies the call if userContext.userId differs from the token’s email claim.
• Resource-based policy: the knowledge base denies Retrieve and GetDocumentContent to every principal except the gateway execution role.

AWS calls the first two primary defenses and the last two secondary. The second pair covers an interceptor bug, a detached interceptor, or another gateway or direct SDK call that skips the gateway.

Setup details and limits AWS flags

The sample ships as one CDK stack inside the agentcore-access-control folder of AWS’s sample-managed-knowledge-base-patterns GitHub repo. It needs Node.js 22 or later, uv, and aws-cdk-lib 2.274.0 or later. The agent is built with Strands Agents and runs on AgentCore runtime; by default it uses Claude Sonnet 5.5 through a global cross-Region profile. The post does not list supported Regions or prices beyond saying the services must be available in the chosen Region.

Several constraints matter. Adding an email claim to Cognito access tokens needs a pre token generation trigger and the Essentials or Plus plan; on a Lite plan the interceptor and the policy deny every call. For S3 data sources, documents without an ACL entry are not ingested, ACL changes apply only after the next sync, and ACL mistakes do not raise errors: affected documents are silently left out. Matching is by exact email, so the identity provider must keep addresses unique and unchanged. AWS also warns that Microsoft advises against using the Entra ID email claim for authorization.

The post states that ACL awareness “isn’t an authorization mechanism by itself”. It also says the resource-based policy cannot stop another gateway that reuses the same execution role, so that role should not be shared.

What changes for teams building shared agents

For developers, the practical shift is that access control moves out of the agent. The agent only forwards the user’s token and contains no access logic, according to AWS. Anyone running one assistant for many departments or customers can reuse the pattern, and the post says it extends to any MCP tool whose arguments affect authorization.

The pattern also fits the surrounding AgentCore design. AWS’s separate retrieval post shows that maxAgentIteration accepts values from 0 to 5, where 0 is a single retrieval equivalent to the Retrieve API and 2 to 5 is agentic mode. Both modes carry the same userContext argument, so the interceptor and policies have to cover each tool name; the sample creates one Cedar policy per action. Per-user scoping also contrasts with AgentCore’s new web search API, which calls are signed with IAM and priced at $7 per 1,000 queries, with no per-end-user filtering described in that coverage: identity there is the AWS caller, not the employee.

The same identity theme appears in Codex on Amazon Bedrock with AWS logins, where AWS identity replaces vendor keys.

What the test results do and do not show

AWS’s verification script signs in as two demo users and reports that each gets only documents in their ACL. A spoofed userContext is overridden, a gateway without the policy engine is denied, and even an administrator calling Retrieve directly hits an explicit deny. The agent-spoofing scenario depends on the model and is reported as inconclusive if the agent does not attempt it within three turns. These are AWS’s own results on a three-document sample; no independent testing, latency figures or cost comparison are given. Teams should expect to validate the pattern against their own identity provider and data before relying on it.