Multi-tenant AI agent isolation for AI SaaS platforms

Your AI SaaS platform serves hundreds of customers in production. Each customer's agent executes code against that customer's own data. All the agents share a pool of containers. In this scenario, one agent hits an infinite loop and starves the pool's CPU. Other customers see degraded performance at once. The postmortem traces the blast radius to a shared execution environment. It was never designed for tenant-level isolation.

Multi-tenant AI SaaS products face an isolation problem that traditional SaaS architectures never encountered. When agents generate and execute code at runtime, every tenant's workload becomes a potential threat. That threat reaches every other tenant. Shared compute pools and shared filesystems create failure modes, especially when process spaces are shared too.

Containers alone don't solve them. A container can limit CPU and memory for a process. It still shares the host kernel with every neighbor on the node. Per-tenant isolation gives each customer's workload its own execution boundary. A failure or compromise in one tenant's agent can't reach another's.

Why shared execution environments break multi-tenant agent security

Traditional multi-tenant SaaS isolates tenants at the application layer. That means separate database rows and separate API keys, with role-based access controls enforcing them. That model works because the vendor controls what code runs. Agent workloads invert that model.

The agent generates code at runtime from the customer's prompt, then executes it. OWASP's LLM application guidance directs teams to "treat the model as any other user" and validate everything it produces. Code your platform never reviewed is untrusted by definition.

Sharing an execution environment turns container escapes and resource exhaustion into cross-tenant events. Data leakage becomes another cross-tenant risk when isolation stops at the process level. A kernel exploit in one tenant's sandbox can reach every neighbor sharing that host kernel.

CNCF's analysis of the November 2025 runc breakouts warns that the flaws "pose a critical risk" "in multi-tenant environments where users define their own containers or can run unvetted, malicious images." Resource exhaustion creates another failure path.

Measurements of co-located workloads show 5–50% performance degradation from interference alone. That turns one tenant's runaway process into every co-located tenant's latency problem. Data leakage follows from the same weak boundary. A filesystem or memory access flaw lets one tenant read another's data. That happens when isolation stops at the process level.

Plan for risky agent behavior, including improper data exposure and unauthorized system access. 80% of organizations encountered those behaviors from AI agents. In a shared execution environment, each of those behaviors becomes a cross-tenant event.

Isolation architecture patterns for multi-tenant agents

The isolation boundary you choose sets your security ceiling and per-tenant economics while shaping operational complexity. Stronger isolation costs more per tenant but shrinks the blast radius to a single workload. Weaker isolation costs less but leaves shared surfaces. A kernel exploit or runaway process can cross them.

Container-level isolation with namespace separation

Containers isolate at the process level and give each tenant's agent a separate process tree, plus isolated network and filesystem views. They can limit CPU and memory for that workload. That model fits multi-tenant products where the platform controls the code. It includes pre-defined functions or reviewed jobs where the workload has no arbitrary generation.

Even so, Kubernetes' own documentation describes containers as offering "a weaker isolation boundary" than hardware-based virtual machines.

The boundary is still the host kernel that every container on the node shares. That boundary keeps failing under adversarial pressure. Container escape CVEs recur regularly. runc alone produced CVE-2019-5736 and CVE-2024-21626. Both have high-severity CVSS scores. Each disclosure opens a window for tenant-boundary crossing. An attacker can exploit that window. So can an agent that stumbles into an exploit.

MicroVM isolation with dedicated kernels

MicroVMs give each tenant's workload a dedicated guest kernel enforced by hardware virtualization. The boundary sits below the kernel. A kernel exploit inside one microVM can't reach the host or neighboring tenants.

Firecracker, the open-source microVM technology, boots a microVM in 125 milliseconds or less. It adds less than five MiB of memory overhead per VM. Those figures remove the historical objection to VM-per-tenant designs. Dedicated kernels no longer cost seconds of latency or gigabytes of RAM.

