Process Isolation Levels for Coding Agents in Shared Cloud Tenants

Process isolation for coding agents is not a single setting you flip on. It is a spectrum running from shared-kernel containers up to hardware-virtualized microVMs, and the right point on that spectrum depends on three things: what the agent can do, whose credentials it's holding, and what it can reach from inside the session. Get that mapping wrong in a shared cloud tenant, and a single agent session stops being a single-tenant problem. It becomes a cross-tenant one.

Traditional SaaS multi-tenancy solved isolation with separate database rows, scoped API keys, and role-based access control. The vendor wrote the code, reviewed it, shipped it, and controlled exactly what ran against whose data. Coding agents break that model at the root: the agent generates code at runtime, from a user's prompt, and the platform never reviewed a line of it before execution. OWASP's guidance on large language model applications states this: treat the model's output as you would treat input from any other untrusted user, not as vendor-approved code. That's a real inversion, and it changes what "isolation" has to mean.

How to think about agent risk before choosing an isolation level

Three axes decide how dangerous a given agent session actually is. First, what the agent can do: read-only analysis is at one end, arbitrary shell execution and binary installation at the other, with outbound network calls somewhere in between. Second, whose credentials it holds: a scoped read token is a very different animal from a deploy key, which is a very different animal from a cloud IAM role with write access to production. Third, what it can reach: an isolated scratch filesystem versus a shared repo versus a live customer data store versus an open path to external package registries.

None of these axes is dangerous alone. The risk occurs when they combine. An agent that can legitimately read a config file containing a secret, and can also legitimately open a pull request against an external repo as part of a normal contribution workflow, has just been handed a two-step path to credential exfiltration, even though each step, on its own, is a sanctioned task. Security researchers call this composition, and it's the reason capability lists are the wrong unit of risk analysis. Sequences are.

Sub-agent delegation makes the composition problem worse, not better. A test-generation sub-agent that inherits its parent agent's deployment credentials now holds more authority than its actual job requires, and if nothing attenuates privilege at the point of delegation, that sub-agent becomes a lateral-movement vector regardless of how carefully the parent was scoped. GitGuardian's 2025 count of AI-service secrets found in public repositories, a substantial and fast-growing haul, up 81% from the year before, is a fair signal that attackers already understand this composition and are actively hunting for it.

For the rest of this piece, four risk tiers are named. Tier 1 is platform-controlled code with no arbitrary execution, the lowest-risk case. Tier 2 is LLM-generated scripts running in a sandboxed interpreter with no outbound network. Tier 3 is LLM-generated code that makes outbound calls, installs packages, and touches credentials. Tier 4 is arbitrary binary execution with a full shell and broad credential scope, the highest-risk case and the one that deserves the most isolation engineering. Industry surveys heading into 2026 put agentic AI at or near the top of the list of attack vectors cybersecurity professionals worry about, which tracks with the tier framework rather than contradicting it: the concern scales with capability, not with the mere fact that an LLM is involved.

The shared-kernel problem and why container isolation keeps failing under adversarial pressure

Containers isolate tenants using Linux kernel namespaces and cgroups. Each tenant gets its own process tree, its own network view, its own filesystem view, and CPU and memory limits that the kernel actually enforces. That's a real boundary, and for years it was treated as sufficient.

It isn't, structurally, because every container on a node shares one host kernel. Researchers studying the exposed syscall surface put the number of system calls reachable from inside an unprivileged container north of 300, and each one is a potential path from "contained process" to "host kernel." This isn't a hypothetical gap. CVE-2024-21626 let an attacker manipulate a container's working directory through a leaked file descriptor to reach the host filesystem directly, and it hit Amazon ECS, Amazon EKS, and Docker. CVE-2022-30137, known as FabricScape, allowed a full container escape and cluster takeover inside Azure Service Fabric, affecting multiple Azure services from the same cloud provider. Add CVE-2019-5736, a runc vulnerability, and a pattern becomes visible across these cases that isn't a string of unlucky one-offs. It's a structural property of shared-kernel design.

An industry foundation's own analysis of the runc container-breakout flaws disclosed in November 2025 called the risk "critical" specifically for multi-tenant environments where users define their own containers or run images nobody vetted. That's the exact shape of a coding-agent platform: users, or their agents, building and running containers nobody on the vendor side reviewed. A 2026 experiment researchers nicknamed Dirty Frag underlined the point with a stopwatch: on the container side, an unprivileged user reached root in under two seconds, while the same attack against a virtual machine, even one configured more permissively than the container, simply didn't land. What mattered wasn't the permission set granted to the software. What mattered was whether the kernel underneath was shared at all. Kubernetes' own documentation is honest about this, describing containers as offering "a weaker isolation boundary" than hardware-based virtual machines. That's the vendor's characterization, not an outside critique.

