Multi-Tenant RAG Security: Authorization Before Retrieval

Retrieval changes the application trust model

Retrieval-augmented generation connects a model to data that is newer, more private, and more application-specific than its weights. That improves usefulness, but it also creates a new authorization path:

principal --> query --> candidate retrieval --> context --> model --> answer

If authorization is applied only to the final answer, private content has already crossed the boundary. The model may quote it, transform it, infer from it, leak it through a tool call, or place it in memory. Output filtering cannot reliably reconstruct which facts the caller was entitled to receive.

The core rule for multi-tenant RAG is therefore:

A chunk must be authorized for the current principal and purpose before it becomes a retrieval candidate or model input.

The OWASP Vector and Embedding Weaknesses guidance highlights unauthorized access, cross-context leakage, data poisoning, and embedding inversion among the risks. A secure design must address both confidentiality and integrity across ingestion, retrieval, generation, and retention.

Model tenants, principals, and resources explicitly

“Tenant ID” is not a complete authorization model. A person may belong to multiple tenants, groups, matters, projects, regions, or sensitivity compartments. Access may depend on document state, contractual purpose, time, and source-system policy.

Define at least:

• Tenant: the primary isolation domain.
• Principal: human or workload identity making the request.
• Groups and roles: attributes used by the source system.
• Resource: document, record, message, object, or generated artifact.
• Derived resource: page, chunk, summary, embedding, cache entry, or citation derived from a resource.
• Purpose: why the data is being accessed, when purpose limitation applies.
• Policy version: the authorization state under which ingestion or retrieval occurred.

Never infer the tenant solely from user-controlled query text, a document label, or a model-selected filter. Resolve it from the authenticated session and trusted application state.

Separate the ingestion and query planes

A secure RAG system has two related but distinct data flows.

INGESTION PLANE
source identity --> fetch --> parse --> classify --> authorize/index
                               |                     |
                               v                     v
                         provenance log        chunks + embeddings

QUERY PLANE
caller identity --> policy context --> filtered retrieval --> context builder
                                               |                  |
                                               v                  v
                                        citations/evidence --> model

The ingestion plane establishes provenance and propagates policy. The query plane proves that the current caller may receive each derived artifact. A weakness in either plane can cause cross-tenant disclosure.

The planes should use different credentials. A connector that reads from a source system should not automatically become an inference identity that can query every tenant. Likewise, a query service should not be able to overwrite indexed content.

Preserve authorization through derivation

Chunking and embedding do not erase ownership. Every derived object must remain linked to its source resource and authorization attributes.

A practical chunk record might include:

{
  "chunk_id": "chk-7f8c",
  "tenant_id": "tenant-42",
  "source_system": "knowledge-base",
  "source_resource_id": "doc-981",
  "source_version": "17",
  "content_hash": "sha256:...",
  "embedding_model": "approved-embedder@revision",
  "acl": {
    "allow_groups": ["engineering"],
    "classification": "internal",
    "region": "eu"
  },
  "policy_version": "2026-08-14.3",
  "valid_from": "...",
  "valid_until": null
}

Keep the source identifier even when the source is deleted or replaced so stale artifacts can be found and invalidated. Do not store a free-form model-generated statement such as “safe for employees” as the authoritative access decision.

Summaries require special attention. A summary may combine facts from several documents with different access rules. Its effective policy must be at least as restrictive as the union of its sources, or the summary must be generated separately for a specific principal. The same rule applies to extracted tables, entity graphs, synthetic questions, and cached answers.

Filter before similarity search

Post-filtering retrieves a broad nearest-neighbor set and removes unauthorized results afterward. This can be unsafe and operationally fragile:

• Unauthorized candidates may appear in traces, metrics, caches, or reranking prompts.
• Filtering can leave too few results and tempt fallback logic to widen scope.
• Side channels may reveal that a matching private document exists.
• A shared reranker may process content the caller cannot access.

