Enterprises are racing to deploy AI agents that pull from databases, document repositories, and SaaS platforms to automate workflows. But a quiet risk lurks beneath the convenience: a compromised agent manipulated via prompt injection could hand over data the requesting user was never authorized to see. We will show you how to close this gap by moving authorization out of the agent’s code and into the AWS infrastructure itself.
This architectural shift ensures that even a fully hijacked agent remains cryptographically constrained to the user’s specific permissions. Just as we discussed the catastrophic consequences of unauthorized data manipulation in our recent breakdown of the Critical GitLab GraphQL Flaw, relying on application-level filtering for AI access is a severe structural weakness.
Why is Agent-Level Filtering a Structural Security Flaw? #
Relying on an AI agent’s internal logic or prompt instructions to filter database results is a critical vulnerability. If an attacker bypasses the agent’s logic using prompt injection, the agent’s full underlying dataset is exposed. True security requires enforcing authorization at the infrastructure layer, independently of the LLM’s reasoning.
The traditional fix has been to give an AI agent broad administrative credentials and trust the agent to filter results before returning them to the user. AWS identifies this as a fundamentally flawed design. The AGENTSEC03 best practice in the AWS Well-Architected Agentic AI Lens dictates that the agent should purely act as an orchestrator, while access decisions are strictly enforced by the downstream services.
How Does Amazon Bedrock AgentCore Validate User Identity? #
Amazon Bedrock AgentCore validates user identity by intercepting JSON Web Tokens (JWTs) enriched with custom department claims and AWS session tags via Amazon Cognito. The AgentCore Runtime verifies this token on arrival, blocking unauthorized invocation requests before the AI agent’s code even begins to execute**.**
When a user logs in, a pre-token generation Lambda trigger directly injects identity metadata into the token. From there, AWS demonstrates distinct infrastructure-enforced identity propagation patterns for downstream services, ensuring that the agent’s execution role holds no direct data-store permissions of its own.
How Do We Secure DynamoDB, Knowledge Bases, and SaaS Integrations? #
For DynamoDB, the agent exchanges the user token for scoped credentials using AssumeRoleWithWebIdentity, enabling IAM LeadingKeys conditions. For Knowledge Bases, it appends department metadata filters to retrieval calls. For Salesforce, it utilizes RFC 8693 On-Behalf-Of token exchange to swap the user identity securely**.**
| Downstream AI Service | Identity Propagation Mechanism | Authorization Enforcement Layer |
|---|---|---|
| Amazon DynamoDB | AssumeRoleWithWebIdentity (STS) | IAM Policy (LeadingKeys Condition) |
| Bedrock Knowledge Bases | Metadata Attribute Appending | Application-Layer Retrieval Filter |
| Salesforce (External SaaS) | RFC 8693 On-Behalf-Of Exchange | SaaS Native Sharing Rules |
As detailed in the official AWS Security Blog, enforcing authorization at the infrastructure layer ensures data boundaries remain intact regardless of agent-level manipulation. Each request carries short-lived, cryptographically derived credentials that expire rapidly and cannot be forged by malicious prompts.
Frequently Asked Questions #
Can a prompt injection attack bypass AWS infrastructure authorization?
No. Because the access controls are enforced by IAM conditions and downstream SaaS rules based on cryptographically signed user tokens, manipulating the LLM prompt cannot escalate privileges beyond the user’s explicit permissions. Does Amazon Bedrock AgentCore support third-party Identity Providers (IdPs)?
Yes, while the AWS architecture often highlights Amazon Cognito, the token exchange mechanisms and runtime validations can be integrated with standard OIDC-compliant third-party identity providers. What is RFC 8693 On-Behalf-Of (OBO) token exchange?
RFC 8693 is an OAuth 2.0 extension that allows an intermediary (like an AI agent) to exchange an incoming user token for a new token tailored to a downstream service (like Salesforce), without exposing raw credentials.