None of this means containers are wrong, full stop. They remain a defensible choice for Tier 1 workloads, platform-controlled jobs with no arbitrary code generation, where the code running inside the container was written and reviewed by the vendor, not produced on the fly by a model responding to a stranger's prompt. The failure mode is reaching for container isolation as a general-purpose answer once the workload crosses into agent-generated code.

The isolation spectrum: four boundary types and what each one actually guarantees

Isolation level sets a ceiling on how bad a breach can get. Cost and operational overhead follow from that ceiling, not the other way around, and the spectrum from weakest to strongest boundary comes before matching anything to a risk tier.

Namespace and cgroup separation, the baseline container model, gives process-tree separation, resource limits, and separate filesystem views, all on a shared kernel and often a shared node. It does not provide a kernel boundary: a kernel exploit inside one tenant's container can, in principle, reach every co-tenant on that node. Cold start times run around 50 milliseconds, which is part of why this model got so popular in the first place. It belongs to Tier 1 work only, internal background jobs running code the platform itself wrote.

gVisor moves up one step by intercepting syscalls in a userspace kernel instead of passing them straight to the host. That shrinks the blast radius meaningfully compared to a plain container, without paying for a full virtual machine, though it still shares some host kernel surface underneath and syscall-heavy or I/O-heavy work slows down under the interception layer. This fits Tier 2 and much of Tier 3: LLM-generated scripts where the main worry is a runaway process or a logic bug chewing through resources rather than a deliberate, hands-on-keyboard exploit attempt. Google has reported sandbox usage on GKE growing sixteen-fold in under five months, a signal of real production demand at this tier, which suggests real production demand at this tier, not a niche use case. Platforms built around gVisor-style isolation for machine learning workloads written largely in one programming language, with GPU support and autoscaling down to zero instances, sit here too, alongside newer offerings that give each sandbox its own full virtual machine and real Linux kernel for teams that need more than the userspace-kernel model provides.

Kata Containers goes further: it spins up a lightweight virtual machine, using a trimmed QEMU build or Cloud Hypervisor, boots a minimal guest Linux kernel, and runs a kata-agent process to translate ordinary container runtime instructions into that VM. Each microVM gets its own virtual CPU and memory, and a guest-kernel compromise stops at the VM boundary instead of reaching the host or any neighboring tenant. The cost is orchestration complexity beyond gVisor, and it still leans on a conventional hypervisor underneath. Northflank, for instance, runs more than two million isolated workloads a month across Kata Containers and gVisor, with support for customer-managed cloud deployment and no cap on session length. This tier fits Tier 3 work well: agents that make outbound calls and touch real credentials, where a dedicated guest kernel earns its keep but the full engineering weight of Firecracker isn't justified yet.

Firecracker microVMs are at the top of the spectrum, using hardware virtualization enforced at the kernel level. The isolation boundary sits below the kernel itself, so a kernel exploit inside one microVM has no path to the host or to a neighboring tenant's microVM. Firecracker's engineering numbers are why this model stopped being a latency and cost argument against VM-per-tenant designs: cold starts around 125 milliseconds, versus one to two seconds for a conventional VM and roughly 50 milliseconds for a bare container, and memory overhead under 5 mebibytes per VM. AWS Lambda runs thousands of these microVMs per physical host, and AWS Bedrock AgentCore gives each user session its own dedicated microVM with isolated CPU, memory, and filesystem. Sandbox providers built on Firecracker, such as offerings that cap sessions at 24 hours and price in the low hundreds of dollars a month plus usage that climbs with real agent traffic, sit in this category too, with the tradeoff that scaling at high volume becomes a job the platform team has to manage directly. This is the tier to reach for by default once an agent is doing Tier 4 work: arbitrary binaries, unvetted package installs, broad credential scope, in a multi-tenant setting where the other tenant's blast radius matters.

The cost premium for microVMs over containers at scale runs in the range of 10 to 20%. That's a real number, but it's small next to the cost of a cross-tenant breach, and it doesn't have to be an all-or-nothing choice. Running Tier 1 jobs in containers while routing Tier 3 and Tier 4 agent sessions into microVMs is a legitimate production architecture on its own terms, not a compromise made to save money.

What isolation alone doesn't cover: credentials, noisy neighbors, and session duration

Compute isolation and credential scope are separate problems, and it's a mistake to let strength in one stand in for strength in the other. A microVM running under a broadly scoped IAM role is still a credential-exfiltration risk sitting inside a very strong box. The microVM boundary stops the agent from reaching other tenants. It does nothing to stop the agent from misusing the credentials it was legitimately handed for its own session.

Session-state separation catches a different failure than compute isolation catches. If an agent's session state simply cannot carry a secret retrieved during one tool call into the payload of a later outbound call, the read-secret-then-publish composition described earlier gets ruled out at the planning level, before execution isolation is ever tested. That's a design decision about how session memory is structured, and it produces a property of the orchestration layer, not the sandbox underneath it. Executives report strikingly low visibility into what permissions their agents actually hold and how those permissions get used moment to moment, which is a governance gap distinct from, and just as consequential as, the isolation gap.

