Permission-Aware RAG Guide: Securing Agent Access to Enterprise Data

Retrieval-augmented generation (RAG) lets AI assistants and agents answer questions from your own documents, tickets, wikis and databases, and if retrieval does not check what the person asking may see, it becomes one of the easiest ways to leak data internally. When the retrieval layer can read everything, any user, or any agent acting for them, can surface salary files, legal advice, customer data or board papers by asking the right question. This guide explains how RAG changes access control, where data leaks, the main patterns for permission-aware retrieval and their trade-offs, and how to secure the non-human identities that build and query the index. It is written for engineers building RAG and agent platforms, identity architects and data protection teams reviewing them.

Key takeaways

• Retrieval is an access decision: it must enforce the requesting user's permissions, not the permissions of the indexing service, and fail closed when they cannot be evaluated.
• Carry permissions with the content: store source access control lists as metadata and filter at query time, or query sources live with the user's delegated identity, and keep both in sync with the source.
• The pipeline identities are high-value NHIs: indexing connectors and vector store credentials often hold broad read access to copies of sensitive content, so scope, protect and monitor them.
• Retrieved content is untrusted input: documents, messages and tickets can carry instructions, as EchoLeak and the Slack AI research showed, so retrieval controls must limit what injected text can reach and where output can go.
• Fix over-sharing at the source: permission-aware retrieval faithfully reproduces whatever the source allows, so broad sharing becomes broad AI exposure.

How RAG works, and where identity fits

1. Ingest: an indexing service reads documents from sources (file shares, SaaS, databases, ticketing), splits them into chunks and creates embeddings.
2. Store: chunks, embeddings and metadata go into a vector database or search index.
3. Retrieve: when a user or agent asks a question, the system finds relevant chunks, ideally filtered by what the requester may read.
4. Generate: the model answers using those chunks as context, sometimes with tools that can act on the answer.

Three identities matter, and each needs its own controls.

OWASP's guidance on excessive permissions describes the same mistake for any LLM extension: one designed to act for an individual user that "accesses downstream systems with a generic high-privileged identity". See the RAG Security Guide for the wider RAG threat model.

Where data leaks

• Retrieval ignores user permissions: the index returns any matching chunk regardless of who asked, so the assistant becomes a universal search over everything the indexer could read.
• Permissions go stale: access changes at the source but the index keeps the old ACL or none. Amazon's documentation for Q Business notes that connectors update ACLs "each time that your data source content is crawled" and advises re-syncing "regularly".
• Identity mismatches: groups deleted and recreated with the same name, or email addresses reused by a new joiner, can silently change who matches a document's ACL. Amazon Q Business warns about both cases.
• Over-shared sources: files shared with "everyone" or broad groups were never meant to be discoverable; AI search makes them easy to find.
• Broad indexing identities: the service account that indexes sources can read everything, and its credential becomes a high-value target.
• Vector store exposure: chunks and embeddings readable with a single API key, or shared across tenants or sensitivity levels. OWASP LLM08 lists "Unauthorized Access & Data Leakage", cross-context leaks in multi-tenant stores and embedding inversion attacks that "recover significant amounts of source information".
• Prompt injection via retrieved content: a document or message contains instructions that steer the assistant. In EchoLeak 2025, according to BleepingComputer's account of Aim Labs' research, a crafted email retrieved by Microsoft 365 Copilot's RAG engine caused internal data to be placed in a link sent to the attacker. PromptArmor showed that Slack AI could be steered by a message in a public channel the victim had not joined to render a link carrying data from the victim's private channel. See the Prompt Injection Guide.

OWASP lists these risks as LLM02 Sensitive Information Disclosure, LLM08 Vector and Embedding Weaknesses and LLM01 Prompt Injection in its Top 10 for LLM Applications (2025).

Patterns for permission-aware retrieval

Making metadata filtering safe

Search platforms support the first pattern in different ways. Azure AI Search offers a security filter pattern but is explicit that "the principal is just a string" with "no authentication or authorization through the security principal", so the application must resolve the caller's identity and groups correctly; it also offers native document-level permissions for some sources in preview. Elasticsearch document level security uses a role query that can be templated with details of the authenticated user. Amazon Q Business indexes source ACLs into a user store and filters responses by the end user's access. Microsoft Graph connectors attach an ACL to each item, where deny takes precedence over grant.

• Resolve the requester's identity from a verified token, never from a parameter the client or model can set.
• Expand nested and external groups at index time or query time consistently, and test both.
• Treat "no ACL" as "no access", not "public", unless the source marks the item public.

Combining patterns

OpenFGA's guidance on searching with permissions sets out three options, search then check, build a local index from the changes feed then check, or list accessible IDs then search, and notes that a final check catches permissions "revoked but whose authorization data has not made it into your index yet". Many implementations combine a metadata pre-filter for speed, a post-retrieval check for recently changed items, and segregated indexes for the most sensitive content. For multi-tenant SaaS, Pinecone recommends a namespace per tenant, which "provides physical isolation of data between tenants". See the Authorisation Models Guide.

Securing the pipeline identities

• One identity per connector: give each indexing connector its own identity, read-only and scoped to the sources it needs, rather than one all-seeing service account.
• No long-lived keys where avoidable: use workload identity or managed identities for the indexer and query service; where API keys remain, vault and rotate them. The OWASP NHI Top 10 lists Overprivileged NHI (NHI5) and Long-Lived Secrets (NHI7). See the AI Infrastructure Workload Identity Guide.
• Separate write and read: the indexer writes; the query service reads; neither should administer the store.
• Protect the identity store too: Amazon advises treating changes to its Q Business user store, which maps users and groups to documents, "as a privileged operation".
• Log with identity: record index writes and every retrieval with the requesting user, agent and application identity.

