As enterprises increasingly rely on AI agents to draw from internal knowledge bases, document stores, and SaaS applications, a critical vulnerability is gaining attention: many agents lack awareness of the user making data requests. If attackers take control—via prompt injection or code exploits—they may forcibly expose data that the actual user never had rights to see. To address this, AWS has laid out an architecture using Amazon Bedrock AgentCore that shifts authorization out of the agent’s logic and into the surrounding infrastructure. This aims to ensure users only ever access data for which they are legitimately permitted.
From Broad Permissions to Infrastructure-Enforced Controls
The common structure today often grants agents broad credentials, depending on internal filtering code to block unauthorized data access. AWS calls this a weak point: if filtering logic is compromised through attacks, that dataset becomes exposed in full. What AWS proposes is aligning with its well-architected agentic AI lens, specifically AGENTSEC03, by treating the agent as an orchestrator. The real control happens in infrastructure and downstream services—not in the agent’s own code.
The Demo: Isolation by Department
In AWS’s demonstration, a CRM chat app shared among Sales and Finance shows how strict data isolation works. Different roles need access to different data: customer records in DynamoDB, documents in Bedrock Knowledge Bases (backed by S3), and external CRM data in Salesforce. AWS uses Amazon Cognito to authenticate users, then a Lambda trigger adds a “department” claim into a JSON Web Token. AgentCore then validates this token on every agent call—rejecting anything where the department doesn’t align. Thus, data boundaries are enforced before any agent logic runs. ([cybersecuritynews.com](https://cybersecuritynews.com/aws-ai-agent-data-access/))
For DynamoDB, AWS exchanges the user’s signed identity token for temporary, user-scoped credentials using AssumeRoleWithWebIdentity. Access policies then rely on IAM conditions bound to that department tag, rejecting cross-department access at the policy level. ([cybersecuritynews.com](https://cybersecuritynews.com/aws-ai-agent-data-access/)) Documents in Bedrock Knowledge Bases are tagged by department at ingestion, and filters matching that metadata are added during retrieval—all handled at the application layer because the retrieve API doesn’t yet support IAM-style conditions. For Salesforce, AWS performs an on-behalf-of token exchange following RFC 8693 so that Salesforce’s internal sharing rules enforce access, without agent-level credentials being exposed. ([cybersecuritynews.com](https://cybersecuritynews.com/aws-ai-agent-data-access/))
Why This Matters, and What’s Next
Under this architecture, even if an agent is fully compromised, it contains no inherent permission to read data stores directly. All access uses short-lived, cryptographically bound credentials with scoped privileges, drastically reducing risk of unauthorized disclosure. Regular API security testing remains essential to ensure these token exchanges can’t be manipulated for privilege escalation. ([cybersecuritynews.com](https://cybersecuritynews.com/aws-ai-agent-data-access/))
This model isn’t limited to department-based divisions. AWS argues it translates to any attribute system—role, region, business unit, project. As agentic AI expands into sectors like healthcare, finance, and customer information systems, infrastructure-level authorization could become a benchmark defense against attacks that aim to force AI agents into illegal data exposure. Prompt injection and agent hijacking are viewed as among the top risks for 2026, making these controls more urgent than ever. ([cybersecuritynews.com](https://cybersecuritynews.com/aws-ai-agent-data-access/))
What this approach means is that organizations no longer have to rely solely on agents to police themselves. Validating the user’s identity, tagging data with metadata at ingestion, enforcing access via IAM or external sharing rules—all of this means the infrastructure acts as guardrails. It turns what had been soft, code-based restrictions into hardened policy and architecture-based enforcement. As AI agents proliferate in sensitive applications, this becomes a critical shift—not just to guard data but to preserve trust in AI systems themselves.
