What is a multi-tenant AI platform?

A multi-tenant AI platform serves many tenants and keeps each tenant’s data, prompts, answers and logs out of the others’ reach. A tenant is whoever the platform keeps apart: a customer, a subsidiary, or a team inside one company.

Three neighboring ideas get mixed up with it.

• Multi-user means many people in one tenant. They share its data, under its permissions.
• Permissions decide what each person inside a tenant may open. Tenant isolation decides that nobody outside it can open anything. A platform needs both, and they fail in different ways. Our article on permission-aware retrieval covers the first.
• Single-tenant means a deployment that serves one tenant. A platform can run many of those behind one front door and still be multi-tenant as a whole.

Every multi-tenant design answers one question: which layers do the tenants share? Microsoft’s guide to tenancy models puts it plainly: “Instead of viewing isolation as a discrete property, consider it a spectrum.” Three points on that spectrum cover most platforms.

• Shared everything. One app, one cache, one database. Each row carries a tenant id, and every query filters on it. This is the cheapest to run, and the separation lives in code and database policy.
• A database per tenant. The app is shared, the data is not. The boundary is the database and its credentials. It holds when the credentials, network paths and backups are separate too.
• An instance per tenant. Each tenant gets its own copy of the application and its own data. Only the address, the operations around it and the hardware are shared.

The AWS SaaS Lens calls the ends of the range silo and pool, and the mix in between bridge. It adds that a silo still shares identity, onboarding and operations. Without them, it is a managed service running separate copies of a product.

A platform without AI keeps tenant data in a database and a file store. An AI platform keeps it in many more places, and each one needs the same boundary:

• Prompts and chat history. A question often says more than the records it is about.
• The context sent to the model. An answer built from two tenants’ records is a leak, even when nothing is stored.
• Search indexes, the keyword index and the one built for search by meaning.
• Caches of answers, of search results and of prompts on the model server.
• Tuned models. Microsoft’s guidance on AI in multitenant solutions says to treat a model as sensitive as the data it was trained on. A model tuned on one tenant’s records and served to another can repeat them.
• Logs and traces, which often hold the full prompt and the full answer.
• Agent memory and tool credentials, which outlive a single conversation.

In a shared design, isolation is a rule that every code path has to follow. OWASP’s multi-tenant security cheat sheet starts from the cost: a single bug can expose every tenant’s data. Its list of failures reads like a tour of the layers above.

• A tenant id taken from a request header without checking that the caller belongs to that tenant.
• A record fetched by its id alone, with no check of whose it is.
• A database connection returned to a pool still set to the last request’s tenant.
• A cache keyed on the question and not on who asked. The cheat sheet’s rule: “Include the tenant identifier in every cache key whose value or authorization varies by tenant.”
• Logs that mix tenants, or hold their data in plain text.

Caches can leak without any bug in the application. In a 2025 audit of language model APIs, researchers timed how fast prompts came back. A cached prompt returns faster, which can reveal what someone else asked. They report: “We detect global cache sharing across users in seven API providers, including OpenAI, resulting in potential privacy leakage about users’ prompts.”

Our paper The app is the easy part collects documented leaks of this kind, and the layer each one was missing.

Isolation is about performance too. Microsoft’s noisy neighbor antipattern describes the problem: one tenant’s heavy use slows down or breaks the system for the others. It also happens when many small tenants peak at the same hour.

AI makes the neighbors louder. One tenant re-indexes its whole archive, or runs a batch of long prompts through a shared model server. Everyone else waits for the GPU, or hits the rate limit the platform shares with its model provider.

The remedies are the ones Microsoft lists: measure use per tenant, set quotas, and give a tenant capacity of its own when it needs it. Separate instances remove most of the problem, but not all of it. Instances on one machine still share its memory and processors.

“Your data is isolated” is a claim, not an answer. Ask for the mechanism, layer by layer:

1. What is a tenant in your system: our company, or each team or customer we serve?
2. Which layers do tenants share: the app, the database, the search index, the caches, the model, the logs, the backups?
3. Where a layer is shared, what enforces the boundary: application code, a database policy, separate credentials or a separate process?
4. Are prompts, answers and traces kept per tenant, and who at your company can read them?
5. Is any model trained or tuned on our data, and is it served to anyone else?
6. What stops one tenant from slowing the others down, and what capacity is ours alone?
7. How do you test isolation, and can we see the tests?
8. When we leave, what is deleted, from where, and when?

Microsoft’s guide ends on the same point as question 7: whatever the model, test that one tenant’s data does not reach another. A vendor with a good answer will show you the test, not only the diagram.

Curiosity takes the instance per tenant end of the range. Curiosity Orchestrator gives each team, project or customer its own Curiosity Studio on hardware you control. Each Studio keeps its own data, its own users and its own settings, the model among them. In the Orchestrator documentation, each is a container with its own data volume.

What the Studios share is the front: one address, one console to manage all of them, and an optional single sign in. A Studio nobody has opened for a while goes to sleep, and the next visit wakes it. So the server is sized for the Studios in use, not for every Studio.

They also share the machine. You can cap how many run at once, and when memory runs short the Studio used least recently sleeps first. One orchestrator can manage others on more machines. The orchestrator controls Docker on the server, so treat that server as sensitive. Opened on its own subdomain, a Studio is kept apart from the others in the browser too. The security guide says when that matters.

Inside each Studio, access is synced from your source systems and checked per record at query time. Cloud deployments keep each customer in an isolated tenant, as the Trust Center lists.