Access Control & Identity for AI Components & Users · Multi-Tenant Isolation
Tenants can't observe each other's compute
Verify that one tenant cannot influence or observe another tenant's operations through shared compute resources. Satisfying this requirement typically requires hardware partitioning, confidential computing, or dedicated per-tenant compute allocation.
OWASP AISVS v1.01, requirement 5.3.2
In plain English
Stop tenants affecting or observing each other through shared hardware. Software isolation is not enough on shared GPUs. Meeting this normally takes partitioned hardware, confidential computing or dedicated machines per tenant. It is a Level 3 control.
What good looks like
- Tenants share a GPU only with hardware partitioning, and otherwise get dedicated devices.
- The design considers side channels: leftover memory, timing, and shared caches on the inference server.
- The approach for each tenant tier is documented, with the reasoning.
- GPU memory is cleared between tenants (see 4.2.4).
How teams usually do it
- Dedicated instances or nodes for high-risk tenants.
- GPU hardware partitioning (for example NVIDIA MIG) or confidential computing for shared pools.
- No cross-tenant request batching, and no shared KV cache, where the threat model includes a hostile tenant.
Suggested evidence
- The compute allocation design per tenant tier.
- Scheduler configuration enforcing it.
- Results of any side-channel or leftover-memory testing.
Common mistakes
- Assuming container isolation is enough on a shared GPU.
- Batching different tenants' requests together for throughput without considering what that can leak.
Not sure which requirements apply to your system? Take the assessment, or browse every guide in this chapter.
Requirement text from the OWASP AI Security Verification Standard, licensed under CC BY-SA 4.0. This guidance is shared under the same licence.