Noisy-neighbor interference is its own problem again, and it survives even a compute boundary as strong as those built by leading microVM technology, because shared components like knowledge bases, inference endpoints, and API gateways sit outside any individual microVM. AWS Bedrock AgentCore's pooled runtime model, for instance, hosts multiple agents inside a shared container image and process pool and relies on strict in-process tenant-context propagation, carried through strict in-process tenant-context propagation applied consistently across the runtime stack. A basic-tier tenant can be throttled harder than a premium-tier tenant without touching the compute isolation level at all. That's a policy lever, separate from the sandbox choice.

Session duration is a plain operational ceiling that a lot of isolation designs skip past. AWS Lambda's 15-minute execution limit, to take one well-known example, will forcibly cut off an agentic task that legitimately needs longer, so any isolation architecture built around short-lived functions has to reckon with agent sessions that run for minutes or hours, not milliseconds. Isolation level decides blast radius. Credential scoping, session-state design, throttling policy, and observability decide whether an agent session ever actually reaches that blast-radius boundary in the first place.

How governance and compliance requirements map onto isolation choices

The EU AI Act sets explicit traceability, logging, and post-market monitoring duties for high-risk AI systems, and agent execution traces map onto those audit requirements naturally, provided the isolation boundary is clean enough to say with confidence which tenant a given trace belongs to. A blurry isolation boundary produces a blurry audit trail, and regulators are unlikely to accept "probably tenant A" as an answer.

The OWASP Top 10 for Agentic Applications, a peer-reviewed framework released in December 2025 covering the major security risks facing autonomous AI systems, names three risks that line up directly with the tier framework used throughout this piece. ASI02, Tool Misuse and Exploitation, covers agents using legitimate tools unsafely because a configuration was too permissive or too ambiguous, which is squarely a Tier 3 and Tier 4 concern. ASI03, Identity and Privilege Abuse, is the sub-agent delegation problem named earlier: high-privilege credentials inherited without being scoped down first. ASI04, Agentic Supply Chain Vulnerabilities, covers compromised tools, plugins, and MCP servers pulled in dynamically at runtime, a risk that appears at any isolation level the moment an agent can reach an external registry.

Package registries deserve specific mention here, because the overwhelming majority of npm maintainer account takeovers ever recorded happened in 2025 alone. Any Tier 4 agent installing unvetted packages needs that fact sitting explicitly in its threat model, not treated as background noise. A 2025 study out of the University of San Francisco, presented at IEEE-ISTAS, ran 400 code samples through five rounds of fully automated AI refinement with no human review at any step and found critical vulnerabilities in the code rose by 37.6% over those rounds. That's a direct, measured cost for iterating without a human checkpoint, and it argues for placing human-in-the-loop gates at specific, high-consequence action boundaries rather than sprinkling review evenly and thinly across every step. NIST's Generative AI Profile, AI 600-1, lists twelve risk areas including information security, data privacy, and value-chain integrity, and the throughline across all of it is the same: compute isolation is one layer of defense, not the whole compliance posture on its own.

The real governance failure mode, though, is simpler than any framework: agents nobody formally reviewed. A large majority of enterprises expect to expand agent use over the next year, with something close to half aiming for organization-wide rollout, and an agent spun up outside that formal review process bypasses credential scoping, approval workflows, and audit logging no matter how strong the isolation layer underneath it happens to be. Isolation can't compensate for governance that never got applied in the first place.

Matching isolation level to agent capability in practice

The working question for any given agent session is blunt: what is the worst plausible combination of action, credential, and reachable data for this session type, and which isolation boundary actually survives that scenario? Everything else in this piece is context for answering that one question correctly.

Tier 1, platform-controlled code with no arbitrary execution, is the one case where namespace and cgroup separation is a defensible, complete answer on its own. Tier 2, sandboxed LLM-generated scripts with no outbound network, is a reasonable fit for gVisor, provided credentials in play are minimal and the session doesn't linger. Tier 3, LLM-generated code that makes outbound calls and touches real credentials, calls for a dedicated guest kernel, either Kata Containers or Firecracker, paired with credentials minted fresh and scoped tightly to that one session, plus egress filtering on top. None of those three controls substitutes for the other two; they're additive, not alternatives. Tier 4, arbitrary binary execution with a full shell and broad credential scope, is where the isolation boundary has to be strongest and the credential scope has to be narrowest at the same time, because that's the combination where a mistake in either dimension stops being contained by the other.

The tier framework holds up because it ties the strength of the boundary to the actual damage a session could do if everything went wrong at once, rather than to how the platform happens to be built or how much a given sandbox costs per hour. Coding agents in shared tenants are still new enough that a lot of platforms are choosing isolation levels by convenience or by what the infrastructure team already had running. That's a shortcut, and it's the one that container-escape vulnerabilities on record and gVisor's own production growth numbers are already starting to punish.