Most SaaS platforms building RAG features share one vector database across every customer and rely on a metadata filter to keep tenants apart. That filter is application logic, not database-enforced access control, and vector databases were not built with the same isolation guarantees relational databases have had for decades. The result is a semantic search stack where one tenant’s query can, under the right conditions, retrieve another tenant’s private documents.

What’s happening

Multi-tenant RAG architecture almost always follows the same shortcut: one collection, one index, and a tenant_id field attached to every vector at ingestion time. Isolation is enforced by adding a WHERE tenant_id = X equivalent to the similarity search call, not by anything the database itself guarantees at the storage or index level. Recent security research on RAG pipelines has formalized this as a distinct attack surface — cross-tenant filter bypass and embedding-based information leakage — separate from the more widely discussed problems of prompt injection or knowledge poisoning (RAG Pipeline Attack Scenarios: Context & Data Leakage, RedFox Security, 2026).

The core issue is architectural, not a bug in any single product. Analysis of production multi-tenant vector database patterns shows that tenant isolation is typically enforced in application code as a post-hoc metadata filter, and that vector databases have no native access control model comparable to row-level security in a relational engine (Curator: Efficient Indexing for Multi-Tenant Vector Databases, arXiv, 2026). If the tenant identifier used in that filter is user-controlled, derived from a client-side parameter, or passed through a GraphQL or REST layer without strict server-side enforcement, an attacker can manipulate it directly. Even without any deliberate attack, a subtler version of the same problem shows up organically: because embeddings encode semantic similarity rather than identity, one tenant’s query vector can land close enough to another tenant’s vectors in the index that a loosely scoped or misconfigured filter still surfaces results it shouldn’t.

There’s a second, quieter leak path underneath the filter-bypass problem: the embeddings themselves. Many vector databases don’t encrypt vectors at rest by default, and research on embedding inversion has shown that raw vectors can be reconstructed into text approximating the original content. If an attacker gets network access to the index or a stolen API token, they don’t need to bypass a filter at all — they can dump the index and run inversion offline, tenant boundaries notwithstanding (Multi-Tenant Security and Data Isolation for AI Databases, The AI Database Blog, 2026).

Who is affected

Any team building a SaaS product with per-customer RAG or semantic search on a shared vector store is exposed, and the exposure scales with customer count and data sensitivity. This hits data engineering and platform teams hardest, because they typically own the vector database and the ingestion pipeline that assigns tenant identifiers, but frequently don’t own the API layer that constructs the filter at query time — which means the two teams responsible for the two halves of tenant isolation often aren’t in the same room when the architecture gets decided.

Security and compliance teams are affected in a way that’s easy to underweight during a standard vendor security review: a vector database can pass a conventional network and access-control audit while still having no real tenant isolation, because the isolation logic lives in application code that the audit didn’t examine. This is a particular problem for regulated industries — healthcare, financial services, legal — where a cross-tenant leak of even a few documents is a reportable incident, not just an embarrassing bug. CTOs and heads of engineering at any multi-tenant SaaS company with an AI feature roadmap are ultimately accountable, because the decision to share a single vector index across tenants is usually made early, for cost and simplicity reasons, well before anyone models what a leak actually costs.

When this becomes a real problem

This is an active architectural gap today, not a speculative future risk. The pattern of relying on metadata filters as the sole isolation mechanism is the default in most RAG tutorials, starter templates, and early-stage SaaS builds shipping right now in 2026, which means the exposure is already baked into a large and growing number of production systems. Vendors have started responding: current comparisons of pgvector, Pinecone, and Qdrant show meaningfully different maturity levels, with Pinecone’s namespace model and Qdrant’s per-tenant collection pattern offering stronger isolation than a bare metadata filter, and pgvector able to lean on Postgres row-level security for smaller tenant counts.

The realistic timeline splits into two tracks. For companies already running shared-index multi-tenant RAG in production, this is a present-tense risk that scales with every new customer onboarded onto the shared index — the blast radius grows continuously, not at some future inflection point. For the industry as a whole, expect this to follow the same maturity curve API and object-storage access control did a decade ago: isolation-by-default architecture (dedicated collections, enforced server-side scoping, encrypted-at-rest vectors) becoming a baseline expectation and eventually a compliance checkbox over the next one to two years, driven by the first well-publicized cross-tenant RAG leak rather than by proactive adoption.

How this manifests in a real database environment

