Execution Context Isolation in Multi-Tenant Agent Runtimes

Multi-tenant agent platforms face an isolation problem that traditional SaaS never had to solve, because the code running inside each tenant's session was never written or reviewed by anyone on the platform side. Traditional SaaS keeps things simple: the vendor writes the code, the vendor ships the code, and separation between tenants happens at the application layer through separate database rows, separate API keys, and role-based access control. Nobody has to worry about a customer's session running something unpredictable, because the vendor already knows exactly what will execute before it ever reaches production.

Agent workloads flip that arrangement on its head. An agent generates code at runtime, pulling from prompts, file uploads, or whatever task context it's been handed, and that code is something the platform has never seen before and cannot whitelist in advance. OWASP's guidance on this point is blunt: treat the model as any other user, and validate everything it produces, because it is an untrusted external process now. That's a real shift in posture. A vendor used to reviewing its own code now has to treat its own agent's output the way it would treat an anonymous, unauthenticated request from the open internet.

Three properties compound to make this worse than it sounds at first. Execution is multi-step, so a single session might run dozens or hundreds of individual code steps, each one shaped by whatever ran before it. State compounds risk on top of that: a malformed or compromised early step doesn't just cause one bad outcome, it poisons every step downstream in that session. And code is unpredictable by design, since the model decides what to generate at the moment of execution, which means no static whitelist can ever cover it.

Tool use adds a second dimension entirely. Agents call external APIs as a normal part of doing their job, fetching data, writing to a database, hitting a third-party service. That's necessary connectivity. But it's also a straight line for exfiltration if a session goes wrong, which puts platform builders in the position of granting agents the reach they need while trying to prevent that same reach from becoming a leak. When multiple tenants run agents concurrently, on shared infrastructure, tenant isolation is as load-bearing as the workload isolation itself, because one agent's execution should have zero visibility into another's.

The scale at which this needs solving isn't some distant hypothetical. Gartner forecasts that 40% of enterprise applications will integrate task-specific AI agents by the end of 2026, up from under 5% at the time the forecast was made Gartner / Make Multi-Agent Penetration Testing AI for the Web. That's a sharp break, not a gradual curve. That's a rewrite of the threat model happening across a huge share of enterprise software in a short window, and it means the isolation architecture teams choose now determines what breaks later.

Why the container assumption breaks under adversarial agent workloads

Containers were never built for this. They isolate processes and give each one its own view of the runtime, but every container on a node still shares the same host kernel. A successful escape from that boundary doesn't just compromise one container. It hands an attacker the host node, and from there, potentially every workload sitting next to it.

That's not a theoretical concern dressed up for effect. runc, the low-level runtime underneath most container platforms, produced CVE-2019-5736 and CVE-2024-21626, both rated high-severity container escapes. Each disclosure like that opens a window where crossing a tenant boundary becomes possible, and in an agent context, that window doesn't require a deliberate attacker. An agent that stumbles into the wrong syscall sequence while executing generated code can trigger the same outcome by accident. CNCF's analysis of the runc breakouts disclosed in November 2025 found that the flaws could leave multi-tenant environments at risk, specifically where users define their own containers or run unvetted, malicious images. That description matches agent platforms almost exactly, since the whole premise is that users, by way of their agents, are defining what runs.

Even short of an outright escape, shared infrastructure creates friction on its own. Measurements of co-located workloads show performance degradation in the range of 5% to 50% from interference alone Blaxel Multi-Agent Penetration Testing AI for the Web. One tenant's runaway agent, looping through retries or chewing through memory, becomes every neighboring tenant's latency problem without any exploit. And behavior surveys back this up from a different angle: 80% of organizations reported encountering risky agent behaviors, including improper data exposure and unauthorized system access Blaxel Stateful Agent Backdoor / arXiv Multi-Agent Penetration Testing AI for the Web. In a single-tenant deployment, that's a bug to fix. In a shared execution environment, every one of those behaviors is a potential cross-tenant event.

None of this makes containers a bad technology. It makes them the wrong default for a specific job. Containers are a fine fit for trusted, platform-written jobs where the vendor knows what's running. They're the wrong choice as a default whenever agents are executing LLM-generated code on behalf of external users, because the boundary that contains a bug is not the same boundary that contains an adversary. Hardened variants like gVisor try to close the gap by intercepting syscalls before they reach the host kernel, and that's a meaningful improvement over a bare container. But it comes with its own latency costs, gaps in kernel feature compatibility, and a new attack surface sitting at the interception layer itself. So if the kernel is shared, and the kernel is the thing under attack, the fix isn't a better container. It's moving the boundary somewhere the kernel itself can't reach.

How microVMs move the isolation boundary below the kernel

MicroVMs solve this by giving up on sharing the kernel. Each tenant workload gets its own guest kernel, enforced by hardware virtualization rather than the operating system's own process controls. That means a kernel exploit inside one microVM stays inside that microVM. It can't reach the host, and it can't reach any neighboring tenant, which is a fundamentally different guarantee than what a container offers, where a kernel exploit crosses to every workload sharing that kernel.

