Multi-Tenant Isolation for SaaS and AI: How to Prevent Cross-Tenant Data Breaches, Segregate Tenant Data, and Use Customer-Managed Keys

Cross-tenant breaches are prevented by enforcing the tenant boundary at every layer of the stack, including identity and authorization, network, compute, storage, encryption keys, and AI-specific data such as retrieval indexes, caches, and fine-tuning datasets, with application code as one layer among several. Choose the tenancy model (silo, pool, or bridge) per tier based on customer risk and compliance needs. On Control Plane, teams enforce these boundaries with deny-by-default workload firewalls, workload identities, policy-based access control, and separate environments per tenant on AWS, GCP, Azure, Kubernetes clusters you already run, or a tenant’s own infrastructure.

Disclosure: Control Plane publishes this guide.

TL;DR

Preventing cross-tenant data breaches in multi-tenant SaaS and AI systems requires isolation at every architectural layer and the right tenancy model for each tier.

• Tenancy models. Silo (dedicated stack per tenant), pool (shared infrastructure with tenant ID enforced everywhere), and bridge (shared tiers plus dedicated tiers for regulated or large tenants) each carry different cost, complexity, and isolation trade-offs.
• Isolation layers. Identity and authorization, network segmentation, compute boundaries, storage and databases, encryption keys, AI data (indexes, caches, memory, fine-tuning), logs and observability, and CI/CD each need their own tenant-aware controls.
• Customer-managed keys. BYOK (bring your own key), meaning customer-managed encryption keys held in the customer’s key management service, gives tenants a cryptographic kill switch over their data. Per-tenant data keys wrapped by each tenant’s own customer-managed key through envelope encryption limit blast radius.
• AI-specific risks. Shared retrieval indexes, prompt caches, conversation memory, and fine-tuning datasets can leak data across tenants if the tenant filter is missing or applied after retrieval.
• Evidence for auditors. Automated cross-tenant tests in CI, access reports, penetration tests, and immutable audit trails demonstrate isolation to compliance reviewers.
• How Control Plane fits. Control Plane provides deny-by-default internal firewalls, workload identities, policy-based access control, and a separate Global Virtual Cloud (GVC), Control Plane’s term for a set of locations a workload runs across, or a separate org per tenant, on AWS, GCP, Azure, Kubernetes clusters you already run, or on premises.

What causes cross-tenant data breaches?

Cross-tenant breaches stem from a small set of recurring failure classes.

Missing tenant filter in a query. A database query that omits the WHERE tenant_id = ? predicate returns rows belonging to other tenants.

Broken object-level authorization. When an API endpoint checks authentication but does not verify that the caller may access the specific object requested, one tenant can read or modify another tenant’s resources. OWASP lists this as API1: Broken Object Level Authorization.

Shared caches keyed without tenant ID. A cache entry keyed only by object ID or query hash can serve one tenant’s data to another. Every cache key must include the tenant identifier.

Shared credentials or service accounts across tenants. When several tenants share one service account or database credential, a compromise in one tenant’s context grants access to every tenant’s data.

Overly broad network paths between services. If every service can reach every other service, a vulnerability in one can be used to reach tenant data held by another.

Shared retrieval indexes or vector stores without tenant filtering. In AI systems using retrieval-augmented generation (RAG), a vector search that does not enforce a tenant metadata filter before returning documents can surface another tenant’s content to the model.

Logs and support tooling exposing data across tenants. Centralized logging or support dashboards that do not filter by tenant let operators or attackers view data from tenants they should not see.

Container escape on shared hosts. A kernel exploit or container runtime vulnerability on a shared host can expose the credentials, environment variables, and storage volumes of co-located tenants. Shared GPUs can leak data between co-located jobs when memory is not cleared between them.

Tenant context lost in async paths. Queue messages, background jobs, and event handlers that drop the tenant ID run with no tenant scope or the wrong one.

Server-side request forgery. Tenant-supplied URLs (webhooks, imports, agent browsing) can reach internal services or cloud metadata endpoints.

Noisy neighbor and resource exhaustion. One tenant’s traffic, jobs, or GPU use can starve shared compute, connection pools, or model provider quotas, which degrades every other tenant.