Prefer pre-filtering in the vector store or physically separated indexes so unauthorized records are excluded from candidate generation. The trusted query layer should inject filters from authenticated policy context; the model and user should not author them.

When the database cannot express the complete policy, retrieve stable resource identifiers from a policy-aware index or entitlement service first, then restrict vector search to those identifiers. For very high-sensitivity tenants, separate indexes, encryption keys, accounts, or clusters may be justified.

Test the actual behavior of approximate nearest-neighbor indexes. Configuration that looks like a filter in an SDK may be applied after candidate generation by a specific backend or query mode.

Recheck policy at query time

Copying an access-control list during ingestion creates a stale authorization problem. A user may leave a group, a document may become restricted, or a legal hold may change its permitted use before the next index refresh.

Choose and document one of these models:

1. Live authorization: query the source-of-truth policy service for candidate resources.
2. Versioned entitlement snapshot: use rapidly updated, signed policy snapshots with bounded staleness.
3. Event-driven invalidation: process source ACL changes into the index and deny access when synchronization health is uncertain.
4. Physical isolation: keep resources in a tenant-specific store and still validate user access within the tenant.

Fail closed when the identity, tenant, policy version, or entitlement service is unavailable. A “temporary” fallback to unfiltered retrieval converts an availability event into a confidentiality incident.

Record the policy decision and version used for each returned chunk. This enables incident investigation and demonstrates whether leakage came from stale policy, bad metadata, a query bug, or later context handling.

Secure ingestion as a privileged operation

Content entering the index can influence every later answer. Treat ingestion as a supply-chain boundary rather than a background convenience job.

For each connector:

• Use a dedicated identity with read access only to intended collections.
• Verify tenant and collection mapping from trusted configuration.
• Validate MIME type, parser behavior, file size, decompression ratio, and recursion.
• Preserve author, source, version, timestamps, and content hashes.
• Scan or quarantine unsupported active content.
• Apply data classification and retention rules before indexing.
• Reject records with missing or ambiguous authorization metadata.
• Make re-index and deletion operations attributable and reversible.
• Monitor unexpected volume, contributors, formats, and policy changes.

Do not trust document metadata merely because a connector supplied it. Validate identifiers against the source API and bind the connector to the tenant it serves. Cross-tenant index poisoning often begins as a mapping or synchronization bug rather than a sophisticated model attack.

Address poisoning and indirect prompt injection

An authorized contributor may still be malicious, compromised, or mistaken. A retrieved document can manipulate model behavior even when the caller is allowed to read it.

Separate two questions:

1. May this principal receive this content? This is authorization.
2. May this content instruct the application? Usually not; it is untrusted data.

Maintain provenance labels through the context builder. Delimit retrieved content and identify the source, but do not rely on delimiters as the security boundary. Tool policy, output handling, and approvals must assume the model can follow embedded instructions.

Test poisoning at multiple levels:

• A new malicious document designed to rank highly for common queries.
• Small edits to a trusted, frequently retrieved document.
• Metadata or synthetic-question manipulation that changes ranking.
• Repeated near-duplicate chunks that crowd out legitimate sources.
• Conflicting documents with different freshness and authority.
• Instructions introduced by OCR, comments, or hidden fields.
• A compromised connector that alters content or ACL metadata.

Defenses include contributor accountability, review workflows for authoritative collections, anomaly detection, duplicate suppression, source weighting, freshness policy, signed ingestion manifests, and immutable provenance. None substitutes for tool authorization after retrieval.

Protect caches, histories, and generated artifacts

RAG confidentiality failures often appear outside the vector database.

Audit these cache keys and stores:

• Query embedding caches.
• Retrieved candidate and reranking caches.
• Prompt and model-response caches.
• Conversation history and generated memory.
• Citation previews and document thumbnails.
• Evaluation, tracing, support, and analytics systems.