Firecracker-based microVM platforms like Blaxel apply this per sandbox. Combined with custom Docker images, custom domains, domain filtering, dedicated egress gateways in private preview, and proxy-based secrets injection, teams get tenant-level isolation. Networking gets tenant-specific controls. Storage and credential handling get tenant boundaries too. Teams avoid building the isolation layer themselves.

MicroVMs fit any multi-tenant product where agents execute arbitrary, AI-generated code. AWS made the same choice for its own agent service. AWS Bedrock AgentCore runs each user session in a dedicated microVM with isolated CPU and memory as well as an isolated filesystem. When a tenant's agent generates and runs code at runtime, use a dedicated guest kernel per workload. It is the default worth reaching for.

Hybrid isolation with tiered tenant separation

Some multi-tenant products mix workload types. Run customer-facing agents that execute arbitrary code in microVMs. Keep internal background jobs and scheduled tasks running platform-written code in containers.

A hybrid model runs trusted workloads in containers and untrusted workloads in microVMs. The orchestration layer routes them by workload classification. For reviewed asynchronous or scheduled workloads, Batch Jobs can handle parallel background execution. Untrusted agent-generated code still routes to Sandboxes.

Classification happens at the orchestration layer, before execution. The orchestration layer tags each workload by its source at enqueue time. Agent-generated code carries one tag. Platform-defined and reviewed code carries another. Code generated by an agent routes to a microVM. Code the platform defined and reviewed routes to a container.

Route first, execute second. After execution starts in the wrong runtime, the escape window has opened. Misclassification risk drops when the platform treats any unverifiable code provenance as untrusted by default. That means sending it to a microVM rather than assuming it is safe.

Two jobs hit the same queue. A nightly analytics rollup written by the platform team carries the trusted tag. It routes to a container, because the platform reviewed every line before it shipped. A customer prompt asks the agent to "parse this uploaded CSV and generate a summary script." That job carries the untrusted tag and routes to a microVM. The generated script was never reviewed. It could do anything the interpreter allows.

The tag travels with the job through the queue. The executor reads the tag and dispatches to the right runtime. It does not have to re-derive provenance at runtime. That matters because provenance is cheap to establish at enqueue time. It is expensive, sometimes impossible, to reconstruct after a worker has dequeued the job.

The tradeoff is routing complexity plus a hard dependency on classification accuracy. A single misclassified agent workload running in a container recreates the exact gap. The hybrid model was built to eliminate that gap. A hybrid model only holds up when the platform can reliably tell trusted code from untrusted code. If it cannot, route everything to microVMs.

How to implement per-tenant isolation beyond compute

Compute isolation stops one tenant's code from reaching another tenant's processes and kernel. Cross-tenant leakage also travels outside compute. Networking, storage, and credential handling each need tenant boundaries.

Isolate network egress per tenant

Without per-tenant network controls, a compromised agent can send outbound requests anywhere. That includes endpoints that exfiltrate data or reach an attacker's infrastructure. Egress isolation restricts which external services each tenant's agent can contact. Start with deny-by-default outbound rules. Then enforce per-tenant outbound policy through controls like these:

• Egress allowlists: each tenant defines the domains and IPs its agent may reach. Everything else is blocked before it leaves the sandbox.
• Static outbound IPs: each tenant's traffic leaves through a dedicated IP. Receiving systems can whitelist that tenant on their own firewalls.
• Outbound traffic logging: per-tenant flow logs give you audit trails and forensic evidence after an incident.

Managing these policies as tenant counts grow requires a networking layer that's programmable per sandbox, not configured globally. Teams that bolt egress rules onto container hosts through iptables hit a maintenance wall. Host-level rule management does not scale cleanly.

Rule updates took more than 10 seconds as rule counts grew. That update cost compounds with every tenant you add. Per-sandbox programmable egress ties each rule set to the sandbox lifecycle instead. A new tenant's allowlist is provisioned when its sandbox is created. It is torn down when the sandbox is destroyed.

