Tenant and session isolation

What it does

It keeps one party's data out of another's session by construction, in each place where an AI system holds state. The standard to meet is that no instruction, error or optimisation can cause the boundary to be crossed. Engineering owns it; the system owner is accountable for separation. It is designed in and re-tested at every change that adds or alters a stateful component.

How to implement it

• List every component that retains anything between requests.
• Include user and tenant identity in every cache key and memory key.
• Use separate indexes, or enforced filters, per tenant for retrieval.
• Do not share fine-tuned weights between customers unless the training data may be shared.
• Enforce separation in code and infrastructure, never by instruction to the model.
• Test with paired accounts that attempt to obtain each other's data.

Evidence it operates

Design: an inventory of stateful components with the isolation mechanism for each. Operation: cross-tenant test results for each release; configuration showing identity in cache and memory keys; no shared model serving customers whose data was used to tune it.

Where it fits

Built at design and verified before each release. It is the primary control for cross-tenant and cross-session leakage and supports vector store access controls and agent memory controls.

Limits

Isolation is defeated by the one component nobody listed, typically a cache added later for performance. It does not address disclosure within a tenant to users with differing rights, which needs permission-aware retrieval. Suppliers' components need the same scrutiny: a hosted model or vector database that caches across customers undoes isolation built above it.