The old objection to this approach was cost. Spinning up a full VM per tenant sounded like seconds of boot latency and gigabytes of memory overhead, which made it a nonstarter for anything that needed to respond quickly Blaxel. Firecracker changes that math. Boot time is 125 milliseconds or less, with memory overhead under five MiB per VM Blaxel. Those numbers erase the historical argument against VM-per-tenant designs almost entirely Blaxel. A microVM that boots in under an eighth of a second and costs less than five megabytes of memory isn't some heavyweight compromise anymore; it's a legitimate default for session-level isolation Blaxel.

The hypervisor itself is still part of the threat model. A guest kernel compromise doesn't hand an attacker the host kernel directly, but the hypervisor still needs to be maintained and patched like any other piece of critical infrastructure, since it remains part of the threat model.

Two microVM technologies dominate production use today. Firecracker is open source, purpose-built for fast boot times and low overhead, and was designed from the ground up for exactly this kind of workload. Kata Containers is OCI-compatible and integrates with Kubernetes tooling. Northflank's production analysis lands firmly on one side: microVMs, whether Firecracker or Kata, are the standard for production multi-tenant agent platforms, with each session getting its own guest kernel.

But a guest kernel per session is not the whole security posture. A guest kernel per session is the ceiling on the security posture, not the whole of it. Networking, storage, and credential handling each need their own isolation controls layered on top, because none of those get automatically covered just because compute is locked down.

Three tenant isolation patterns and how to choose between them

AWS's Bedrock AgentCore work on multi-tenant design lands on three patterns worth knowing by name: Silo, Pool, and Bridge, with tiering strategy as a central factor in choosing among them.

Silo gives each tenant a fully separate execution environment: its own container image, its own process space, its own lifecycle. It offers the strongest protection against noisy neighbors and makes compliance audits far simpler, since a tenant's data and execution never touch anyone else's infrastructure. That strength comes at a cost, though, and it's the highest per-tenant infrastructure spend of the three patterns. Silo is the right fit for customer-facing agents that execute arbitrary AI-generated code, for high-compliance environments, and for enterprise tiers where customers are paying for that level of guarantee.

Pool takes the opposite approach, hosting agents from every tenant inside the same container image and the same process pool. Costs and operational overhead drop substantially, but the separation between tenants now lives entirely in software, enforced through strict in-process tenant context propagation rather than hardware boundaries. That's a reasonable tradeoff for platform-written, bounded, low-risk internal jobs where the vendor controls exactly what code runs. It's a much harder sell the moment tenants start feeding arbitrary instructions into agents that generate their own code.

Customer-facing agents that execute arbitrary code get routed into microVMs, while internal background jobs and scheduled tasks running platform-written code stay in containers. This pattern also opens the door to tiering: premium tenants get silo-level isolation, standard tenants get pooled execution with in-process separation. The catch is that the orchestration layer has to correctly classify every workload before it decides where to route it, and a misclassification here isn't a cosmetic bug but a tenant boundary quietly failing.

Teams frequently miss that separate folders or a tenant header are not process confinement, since an in-process Node import retains ambient authority, per the kontourai/station issue #487 architecture acceptance notes. Isolation that lives only in naming conventions isn't isolation, it's bookkeeping.

It helps to keep three separate levels of isolation distinct in the design itself, rather than folding them into one another. Customer isolation means one tenant cannot reach another, full stop. Member authorization is a layer down from that, governing role separation within a single tenant's own team. And per-job or per-plugin isolation handles separate trust classes that might exist inside a single tenant's own workload, where not every plugin a customer installs deserves the same access as another. Conflating these three creates gaps that look like isolation on paper but aren't. And the choice of which tier gets which guarantee is a product decision as well as a technical one. It's a product decision about what customers are actually paying for, and it deserves to be made explicitly rather than inherited by accident from whatever infrastructure happened to be lying around.

Isolating networking, storage, and credentials beyond the compute boundary

Compute isolation sets a ceiling, not a floor. The actual security posture of a platform is only as strong as the weakest of compute, network, storage, and credential controls, and it's entirely possible to nail one of these and leave the others wide open.

Networking is the most obvious gap, because tool calls need outbound connectivity to function. The fix isn't blocking outbound traffic, it's scoping it. Northflank's production guidance is direct: connectivity should be limited to known endpoints, with default-deny everywhere else. Leave outbound access open by default, and every agent session becomes a potential exfiltration channel, whether or not anything malicious was ever intended. For multi-tenant MCP servers, where a single deployed server handles requests from many different users, the isolation model needs to reach further than the infrastructure layer. Each user's memory needs to be partitioned at the data layer itself, according to mem0.ai's analysis of FastMCP deployments, because infrastructure-level separation alone leaves the data commingled even when the compute is properly isolated.