Picture a B2B SaaS platform offering an AI assistant that answers questions from each customer’s uploaded documents. To keep infrastructure costs down, engineering puts every customer’s document chunks into one Pinecone index or one pgvector table, tagging each row with a customer_id. The application layer is supposed to pass that ID into every query as a filter. Under normal operation, this works fine — until one of a few things happens.

First, the trivial case: a bug or a rushed feature ships a code path where the filter is optional or defaults to unscoped when the parameter is missing, and a query silently searches the entire index across all customers. This is not exotic; it’s the vector-database equivalent of a missing WHERE clause, and it’s exactly as easy to introduce.

Second, the adversarial case: if the tenant identifier is derived from something the client can influence — a request parameter, a JWT claim that isn’t properly validated server-side, or a GraphQL query the API layer trusts too much — an attacker can substitute another tenant’s ID and retrieve their documents directly through the normal application flow, no database compromise required.

Third, the subtle case that doesn’t require any bug at all: two tenants happen to store conceptually similar content (common in verticals like legal, healthcare, or customer support, where document types recur across customers), their embeddings cluster near each other in vector space, and a filter that’s technically present but loosely scoped — say, scoped at an organization level when it should be scoped per workspace — surfaces cross-boundary results that look plausible enough that nobody questions the answer.

In all three cases, the database did exactly what it was asked to do: return the nearest vectors to a query. Nothing about the retrieval itself signals a violation, which is why these leaks are so often discovered by a customer noticing unfamiliar content in an AI answer rather than by any internal monitoring.

Actions to take now

  1. Audit how your tenant filter is actually constructed and enforced, end to end. Confirm the tenant ID used in every vector query is derived server-side from an authenticated session, never from a client-supplied parameter, and that there is no code path where the filter is optional or silently skipped.
  2. Move isolation from “filter after search” to “scope before search.” Prefer database features that scope the search itself — Pinecone namespaces, Qdrant per-tenant collections, or Postgres row-level security with pgvector — over a bare metadata filter applied to a shared, unscoped index.
  3. For your highest-sensitivity tenants or verticals, use the silo pattern: a dedicated index, collection, or database per tenant rather than a shared one. This costs more operationally, but for regulated data it removes the entire class of cross-tenant leak risk rather than mitigating it.
  4. Encrypt vectors at rest and enforce per-tenant authorization at the query layer, not just at the application’s outer API boundary. Treat the vector index itself as a data store that needs its own access controls, not a cache that inherits security from the app in front of it.
  5. Add monitoring for anomalous retrieval patterns — queries that return results spanning multiple tenant identifiers, or a spike in results from a tenant that hasn’t been active, are detectable signals most teams currently don’t instrument at all.
  6. Run a red-team exercise specifically against your tenant filter, treating the tenant ID as an attacker-controlled input even if you believe it isn’t. Try substituting IDs, omitting the filter, and querying with intentionally broad or adjacent content from a different tenant’s domain to see what comes back.
  7. Rotate API keys and credentials for managed vector services on a fixed schedule and immediately on offboarding, and put the vector database behind private networking rather than a public endpoint reachable with just an API key.
  8. Revisit the shared-index decision as customer count and data sensitivity grow. What was a reasonable cost tradeoff at ten customers may not be at a thousand, particularly once any customer in a regulated industry is on the platform — build a plan for migrating to per-tenant isolation before you need it under incident-response time pressure.

Key takeaways

  • Most multi-tenant RAG systems isolate tenants with an application-level metadata filter, not a database-enforced access control model — a filter bug or bypass leaks data with no database compromise required.
  • Embeddings themselves are a leak path independent of the filter: unencrypted vectors can be reconstructed toward their original content through inversion techniques if an attacker gets index or credential access.
  • pgvector, Pinecone, and Qdrant each offer stronger native isolation primitives (row-level security, namespaces, per-tenant collections) than a bare metadata filter, but none of these are the default a team reaches for without deliberate design.
  • The risk is present-tense and scales with tenant count, not a future or theoretical concern — it’s baked into the default architecture of most RAG starter templates shipping today.
  • For regulated or high-sensitivity data, the dedicated-index silo pattern removes this risk class entirely; for everything else, scoping search before retrieval and monitoring for anomalous cross-tenant results are the practical middle ground.

Data Platform Advisory helps teams design vector database architecture that treats tenant isolation as a database problem, not an app-layer afterthought. Get in touch if you’re not sure how your multi-tenant AI feature is actually isolated.

Ivan Lima is a data engineer specializing in database modernization for AI systems. Get in touch if your database needs to be ready for what’s next.