Enterprises are racing to deploy AI agents that pull from databases, document repositories, SaaS platforms, and internal knowledge bases to automate workflows.
But a quiet risk lurks beneath the convenience: most agents have no built-in awareness of who is actually asking the question, which means a compromised or manipulated agent could hand over data the requesting user was never authorized to see.
AWS has now published a detailed architecture using Amazon Bedrock AgentCore that closes this gap by moving authorization out of the agent’s code and into the infrastructure itself.
AWS Shows How to Prevent AI Agent Data Access
The traditional fix for this risk has been to give an agent broad credentials and rely on the agent’s own logic to filter results, often through simple query conditions. AWS’s guidance identifies this as a structural weakness.
If an attacker manipulates the agent through prompt injection or exploits a bug in that filtering code, the agent’s full underlying dataset becomes exposed. Evaluating robust AI security software is becoming necessary as enterprises adopt autonomous agents.
AWS’s proposed answer, aligned with the AGENTSEC03 best practice in the AWS Well-Architected Agentic AI Lens, treats the agent purely as an orchestrator that coordinates tool calls and reasoning, while actual access decisions are enforced by the services the agent talks to.
The demonstration centers on a CRM chat application shared by Sales and Finance employees, each needing isolated access to customer records in Amazon DynamoDB, department-tagged documents in Amazon Bedrock Knowledge Bases backed by Amazon S3, and external CRM data in Salesforce.
When a user logs in through an Amazon Cognito user pool, a pre-token generation Lambda trigger injects a department claim and AWS session-tag metadata directly into the JSON Web Token before it reaches the application.
Amazon Bedrock AgentCore Runtime validates this token on arrival and rejects any request whose department claim doesn’t match an allowed value, blocking unauthorized calls before agent code ever runs. From there, AWS demonstrates three distinct patterns for propagating that verified identity downstream.
For DynamoDB, the agent exchanges the user’s signed ID token for temporary, user-scoped credentials via AssumeRoleWithWebIdentity, letting AWS Identity and Access Management evaluate a LeadingKeys condition tied to the user’s department tag, so cross-department queries are rejected at the policy level rather than filtered after the fact.
Adopting these identity constraints aligns directly with core principles for securing cloud APIs across multi-tenant environments.
For Bedrock Knowledge Bases, documents are tagged with department metadata at ingestion, and the agent appends a matching metadata filter to each retrieval call, an application-layer control since the retrieve API doesn’t yet expose filters as IAM conditions.
For Salesforce, AgentCore Identity performs an on-behalf-of token exchange under RFC 8693, swapping the user’s authenticated identity for a Salesforce-recognized token without any credential ever touching the agent, letting Salesforce’s own sharing rules govern what comes back.
As detailed in the architecture guide shared by AWS Security Blog, enforcing authorization at the infrastructure layer ensures data boundaries remain intact regardless of agent-level manipulation.
| Downstream Target | Authorization Mechanism | Enforcement Method |
| Amazon DynamoDB | AssumeRoleWithWebIdentity Token Exchange |
IAM LeadingKeys condition tied to department session tag |
| Bedrock Knowledge Bases | Ingestion-time metadata tagging | Application-layer filter appended to /retrieve API queries |
| Salesforce CRM | RFC 8693 on-behalf-of token exchange | Native Salesforce sharing rules and user role policies |
The practical significance is that even a fully compromised agent, one manipulated through prompt injection or a coding flaw, cannot reach beyond what the authenticated user is entitled to see, because the agent’s execution role holds no direct data-store permissions of its own.
Each request instead carries short-lived, cryptographically derived, user-bound credentials that expire quickly and cannot be reused or forged. Regularly conducting API security testing helps verify that downstream token exchanges remain resilient against privilege escalation attempts.
AWS frames this as a generalizable pattern: department scoping in the example maps just as easily to role, business unit, region, or project-based access controls in other environments.
As organizations expand agentic AI into sensitive systems handling financial, healthcare, or customer data, this shift toward infrastructure-enforced authorization, rather than trusting an LLM-driven agent to self-police, represents a meaningful hardening step against the growing class of prompt-injection and agent-hijacking attacks that security researchers have flagged as a top concern for 2026.
Prevent incidents due to slow investigations. Power your Tier 1 with threat intelligence from 15K SOCs: Integrate TI Lookup in your SOC
The post AWS Shows How to Stop a Hijacked AI Agent From Reading Data the User Cannot Access appeared first on Cyber Security News.