Storage carries its own version of the same problem. Agents that hold context across multiple steps need persistent storage, not just a throwaway filesystem that vanishes when the session ends. Blaxel's Agent Drive, currently in private preview, offers shared filesystem storage for context history and intermediate artifacts, with workspace-level isolation as the current default and Volumes available for stronger per-tenant boundaries. The design principle underneath that offering: the storage boundary should make it physically impossible for a sandbox to mount another tenant's volume, not merely discouraged by configuration. AWS's approach with Bedrock AgentCore follows a similar logic, giving each session its own persistent file system specifically to reduce the risk of data leaking across sessions. And whatever the storage model, ephemeral sessions need a clean teardown when they finish, with nothing left behind that could leak into the next session that spins up on the same infrastructure.

Credentials might be the sharpest edge of all. Multi-tenant agents need API keys, database credentials, and service tokens, and each of those needs to be scoped to the specific tenant it belongs to. What determines whether a compromised agent can walk off with those secrets and use them somewhere outside the sandbox is the delivery mechanism, not the existence of scoping. Environment variable injection is the weakest option available, because any process running inside that sandbox can read those variables, and a leak anywhere in the session becomes a leak of everything. Stronger designs favor proxy-based secrets injection, which minimizes how often a secret ever enters the sandbox in the first place, or operation-scoped secrets resolved only at the moment a specific action needs them. Beyond credentials, the acceptance criteria worth building toward deny host mounts, ambient credentials, metadata-service access, shared writable caches, and privileged sockets by default, unless a specific case deliberately grants one.

Resource limits are what everything else depends on. CPU, memory, process counts, disk, runtime duration, network egress, each needs a hard bound per session. Skip that step, and a single runaway agent doesn't just fail on its own, it exhausts shared resources and turns one tenant's bad session into a platform-wide event.

Persistent agent memory as a cross-session threat surface

Persistent memory is what makes an agent worth more than an expensive chatbot. Context that survives across sessions is what allows an agent to pick up a multi-step task tomorrow where it left off today. But that same persistence opens a threat class that stateless sandboxes were never built to face.

A May 2026 paper from East China Normal University and collaborators lays this out in detail. Existing backdoor attacks against LLM-based agents are stateless: the malicious behavior has to complete entirely within a single session, and it simply fails if the session ends before every step in the attack chain finishes. A stateful agent backdoor breaks that constraint by storing its own attack state inside the agent's persistent memory. An attacker injects the trigger once, and from that point on, the trigger persists and reactivates on its own in later sessions, with no further intervention needed.

What makes this genuinely unsettling is how the attack moves through phases: initialization, data collection, exfiltration, waiting patiently if a needed tool isn't available in a given session, then resuming from wherever it left off in the next one. That patience is the mechanism that breaks session-level permission isolation. Conditions that would be mutually incompatible if they had to happen in a single session (file access in one session, network access in another, say) can be satisfied one at a time across separate sessions, each of which looks unremarkable on its own.

The design implication is straightforward even if the fix is not: isolation boundaries that reset cleanly at the end of a session are necessary, but they stop being sufficient the moment memory persists across sessions. Memory stores need to be scoped, auditable, and protected against both cross-tenant reads and cross-session write poisoning, treated as their own isolation surface rather than an afterthought bolted onto compute. And this isn't some edge case that occurs only in adversarial research settings. It exploits exactly the same persistence mechanism that makes agents useful for long-horizon work in the first place, which means the capability and the risk are the same feature viewed from two directions. Broader research on agentic AI governance points at the same gap from a policy angle: most general-purpose AI risk frameworks weren't built with agentic AI's specific challenges in mind, and the field needs a shift from static, model-level alignment toward dynamic, system-level runtime governance. The paper's primary instantiation results report an attack success rate of 80%–95% across four models tested (Gartner / Make, Stateful Agent Backdoor / arXiv).

Responsibilities of an agent operating system beyond process scheduling

Classical operating system abstractions, processes, threads, files, sockets, resource controllers, were built for workloads that are deterministic and written by humans. None of that design lineage anticipated a workload that's dynamic, semantically rich, and adaptive in the way an agent session is. That gap is exactly what's driving a wave of research into what's being called the Agent Operating System, or AOS.

The paper analyzes where classical OS abstractions fall short for agent workloads and proposes integration models ranging from lightweight user-space runtimes up to full distributed control planes. The goal isn't replacing operating systems as a category. It's building a systems foundation rigorous enough that agentic computation stays controllable, accountable, and secure even as it scales.

Earlier framing work already pointed in this direction. The AIOS proposal from 2024 lays out an LLM-agent operating system that folds scheduling, context management, memory management, storage management, tool management, and access control into a single kernel that manages the agents running on top of it. Read next to the AOS paper's five-part breakdown, the throughline is consistent: Firecracker's boot time of 125 milliseconds or less and memory overhead of less than five MiB per VM remove the historical objection to VM-per-tenant designs, which assumed seconds of latency and gigabytes of RAM Blaxel. It needs its own kernel-level thinking, built from the ground up for a workload that decides what to do while it's already running. The Quine identity model realizes agents, a matter an agent operating system must manage that a process scheduler never had to.