AWS Guide: Prevent AI Agents From Accessing Unauthorized Data

Key Takeaways

• Enterprises deploying AI agents risk unauthorized data exposure if agents lack user-specific authorization context.
• AWS has introduced a new architecture using Amazon Bedrock AgentCore to enforce authorization at the infrastructure level, rather than relying on agent-side logic.
• This approach prevents compromised or manipulated agents from accessing data beyond a user’s authorized scope, mitigating prompt injection and agent hijacking risks.
• The solution leverages identity propagation and short-lived, user-bound credentials across services like Amazon DynamoDB, Bedrock Knowledge Bases, and Salesforce.

AWS Fortifies AI Agent Security Against Unauthorized Data Access

As enterprises increasingly integrate AI agents to automate workflows, drawing information from diverse sources such as databases, SaaS platforms, and internal knowledge bases, a critical security vulnerability has emerged. Most autonomous agents currently lack a built-in mechanism to verify the identity and authorization of the end-user initiating a query. This deficiency creates a significant risk: a compromised or maliciously manipulated agent could inadvertently disclose sensitive data to a user who lacks the necessary permissions.

In response, Amazon Web Services (AWS) has released a comprehensive architectural blueprint designed to close this security gap. The new guidance, utilizing Amazon Bedrock AgentCore, shifts the responsibility for authorization enforcement from the agent’s internal code to the underlying infrastructure, thereby enhancing data security.

Rethinking AI Agent Authorization

Traditionally, AI agents were often granted broad credentials, with the expectation that the agent’s own logic—typically through simple query conditions—would filter results based on user permissions. AWS identifies this common practice as a fundamental weakness. Should an attacker successfully manipulate the agent via prompt injection, or exploit a flaw in the agent’s filtering code, the entire dataset accessible to the agent could become exposed. As organizations accelerate the adoption of autonomous agents, robust AI security software evaluation is becoming an imperative.

AWS’s recommended solution, which aligns with the AGENTSEC03 best practice outlined in the AWS Well-Architected Agentic AI Lens, redefines the agent’s role. Under this model, the agent functions purely as an orchestrator, coordinating tool calls and reasoning processes. Actual data access decisions and their enforcement are delegated to the specific services the agent interacts with.

The demonstration architecture centers on a customer relationship management (CRM) chat application, designed for use by both Sales and Finance departments. Each department requires segregated access to customer records stored in Amazon DynamoDB, department-tagged documents within Amazon Bedrock Knowledge Bases (backed by Amazon S3), and external CRM data managed in Salesforce.

The process begins when a user authenticates via an Amazon Cognito user pool. A pre-token generation Lambda trigger dynamically injects a department claim and AWS session-tag metadata directly into the JSON Web Token (JWT) before it reaches the application. Upon arrival, the Amazon Bedrock AgentCore Runtime rigorously validates this token. Any request where the department claim does not match an authorized value is immediately rejected, effectively blocking unauthorized access attempts before any agent code is executed. From this foundational validation, AWS illustrates three distinct methods for propagating this verified user identity downstream to various data sources.

Identity Propagation Across Diverse Data Sources

For Amazon DynamoDB, the agent facilitates an exchange where the user’s signed ID token is traded for temporary, user-scoped credentials using AssumeRoleWithWebIdentity. This allows AWS Identity and Access Management (IAM) to evaluate a LeadingKeys condition, which is directly linked to the user’s department tag. Consequently, cross-departmental queries are rejected at the policy level, preventing unauthorized access before data retrieval. This method of enforcing identity constraints is consistent with established principles for securing cloud APIs in multi-tenant environments.

When interacting with Bedrock Knowledge Bases, documents are tagged with department-specific metadata during ingestion. The agent then appends a corresponding metadata filter to each retrieval call. This acts as an application-layer control, as the retrieve API currently does not expose filters as IAM conditions.

For Salesforce integration, AgentCore Identity performs an “on-behalf-of” token exchange, adhering to RFC 8693. This process swaps the user’s authenticated identity for a Salesforce-recognized token without the agent ever directly handling credentials. This mechanism ensures that Salesforce’s native sharing rules and user role policies govern what data is returned, maintaining granular control within the external CRM system.

As detailed in the AWS Security Blog, enforcing authorization at the infrastructure layer guarantees that data boundaries remain intact, irrespective of any manipulation at the agent level.

The core advantage of this approach is that even if an AI agent is fully compromised—whether through prompt injection or a coding vulnerability—it cannot access data beyond the authenticated user’s entitlements. This is because the agent’s execution role itself possesses no direct data-store permissions. Instead, each request carries short-lived, cryptographically derived, user-bound credentials that expire rapidly and are resistant to reuse or forgery. Regular API security testing is crucial to confirm the resilience of these downstream token exchanges against potential privilege escalation attempts.

AWS emphasizes that this pattern is highly generalizable. The department-scoping example can be readily adapted to implement role-based, business unit-based, regional, or project-based access controls in diverse environments. As organizations expand the deployment of agentic AI into sensitive systems handling financial, healthcare, or customer data, this architectural shift towards infrastructure-enforced authorization—rather than relying on a Large Language Model (LLM)-driven agent to self-police—represents a significant security enhancement against the escalating threat of prompt injection and agent hijacking attacks that security researchers anticipate will be a major concern by 2026.

What You Should Do

• Adopt infrastructure-level authorization for AI agents, moving away from agent-side filtering logic.
• Implement robust identity propagation mechanisms, such as those demonstrated by AWS, to ensure user authorization context is carried through to all downstream data sources.
• Utilize short-lived, cryptographically derived, user-bound credentials for agent interactions with data stores.
• Regularly conduct API security testing to validate the resilience of token exchanges and prevent privilege escalation attempts.
• Ensure all sensitive data is tagged with appropriate metadata for granular access control, particularly for knowledge bases.

Disclaimer: HackersRadar reports on cybersecurity threats and incidents for informational and awareness purposes only. We do not engage in hacking activities, data exfiltration, or the hosting or distribution of stolen or leaked information. All content is based on publicly available sources.