Onboarding and offboarding a tenant never triggers a global rule reload. That reload can stall traffic for every other tenant on the host. Egress controls are the second line of defense. If the compute boundary fails, they limit what a compromised agent can reach externally.

Scope storage and state per tenant

Multi-tenant agent products store filesystem snapshots along with the context history and intermediate artifacts agents create. Those artifacts often live in shared storage infrastructure. A misconfigured mount path or a bug in the storage layer can expose one tenant's data. It can expose that data to another tenant's sandbox. Enforce the boundary at the infrastructure level:

• Per-tenant volumes: attach block storage exclusively to that tenant's sandboxes, with no shared mounts between tenants.
• Tenant-scoped filesystem access: on shared filesystems, filter mounts by tenant identifier. A sandbox can only see its own tenant's paths.
• Per-tenant encryption keys: where storage account sharing is required, use separate tenant keys. Azure supports assigning different keys to different tenants within one storage account. It names a dedicated account per tenant as the strongest isolation.

A shared NFS mount holds every tenant's snapshot directories under one root. A path-traversal bug in the storage layer can cross into a sibling tenant's directory. So can a symlink one sandbox plants that points up and across. Either flaw lets that sandbox read snapshots it was never scoped to see. Per-tenant block volumes remove that entire class of bug. There is no shared inode namespace to traverse in the first place.

On Blaxel, Agent Drive, currently in private preview, provides shared filesystem storage for context history and intermediate artifacts. Use workspace-level isolation today and Volumes for stronger per-tenant storage boundaries where required.

The storage boundary should make it physically impossible for a sandbox to mount another tenant's volume. That sandbox stays isolated. That remains true even on the day the application layer fails.

Inject credentials without exposing them to agent code

Multi-tenant agents need API keys and database credentials, plus service tokens scoped to each tenant. The delivery mechanism decides whether a compromised agent can steal them and use them outside the sandbox. Credential delivery should minimize how often secrets enter the sandbox.

• Environment variable injection (weakest): Environment variables are readable by every process in the sandbox. They can leak into logs or system dumps. That is why OWASP's secrets guidance recommends against them ("are generally accessible").
• Runtime vault retrieval (medium): the workload fetches secrets through a secure API at execution time. Short-lived secrets issued at runtime shrink the theft window. The credential still lands in the sandbox's memory.
• Proxy-based injection (strongest): credentials are applied at the network layer and never enter the sandbox. Proxy-based identity frameworks stream key material to the proxy. The private key does not touch the sandbox. SPIFFE's Envoy integration, for instance, does this "without the private keys" ever having to touch the disk.

For multi-tenant products, proxy-based injection is the correct default. Scope each tenant's credentials to its own sandbox. Log every credential use per request.

Common mistakes in multi-tenant agent isolation

Teams building multi-tenant AI SaaS often get compute isolation right and miss the adjacent layers. Both mistakes below stay invisible through development and testing. Both pass functional tests because nothing breaks under normal load.

Functional tests can still pass because queries return the right rows and agents run their code; demos show no visible cross-tenant exposure. The shared boundary only fails under adversarial pressure. That happens when a determined attacker or a sufficiently creative agent probes for the gap.

Rely on application-layer tenant filtering for storage

All tenants' data lives in one storage system. The application appends a tenant ID filter to every query. If you use row-level tenant filtering, every query must carry an AND TENANT = tenant ID predicate. Isolation then depends on no engineer ever forgetting that predicate. One missed filter exposes the full dataset. So does one new endpoint that skips the middleware. OWASP found broken access control in 94% of applications tested. It ranked broken access control as the top web application risk. Tenant-ID filtering asks every engineer to beat those odds on every query.

