Your AI agent should not be the gatekeeper

Most AI agents we see in the wild have one service account with the union of every permission any user might need, and a system prompt that says "only show the user their own data." That is not access control. That is a suggestion. On August 19, AWS published a detailed architecture for doing it properly, and the useful part is that the pattern has nothing to do with AWS.

What actually happened

Anshu Bathla, Prafful Gupta, and Rohit Verma at AWS walked through propagating user authorization context end to end in an agent built on Amazon Bedrock AgentCore. Their framing is the whole argument: "The agent acts as an orchestrator, not a gatekeeper; it coordinates tool calls and reasoning but doesn't control access to data."

The chain, concretely. A Cognito user pool issues the user's JWT, with a pre-token-generation Lambda adding a department claim. AgentCore Runtime's inbound JWT authorizer validates signature, expiry, issuer, and the custom claim — using a CONTAINS_ANY operator against allowed values — and rejects the request before the agent runs. A requestHeaderAllowlist config forwards the ID token into the agent's code. From there, AgentCore Identity performs an RFC 8693 on-behalf-of token exchange (GetResourceOauth2Token, or the @requires_access_token decorator with an ON_BEHALF_OF_TOKEN_EXCHANGE flow) to mint a service-scoped, user-bound token for each downstream call.

Then the downstream services do the actual enforcing. DynamoDB via AssumeRoleWithWebIdentity with session tags and a dynamodb:LeadingKeys IAM condition. Bedrock Knowledge Bases via metadata filtering in retrievalConfiguration. Salesforce via OAuth token exchange, so Salesforce's own sharing rules apply to the agent exactly as they would to the person. Help Net Security's coverage puts the consequence bluntly: configure the services to reject unauthorized requests regardless of what the agent asks for.

Why agent authorization matters for your business

Here is the failure mode this prevents, and it is not hypothetical. You build an internal agent over your CRM and your invoices. It runs as one identity with read access to everything. A salesperson asks it a leading question — or a customer pastes text into a support ticket that the agent later reads — and the agent cheerfully retrieves payroll data, because the only thing standing between the question and the answer was a paragraph of English in a system prompt.

Prompt injection beats prompt-based access control every time. That is not a model quality problem you can fix with a better model or a stricter instruction. The agent is an untrusted component that happens to run inside your network.

The architecture that fixes it is three rules, and you can apply them on AWS, on Azure, or on a Postgres database behind a Node service:

The agent never holds a shared credential. Every downstream call carries a token derived from the human who made the request. If the agent has no key of its own, there is nothing for an injected prompt to abuse.

Rejection happens before inference. Claim validation at the runtime boundary is cheaper and more reliable than any check the model performs on itself, and it produces an auditable deny.

The data layer enforces, not the prompt. Row-level security, tenant IDs in the IAM condition, metadata filters on your vector store. Ask yourself: if the agent asked for every row in the table, what would come back? If the answer is "every row," your access control lives in the prompt.

That third question is the whole test. Run it against whatever agent you shipped last quarter.

Sources: AWS Security Blog, Help Net Security.