The post describes an internal assistant in which every employee shares one agent and knowledge base, yet each person sees only documents they are allowed to view. The knowledge base is exposed as MCP tools through Amazon Bedrock AgentCore Gateway, and trusted code rather than the model determines the user identity. Without this design, a search argument such as userContext could be set by the model through an error or a prompt injection.
A request interceptor, a Lambda function on the gateway, overwrites the userContext argument of each tools/call request with the email from the validated access token. Amazon Cognito adds that email claim through a pre token generation trigger, which requires the Essentials or Plus feature plan. Policy in AgentCore then compares the injected value with the email claim and denies any request where they differ.
The knowledge base uses ACL awareness to return only documents that the named user may view, and its resource-based policy denies Retrieve and GetDocumentContent to principals other than the gateway execution role. The post notes that ACL awareness filters results but does not authorize access by itself. Documents that fail ACL matching are silently left out of results rather than returning an error.
Why it matters if you build agents
Developers who expose a knowledge base as an MCP tool should not let the model set a user identifier, because neither the gateway nor the knowledge base verifies that value. Injecting the verified email in code, checking it with a second policy and restricting direct calls with a resource policy gives independent layers if one control fails. Teams should also remember that ACL changes take effect only after the next sync and that missing ACL entries cause silent omissions.
Get stories like this every weekday
One short email with the day's agent tooling news.