AWS's answer to prompt-injected agents: orchestrate, never gatekeep

AWS has published an approach for propagating a user's authorization context through an AI agent so that access controls are enforced by infrastructure and downstream services rather than by the agent itself ^[1]. That matters because the usual industry response to prompt injection is a behavioral one - more guardrails, better system prompts - and this is an architectural one that teams can copy without waiting for a model to get more obedient.

The framing AWS uses is blunt: "The agent acts as an orchestrator, not a gatekeeper," the company said, adding that "authorization is enforced by downstream services" ^[2]. The problem it addresses is mundane rather than exotic. Customers using Amazon Bedrock AgentCore can build agents that pull from Amazon DynamoDB tables, document repositories, SaaS platforms and internal knowledge bases ^[3], and an agent with no awareness of who is asking can return information that the requester is not authorized to see ^[4].

The worked example is a CRM where Sales and Finance staff talk to the same agent ^[5]. Sales needs contracts, pricing strategies and pipeline data; Finance needs invoices, payment records and financial reports ^[6]. The agent can reach DynamoDB, Amazon Bedrock Knowledge Bases and Salesforce ^[7]. AWS's argument is that putting the restriction outside the agent holds even if the agent is manipulated through prompt injection or broken by an application bug ^[8].

The mechanics are ordinary identity plumbing, which is the point. Employees authenticate with corporate credentials - Amazon Cognito in AWS's example, though Microsoft Entra ID and Okta also work ^[9] - and attributes such as department are embedded in the authentication tokens and carried with the request ^[10]. Amazon Bedrock AgentCore Runtime validates the token and checks authorization before the request reaches the agent, so requests that fail the configured requirements can be rejected before the agent runs at all ^[11]. That context is then passed along when the agent calls other services, which decide for themselves what the user may see ^[12].

Enforcement then varies by data plane, and the differences are worth reading closely. DynamoDB access can be scoped to records tied to the user's department ^[13], and Salesforce applies its own sharing rules so the agent only receives records available to that individual ^[14]. Bedrock Knowledge Bases uses metadata filtering, which AWS itself notes operates at the application layer, with separate knowledge bases and IAM policies recommended where stricter isolation is needed ^[15]. So two of the three demonstrated integrations enforce inside the target system's own policy engine, and one does not ^[16]. The unstructured-document path is the weakest link in the design AWS shipped, and AWS says so.

The stated goal is to stop granting an agent broad access and trusting it to filter, and instead configure the underlying services to reject unauthorized requests "regardless of what the agent asks for" ^[17]. Authors Anshu Bathla, Prafful Gupta and Rohit Verma conclude that the agent's credentials are then inherently limited to the requesting user's permissions, and that "no amount of prompt manipulation can bypass those boundaries" ^[18].

Read that claim for what it is: a bound on reach, not a cure for injection. What to watch is whether teams adopting the pattern do the unglamorous half - per-department knowledge bases with IAM policies rather than metadata filters ^[15], and token claims that actually reflect current entitlements ^[10] - or whether they ship the token-passing and call it done.