Retrieval-augmented generation (RAG) lets AI assistants and agents answer questions using your own documents, tickets, wikis and databases. It also creates one of the easiest ways to leak data internally. If the retrieval layer can see everything, and does not check what the person asking is allowed to see, then any user, or any agent acting for them, can surface salary files, legal advice, customer data or board papers simply by asking the right question. This guide explains how RAG changes access control, where data leaks happen, and how to build permission-aware retrieval that respects the identities of the people and agents behind each query.
Key takeaways
- In RAG, retrieval is an access decision. It must enforce the requesting user's permissions, not the permissions of the indexing service.
- Carry source permissions into the index as metadata and filter results at query time, or query sources live with the user's delegated identity.
- Protect the indexing identities and vector databases: they often hold broad read access and copies of sensitive content.
- Fix over-sharing at the source. AI assistants surface existing permission mistakes faster than anything before them.
How RAG works, and where identity fits
- Ingest: an indexing service reads documents from sources (file shares, SaaS, databases), splits them into chunks and creates embeddings.
- Store: chunks and embeddings go into a vector database or search index.
- Retrieve: when a user asks a question, the system finds relevant chunks.
- Generate: the model answers using those chunks as context.
Two identities matter: the indexing identity that reads sources, and the requesting identity (user or agent) whose permissions should limit what is retrieved.
Where data leaks
- Retrieval ignores user permissions: the index returns any matching chunk, regardless of who asked.
- Permissions go stale: a document's access changes at the source, but the index keeps the old permissions or none.
- Over-shared sources: files shared with "everyone" or broad groups were never really meant to be discoverable; AI search makes them easy to find.
- Broad indexing identities: the service account that indexes sources has read access to everything, and its credential becomes a high-value target.
- Vector store exposure: the database of chunks is accessible with a single API key, or is shared across tenants or sensitivity levels.
- Prompt injection via retrieved content: a document contains instructions that steer the assistant. See How to Prevent Prompt Injection in AI Agents.
OWASP lists related risks as LLM02 Sensitive Information Disclosure and LLM08 Vector and Embedding Weaknesses in its Top 10 for LLM Applications (2025).
Patterns for permission-aware retrieval
| Pattern | How it works | Trade-offs |
|---|---|---|
| Access control metadata in the index | Each chunk stores the users and groups allowed to read its source; queries filter by the requester's identity and groups | Fast; requires reliable, frequent permission sync and group resolution |
| Live query with delegated identity | The assistant queries sources at request time using the user's delegated token | Always current; slower and depends on each source's search capability |
| Post-retrieval permission check | Retrieve candidates, then check each against the source's authorisation API before use | Accurate; adds latency; must fail closed |
| Segregated indexes | Separate indexes per sensitivity level, department or tenant, with access controlled at index level | Simple; coarse; more indexes to manage |
Many implementations combine metadata filtering with segregated indexes for the most sensitive content.
Securing the pipeline identities
- Give each indexing connector its own identity, scoped to the sources it needs; read-only.
- Prefer delegated or per-source identities over a single all-seeing service account.
- Protect vector database credentials; use workload identity where supported; separate indexing and query rights.
- Log index access and queries with the requesting identity.
- See Securing AI Infrastructure Workload Identities.
Agents and RAG
When an AI agent retrieves data on behalf of a user, retrieval should use the user's permissions intersected with the agent's scope, not the agent's own broad access. An agent acting for several users must not carry one user's retrieved data into another's session. See the AI Agent Authorisation Guide and the AI Agent Memory Security Guide.
Fix over-sharing first
- Before enabling AI search over a source, run an over-sharing review: files shared with everyone, anonymous links, broad groups.
- Apply sensitivity labels and exclude highly sensitive locations from indexing until permissions are cleaned up.
- See the Enterprise AI Copilot Security Guide.
Practitioner checklist
- Enforce the requester's permissions at retrieval, and fail closed if they cannot be evaluated.
- Sync source permissions into the index frequently, including group membership changes.
- Segregate highly sensitive content into separate indexes or exclude it.
- Scope indexing identities narrowly and protect vector store credentials.
- Clean up over-shared content before indexing.
- Log retrieval with user and agent identity; test with users of different access levels.
- Treat retrieved content as untrusted input to the model.
Standards and references
- OWASP Top 10 for LLM Applications (2025): LLM02, LLM08, LLM01
- OWASP Top 10 for Agentic Applications for 2026: ASI06 Memory and Context Poisoning
- NIST AI 600-1 Generative AI Profile
Related NHI Mgmt Group resources: Agentic AI Security Guide · Enterprise AI Copilot Security Guide · Authorisation Models Guide · AI Infrastructure Workload Identity Guide