See the Service Account Security Guide and the Secrets Management Guide.

Agents and RAG

When an AI agent retrieves data for 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 or memory. OWASP's agentic Top 10 places embeddings and RAG stores within ASI06 Memory and Context Poisoning, and its ASI03 entry describes memory-based privilege retention, where cached credentials or retrieved data are reused across tasks or users.

• Pass the user, not just the agent: use delegation or token exchange so downstream checks see both. See the OAuth Token Exchange and Delegation Guide.
• Re-check at use: permissions validated at the start of a long workflow can change before the agent acts. See the Zero Trust for AI Agents Guide.
• Segment memory: clear or partition retrieved context between users and tasks. See the AI Agent Memory Security Guide.
• Limit tools after retrieval: an agent that has just read untrusted content should not be able to send data externally without approval. See the AI Agent Authorisation 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 and ownerless locations.
• Apply sensitivity labels and exclude highly sensitive locations from indexing until permissions are cleaned up; some platforms can enforce labels at query time. See the Data Classification Guide.
• Index only what the use case needs; a narrow, curated corpus is easier to secure than a crawl of every share.
• Recheck after clean-up that the index reflects the new permissions. See the Enterprise AI Copilot Security Guide and the Access Reviews Guide.

Detection and monitoring

OWASP LLM08 recommends keeping "detailed immutable logs of retrieval activities". Useful signals:

• Retrievals of labelled or restricted content by users outside the expected group, or a sudden rise in sensitive chunks retrieved per user.
• Index or vector store access from identities other than the indexer and query service, or from unexpected networks.
• Bulk reads or exports from the vector store, and new API keys created for it.
• Permission sync failures or long gaps since the last successful ACL sync for a source.
• Responses containing external links or images built from retrieved content, a common exfiltration route in EchoLeak and the Slack AI research.

Route these to the SOC with the same identity context as other NHI alerts. See the AI Agent Observability and Incident Response Guide and the Generative AI Data Loss Prevention Guide.

Framework mapping

Indicative alignment prepared by NHI Mgmt Group, not an official mapping. Control IDs were checked against NIST CSWP 29, the SP 800-53 Rev. 5 catalogue, the CIS Controls v8.1 list, a published ISO/IEC 27001:2022 Annex A list and the OWASP texts.

NIST AI 600-1, the Generative AI Profile, lists data privacy and information security among the risks generative AI introduces or worsens, and is a useful frame for the risk assessment behind these controls.

Common failure patterns

• The demo index goes live: a proof of concept indexed everything with an administrator token and no ACLs, and it becomes production because it works.
• Filtering in the prompt: the system prompt tells the model to "only show what the user may see", which is not an access control.
• Client-supplied identity: the user or group filter is taken from a request parameter or from the model's tool call rather than a verified token.
• ACL sync that silently stops: connector failures go unnoticed, so revoked access persists in the index for weeks.
• One collection for everyone: tenants or sensitivity levels share a store with metadata filters only, and a single missing filter leaks across the boundary.
• Treating retrieved text as trusted: retrieved content can trigger tools or render links, as in the EchoLeak and Slack AI research.
• Forgetting derived copies: chunks, embeddings, caches and conversation logs hold sensitive content outside the source system's controls and retention.

Metrics that show progress

Implementation roadmap

Practitioner checklist

• Enforce the requester's permissions at retrieval, resolved from a verified token, and fail closed.
• Sync source permissions into the index frequently, including group membership changes, and alert on sync failures.
• Treat items without ACL metadata as restricted unless the source marks them public.
• Segregate highly sensitive content and tenants into separate indexes or namespaces, or exclude it.
• Give each indexing connector its own read-only, scoped identity; avoid long-lived keys.
• Protect vector store credentials and the identity mapping store as privileged.
• Clean up over-shared content before indexing and index only what the use case needs.
• Intersect user and agent permissions for agent retrieval and segment agent memory.
• Treat retrieved content as untrusted input and restrict links, images and tool calls built from it.
• Log retrieval with user and agent identity, and test with users of different access levels on every change.

Standards and references

• OWASP GenAI Security Project: LLM08:2025 Vector and Embedding Weaknesses
• OWASP GenAI Security Project: LLM02:2025 Sensitive Information Disclosure
• OWASP GenAI Security Project: LLM01:2025 Prompt Injection
• OWASP GenAI Security Project: Top 10 for Agentic Applications for 2026
• NIST: AI 600-1, Generative Artificial Intelligence Profile
• Microsoft Learn: Document-level access control in Azure AI Search
• Microsoft Learn: Security filters for trimming results in Azure AI Search
• Elastic Docs: Controlling access at the document and field level
• AWS: Amazon Q Business connector concepts (ACL crawling)
• OpenFGA: Search with permissions
• Pinecone Docs: Implement multitenancy
• PromptArmor: Data exfiltration from Slack AI via indirect prompt injection

Related NHI Mgmt Group resources: RAG Security Guide · Enterprise AI Copilot Security Guide · Authorisation Models Guide · AI Infrastructure Workload Identity Guide · Agentic AI Security Guide