INF-015 Multi-Tenant and Workload Isolation
Description
Tenant data and workloads are isolated at the compute, memory, storage and data layers. Both the boundary and the mechanism that enforces it are documented. Management and security functions run in execution domains separate from user functions. Each executing system process holds its own execution domain. Shared resources, including memory, temporary storage, caches and object storage paths, are cleared before reuse so that no residual data passes between tenants or between workloads. Cross-tenant isolation is tested at defined intervals, including attempts to reach another tenant's data through a shared component, with the results recorded. A vector index or embedding store built from tenant or corpus content sits inside the same boundary. Each entry records the source it was derived from, the time it was ingested, the trust tier of that source and the version of the pipeline that produced it, and content of different trust tiers is held in separate indexes rather than distinguished by a field on a shared one. An entry is removed within a defined window of its source being deleted, with a reconciliation showing the removal happened. A change of embedding model is applied to the whole corpus rather than leaving generations mixed in one index.
Rationale
Cross-tenant data leakage is the failure a multi-tenant provider cannot recover from and the first question on an enterprise security questionnaire, yet the library stated it nowhere: INF-004 isolates networks and stops at the network layer. INF-004 keeps that layer and is the segmentation evidence; INF-015 holds the layers above it. DAT-001 holds the classification scheme that sets handling requirements and DAT-008 holds retention and deletion of tenant data; neither says that one tenant cannot read another's. Enforcement is normally a tenant identifier applied at the data access layer or a separate store per tenant, with hypervisor or container separation for compute. The testable part is the residue: a shared cache, a temporary file or a reused object storage path is where isolation usually fails. A vector index is a derived store, and the residue problem applies to it in a shape the primary store does not have: an embedding outlives its source document unless something removes it, and a tag on a shared index is a setting somebody can get wrong where a separate index is not. DAT-008 holds the retention schedule and the deletion of the source; INF-015 holds the derived copy following it. The state an agent writes for itself at run time between tasks, its validation, provenance, expiry and rollback, is AIG-056; this control holds the tenant boundary and the vector index built from ingested corpus content.
Applicability (9 profiles)
Tenant isolation exists because the product is cloud-hosted and shared.
Condition: deployment_model in on-prem, hybrid, edge, on-device, embedded, air-gapped
Where the deployer runs the AI system on infrastructure it controls, isolation between its own tenants, environments and workloads is its own and INF-004 covers the boundary. Under cloud-saas or cloud-single-tenant the row is satisfied by the provider: the isolation statement and the cross-tenant test summary are obtained under VND-004.
Condition: deployment_model in cloud-saas, cloud-single-tenant
Tenant isolation exists because the product is cloud-hosted and shared. Conditional since 1.1: the profile lists every deployment model and this row is a commitment of a hosted service, so a provider that publishes weights or runs on infrastructure the customer controls has no hosted service to carry it (ADR-046 amendment, 2026-09-16).
Tenant isolation exists because the product is cloud-hosted and shared.
Condition: deployment_model in on-prem, hybrid, edge, on-device, embedded, air-gapped
Where the deployer runs the AI system on infrastructure it controls, isolation between its own tenants, environments and workloads is its own and INF-004 covers the boundary. Under cloud-saas or cloud-single-tenant the row is satisfied by the provider: the isolation statement and the cross-tenant test summary are obtained under VND-004.
Tenant isolation exists because the product is cloud-hosted and shared.
Tenant isolation exists because the product is cloud-hosted and shared.
Tenant isolation exists because the product is cloud-hosted and shared.
Tenant isolation exists because the product is cloud-hosted and shared.
Framework Mappings (13)
| AIS-14 | AI Cache Protection | partial |
| HIPAA-164.310.d.2.ii | Media Re-use | informative |
| AML.M0032 | Segmentation of AI Agent Components | informative |
| NIS2-CIR-6.8 | Network Segmentation | informative |
| SC-2 | Separation of System and User Functionality | full |
| SC-3 | Security Function Isolation | full |
| SC-39 | Process Isolation | full |
| SC-4 | Information in Shared System Resources | full |
| SC-49 | Hardware-enforced Separation and Policy Enforcement | informative |
| SC-50 | Software-enforced Separation and Policy Enforcement | full |
| SI-16 | Memory Protection | partial |
| ASI06 | Memory & Context Poisoning | informative |
| LLM09 | Vector and Embedding Weaknesses | partial |
Evidence (3)
Isolation configuration for the tenant boundary: per-tenant accounts, projects, namespaces or schemas, the data-layer policy that scopes every query to a tenant identifier and the runtime settings that give each workload its own execution domain. Where a vector index or embedding store is in use, the export also carries its tenant and trust-tier scoping and the provenance fields held on each entry.
Example: Infrastructure-as-code export showing one namespace and one database schema per tenant with row-level security policies enabled, plus the container runtime profile applied to application workloads, generated 2026-08-14.
Test: Export the tenant isolation configuration from the platform or its infrastructure code. Verify: (1) the isolation boundary described in the architecture record is the one the configuration implements, (2) data-layer access is scoped by a tenant identifier enforced by the platform rather than by application code alone, (3) each workload runs in its own execution domain with no shared writable filesystem path between tenants, (4) administrative and management interfaces are served from a separate execution domain from tenant-facing interfaces. (5) a vector index or embedding store scopes every query by tenant on the server rather than on a value the caller supplies, holds content of different trust tiers in separate indexes, and carries the source, the ingestion time, the trust tier and the pipeline version on each entry.
Results of the cross-tenant isolation test suite, showing the attempted paths between tenants and the outcome of each attempt.
Example: Isolation test suite run from the CI pipeline, 2026-08-20, covering direct object reference, cache key collision, search index and export path cases, with each case asserting a denial.
Test: Obtain the most recent isolation test run and the suite definition. Verify: (1) the suite includes at least one case per isolated layer named in the architecture record, (2) each case asserts a denial rather than recording a response, (3) the run is within the defined testing interval, (4) any failed case has a tracked remediation record, (5) the suite covers shared components such as caches, search indexes and export paths, not only the primary data store. (6) deleting a source document removes the entries derived from it within the defined window, shown by a reconciliation rather than asserted.
Architecture record naming the isolation boundary at each layer, the mechanism that enforces it and the shared components that are scrubbed between uses.
Example: Tenant Isolation Architecture record v3.1, approved 2026-06-02, with a table of compute, memory, storage and data-layer boundaries and the enforcement mechanism for each.
Test: Request the tenant isolation architecture record. Verify: (1) each of the compute, memory, storage and data layers has a stated boundary and a named enforcement mechanism, (2) every shared component that holds tenant data in transit is listed with its scrubbing or re-keying behaviour, (3) the record names the separation between management and user functions, (4) the record was reviewed within the defined interval and matches the deployed configuration on a sampled service.
Questions (3)
Is tenant data isolated so that one tenant cannot read another tenant's data?
Answer yes only where a mechanism enforces the boundary. An application convention that every query includes a tenant identifier is not enforcement; a platform that refuses the query without one is.
At which layers is isolation between tenants or between workloads enforced?
Isolation usually fails at a layer nobody drew: a shared cache, a search index, an export path or a vector index built from several tenants' documents. Count a layer only where the enforcement is in the platform rather than in the calling code.
How is cross-tenant access tested?
Options run from strongest to weakest. A design review records an intention; a test that asserts a denial records the current behaviour of the deployed system.