Multitenant AI Application Security: Tenant Isolation

An AI feature added to a multitenant SaaS product creates new places where one customer's data can reach another: the vector index, the prompt cache, the agent's memory, the fine-tuned model and the tools an agent can call. Classic tenant isolation protects databases and APIs; it rarely covers what a model retrieves, remembers or is trained on. This guide covers tenant isolation for each AI layer, with the isolation patterns, the tenant context that must flow through every call, and the tests that prove it works. It draws on OWASP LLM08 Vector and Embedding Weaknesses, Microsoft's guidance on AI in multitenant solutions, AWS's multi-tenant RAG and multi-tenant agent patterns, and Azure OpenAI's prompt caching documentation. It is for SaaS architects, AI platform engineers and security reviewers. For general tenancy models and data isolation, see the Multi-Tenant SaaS Architecture Security Guide; this page covers the AI-specific layers only.

Key takeaways

Tenant context must come from the token, never the prompt. Every retrieval, memory read, tool call and log line should carry a tenant ID taken from a verified credential, because anything in the prompt can be changed by an attacker or by injected content.
Choose an isolation pattern per AI layer. AWS's silo, bridge and pool patterns for RAG trade cost against isolation; per-tenant encryption keys and performance isolation come only with silo.
Models trained on tenant data are tenant data. Microsoft advises treating a model with similar sensitivity to the data used to train it, and getting tenant agreement before training shared models on their data.
Agents multiply the paths across tenants. Tools, memory and credentials must be scoped per tenant, and delegated tokens should record both agent and caller, as AWS recommends for multi-tenant agents.
Prove isolation with cross-tenant tests. Seed canary data in one tenant and try to retrieve it from another through every AI path, on every release.

Where AI breaks tenant isolation

OWASP LLM08:2025 names the core risk: in multi-tenant environments where multiple classes of users or applications share the same vector database, embeddings from one group can be retrieved in response to another group's queries. The same pattern repeats at every AI layer.

Layer	How cross-tenant leakage happens	Primary control	OWASP
Retrieval (vector store)	Shared index without a server-side tenant filter; filter taken from request input	Per-tenant index or enforced metadata filter from token claims	LLM08
Prompt assembly	System prompt or few-shot examples containing another tenant's data	Tenant-specific prompt templates; no customer data in shared templates	LLM07, LLM02
Caches	Application-level response or semantic caches keyed without tenant ID	Cache keys include tenant ID; provider caches scoped per subscription or account	LLM02
Conversation history and memory	Memory keyed by session or user only, or shared across agents	Composite keys such as tenant:user; per-tenant stores for high-isolation tenants	LLM02; ASI06
Fine-tuned models	A model tuned on one tenant's data serving another; memorised data in outputs	Tenant-specific models or adapters; consent for shared training	LLM02, LLM04
Agent tools	Tools that query across tenants, or use a platform-wide service credential	Tools receive tenant-scoped tokens; gateway checks tenant claims	LLM06; ASI03
Logs and evaluation data	Prompts and outputs from all tenants pooled for debugging or evaluation	Tenant-tagged, access-controlled logs; minimised retention	LLM02
Capacity	One tenant exhausts model quota for everyone	Per-tenant quotas and rate limits checked at request time	LLM10

Tenant context: the thread through every call

AWS's guidance for multi-tenant agents is to encode tenant context in JWTs, carrying a tenant ID and tenant-specific scopes as claims, and to check quotas, tier permissions and usage limits at request time rather than relying only on static claims. In practice:

Authenticate the user through the tenant's identity configuration and issue a token with a tenant_id claim set by the identity service, not by the client.
Bind the session to that tenant and user; session state is keyed by tenant, user and session, never by session ID alone.
Derive every filter server-side from the token: vector query filters, memory namespaces, cache keys, log tags and tool parameters.
Exchange, do not forward, tokens when the AI layer calls downstream services. AWS recommends act-on-behalf delegation (OAuth 2.0 Token Exchange, RFC 8693) over impersonation, so the token records both the agent and the original caller and is scoped to one resource.
Re-check at the data layer: row-level security, IAM conditions on tenant tags, or per-tenant credentials enforce the boundary even if application code fails. See the Multi-Tenant SaaS Authorisation and Tenant Isolation Guide.

The rule that matters most: the model never decides which tenant it is serving. A prompt that says "you are now working for tenant B" must have no effect, because nothing downstream reads tenant identity from model output.