What cloud solutions offer multi tenant protection against cross tenant data breaches?

Silo, pool, and bridge tenancy models compared

The AWS Well-Architected SaaS Lens describes three tenancy models: silo, pool, and bridge. Each makes a different trade-off between isolation strength, cost, and operational effort.

Dimension	Silo	Pool	Bridge (Hybrid)
What is shared	Little or nothing. Dedicated account, network, database, and compute per tenant.	Nearly everything. Shared compute, database, cache, and network with tenant ID enforced in every layer.	Shared tiers (compute, API gateway) plus dedicated tiers (database, encryption keys, or compute) for regulated or large tenants.
Isolation strength	Strongest. Infrastructure boundaries limit the blast radius to one tenant.	Depends on application and platform controls. A single missing tenant filter can expose every tenant.	Strong where dedicated, application-dependent where shared.
Cost	Highest. Infrastructure is duplicated per tenant.	Lowest. Amortized across all tenants.	Middle. Dedicated tiers add cost only for tenants that need them.
Operational effort	High. Every tenant is a separate deployment to patch, monitor, and scale.	Lower per tenant, but requires rigorous enforcement of tenant context across every service, cache, queue, and store.	Moderate. Operators run both shared and dedicated tiers.
When to use	Regulated industries, contractual requirements for physical separation, tenants with unique compliance needs.	High-volume SaaS with many small tenants, low per-tenant revenue, and acceptable shared-infrastructure risk.	Many enterprise SaaS platforms. Offer a shared tier by default and move tenants to dedicated tiers based on contract, regulation, or risk.

Capabilities to look for in a platform

Whatever model you choose, the underlying platform should provide:

• Deny-by-default network policy between services, so workloads cannot communicate unless explicitly permitted.
• Per-service identity, so each service authenticates on its own and no shared static keys exist.
• Fine-grained access policy that can target resources by name, tag, or query, and that applies automatically to resources created later.
• Separate environments per tenant, with the option to place a tenant’s workloads in a dedicated account or region.
• A dedicated infrastructure option for tenants that need physical separation, including in a tenant’s own cloud account or on premises.
• Encryption with customer-managed keys, so tenants keep control over their data’s cryptographic lifecycle.
• A tamper-proof audit trail of platform actions, queryable for compliance evidence.

On Control Plane, deny-by-default firewalls, workload identities, query-based policies, a separate GVC or org per tenant, dedicated clusters in a tenant’s own cloud account, and a tamper-proof audit trail are built in; the details are in How Control Plane fits.

How do I design AI infrastructure for cloud compliance using BYOK and tenant data segregation?

Customer-managed keys, BYOK, and HYOK

BYOK (bring your own key) means the tenant creates and manages an encryption key in its own cloud key management service (such as AWS KMS, Azure Key Vault, or Google Cloud KMS) and grants the SaaS provider limited permission to use that key to encrypt and decrypt the tenant’s data. The provider never holds the customer’s key material; it holds plaintext data keys in memory only while it processes that tenant’s data.

HYOK (hold your own key) is a stricter variant in which the key stays in an external key manager or hardware security module the tenant controls, often on premises. The provider calls the tenant’s key manager to wrap or unwrap each data key, which adds latency and availability risk.

Envelope encryption with per-tenant keys

A practical pattern is envelope encryption. Each tenant’s data is encrypted with a unique data encryption key (DEK). That DEK is wrapped by the tenant’s customer-managed key (the key encryption key, or KEK) in the cloud KMS, and the wrapped DEK is stored alongside the ciphertext. To decrypt, the provider calls the tenant’s KMS to unwrap the DEK, then uses the DEK locally.

Bind each wrap and unwrap call to the tenant with a KMS encryption context (additional authenticated data) such as tenant_id. A wrapped DEK then fails to unwrap under any other tenant’s context, and on AWS KMS each CloudTrail entry records the tenant. Rotating the KEK does not require re-encrypting data. The KMS keeps prior key versions for unwrapping, and you can rewrap DEKs under the new version.

