Tenant isolation for AI features in multi-tenant SaaS products
Prevent one customer's data from appearing in another customer's AI answers by isolating embeddings, caches, memory and fine-tuning per tenant.
This is for founders and engineering leads of B2B SaaS products adding AI search, assistants or summaries. Your main database probably enforces tenant boundaries well. AI features quietly add new places where data lives: embeddings, response caches, conversation memory, evaluation sets and customised models. If any of these is shared without strict tenant scoping, one customer may see another's contracts or tickets in an answer. This post shows where cross-tenant leaks hide in AI features and how to close each one.
A SaaS company adds an assistant that answers questions over each customer's uploaded documents. Embeddings for all customers go into one vector collection, and the application adds a tenant filter at query time. A developer later builds a new summary endpoint, forgets the filter, and a customer's assistant starts quoting pricing terms from a competitor who is also on the platform.
Other leaks are less obvious. A semantic cache returns a stored answer because two tenants asked similar questions. Agent memory saves a fact from one customer's session into a shared profile. A model customised on pooled support tickets reproduces a phrase containing another customer's name. Each was built by a careful team that simply did not treat the AI layer as part of the tenancy model.
An HR software provider serving mid-sized employers built an assistant that answered employee questions from each employer's policy documents. Early on, all embeddings lived in one shared index with a filter added in the API layer, and responses were cached by question text to save cost. A security review flagged both. The team moved to per-tenant namespaces in the vector store, rebuilt the cache key to include tenant and role, and added nightly tests with planted marker phrases for two dummy employers. After the change, the assistant behaved the same for users, the team could show enterprise buyers a clear isolation design during security questionnaires, and two new endpoints added later were caught by the tests before release.
Should every tenant have a separate vector index?
Not always. Per-tenant namespaces or enforced row-level filters in a shared index can be sufficient. Separate indexes suit customers with strict contractual or regulatory needs. What matters is that a query without tenant context returns nothing.
Are AI logs also a tenant isolation risk?
Yes. Prompt and response logs contain customer data, so scope access by tenant, restrict who can search across tenants, and apply the same retention rules you use for the source data.
How do we explain our isolation design to enterprise buyers?
Prepare a one-page diagram showing each AI data store, how tenant scope is enforced, and how you test it on each release. Buyers' security teams respond well to specific controls and evidence rather than general assurances.
Can a shared base model leak data between tenants?
A base model you did not train on customer data does not hold tenant data itself. The risk comes from what you add: retrieval, caching, memory and customisation. Isolate those layers and the base model stays neutral.
Want this fixed in your business?
Send the workflow. You get a scope and a fixed price within two working days — or a straight answer that it isn't a fit.