Retrieval and vector store isolation

AWS describes three patterns for multi-tenant RAG on Bedrock Knowledge Bases, which generalise to any vector store.

Pattern	Isolation mechanism	Per-tenant keys	Performance isolation	Choose when
Silo	Separate bucket, knowledge base and vector collection per tenant	Yes	Yes	Regulated or contractually isolated tenants; tenants needing their own embedding model or chunking
Bridge	Shared storage with per-tenant prefix; separate knowledge base and vector index per tenant	No	No	Moderate tenant counts wanting index-level separation without silo cost
Pool	One index; each document carries a tenantId metadata field and every query applies a metadata filter	No	No	Many small tenants with lower sensitivity; requires flawless server-side filtering

Pool pattern hardening: apply the tenant filter in a retrieval service the model cannot bypass; reject queries without a tenant filter; never expose the vector store directly to the agent as a tool.
Within-tenant permissions: OWASP LLM08 calls for permission-aware vector stores. Tenant isolation is not enough when users inside a tenant have different rights. See the Permission-Aware RAG Guide.
Offboarding: AWS notes that in the pool pattern there is no managed API to remove one tenant; you delete that tenant's source objects and re-sync. Test that deletion actually removes embeddings.
Encryption: only silo gives per-tenant KMS keys, which is what enables crypto-shredding on offboarding.

See the OWASP LLM08 Guide for the wider risk.

Prompts, caches and memory

Shared prompt templates: keep tenant data out of system prompts and few-shot examples that are shared. OWASP LLM07 System Prompt Leakage assumes system prompts can be extracted, so anything in a shared template is effectively visible to every tenant.
Provider prompt caching: Azure OpenAI documents that prompt caches are not shared between Azure subscriptions, that caching applies to prompts of at least 1,024 tokens, and that in-memory caches are typically cleared after 5 to 10 minutes of inactivity and always within an hour, with an optional extended 24-hour retention. If all tenants share one subscription, the provider's boundary does not separate them, so check each provider's isolation statement for the boundary you actually use.
Application caches: response and semantic caches must include tenant ID (and, where answers depend on permissions, user or role) in the cache key.
Agent memory: AWS recommends memory namespaces at global, strategy, tenant, user and session levels, composite identifiers such as tenant_123:user_456 enforced by attribute-based policy, and a dedicated memory store per tenant in silo deployments. Validate what is written to memory, since poisoned memory persists. See the AI Agent Memory Security Guide.
Session isolation: AWS states AgentCore Runtime runs each session in its own microVM with a session-scoped file system. Whatever runtime you use, code interpreters and scratch storage must not persist across tenants.

Models, fine-tuning and training data

Microsoft describes three model approaches for multitenant solutions: tenant-specific models trained only on one tenant's data, shared models used by all tenants, and shared base models tuned per tenant.

Approach	Isolation	Cost and operations	Key requirement
Shared foundation model, no tenant training	Strong for training data; isolation then depends on retrieval and prompts	Lowest	Provider terms exclude your prompts from training
Shared model trained on pooled tenant data	Weakest; outputs may reflect other tenants' data	Low per tenant	Tenant agreement, de-identification, a way to exclude a tenant from future training
Shared base tuned per tenant	Good if each tuned model or adapter is served only to its tenant	Medium; one artefact per tenant	Routing that maps tenant to model from token claims
Tenant-specific model	Strongest	Highest; compute and storage grow with tenants	Model treated as that tenant's data for retention and deletion

Microsoft's guidance is to treat models with similar sensitivity to the raw data used to train them, to make sure tenants understand and agree to their data being used for shared models, and to plan for a tenant that objects. Its named antipatterns are failing to consider isolation requirements and noisy neighbours.

Agents and tools in a multitenant product

Tenant-scoped credentials: AWS recommends issuing tenant-scoped credentials for each operation and, in silo deployments, a separate IAM execution role per tenant runtime. A single platform service account that can reach every tenant's data turns any prompt injection into a cross-tenant breach.
Tool filtering: offer tools according to tenant tier, feature flags and quotas, and check JWT claims and tenant mappings in a gateway interceptor before each call.
Customer-connected tools: when tenants connect their own SaaS or MCP servers, store each tenant's tokens separately in a vault, encrypted per tenant, and never let one tenant's agent session load another's connection. See the MCP Gateway and MCP Server Governance Guide.
Customer API keys for model providers: where tenants bring their own model keys, treat them as tenant secrets with their own rotation and revocation. Exposed customer keys get scraped and access resold, as in the Azure OpenAI abuse by Storm-2139. See the LLMjacking Guide.