Key revocation works as a kill switch for data encrypted under that tenant’s DEKs. It takes effect once cached plaintext DEKs expire, so keep the DEK cache short-lived. Vector embeddings, caches, logs, and copies held by third parties are covered only if they are also encrypted under the tenant’s keys. Revocation breaks reads, writes, backups, search, and AI inference for that tenant, so document the blast radius before launch.

AI-specific data segregation

AI workloads add data surfaces that need tenant isolation:

• Retrieval indexes and vector namespaces. Use separate vector collections or namespaces per tenant when feasible. When a shared index is necessary, apply a mandatory server-side tenant metadata filter on every query. Never let the model choose or infer the tenant ID.
• Prompt and response caches. Key every cache entry by tenant ID, and add user ID when the response depends on the user’s permissions. A shared semantic cache without tenant scoping will serve one tenant’s cached answer to another.
• Conversation memory and logs. Scope conversation history, uploaded files, and agent state to tenant, user, and session. Purge or archive them per the tenant’s retention policy.
• Fine-tuning data. Train per-tenant models or adapters on that tenant’s data only, and route inference to the requesting tenant’s adapter. Pool data across tenants only with explicit contractual consent, because fine-tuned models can reproduce training data. Keep provenance records for every training dataset.
• Document-level permissions. Filter retrieval by the requesting user’s permissions as well as the tenant ID. Without this, a shared index leaks documents across roles inside one tenant.
• Agent tool calls. Tools and connectors an agent invokes must run with credentials scoped to the requesting tenant and user, never a shared service account.
• Model provider data retention. Configure data retention and training opt-out settings with every model provider that processes tenant data, and recheck them periodically.
• Per-tenant region pinning. For data residency, pin a tenant’s data, including AI indexes and caches, to locations in the required jurisdiction.

Prompt injection can try to make the model retrieve or reveal another tenant’s data. Authorization must sit outside the model, enforced by the application or platform before any data reaches the model context. The OWASP Top 10 for LLM Applications catalogs these risks.

What are the best identity and access management solutions for multi tenant environments with provenance in mind?

Evaluate IAM options for a multi-tenant environment against these criteria.

Tenant context in signed tokens. Every request should carry a tenant claim in a signed token (for example, a JWT) that is validated on every API call. Derive the tenant ID from the authentication system, never from user input or URL parameters. Reject requests without a valid tenant claim before business logic runs, and reject a request when a tenant ID in the URL or body differs from the token claim.

Separate identities for each service and environment. Each service and each environment (development, staging, production) should have its own identity. A service account shared across services or environments turns a compromise in one context into access to all of them.

Workload identity federation instead of shared static keys. Cloud providers support workload identity federation, where a workload presents a token from a trusted identity provider and exchanges it for short-lived cloud credentials. That removes long-lived API keys and service account files that could leak.

Least privilege scoped to tenant resources. Scope permissions to the specific tenant’s resources rather than every resource of a type. A database role that can read every tenant’s rows is too broad even if it cannot write.

Provenance. Every action, whether by a human operator or an automated workload, must be attributable to a specific identity in an immutable audit trail. Provenance also covers software artifacts: signed builds and a verifiable build process, as defined by the SLSA framework, show that the code running in production is the code that was reviewed and approved.

Tenant isolation checklist by layer

Each layer below lists a control and a concrete way to verify it.