Because application bugs can bypass software-level logic, infrastructure-enforced boundaries are critical for strict isolation. Separate volumes or separate mount paths, backed by platform-enforced tenant scoping, create a stronger failure mode. A complete application failure still can't expose cross-tenant data. Use application-layer filtering for access control, then add storage isolation as the tenant boundary.

Share a container pool across untrusted workloads

A container orchestrator schedules every tenant's agent onto a shared pool. That leaves a shared host kernel between tenants. Recent ECScape research showed where that leads. A low-privileged container on a shared Amazon ECS host could intercept IAM credentials.

Those credentials were intended for other tasks on the same machine. The identical attack failed against AWS Fargate. Fargate runs each task in a hardware virtualization environment. In that environment, CPU, memory, storage, and network interfaces are never shared.

Bin-packing tenants densely onto shared nodes cuts the per-tenant compute bill. Cost pressure rewards packing more agents onto fewer hosts. On a shared host, one exploit compromises every co-located tenant. Exposure grows with every tenant you pack onto the node. For any workload executing arbitrary, AI-generated code, use microVM isolation with a dedicated kernel per tenant. Container pools assume trusted workloads.

How to architect per-tenant isolation for your AI SaaS platform

Isolating tenants at every layer: compute, networking, storage, and credentials, limits the blast radius. It keeps a single compromised agent from becoming a platform-wide breach with breach reporting obligations attached. A cross-tenant breach in a multi-tenant AI product hits every customer on the platform at once.

The notification clocks start immediately. GDPR requires reporting to the supervisory authority within 72 hours of discovering a breach. California requires a business that maintains data it doesn't own to notify the owner immediately following discovery.

For teams building multi-tenant AI SaaS where each customer's agent executes code in production, perpetual sandbox platforms like Blaxel provide microVM isolation per sandbox. Custom domains support per-tenant white-labeling. Domain filtering restricts outbound destinations. Dedicated egress gateways are available in private preview for static outbound IPs.

Proxy-based secrets injection keeps credentials out of agent code entirely. Agent Drive and Volumes give teams storage options for shared context, artifacts, and stronger per-tenant persistence boundaries.

Blaxel fits coding agents and codegen agents first. It also fits PR review agents and data analyst agents that execute generated code against customer data. Coding-agent and code-execution products hit this isolation problem earliest. Each customer's agent writes and runs code against that customer's repository as its core loop. That includes platforms like Webflow and Strapi.

Talk to the team at blaxel.ai/contact or start building at app.blaxel.ai.

FAQ

What is per-tenant isolation in multi-tenant AI SaaS?

Per-tenant isolation means each customer's agent workload runs in its own execution environment, behind a boundary no other tenant can cross. It starts with separate sandboxes for compute and tenant-specific outbound rules for network access. Storage stays scoped to the tenant, and secrets stay sandbox-specific. The goal is zero blast radius when one tenant's agent fails, loops, or generates unsafe code.

Why do AI agents need stronger isolation than traditional SaaS applications?

Traditional SaaS runs vendor-controlled code that the vendor can review before production. AI agents generate and execute code at runtime from prompts, uploads, repositories, or task context. That makes each workload untrusted. Stronger isolation moves the tenant boundary below application logic, so unsafe code cannot reach neighboring workloads, storage, credentials, or network access.

What is the difference between container isolation and microVM isolation for multi-tenant AI agents?

Containers isolate processes and runtime views, but all containers on a node still share the host kernel. MicroVMs give each tenant workload a dedicated guest kernel enforced by hardware virtualization. Containers fit trusted platform-written jobs. MicroVMs are the stronger default for customer-facing agents that write and run arbitrary code at runtime.

How should multi-tenant AI SaaS products handle per-tenant credentials?

Use proxy-based credential injection. Environment variables are readable inside the sandbox, and runtime vault retrieval still places credentials in sandbox memory. A proxy applies tenant-scoped credentials at the network layer instead, outside the agent's process. Scope credentials to the specific sandbox and log each use per request for audit.