A safe cache key normally includes tenant, effective entitlement or policy version, model and prompt versions, and other inputs that affect visibility. When precise entitlement keys are impractical, use tenant-specific caches and reauthorize every referenced resource before serving the result.

Do not place raw query text, retrieved chunks, or prompts into broad infrastructure logs by default. The OpenTelemetry generative AI conventions explicitly note that model messages and retrieval queries can contain sensitive information. Capture protected artifact references or hashes where ordinary telemetry is sufficient.

Deletion must reach derived artifacts. Removing a source document should invalidate its chunks, embeddings, summaries, cached answers, evaluation fixtures, and user-visible history according to the documented retention policy.

Make citations part of the security design

Citations are useful for verification, but they can leak document titles, paths, identifiers, snippets, or the existence of restricted material. Generate citations only from the authorized set used for the answer.

A citation resolver should:

• Reauthorize the source when the user opens it.
• Use opaque stable identifiers rather than guessable storage paths.
• Avoid returning titles or snippets before authorization.
• Link to the source system's access-controlled view where possible.
• Preserve the source version and chunk relationship used for the answer.
• Distinguish quoted evidence from model-generated synthesis.

Do not accept model-invented citation URLs. The application should construct citations from trusted retrieval metadata.

Design a multi-tenant RAG test environment

Create synthetic tenants and identities with deliberate overlap:

Plant unique canaries in every document and derived artifact. Include documents with identical ordinary text but different tenant canaries so semantic similarity is high. Add group changes, deletions, classification changes, duplicate documents, malformed ACLs, and delayed synchronization.

Then test:

• Direct requests for another tenant's facts and identifiers.
• Semantically similar queries that should cross no boundary.
• Empty, malformed, or model-generated filters.
• Retrieval during policy-service failure and index lag.
• Access immediately after group removal or document reclassification.
• Cache reuse across users, groups, tenants, and policy versions.
• Reranking, citation, export, feedback, and conversation-history paths.
• Indirect prompt injection that asks for different documents or tool use.
• Batch and streaming APIs whose enforcement may differ from the interactive path.
• Administrative previews and support tools with elevated visibility.

Measure at each stage: candidates returned by the store, content given to the reranker, content assembled into context, output produced by the model, citations generated, cache entries written, and logs emitted.

Rate findings by the boundary crossed

Not every odd answer is a cross-tenant leak. Confirm provenance.

Include the affected tenants, principals, resource classes, policy state, repeatability, cache behavior, and deletion implications in the impact analysis.

A secure RAG review checklist

Before production, require evidence that:

1. Authentication establishes tenant and principal from trusted state.
2. Derived artifacts retain source identity, provenance, and policy.
3. Unauthorized resources are excluded before similarity search or model use.
4. Policy freshness and failure behavior are defined and tested.
5. Ingestion identities, mappings, parsers, and writes are constrained.
6. Retrieved content cannot grant tools, permissions, or approval.
7. Caches and histories are partitioned and invalidated correctly.
8. Citations are created from trusted metadata and reauthorized on access.
9. Telemetry avoids uncontrolled sensitive content collection.
10. Deletion reaches chunks, embeddings, summaries, caches, and fixtures.
11. Cross-tenant regression tests run on every retrieval-layer change.
12. An incident response process can identify every query that received a bad chunk.

Multi-tenant RAG security is conventional access control carried through an unconventional data pipeline. The model does not simplify the authorization problem; it makes early, precise enforcement more important.

For end-to-end adversarial validation, see AI security testing. For trust-boundary design and tenant-isolation review, see security architecture. The related prompt injection testing methodology covers hostile instructions inside otherwise authorized content.

Sources and further reading

• OWASP LLM08:2025 Vector and Embedding Weaknesses
• OWASP LLM01:2025 Prompt Injection
• NIST SP 800-207, Zero Trust Architecture
• NIST SP 800-207A, Cloud-Native Applications in a Zero Trust Architecture
• OpenTelemetry Generative AI Semantic Conventions