Tenant isolation for AI features: what enterprise buyers ask

Tenant isolation AI SaaS questions now appear in every enterprise security questionnaire that mentions AI. The buyer wants to know two things: can one customer's data ever reach another customer's answers, and does anyone train a model on their data. The correct answers are no and no, and the vendor must be able to show how. This article lists the questions buyers ask, the architecture that lets you answer them honestly, the evidence they expect, and the mistakes that fail a review.

Why AI features reopen the isolation question

Most SaaS products settled tenant isolation years ago at the database layer: a tenant column, row-level security, or a schema per tenant. AI features add new paths for data to move that the original design never covered. Documents are chunked and embedded into a vector index. Prompts are assembled from records and sent to a model provider. Responses are cached. Traces are logged for debugging and evaluation. Each of these is a place where one tenant's content can leak into another's context unless the tenant boundary is carried through explicitly. The SaaS industry page describes how we approach these builds.

The questions buyers ask and the answers they expect

Isolating retrieval

Retrieval is the highest-risk path. A shared vector index that relies on a metadata filter in the query is acceptable only if the filter is applied by the data layer on every query without exception, and cannot be omitted by a caller. Stronger options are a namespace or collection per tenant, or a separate index per enterprise tenant. The choice depends on tenant count and size; a product with thousands of small tenants uses namespaces, while a product with a few large enterprise tenants can afford an index each.

Whatever the index design, retrieval must also respect user permissions inside the tenant. An enterprise buyer will ask whether a junior user can retrieve a document their role could not open. The answer must be no, enforced at retrieval time from the same permission model the product already uses. We described this in permission-aware retrieval.

Isolating prompts and context

Prompt assembly is where subtle leaks happen. Few-shot examples drawn from real customer data, a shared conversation memory, or a system prompt that includes account-specific instructions can all move content across tenants if they are not scoped. The rule is that everything placed in a prompt is either static and reviewed, or fetched for this tenant and this user at request time. Prompt templates are versioned and tested; tenant content is never baked into them. Our post on multi-tenant LLM architecture for SaaS sets out the request pipeline.

The training question

"Do you train on our data?" has two halves. The first is about model providers: the major APIs offer business terms under which prompts and completions are not used for training and are retained only briefly for abuse monitoring, and some offer zero-retention arrangements. You must be on those terms, be able to show the documentation, and list each provider as a sub-processor. Anthropic's commercial terms and data-usage documentation and equivalent pages from other providers are what buyers will ask you to cite.

The second half is about you. If you fine-tune models, build evaluation sets or improve prompts from customer traffic, say so, say how, and get consent per tenant. Evaluation sets built from anonymised, tenant-consented examples are normal practice; silently using one customer's tickets to improve another customer's answers is not. Model-agnostic routing helps here, because you can route an enterprise tenant to a provider or a private deployment that meets their specific terms without changing the product.

Logs, traces and caches

Observability tools capture prompts and responses, which means they hold customer data. Traces must carry tenant identity, be retained for a stated period, and be visible only to engineers with a reason to see them. Enterprise buyers increasingly ask for the retention period in days and for the ability to request deletion. Caches are the quiet risk: a response cache keyed on the prompt text alone will serve one tenant's answer to another tenant who asks the same question. Include tenant identity in every cache key or disable caching for tenant-specific content.

SaaS AI compliance: the evidence pack

Questionnaires are easier when the evidence exists before the question. A short pack answers most of them.

• A data-flow diagram showing every path customer content takes through AI features, with the tenant boundary marked
• A sub-processor list naming each model provider, its region and its data terms
• The retrieval isolation design and an automated test that proves cross-tenant queries return nothing
• The trace retention policy with the period in days and the deletion process
• The per-tenant AI opt-out and how it is enforced server-side
• A statement on training, covering providers and your own use of customer data
• The private or regional deployment option for tenants that need it

Most of this maps directly onto existing controls in frameworks such as ISO 27001 and SOC 2, and onto the AI-specific guidance in the NIST AI Risk Management Framework, which buyers are beginning to reference. Our security page describes how we handle these controls in client builds.

Private deployment for the tenants that need it

Some enterprise buyers, particularly in banking, healthcare and government, will not accept any shared model provider. The answer is a private or self-hosted deployment for that tenant: open-weight models on infrastructure in their region or their cloud account, with the same product code routing to it. Building the product model-agnostic from the start makes this a configuration change rather than a fork. The private agentic AI service covers this pattern.

A worked example

A field-service B2B SaaS added an in-app copilot and immediately received AI questions from its largest enterprise prospect's security team. The copilot's retrieval used a shared index with a tenant filter applied in application code, traces were in a shared observability tool with no tenant field, and the model provider account was on consumer terms.

The remediation was not a rewrite. Retrieval moved to a namespace per tenant with the filter enforced in the data layer and covered by an automated test. Traces gained a tenant field and a retention period. The provider account moved to business terms with training opt-out, and a per-tenant AI switch was added to the admin settings. The evidence pack above was written once and answered the next several questionnaires with minor edits.

Team and timeline

Making an existing AI feature enterprise-ready is typically a three-week engagement: an AI engineer for retrieval and prompt isolation, a backend engineer for tracing, caching and the opt-out switch, and a security-minded lead who writes the evidence pack with your compliance owner. This fits the ProofRun programme at $6,250–10,500 or from ₹4,00,000. Building isolation in from the start is part of the retrieval and knowledge engineering service from $14,000 or ₹8.8L, and a private deployment for a specific tenant starts at $31,500 or ₹20.8L plus infrastructure; see the pricing page for programmes and Care Plans.

Before you start: a checklist

• Map every path customer content takes through AI features
• Decide the retrieval isolation model: filter, namespace or index per tenant
• Confirm provider accounts are on business terms with training opt-out
• Add tenant identity to traces and cache keys
• Set and document trace retention in days
• Build the per-tenant AI opt-out and enforce it server-side
• Write the automated cross-tenant retrieval test
• Draft the evidence pack before the next questionnaire arrives

Glossary

• Tenant: one customer organisation within a multi-tenant SaaS product
• Namespace: a partition within a vector index that scopes queries to one tenant
• Sub-processor: a third party that processes customer data on your behalf, such as a model provider
• Zero retention: a provider arrangement under which prompts and responses are not stored after the request
• Trace: the recorded prompt, retrieved context, response and metadata for one AI request
• Permission-aware retrieval: retrieval that returns only records the requesting user could open directly

Related reading

See SSO, RBAC and audit logs: enterprise-ready SaaS from the start, row-level security for AI analytics and multi-tenant SaaS architecture for the surrounding controls.

Carry the tenant boundary through every index, prompt, cache and trace, put providers on the right terms, and the questionnaire becomes a formality.