Can RAG Metadata Filters Prevent Cross-Tenant Data Leaks?
Metadata filters can scope retrieval only when trusted identity, source permissions, every query path, and release tests preserve the same tenant boundary.
Short answer: metadata filters can help keep one customer's documents out of another customer's retrieval results, but a filter is not automatically an authorization boundary. The application must authenticate the requester, derive tenant and document scope from trusted identity and permissions, and apply that scope to every retrieval path. A native ACL or multi-tenancy feature is enough when it matches the access model and every query uses it. Prove the boundary with tests that inspect retrieved chunks and citations, not just the final answer.
Consider a SaaS customer portal that answers questions from tenant-specific implementation runbooks. Tenant A asks how its staging deployment is configured. A convincing answer is not enough: the release test must show that the retrieved evidence, reranked context, citations, cache entries, and final response contain no Tenant B material. OWASP calls out cross-context leaks in shared vector stores as a RAG risk and recommends permission-aware stores and strict logical or access partitioning (OWASP LLM08:2025).
Treat the filter as one link in the access path
Keep three decisions separate:
- Who is asking? Authenticate the user or service and resolve its authorized tenant and groups in application code.
- Which chunks may that identity retrieve? Apply tenant or document permissions in the retrieval layer before the chunks reach reranking or generation.
- What evidence may leave the system? Check the retrieved records and citations, and scope any retrieval cache to the same identity and permission state.
Do not let a model-proposed tenant_id, a query parameter, or text inside a document choose the access scope. The scope should come from the authenticated request and the system that owns the permissions. This is a design recommendation drawn from the documented identity handoff in Azure AI Search and Amazon Bedrock; their filters still depend on the application supplying the right identity context. (Azure AI Search security filters, Amazon Bedrock ACL-aware retrieval)
On narrow screens, scroll each table horizontally to compare the full row.
| Boundary | Owner | Evidence to inspect before release | Fail the release when |
|---|---|---|---|
| Request identity | Authentication and application authorization | Authenticated principal, server-resolved tenant, and allowed groups | The model or caller can widen scope by changing a tenant field |
| Indexed chunks | Source system and ingestion pipeline | Source document, permission version, tenant/group labels, and chunk IDs | Missing or unknown permissions become public by default |
| Retrieval paths | Search or vector service and its adapter | Applied filter or ACL context for vector, keyword, agentic, and fallback queries | Any path can retrieve without the same scope |
| Response and cache | Application response layer | Retrieved IDs, citations, cache key scope, and permission version | A result from one tenant can be served to another |
The table is a release-review artifact, not a claim that every provider exposes the same fields or logs. Adapt the evidence to the selected product and verify the actual request path.
When native isolation is enough—and when custom integration is justified
There is no single “metadata filter” control across platforms. Current first-party documentation describes materially different options:
| Native option | What its documentation supports | When the native option is sufficient |
|---|---|---|
| Amazon Bedrock Managed Knowledge Bases | ACL-aware retrieval accepts a userContext; the application must authenticate users and pass verified identity. Missing ACL metadata on an ACL-enabled source is treated as inaccessible, but non-ACL sources in the same knowledge base remain available to all users. Permission changes are eventually consistent. (AWS ACL-aware retrieval) | The required sources support ACL awareness, the app passes verified context on every request, and shared non-ACL content is intentionally public. Test connector coverage and permission-update behavior. |
| Azure AI Search | The documented string security-filter pattern matches principal IDs but does not authenticate or authorize them. Azure also documents native document-level ACL/RBAC approaches for supported sources; several integrations are marked preview. (Azure security-filter pattern, Azure document-level access control) | Use the supported native permission path when its source, identity model, API status, and synchronization behavior fit. If using string filters, the app must provide the authenticated principal and keep the indexed permission strings current. |
| Qdrant | Multi-tenant designs can use a tenant payload field and filter, or user-defined shards for tenants that need dedicated shard routing. (Qdrant multitenancy) | The app consistently binds the authenticated tenant to the payload filter or shard key and all query paths use that binding. |
| Weaviate | Multi-tenancy is disabled by default; when enabled, each tenant is stored on a separate shard and data in one tenant is not visible to another tenant. (Weaviate multi-tenancy) | The collection is configured for multi-tenancy, ingestion and retrieval use the intended tenant, and the application cannot select a tenant outside the caller's permissions. |
Amazon Bedrock's general metadata-filter API documents operators such as equals, andAll, and orAll; those shape which metadata matches, while ACL-aware retrieval separately requires verified user context. Treat metadata filtering and identity authorization as different parts of the design. (Amazon Bedrock RetrievalFilter API, AWS ACL-aware retrieval)
The native or no-code path is sufficient when it can carry verified user scope, enforce the required document or tenant boundary, cover every retrieval route, and return evidence that your release tests can inspect. Do not build a custom RAG layer only to attach a tenant label if the selected product's native control already fits. Add a custom integration for a demonstrated gap, such as unsupported source permissions, missing identity propagation, or a query path that bypasses the native control.
Test the boundary with tenant-specific canaries
Create two test tenants with deliberately unique, non-sensitive canary facts. Use the same question for both so the test exercises filtering rather than an easy keyword distinction. Run the cases against the deployed retrieval adapter and inspect tool/search calls, returned chunk IDs, source metadata, citations, and the rendered answer.
| Test case | Expected observable result |
|---|---|
| Tenant A asks a question whose answer exists only in A's runbook | A's chunk is retrieved and cited; no B chunk ID or content reaches reranking or generation. |
| The prompt or request body asks to switch to Tenant B | The authenticated A scope remains in force, or the request is rejected; no B content is retrieved. |
| Tenant or permission context is absent, malformed, or unknown | The system returns no protected content or an explicit error; it does not issue an unscoped search. |
| A document has no tenant label or its ACL cannot be read during ingestion | The document is quarantined or treated as inaccessible until its owner and permissions are known. |
| The same question runs through vector search, keyword search, reranking, agentic retrieval, and fallback | Every route applies the same authorized scope before content is used. |
| A cache is warmed with A's answer, then B asks the same question | B receives only B-authorized evidence; cached chunks and citations from A are not reused. |
| A user's permission is revoked | Access stops according to the provider's documented synchronization and cache behavior; the release record states the tested delay. |
Treat the raw retrieved evidence as the primary assertion. A model can omit a leaked paragraph from its answer while the unauthorized chunk still reached its context, logs, or citations. For permission changes, do not assume instant revocation: Azure documents source-specific synchronization into the index, and Amazon Bedrock says ACL updates are eventually consistent and third-party identity credentials can be cached. (Azure document-level access control, AWS ACL-aware retrieval)
Record the result as a release gate: pass only if every protected request has a server-resolved scope, every retrieval route honors it, no cross-tenant canary appears in retrieved evidence or output, and the permission-change test matches the stated operating expectation. A prompt that says “never reveal another customer's data” is not a substitute for these observable checks.
What this means for SaaS product teams
Start by mapping where customer documents enter the index and where a user's permissions can change. If one product tenant maps cleanly to one native vector-store tenant, a built-in multi-tenancy feature may be the simplest fit. If access varies by document, group, or source system, use a permission-aware retrieval feature that represents those rules, or preserve them in a trusted application layer. OWASP's warning is about the access boundary across the whole RAG path, not which vector database has the longest feature list. (OWASP LLM08:2025)
Where Zenovae helps
The AI integrations service is the primary path when retrieval, permissions, and existing customer systems have to work together. For an agent already in production, the Agent Reliability Audit can help review its evidence and release tests. If the workflow needs to be built inside the product, see the production agent build. For the related question of what information belongs in durable state versus a source system, read AI agent memory boundaries; for instructions in customer-controlled records and tool permissions, see the support-ticket authorization boundary.
Claim boundaries
This is an engineering release-test pattern, not a guarantee that a RAG system is secure, a security certification, or a legal or compliance conclusion. Provider features, source connectors, preview status, ACL synchronization, and identity behavior change over time. Recheck the current documentation for the exact service and version in use, and test the complete application path with non-sensitive canary data.
Sources
- OWASP GenAI Security Project: LLM08:2025 Vector and Embedding Weaknesses
- Microsoft Learn: Document-level access control in Azure AI Search
- Microsoft Learn: Security filters for trimming results in Azure AI Search
- Amazon Bedrock API Reference: RetrievalFilter
- Amazon Bedrock: ACL-aware retrieval on managed knowledge bases
- Qdrant: Multitenancy
- Weaviate: Multi-tenancy operations
Need Help with Your AI Project?
At Zenovae, we build production-ready AI systems that scale. From OpenClaw setup to custom integrations, Mission Control workflows, and full-stack delivery, we can help you ship faster and avoid costly mistakes.
Let's Talk