Multi-Tenant RAG Isolation 2026: 7 Attack Vectors and the Architecture That Closes Them

Q: Why are the seven attack vectors specific to multi-tenant RAG and not covered by generic SaaS multi-tenant security?

Generic SaaS multi-tenant security covers the data layers a non-AI SaaS product uses — relational databases with row-level security, object storage with per-tenant prefixes, application caches with tenant-scoped keys. The discipline is mature, well-documented, and supported natively by every major cloud and database. Multi-tenant RAG adds five new data surfaces that the generic discipline does not cover: the vector store (a new storage primitive whose multi-tenancy support varies per product and per version), the embedding model (a shared model whose outputs are tenant-specific data), the re-ranker (a model whose fine-tuning data and inference behaviour both have tenant-data implications), the response cache (a semantic cache whose key is the embedding of the prompt rather than a deterministic identifier), and the LLM call itself (a stateless inference but with prompt-cache and prompt-injection considerations specific to tenant content). Each of these surfaces has a tenant-isolation failure mode that does not exist in generic SaaS, and the failure modes compound — a defence at one layer does not catch a failure at another layer because the layers operate at different abstraction levels. The seven-vector taxonomy is the catalogue of these RAG-specific failures, and the architectural defence is the per-tenant namespace discipline applied consistently across all the new surfaces. The teams that approach multi-tenant RAG by extending their existing SaaS multi-tenant discipline to the RAG layers cover Vectors 1, 3, and 7 (the storage-layer and cache-layer vectors) but miss Vectors 2, 4, 5, and 6 (the embedding-space, ingestion-poisoning, re-ranker-leakage, and eval-contamination vectors); the gap is where the first incident comes from.