Layer	Control	How to verify
Identity and authorization	Tenant ID derived from a signed token and validated on every request. Object-level authorization on every endpoint. Jobs and messages carry the tenant ID, and workers re-check it before acting.	Automated cross-tenant API tests in CI. Access reports showing which identities hold which permissions.
Network	Deny-by-default firewall between services. Explicit allow rules only for required paths. mTLS between services.	Network policy audit. Penetration test attempting lateral movement between tenant workloads.
Compute	Workload isolation through cgroups, namespaces, and restricted syscalls. Sandboxed or dedicated compute for higher-risk tenants.	Container escape penetration test. Review of runtime security configuration.
Storage and databases	Row-level security with tenant context set per transaction. Separate databases or schemas for siloed tenants. Tenant context reset in connection pools. RLS forced on table owners (FORCE ROW LEVEL SECURITY), and application roles lack BYPASSRLS.	Automated queries attempting to read another tenant’s rows. Database role privilege audit.
Encryption keys	Per-tenant data encryption keys. Tenant ID bound as KMS encryption context. Customer-managed KEK through envelope encryption where required. Documented rotation and revocation procedures.	KMS access policy review. Revocation test confirming data becomes unreadable. Key usage audit log.
AI data (indexes, caches, memory, fine-tuning)	Server-side tenant filter on every vector query. Tenant-scoped caches and conversation memory. Fine-tuning data provenance.	Cross-tenant retrieval test returning zero results. Cache key inspection. Fine-tuning dataset lineage audit.
Resource limits and rate limiting	Per-workload CPU and memory limits. Per-tenant API rate limits, queue quotas, and model token budgets.	Load test one tenant past its quota and confirm other tenants’ latency holds.
Logs and observability	Logs tagged with tenant ID. Log access restricted by tenant. No unfiltered tenant data in shared dashboards.	Log query attempting to retrieve another tenant’s entries. Dashboard access review.
Support and operations access	Operator access scoped to tenant. Break-glass access logged and alerted. No persistent admin credentials.	Access report for support roles. Audit trail query for break-glass events.
CI/CD and secrets	Secrets scoped to environment. Signed build artifacts. Pipelines cannot deploy to a tenant’s environment without authorization.	Secret access audit. SLSA provenance verification. Pipeline permission review.
Backups, offboarding, and deletion	Backups encrypted with the tenant’s key. Per-tenant restore tested. Tenant data export before deletion. Offboarding deletes or crypto-shreds the tenant’s keys, vector namespaces, caches, conversation memory, and fine-tuned models or adapters, and requests deletion from model providers.	Restore a backup and confirm only the target tenant’s data is present. Deletion verification script.

What cloud compliance checklist should I follow when migrating a regulated application to AI infrastructure?

This checklist is not legal advice. Consult qualified counsel for your specific obligations.

1. Classify data and decide what may reach a model. Identify which data elements are regulated (PHI, personal data, cardholder data) and decide whether they may go to a third-party model or must stay within your own infrastructure.
2. Confirm data residency and region pinning. Verify that processing, storage, and AI inference for regulated data happen in the required jurisdiction, and pin workloads and data stores to those regions.
3. Sign a BAA or DPA with every provider that touches regulated data. HIPAA requires a business associate agreement with each business associate that creates, receives, maintains, or transmits PHI on your behalf, and each business associate must sign one with its subcontractors. GDPR Article 28 requires a contract or other binding legal act, usually called a data processing agreement, with each processor, and each processor must bind its sub-processors to the same obligations. That includes model providers, infrastructure providers, and observability vendors.
4. Set model provider data retention and training opt-outs. Confirm in writing how long the model provider retains prompts and completions and that it does not train on your data.
5. Encrypt with customer-managed keys where required. Use envelope encryption with per-tenant keys, and grant the provider only the key permissions it needs.
6. Isolate tenants per the checklist above. Apply every layer of the tenant isolation checklist, with particular attention to AI data surfaces.
7. Log access to regulated data. Keep immutable logs of who accessed what data, when, and why, including model inference calls that process regulated data. Confirm breach notification timelines (under GDPR, 72 hours to the supervisory authority where feasible).
8. Run a DPIA for AI processing of personal data. GDPR Article 35 requires a data protection impact assessment for high-risk processing; update the subprocessor list and customer notices too.
9. Update the risk assessment and SOC 2 system description. Adding AI components changes the system boundary. Document new risks, controls, and third-party dependencies.
10. Test incident response for AI-specific failures. Simulate a model returning another tenant’s data, a prompt injection attack, and a model provider outage, and verify detection, containment, and notification.
11. Document human review where decisions affect people. If AI outputs influence decisions about individuals (credit, insurance, employment), document the human review process and the criteria for overriding model outputs.

For a deeper walkthrough, see our guide to running regulated apps in the cloud.

How Control Plane fits

