Amazon Web Services (AWS) has outlined a new strategy to restrict AI agents' access to sensitive data, even when those agents are subjected to manipulation or internal bugs. The approach focuses on enforcing user authorization at the infrastructure and downstream service levels, rather than relying on the AI agent itself to act as a gatekeeper. This method is designed to ensure that AI agents built using Amazon Bedrock AgentCore only retrieve information that the initiating user is authorized to view.
Customers utilizing Amazon Bedrock AgentCore can develop AI agents that integrate data from various sources, including Amazon DynamoDB tables, document repositories, Software-as-a-Service (SaaS) platforms, and internal knowledge bases. These agents are designed to answer questions and automate workflows. However, without a mechanism to understand the user's authorization context, an agent could inadvertently expose restricted information. AWS emphasizes that the agent's role is that of an orchestrator, with authorization enforcement delegated to the underlying services.
AWS illustrated this approach with a customer relationship management (CRM) application scenario. In this example, employees from both Sales and Finance departments interact with the same AI agent to access customer information. Sales personnel require access to contracts, pricing strategies, and sales pipeline data, while Finance employees need access to invoices, payment records, and financial reports. The agent can retrieve data from Amazon DynamoDB, documents stored in Amazon Bedrock Knowledge Bases, and external services like Salesforce. When a Sales employee queries for customer contracts, the agent should only be able to retrieve Sales-specific information, not Finance data.
The core of the AWS strategy involves propagating the user's authorization context throughout the request lifecycle. Employees first authenticate using their corporate credentials, with Amazon Cognito serving as the identity provider in the AWS example, though Microsoft Entra ID and Okta are also supported. Information about the employee, such as their department, is embedded within their authentication tokens and carried with requests directed to the AI agent.
The Amazon Bedrock AgentCore Runtime is responsible for validating the user's token and checking their authorization details before allowing the request to proceed to the agent. Requests from users who do not meet the configured requirements can be rejected at this stage, preventing the agent from even beginning its operation. Crucially, this authorization context is then passed along when the agent accesses other services, enabling those services to independently determine which information the user is permitted to access.
AWS demonstrated the application of this approach across DynamoDB, Amazon Bedrock Knowledge Bases, and Salesforce. For DynamoDB, access can be limited to records specifically associated with the user's department. Salesforce similarly applies its own sharing rules, ensuring that the agent receives only records available to the individual user. Amazon Bedrock Knowledge Bases utilize metadata filtering to restrict retrieved documents to the appropriate department. AWS notes that this control operates at the application layer and advises the use of separate knowledge bases with distinct IAM policies for situations requiring stricter isolation.
The overarching goal is to avoid granting AI agents broad access to data and then relying on the agent to correctly filter sensitive information. Instead, AWS recommends configuring underlying services to reject unauthorized requests regardless of what the agent asks for. This design ensures that the agent's credentials are inherently limited by the requesting user's permissions, making it impossible for prompt manipulation or application bugs to bypass these established security boundaries.
