Tenant isolation is the set of guarantees that one brand's design data cannot influence another brand's output. In a fashion AI platform that is harder than in ordinary SaaS, because the data is the customer's differentiator — blocks, fits, graded pattern libraries, colourways — and because the inference path gives data far more places to rest than the request path. You do not pick an isolation level once for the platform; you pick one per layer, and you must be able to name the layer where you compromised.
Key takeaways
- Isolation is a per-layer decision: storage, retrieval, model weights, caches and telemetry each need their own answer.
- A shared vector index with a tenant filter is a query-time control; an index per tenant is a structural one, and only the second survives a bug in the filter.
- Fine-tuning on pooled customer data is effectively irreversible, because you cannot delete one tenant's contribution from a weight matrix without retraining.
- Per-tenant adapters over a shared base model give brand-specific behaviour without brand-specific serving cost.
- The leaks that reach production are rarely in the primary database; they are in caches, prompt logs, evaluation sets and support tooling.
What does tenant isolation actually mean here?
Three separate claims get bundled under one word, and enterprise buyers ask about them separately.
- Data isolation. Tenant A's rows, files and embeddings are never returned to tenant B, under any query, including a malformed one.
- Compute isolation. Tenant A's workload cannot read tenant B's memory, temporary files or accelerator state, and cannot starve it.
- Learning isolation. Nothing tenant A uploads changes what the system generates for tenant B.
The third is specific to AI platforms and most often left implicit. A pattern archive is a house style: block shapes, ease conventions, the way a particular brand grades a shoulder. Train one model across several archives and its most valuable capability — reproducing a house style — becomes the channel through which it leaks. Our piece on garment geometry as model input covers why that archive is more than a folder of outlines.
Which layers leak, and which do you close first?
Walk the request path and enumerate every place tenant data comes to rest:
- Primary store. Patterns, tech packs, imagery, cost data.
- Search and retrieval. Vector indexes, keyword indexes, materialised views.
- Model weights. Base model, fine-tunes, adapters.
- Runtime state. Prompt and response caches, embedding caches, queue payloads, temporary files on the inference host.
- Observability. Traces, prompt logs, error payloads, replay tooling.
- Offline. Evaluation datasets, reference examples, human-review queues, training snapshots.
Teams design the first two carefully and inherit the rest. Almost every isolation postmortem lands in the last three, which were built for engineers rather than tenants.
Database per tenant, or shared schema with a tenant key?
The storage options and their retrieval and model equivalents form one ladder:
| Approach | What it separates | Cost and failure mode |
|---|---|---|
| Shared schema, tenant column | Nothing structurally; separation is a query predicate | Cheapest; one missing filter clause is a cross-tenant read |
| Shared schema, row-level security | Enforcement moves into the database | One blast radius still; policy gaps and admin paths are the risk |
| Schema per tenant | Objects and grants | Migrations multiply; connection pooling gets awkward |
| Database or cluster per tenant | Storage, credentials, backups, restore path | Highest operating cost; onboarding a small brand is a project |
| Shared vector index, metadata filter | Nothing; separation is an argument | A dropped filter silently returns another brand's neighbours |
| Index or namespace per tenant | The embedding space itself | More indexes to build and keep warm; sparse recall for small tenants |
| Shared base model, adapter per tenant | Learned brand-specific behaviour | Adapter routing becomes security-critical code |
| Fine-tuned model per tenant | Weights, and therefore learning | Cost per tenant; deletion means retraining |
For pattern libraries and fit data, the defensible default is a database or cluster per tenant, with shared-schema options kept for data that is genuinely yours: metering, feature flags, catalogue metadata. Once a table holds something a competitor would pay for, a predicate is not enough.
How do you isolate retrieval?
Retrieval is where these platforms actually leak, because vector search is approximate and fails silently: a filter that does not apply returns neighbours, not an error. Practical rules:
- Make the tenant an index or namespace boundary, not a payload field. If a request can address only one namespace, an omitted filter is a missing index, not a wide read.
- Derive the tenant from the authenticated principal at the edge, never from a request body, tool argument or model output.
- Keep embeddings tenant-scoped even when the embedding model is shared. The model can be common; the vectors cannot.
- Put the tenant in every cache key. A cache keyed on prompt text alone will serve one brand a completion computed for another.
- Seed each tenant with a distinctive synthetic record and assert continuously that no other tenant can retrieve it. Run that canary in production.
Can each brand have its own model weights?
Three levels, increasing in isolation and in cost.
Context isolation. The base model is shared and untouched; brand specificity comes from retrieved context. Cheapest, fully reversible, and it inherits every retrieval weakness above.
Adapter per tenant. You train a small set of additional parameters on one tenant's data and load it alongside the shared base at inference. Brand behaviour is learned rather than retrieved, deletion is a file deletion, and no gradient update sees two tenants' archives together. The cost moves into routing: loading the wrong adapter is a cross-tenant inference, so adapter selection deserves the scrutiny you give authorisation.
Fine-tune per tenant. Maximum isolation of learning, maximum cost, deletion that is trivial in principle and expensive in practice.
The option to refuse is the pooled fine-tune across many brands' archives. It is not that it always leaks; it is that you cannot demonstrate that it does not, and you cannot undo it when a customer exercises a deletion right. Our walkthrough of how diffusion models generate fashion images is a useful companion, because image models trained on pooled data show the same entanglement.
Where do the platform vendors fit?
Most fashion AI teams buy the substrate and build the isolation themselves.
Azure OpenAI, part of Microsoft and delivered as Azure OpenAI in Foundry Models, offers cloud-hosted foundation models with fine-tuning, agent orchestration, content moderation and enterprise security and compliance tooling, folded increasingly into Foundry. That buys a compliance boundary you can point at — not isolation inside your own product.
Databricks ships a unified data and AI platform including Lakebase, a serverless Postgres tied to the lakehouse, Genie for data-aware analytics agents and Agent Bricks for enterprise agents. The primitive that matters for a multi-brand platform is the governance catalogue: if one place can express that a given table, index and model endpoint belong to a given brand, isolation becomes auditable policy rather than convention in code.
Vibe IQ sits higher up, as an AI product creation and merchandising platform covering visual line planning, assortment building, concept generation from sketch to artwork, product definition and PLM and ERP integration, driven by autonomous agents. It shows how much brand-specific context an agent layer accumulates once it reaches planning and specs — exactly what must stay inside one tenant.
What is still unsolved?
Proving a negative. You can show a query returned nothing. You cannot easily show a generative model carries none of another tenant's style; membership-inference testing is the closest evidence available and it is not a proof.
Deletion. Deletion from storage is solved. Deletion from a learned artefact is not, unless you kept per-tenant learning separable from the start.
Shared improvement. Customers want the platform to improve without their data improving a rival's results. Aggregate-only learning is the usual answer, and it makes a weaker product than pooled training.
Cost. Full per-tenant isolation prices out small customers, so most platforms end up with tiers — and that boundary is a security boundary, which belongs in the documentation.
FAQ
What is tenant isolation in an AI SaaS platform? It is the guarantee that one customer's data cannot reach another — not through queries, not through caches, not through model behaviour. The third form matters most, because training on pooled data can leak a customer's style without exposing a single record.
Is a database per tenant necessary for fashion AI? For design assets, usually yes: pattern libraries and fits are the customer's competitive advantage, and separate credentials, backups and restore paths are easier to defend than a query predicate. Shared schemas stay reasonable for metering and configuration.
Can you fine-tune one model on several brands' data safely? You cannot demonstrate that you did. Once several archives enter the same gradient updates, brand behaviour is entangled in shared weights and per-customer deletion means retraining. Per-tenant adapters keep learning separable.
Where do multi-tenant AI platforms usually leak? Not the primary database. Prompt and embedding caches keyed without a tenant, prompt logs in observability tools, evaluation sets assembled from real customer work, and support tooling that can impersonate any account.
Further reading
- AI-native, not AI-sprinkle: why AI is a business change, not a technology change — on rebuilding software around AI rather than bolting it on.