RAG Security: Access Controls, Data Leakage, and Permission-Aware Retrieval

What happens when a RAG system retrieves information the user was never supposed to see?

A RAG system can understand a well-formed prompt and still leak information the user was never meant to see. It can also ingest tampered source content, retrieve an indirect prompt injection, leak sensitive metadata, or return a citation that reveals the existence of a restricted document.

This makes RAG security an end-to-end architecture issue. While the model endpoint is important, the security boundary is closer to source trust, identity, permissions, tenant isolation, ingestion, indexing, retrieval filters, and the content allowed in the model context.

This guide focuses on controls that mitigate against unauthorized retrieval and data leakage, then broadens the threat model to include prompt injection, data poisoning, vector and embedding weaknesses, output handling, logging, and production security testing.

What RAG Security Means in Practice

A secure RAG system limits what enters the knowledge base, what each caller can retrieve, what the model can use as context, and what the application exposes through answers, citations, metadata, tools, logs, and caches.

• The OWASP Top 10 for LLM and generative AI applications includes risks such as prompt injection, sensitive information disclosure, data and model poisoning, and vector or embedding weaknesses. Those categories matter to RAG because the application connects an LLM to external content and retrieval infrastructure.
• The NIST AI Risk Management Framework provides a broader governance model for identifying, measuring, managing, and monitoring AI risk. For enterprise RAG, the practical work is to translate that risk view into controls at each stage of the pipeline.

Threat-Model the Entire RAG Pipeline

Stage	Representative security failures	Control focus
Source and ingestion	Unauthorized source, stale or poisoned content, malicious instructions inside documents	Source allowlists, provenance, approval workflow, change monitoring, content handling
Parsing and indexing	Permissions dropped, sensitive metadata exposed, and vectors or index endpoints overexposed.	ACL preservation, index access control, encryption, network controls, secret management
Retrieval	Missing authorization filter, cross-tenant candidate set, query, or filter injection	Identity-aware filtering, tenant scoping, safe query construction, negative access tests
Generation	Indirect prompt injection, unsupported claims, sensitive context repeated in answer	Instruction hierarchy, context handling, output policy, grounding, and safety evaluation
Output and operations	Restricted citations, titles, logs, telemetry, caches, or exports	Data minimization, log controls, redaction where appropriate, access control, retention policy

Identity and Document Permissions Must Survive Ingestion

Permission-aware RAG begins with the source access model. If a document is scoped to a group or role, user or tenant, then the indexed representation must include sufficient permission metadata to enforce that decision later.

In Microsoft’s current Azure AI Search security guidance, document-level access control is defined as an identity-based restriction on which documents a caller can retrieve, where permission metadata is captured at indexing time and enforced at query time. This is a platform-specific implementation of the general rule that authorization must be checked before restricted content becomes valid model context.

Do not rely on the front end to “hide” a document that the retrieval service can still serve. Do not assume a vector similarity query knows about authorization. Semantic similarity orders related content. It does not determine whether the caller can see it.

Original architecture pattern: authorization defines the eligible corpus before semantic retrieval and generation.

Apply Authorization Before the Model Receives Context

As a safe default, make sure to make restricted content ineligible for retrieval, rather than retrieve it and hope the model ignores it.

Identify at query time the caller and applicable groups, roles, tenant, or attributes. At the time of the retrieval operation, impose constraints. Then, rank the authorized candidate set based on semantic relevance. In case your search stack contains lexical, vector, or multi-stage queries, make sure that the permission condition is consistently applied to all possible paths that can return a candidate.

When a restricted chunk makes it to the model, it’s too late to remove the source link from the final answer. The information has already crossed the authorization boundary.

Treat Tenant Isolation as More Than a Metadata Field

Multi-tenant RAG requires an explicit isolation model. A tenant ID attached to a chunk is only useful if every retrieval path, cache, tool, and downstream service honours it.

Depending on the threat model, high-risk environments may require separate indexes, separate encryption boundaries, separate credentials, or other stronger isolation. In some architectures a shared index with filters can be appropriate, but the team must test if a missing, malformed, or overridden filter can ever create a cross-tenant candidate set.

Plan for Prompt Injection in Retrieved Content

RAG offers an indirect path to prompt injection, as the retrieved documents may include text that attempts to influence the model. If an attacker can manipulate the content that the system later treats as trusted context, they don’t need to access the user prompt directly.

