The conventional wisdom: AI agents should understand user context and enforce access controls themselves. If an agent is going to retrieve data on behalf of users, it needs to know who those users are and what they're allowed to see.
This thinking is widespread. Teams build elaborate permission systems into their agent logic. They pass user IDs through prompt chains and teach agents to check roles before answering questions. It feels responsible, you're building security into the intelligence itself.
Why we disagree: You're solving the wrong problem and creating a massive attack surface in the process.
When you embed access control logic in an AI agent, you're trusting a probabilistic system to make deterministic security decisions. That's backwards. The agent acts as an orchestrator, not a gatekeeper. Authorization should be enforced by downstream services, the same infrastructure that already protects your data when humans access it directly.
AWS's approach with Amazon Bedrock AgentCore demonstrates this principle. The agent doesn't decide what data a user can see. It passes the user's identity context to backend services, and those services enforce their existing access controls. The agent simply orchestrates the workflow.
This solves several issues: prompt injection attacks become far less dangerous. If someone tricks your agent into ignoring its instructions, it doesn't matter. The agent never had the authority to bypass access controls in the first place. The database, the API, the file store, they all enforce permissions independently.
The evidence: Look at how identity flows through this architecture. You authenticate users through your identity provider (Amazon Cognito, Microsoft Entra ID, Okta, whatever you're already using). That authentication produces tokens with claims about who the user is and what they can do. The agent receives these tokens and forwards them with every downstream request.
Your S3 bucket policies don't care that an AI agent is making the request. They care about the IAM role or user identity attached to that request. Your RDS instance enforces row-level security based on the database user, not on whether the query came from a human or an agent. Your internal APIs validate JWT claims the same way they always have.
This isn't theoretical. If you're meeting PCI DSS v4.0.1 Requirement 7.2.2 (access controls based on job classification and function), you already have role-based access control in your data layer. If you're maintaining SOC 2 Type II controls around logical access, you already enforce authorization at the resource level. You don't need to rebuild these controls inside your AI agent, you need to make sure the agent respects them.
The security model is simpler, too. Instead of auditing agent behavior to verify it's enforcing permissions correctly, you audit the same access logs you already review. Your SIEM doesn't need new rules for "AI agent accessed customer data." It sees the same identity-based access events it always has.
What to do instead: Start with identity federation. If you're not already using an identity provider that can issue tokens your backend services trust, implement that first. This isn't AI-specific work, it's fundamental infrastructure that improves security across your entire application stack.
When you build agent workflows, pass identity context explicitly. If you're using AWS, this means the agent receives the user's IAM credentials or assumes a role scoped to that user's permissions. If you're working with other platforms, use OAuth 2.0 tokens or SAML assertions. The agent becomes a transparent proxy for user identity.
Configure your downstream services to enforce authorization independently. Your agent might call an API to retrieve customer records, but the API should validate that the requesting user has permission to see those specific records. The agent doesn't make that decision, it just handles the orchestration.
For compliance documentation, this approach is cleaner. When auditors ask how you prevent unauthorized data access through AI agents, you point to the same access control documentation you already maintain. The agent workflow doesn't create a separate control domain that needs independent validation.
Test your controls with the same methods you use for traditional access paths. Can a user with read-only permissions trick the agent into modifying data? They shouldn't be able to, because the API enforcing those permissions doesn't care what the agent was told to do. It only cares about the identity token attached to the request.
When the conventional wisdom is right: There are scenarios where agents do need to understand user context for reasons beyond security. If you're building an agent that personalizes responses based on user preferences, or one that needs to explain why certain data isn't available, the agent needs some awareness of who's asking.
The distinction is between context and control. The agent can know "this user is in the finance department" to customize its responses. It shouldn't be the component that decides "therefore this user can see these accounts." That's what your database policies, API authorization middleware, and resource-level permissions are for.
For simple, isolated use cases, a chatbot that only accesses a single, non-sensitive data source, building authorization into the agent might be pragmatic. If you're not integrating with existing identity systems and the data doesn't require compliance controls, you can make different tradeoffs.
But if you're handling data covered by PCI DSS, HIPAA, SOC 2, or similar frameworks, you need defense in depth. Your access controls can't depend on an AI agent correctly interpreting instructions. They need to be enforced by the same infrastructure components you've already hardened, tested, and documented for compliance.
The agent is powerful because it orchestrates complex workflows. Let it do that job. Let your existing security infrastructure do its job. Don't merge the two and create a system where a clever prompt can bypass your access controls.
