Disclosure: BlueBear is a multi-tenant AI platform and therefore has a commercial interest here — we are one of the vendors these questions are aimed at. They are written to be asked of us. Where we give an example of a good answer it is our own implementation, quoted as such.
The short answer: the word tells you almost nothing, so ask for demonstrations
"Multi-tenant" is true of arrangements as different as separate infrastructure per customer and a single shared table with a customer column. Every one of those is honestly described by the word, and they have completely different failure modes. So the term cannot discriminate, and a questionnaire built on it will not either.
Four questions do discriminate, and each has a demonstration attached rather than an assurance.
| Question | The demonstration | What a weak answer sounds like |
|---|---|---|
| 1. Where is the boundary resolved from? | Send an authenticated request naming a boundary the credential does not own | "The request includes the tenant identifier" |
| 2. What enforces the read path? | Ask what happens if a query omits the filter | "The application always filters by tenant" |
| 3. What can a machine credential do across boundaries? | Ask for the mechanism, not the policy | "Our keys are scoped to a tenant" with no enforcement described |
| 4. What does one mistake reach? | Ask them to walk one specific failure through | Any answer that starts with "that could not happen" |
This is the buyer-facing counterpart to multi-tenant AI agent isolation on Kubernetes, which covers the runtime engineering. Nothing here requires you to be technical.
1. Where is the boundary resolved from?
The rule, stated so you can quote it: a request that can nominate its own tenant is a request that can nominate someone else's. The boundary must come from the credential presented, not from a field the caller controls.
The demonstration takes ten minutes. Send an authenticated request that names a boundary the credential does not own, and see what comes back. This is the only one of the four that, if it fails, makes the other three irrelevant.
An adequate answer describes the mechanism. Ours, for example: the boundary is resolved from the credential at admission, and where a lookup accepts an identifier it is keyed on the identifier together with the tenant, so a wrong-tenant lookup finds nothing rather than finding a row and relying on a later check.
2. What enforces the read path?
"The application filters by tenant" is the most common answer and the weakest, because it means the isolation is a convention that holds until someone adds a query in a hurry — and nothing fails loudly when they do.
Better answers involve structure rather than discipline: compound uniqueness constraints that include the tenant, foreign keys that cascade so a boundary's records cannot be orphaned into a shared pool, and a test that fails when a read path is added without the filter.
Two read paths are worth asking about by name because they are routinely overlooked even by teams who have thought about the main ones:
- Retrieval. Document and vector search frequently sits beside the main data model rather than inside it, and a similarity query has no natural tenant clause. Ask specifically how retrieval is scoped.
- Caches and memory. A cache keyed on content rather than on content plus boundary will serve one customer's result to another. This is a quiet, plausible bug, and it is worth asking about explicitly.
3. What can a machine credential do across boundaries?
The only good answer is "nothing", supported by a mechanism rather than a policy.
The specific risk is a key that can create keys, or a key that can act on behalf of a different boundary. Either turns one compromised credential into access to everything. In our gateway an API key cannot manage keys at all — the attempt returns a specific error rather than a generic denial — and creating a key for another boundary requires a human platform administrator session, which a machine credential structurally cannot hold. The audit event for key creation carries an explicit flag recording whether the action crossed a boundary.
You do not need that exact design. What you need is an answer at that level of specificity, because "our keys are scoped" describes an intention and not an enforcement.
4. What does one mistake reach?
Blast radius — how far the damage from a single mistake or a single compromised credential can reach — is the question that turns an abstract discussion into a risk assessment.
Ask the vendor to walk one specific failure through end to end: a leaked customer key, a query deployed without a filter, an agent given the wrong connection. What is reachable, how would it be detected, how long would containment take, and could the affected customers be identified.
Any answer beginning "that could not happen" is the answer to worry about. A vendor who has thought about isolation has thought about how it fails, and will describe the containment rather than deny the possibility.
Two things that are not the same as isolation
Separate storage is not the property that protects you. A separate database per customer with a service layer that trusts a value from the request is weaker than a shared database with structural constraints and a request-scoped boundary. Storage separation is easy to point at in a diagram, which is exactly why it gets pointed at.
Certification is not verification. An audited control framework establishes that a process exists and was tested, which is real and answers a different question. It does not tell you where the boundary is resolved from. Treat certification as a gate on the vendor as a company and these four questions as the gate on the product.
If you operate in a regulated industry
Add a fifth question: can records be exported for one boundary alone? This is where a shared evidence store with a filter shows its limits, and it is usually asked of you before it is asked of your vendor. The audit trail requirements list covers the record shape, and audit trails for financial services covers what a review expects.
If you are a platform or engineering lead
Question 2 is where to spend your own effort, and the deliverable is a failing test rather than a code review convention. Isolation decays through ordinary work by people who were not present at the design discussion, which means only an automated guard preserves it. Workspace boundary access control covers the enforcement points.
If you resell this to customers
Your customers will ask you these four, so the efficient move is to collect your vendor's answers in a form you can pass on. That also surfaces where you are relying on an assurance you cannot evidence, which is better discovered now. White-label brand workspaces explained covers the reseller obligations, and security posture evidence for buyers covers the artefacts to gather.
Do this next
Ask question 1 of whichever vendor is furthest along, and ask for the demonstration rather than the answer. It is a ten-minute test that settles the single most consequential property, and the way it is received tells you as much as the result. Then read what a secure workspace boundary is for the model, or the security evaluation checklist for the wider review.
Questions people actually search for
- what does multi-tenant mean for an ai platform
That several customers share the same software, and almost nothing beyond that - which is why the word is nearly useless in an evaluation. The arrangements it covers run from separate infrastructure per customer, through a shared application with separate databases, to a shared table with a customer column. All three are honestly described as multi-tenant and they have very different failure modes. The useful question is not whether the platform is multi-tenant but where the boundary is enforced and what one mistake costs.
- how do you verify tenant isolation in a saas platform
Four demonstrations rather than four answers. Send an authenticated request naming a boundary the credential does not own and confirm it fails. Ask what happens if a read query omits the tenant filter. Ask them to revoke one customer while you time it. And ask for an export of one customer complete records. Each of these either works in front of you or does not, which is why they discriminate where a questionnaire does not.
- is a shared database safe for multi-tenant ai
It can be, and the deciding factor is where the boundary is enforced rather than how the storage is arranged. A shared database with compound keys that include the tenant, cascading ownership, a request-scoped boundary and a test that fails when a read path omits the filter is defensible. A separate database per customer with a service layer that trusts a value from the request is not. Storage separation is easy to point at and is not the property that protects you.
- what questions should I ask about ai platform isolation
Where is the tenant resolved from - the credential or the request. What enforces the filter on read paths - a structure or a convention. What can a machine credential do across boundaries - and the only good answer is nothing, with a mechanism. And what does one mistake reach - the blast radius, meaning how far a single bad query or a single leaked key can get. The first and third are the ones that most often produce an uncomfortable pause.
- can one customer see another customer data in an ai platform
Not if the boundary is a property of the request and read paths are structurally filtered - and the honest answer from any vendor should describe the mechanism rather than simply saying no. Two specific paths are worth asking about because they are easy to overlook: retrieval, where a document search can reach across boundaries even when the primary records do not, and shared caches or memory keyed on content rather than on content plus boundary.