Controls should come before generation. Design the application to restrict sources that can enter the knowledge base, keep provenance, audit untrusted ingestion paths, and separate document content from system instructions. The model should be told that retrieved content is evidence, not a higher-priority provider of instructions.

Prompt injection is not a one-time filtering problem. Test documents with representative malicious instructions, measuring whether the application follows them, leaks other context, invokes tools inappropriately, or ignores the user’s actual task.

Protect Against Poisoned, Stale, or Untrusted Knowledge

A RAG system can be manipulated by altering the knowledge it retrieves. While poisoning may be intentional, routine content-management failures can produce similar effects when obsolete drafts, duplicated policies, or unapproved documents become searchable.

For sensitive use cases, use source allowlists or explicit ingestion policies. Track source owner, version, approval status, modification date, and ingestion timestamp. Quarantine unknown file types or malformed content. Test deletion and revocation paths so that removed content will actually disappear from the index and caches.

And these controls overlap with RAG data preparation since data quality, provenance, permissions, and security are related. A secure retriever can still fail if the “authorized” source is the wrong document.

Secure the Vector and Embedding Layer

The application’s sensitive data plane includes vector databases and search indexes. Treat them like the other production data services. Authenticate callers with least privilege. Reduce network exposure Encrypt data in transit and at rest where supported by the platform. Protect credentials; monitor administrative access.

Just because embeddings are not plain text, do not think they are harmless. The surrounding index can still show titles, source identifiers, metadata, and retrieved content. Weak tenant boundaries, overly broad service identities, or exposed query endpoints can make the retrieval layer a data-exfiltration path.

Do Not Let Citations, Logs, or Metadata Become Side Channels

A response can avoid quoting restricted text and yet leak information through a document title, citation, URL, file path, snippet, sensitivity label, or debug trace.

Log enough to diagnose failures but limit the amount you log. Where feasible, separate production telemetry from raw sensitive context. Apply access restrictions and retention rules for logs. Review vendor observability defaults to ensure prompt text, retrieved chunks, and model outputs are not copied into tools with a broader audience than the source system.

SECURITY REVIEW CHECKPOINT If your team is moving a RAG pilot toward production, Arcadion can help review data ingestion, retrieval configuration, access controls, testing, tuning, and governance against the use case and operating environment.

Run Negative Security Tests, Not Just Happy-Path Demos

Security testing needs users and content that are expected to fail. Create test identities with deliberately different permissions and verify what never appears.

1. Test a user who lacks access to a restricted document and verify that its chunks never appear in retrieval results.
2. Test two tenants with similar content and verify that each tenant’s queries cannot retrieve the other tenant’s chunks, citations, or metadata.
3. Place indirect prompt-injection text in an approved test document and observe whether the model follows the malicious instruction.
4. Introduce a stale or superseded document and verify that source status, version logic, or retrieval rules prevent the wrong source from dominating.
5. Remove or revoke access to a document and confirm that the index, caches, citations, and search results reflect the change.
6. Inspect logs and telemetry for sensitive prompt, context, citation, title, and metadata leakage.
7. Test fallback paths, error handling, and alternative retrieval modes to confirm that security filters are not bypassed when the primary path fails.

Production RAG Security Review

Control question	Evidence to collect before launch
Can every indexed item be traced to an approved source and owner?	Source inventory, provenance fields, ingestion logs
Are source permissions preserved and enforced at retrieval time?	ACL mapping, authorization tests, denied-user test results
Can one tenant or role ever become a candidate for another tenant or role?	Cross-tenant and cross-role negative tests
Can retrieved content override application instructions?	Indirect prompt-injection test suite and response traces
Are deletion and permission revocation reflected in the index?	Lifecycle tests and reconciliation logs
Can citations, titles, metadata, logs, or caches reveal restricted information?	Output review, log review, access-control validation
Are material architecture changes re-tested?	Security regression suite tied to release process

Secure RAG Means Controlling the Retrieval Path

Adding a model safety filter is only one aspect of RAG security. It needs trusted sources, permission-aware retrieval, tenant isolation, secure indexes, resistance to malicious retrieved instructions, controlled output, and repeatable negative testing.

The most important rule is simple: Never make unauthorized content a valid context for the model. From there treat any stage that moves or reveals that content as part of the security boundary.

How do you organize the deployment of a secure RAG? Discover Arcadion’s RAG Systems and learn about the data, retrieval, testing, and governance efforts needed for a production system.