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

Posted on Nov 3 • Originally published at controlplane.com • AI-assisted

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.

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.

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.

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.

Whatever model you choose, the underlying platform should provide:

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.

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.

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 workloads add data surfaces that need tenant isolation:

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.

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.

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

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

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

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.

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.

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.

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.

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.

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.

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.

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.

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.

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

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.