The ChaosDB case is the warning for shared AI tooling: a notebook feature in a shared service let researchers escape their container and reach other customers' Cosmos DB primary keys. Code interpreters and notebook-style AI tools are the same class of shared execution surface.

Detection and measurement

Tenant-tagged telemetry: AWS recommends tenant-tagged metrics and structured logs for every invocation, covering token usage, tool calls and duration. Use the same tags for cost attribution.
Cross-tenant alerts: any retrieval result, memory read or tool response whose tenant tag differs from the session's tenant; queries arriving without a tenant filter; model routing to another tenant's tuned model.
Canary documents: plant unique strings in each test tenant's knowledge base and memory; alert if one ever appears in another tenant's output or logs.

Metric	Target
AI data paths (retrieval, memory, cache, tools, logs) with server-side tenant enforcement	100 per cent
Cross-tenant canary hits in release testing	Zero
Platform credentials with access to more than one tenant's data used by AI components	Zero, or justified and monitored
Tenants offboarded with verified deletion of embeddings, memory and tuned models	100 per cent
Requests rejected by per-tenant quota without affecting other tenants	Tracked; no cross-tenant latency impact

How to implement

Map every AI data path using the layer table: where tenant data is stored, cached, remembered, trained on or logged.
Classify tenants by isolation need and pick a pattern per layer (for example, silo retrieval for regulated tenants, pool for the rest).
Centralise tenant context in the token and a single retrieval and tool gateway; remove any tenant parameter from client-supplied input.
Build the cross-tenant test suite with canaries, including prompt-injection attempts that ask for another tenant's data, and run it in CI before enabling a new AI feature.
Pilot with internal tenants, then a small set of customers, watching cross-tenant alerts and quota behaviour.
Roll back by disabling the AI feature per tenant via feature flag, keeping the data layer controls in place.
Document the isolation model for customers: which layers are shared, whether their data trains anything, and how deletion works.

Framework mapping

Framework	Reference	Relevance
OWASP Top 10 for LLM Applications 2025	LLM02, LLM04, LLM06, LLM07, LLM08, LLM10	Disclosure, poisoning, agency, prompt leakage, vector weaknesses, capacity
NIST SP 800-53 Rev. 5	SC-4 Information in Shared System Resources; SC-39 Process Isolation; AC-4 Information Flow Enforcement; AC-3 Access Enforcement; SC-28 Protection of Information at Rest	Shared caches and memory, sandbox isolation, tenant flow control, per-tenant encryption
NIST CSF 2.0	PR.DS-01, PR.DS-10, PR.AA-05	Data at rest and in use, access permissions
OWASP Top 10 for Agentic Applications 2026	ASI03 Identity and Privilege Abuse; ASI06 Memory & Context Poisoning	Tenant-scoped agent credentials and memory

Common failure patterns

Tenant ID in the request body: the retrieval filter trusts a parameter the client or the model can change.
One platform credential for all tenants: agents and RAG pipelines query with a service account that can see everything.
Caches keyed by question text: a semantic cache returns tenant A's answer to tenant B's similar question.
Debug logs pooled across tenants: prompts and outputs from every customer readable by every engineer and evaluation job.
Offboarding that forgets embeddings: source documents deleted, vectors and memory left behind.
Shared execution sandboxes: code interpreter state or files persisting between tenants' sessions.

Practitioner checklist

Set tenant_id only in tokens issued by your identity service and derive every AI-layer filter from it.
Choose silo, bridge or pool per tenant class for retrieval, and document why.
Include tenant ID in every cache key and memory namespace.
Keep tenant data out of shared system prompts and examples.
Serve tuned models or adapters only to their own tenant, routed from token claims.
Give agents tenant-scoped, exchanged tokens; never a cross-tenant service credential.
Run code and browser tools in per-session sandboxes with no persistence.
Tag all AI telemetry by tenant and alert on tag mismatches.
Run cross-tenant canary tests on every release.
Verify deletion of embeddings, memory and tuned models on offboarding.

Multitenant AI application security: Isolating prompts, retrieval, memory and agents per tenant