Control Plane is the unbreakable platform for running production workloads. It runs serverless, standard, stateful, and cron workloads natively on AWS, GCP, and Azure, VM workloads on locations joined through Control Plane’s Managed Kubernetes, and workloads on Kubernetes clusters you already run or your own machines, including on premises, active-active across regions and clouds. Control Plane is PCI DSS Level 1, SOC 2 Type II, HIPAA, and GDPR compliant; the customer’s own controls remain the customer’s responsibility.

Resource model and tenant boundaries

An org is Control Plane’s top-level isolation boundary. Secrets, policies, domains, and images are org-scoped. Workloads, identities, and volume sets are scoped to a GVC, and a workload can only use volume sets and identities from its own GVC. Teams use a separate GVC per tenant or per tier for siloed tenants, or a separate org where they want a harder boundary. For Kubernetes-specific pitfalls, see Kubernetes multi-tenancy: 5 things to avoid.

Network isolation

The internal firewall between workloads is deny by default. Each workload’s inbound rule allows nothing, the same GVC, the same org, or a named list of workloads. External inbound and outbound traffic are disabled by default, and outbound rules can allow specific CIDRs or hostnames. All traffic between workloads uses mTLS with a unique client certificate per workload.

Access control and audit

Beyond the built-in superusers and viewers policies, nothing is permitted inside an org until a policy grants it. A policy targets one resource kind and covers every item, named items, or items matched by a query on tags, properties, or relations, so resources created later that match are covered automatically. It binds permissions to users, groups, service accounts, or workload identities. Every resource has an Access Report showing who holds each permission and which policy granted it. Edit on a secret also grants reveal, so grant use when a principal only needs to attach a secret. A tamper-proof audit trail records platform actions from every interface and is queryable for evidence. Workloads can also write their own events, such as tenant data access, to it through an audit context, though it does not collect logs from downstream services.

Workload identity and key management

Attach an identity to a workload and credentials arrive at runtime, stored nowhere in the container. Control Plane’s Universal Cloud Identity (UCI) lets a workload call AWS, GCP, and Azure services, including each cloud’s key management service, with no long-lived cloud keys in your code. Each identity connects to one cloud account per provider. Your application code can therefore call AWS KMS, Azure Key Vault, or Google Cloud KMS at runtime to unwrap per-tenant data encryption keys, with no cloud key stored in the workload.

Compute isolation and secrets

Each workload is isolated with cgroups, namespaces, and restricted syscalls and capabilities, and Control Plane’s Sandboxes, isolated environments for building and testing code and AI agents, run in dedicated Kata Containers microVMs. Org secrets are encrypted with envelope encryption and stored on multiple cloud providers using cloud HSMs, and a workload’s identity needs the reveal permission to read a secret. Control Plane encrypts all volumes by default, and on AWS locations a volume set can use your own AWS KMS key in each region instead, so a tenant’s dedicated volume set can be encrypted with a key you control in your own AWS KMS. Custom volume encryption is currently available only on AWS.

Dedicated infrastructure and data residency

A GVC can run on Control Plane-managed locations in AWS, GCP, and Azure regions, on Kubernetes clusters you already run, or on your own machines, including on premises. A regulated tenant can get dedicated infrastructure, including a Kubernetes cluster in its own cloud account joined as a location, either one it already runs or one created through Control Plane’s Managed Kubernetes, operated the same way as shared tiers. Pin a tenant’s GVC to locations in one country for data residency. For more, see data residency vs data sovereignty.

Endpoint authentication and AI assistants

Control Plane can validate JWTs in a workload’s Envoy sidecar, configured per workload or once for every workload in a GVC, so a request that a rule requires to carry a valid token is rejected before it reaches application code. Claims such as a tenant ID can be passed to the application as request headers. AI assistants act through Control Plane’s MCP server with OAuth sign-in, only in the orgs the user authorizes, and with that user’s permissions; a readonly profile cannot change resources, and every action an assistant takes lands in the same audit trail as actions from the Console, CLI, and Terraform. For more on agent guardrails, see how to let AI agents operate production infrastructure safely.

Availability, operations, and cost

