TL;DR: RAG-powered AI agents can surface sensitive internal data, leak confidential material, or be manipulated through prompt and context injection when permission checks are missing, according to Cerbos. The security problem is not the model alone but the trust boundary around retrieval, authorization, and downstream response generation.
Editorial analysis by NHI Mgmt Group, based on content published by Cerbos: “Access control and permission management for AI agents: building with security in mind”.
Key questions
Q: How should security teams implement RAG so it does not expose data users should not see?
A: Security teams should treat RAG as a retrieval system with access controls, not as a passive answer engine.
Q: Why do RAG systems create more governance risk than a simple chatbot?
A: RAG systems introduce an extra trust boundary because external content enters the prompt window at runtime.
Q: What are the signs that a RAG agent is overprivileged?
A: A common warning sign is when the assistant can answer questions across unrelated business domains or expose records that belong to another role, department, or region.
Practitioner guidance
- Define the retrieval authorization boundary Require policy evaluation before any document, row, or vector is returned to the agent.
- Map the agent to user entitlements Treat the AI companion as a governed identity path that inherits role, department, region, and other attributes from the requesting user rather than using broad application-level access.
- Separate trusted and untrusted context Classify retrieved content by source trust level and block prompt assembly when the input includes unverified or user-controlled material that could steer the model.
Bottom line: RAG-based AI agents create an access-control problem because they can surface live enterprise data through a conversational interface that users experience as trusted but that the organisation still has to govern.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
RAG-based agents turn access control into an identity decision, not just a retrieval feature. The moment an assistant can query live organisational data, it inherits a governance burden that looks much closer to IAM than to model tuning. The key question is whether the agent can prove entitlement before it ever touches the source record. Practitioners should treat the retrieval path as part of the identity plane.
A few things that frame the scale:
- Gartner predicts that by 2028, 33% of enterprise software applications will include agentic AI, up from less than 1% in 2024, and that 15% of day-to-day work decisions will be made autonomously.
A question worth separating out:
Q: Why do AI agents need access controls separate from normal application IAM?
A: AI agents can make independent runtime decisions and call tools in ways that application IAM was never designed to review. Separate controls let teams scope access by task, time, and tool boundary, which reduces the chance that a misbehaving agent can move laterally or write into systems it should only read.
👉 Read our full editorial: RAG-based AI agent access control is now an identity issue