Implementation guide
OWASP AISVS v1.01
Access Control & Identity for AI Components & Users · Multi-Tenant Isolation
Tenants can't affect each other's models
Verify that shared model serving infrastructure prevents one tenant's fine-tuning, inference, or embedding operations from influencing or observing another tenant's operations.
OWASP AISVS v1.01, requirement 5.3.1
In plain English
If several customers share your model-serving platform, one customer's fine-tuning, prompts or embeddings must neither affect nor reveal anything about another's. Shared caches and shared models are where this usually goes wrong.
What good looks like
- Fine-tunes, adapters, caches, memory and vector data are separated per tenant.
- Every request carries a verified tenant identity, and each layer enforces it.
- One tenant's data is never used to train or tune a model another tenant uses, unless both have agreed.
- Tests actively try to read or influence another tenant's data and fail.
How teams usually do it
- The tenant identifier built into storage keys, cache keys and index names by the platform, so application code cannot leave it out.
- A separate adapter or fine-tune per tenant, loaded only for that tenant's requests.
- Per-tenant rate limits and quotas so one tenant cannot starve the others.
Suggested evidence
- The isolation design.
- Cross-tenant test results.
- Cache and index configuration showing tenant scoping.
Common mistakes
- A shared prompt or response cache keyed on prompt text alone, which can return one tenant's answer to another.
- Prompt caching shared across tenants, where response timing reveals what someone else has asked.
- Pooling every tenant's feedback into one fine-tune.
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.