The 99.999% availability SLA applies to workloads running at least two replicas in at least two locations. Control Plane handles Day 2 operations for you, including autoscaling, right-sizing with Control Plane’s Capacity AI, which adjusts reserved CPU and memory based on historical usage, built-in observability, and security, with no Kubernetes cluster you have to operate. Customers typically cut compute costs 30 to 50 percent compared with running directly on AWS, GCP, or Azure.

Control Plane enforces the boundary at the infrastructure and platform layers. The application must still enforce the tenant ID in its own queries, caches, and AI retrieval logic.

FAQ

Common questions about multi-tenant isolation for SaaS and AI platforms.

What is the difference between silo, pool, and bridge tenancy?

Silo gives each tenant a dedicated stack or cloud account. Pool runs all tenants on shared infrastructure with tenant ID enforced in every layer. Bridge shares some tiers (such as compute and the API gateway) and dedicates others (such as databases or encryption keys) for regulated or large tenants. Many enterprise SaaS platforms use a bridge model: a shared default tier, with dedicated tiers for tenants whose contract or compliance needs require them.

How do I stop one tenant’s data appearing in another tenant’s AI answers?

Enforce a server-side tenant metadata filter on every vector query and retrieval call before documents reach the model context. The tenant ID comes from the authenticated session, never from the model. Scope prompt caches by tenant, and by user where permissions differ; scope conversation memory and uploaded files by tenant, user, and session. Test with automated cross-tenant retrieval queries that must return zero results.

Does a dedicated environment per tenant cost more?

Yes. A silo model duplicates infrastructure per tenant, which raises cost and operational overhead. A bridge model dedicates only the tiers that need it, such as the database or encryption keys, while sharing compute and networking, so the extra cost falls only on tenants that require dedicated resources.

What is BYOK and how does it help with tenant isolation?

BYOK (bring your own key) means the tenant manages an encryption key in its own cloud KMS and grants the SaaS provider limited permission to use it. If the tenant revokes that permission, data encrypted under its keys becomes unreadable once cached data keys expire. BYOK does not replace authorization or access controls, but it gives the tenant a cryptographic kill switch and limits blast radius.

How do I prove tenant isolation to auditors?

Run automated cross-tenant access tests in CI covering reads, writes, deletes, exports, and AI retrieval. Use access reports to show which identities hold which permissions, query the platform’s audit trail for evidence, run periodic penetration tests that attempt lateral movement between tenant workloads, and document the isolation architecture and its limits.

Can prompt injection bypass tenant isolation in AI systems?

Yes, if authorization depends on the model. A malicious prompt can instruct a model to retrieve another tenant’s data or repeat data from its context window. Enforce authorization at the application or platform layer before any data enters the model context. The OWASP Top 10 for LLM Applications documents this and related risks.

Should I use row-level security or separate databases for tenant data?

It depends on the tenant’s risk profile and your compliance requirements. Row-level security in a shared database is cost-efficient for many tenants but needs rigorous configuration, testing, and per-transaction tenant context in connection pools. Separate databases give stronger isolation and suit regulated or high-value tenants. A bridge model lets you use both.

How does workload identity federation reduce cross-tenant risk?

Workload identity federation lets a service prove its identity to a cloud provider and receive short-lived, scoped credentials at runtime instead of storing long-lived API keys or service account files. Without stored keys, there is no static secret whose leak could open many tenants’ cloud resources.

What happens if a tenant revokes its customer-managed encryption key?

Data whose DEKs are wrapped by that key becomes unreadable once cached DEKs expire, and every service that decrypts that tenant’s data fails. Plan for this before offering customer-managed keys, including error handling, tenant notification, and documented recovery procedures.

How does Control Plane enforce deny-by-default networking?

Control Plane blocks workload-to-workload traffic until a rule opens it to the same GVC, the same org, or listed workloads. Inbound and outbound internet traffic also start blocked, and outbound access can be opened to listed CIDRs or hostnames. Traffic between workloads uses mTLS.

Ready to enforce tenant isolation at every layer? Talk to the Control Plane team or sign up free.

---

Originally published on the Control Plane blog.