Your Agents Run Code Nobody Read. What Is Actually Containing Them?
Coding agents execute untrusted code all day, and most teams are containing it with a Docker container that shares the host kernel. The isolation layer, what it costs, and who builds it.
What Actually Contains Your Agent When It Runs Code?
Ask an engineering leader what their AI coding agent is allowed to do and you will usually get a confident answer about permissions: which repositories it can read, which tools it can call, whether it can open a pull request without review. Ask what physically stops the code the agent just wrote from reading the host filesystem, and the room goes quiet.
That gap matters more in 2026 than it did in 2024, because the workload changed shape. An autocomplete model suggested text that a human read before it ran. An agent writes a script, runs it, reads the output, writes another one, and iterates, dozens of times per task, at a speed no reviewer is in the loop for. The code being executed is, by construction, code nobody read. Some of it was generated from a prompt. Some of it came from a package the agent installed. Some of it came from an MCP server's tool description, a README, an issue comment, or a stack trace, all of which are attacker-writable surfaces we covered in detail in our piece on agentjacking and MCP supply chain attacks.
The industry answer to "where does that run" has been, overwhelmingly, "in a container." It is the default in nearly every agent harness, every CI runner, and every hosted sandbox product that shipped before the middle of last year. It is also the wrong tool, and the reason is not subtle: a container is not an isolation boundary. It is a packaging format with namespaces bolted on, and every process inside it is calling into the same kernel as everything else on the box.
This is a solvable problem with mature technology, and it is largely a platform engineering problem rather than an application one, which is exactly why it keeps not getting done. Product teams do not have the capacity to build an execution substrate while shipping features, and the work is unglamorous enough that it never wins a planning argument. It is, however, extremely well-suited to a small, senior, dedicated development team that owns the layer end to end.
Why Is a Container Not a Security Boundary?
The technical case is arithmetic. In the container model, every process in every container issues system calls into a single shared Linux kernel, roughly 40 million lines of C exposing more than 450 syscalls, as catalogued in a March 2026 survey of microVM isolation by a staff SRE at Booking.com. Namespaces, cgroups and seccomp filters narrow what a container can reach, but each of them is a software convention enforced by that same kernel. Find one flaw in it, and every convention above it is advisory.
This is not theoretical. The same survey walks through the escape-class CVEs that landed across 2024 and 2025 in the boring, universally deployed parts of the stack: the Leaky Vessels family in runc and buildkit (CVE-2024-21626), a filesystem escape in Buildah and Podman (CVE-2024-1753), two NVIDIA container toolkit flaws including the one tracked as NVIDIAScape at CVSS 9.0 (CVE-2025-23266), plus further runc issues in masked-path handling and console mount validation. None of those required an exotic target. They required a container.
The economics say the same thing from the other direction. A hypervisor escape is worth $250,000 to $500,000 on the bounty market, and Google's own kvmCTF pays $250,000 for a KVM escape, per the same write-up. A container escape is worth a fraction of that, because it is a fraction as hard. When you place an adversarial workload behind the cheaper boundary, you are not saving money, you are choosing the side of the price gap you would rather not be on.
The honest framing is that containers were designed to isolate workloads that are cooperating, not workloads that might be adversarial. For a decade that assumption held, because the code in the container was code your team wrote and your pipeline built. An agent that installs an unvetted package and executes its post-install hook has quietly voided that assumption, and most teams have not re-derived their threat model since.
Key Takeaways
- Containers share one kernel: roughly 40 million lines of C and 450+ syscalls, with namespaces and seccomp enforced by that same kernel
- Escape-class CVEs landed across 2024 and 2025 in runc, buildkit, Buildah/Podman and the NVIDIA container toolkit, including one rated CVSS 9.0
- Hypervisor escapes command six-figure bounties; container escapes do not, and the price gap is a direct statement about relative difficulty
- The container threat model assumed cooperating workloads; agent-generated and agent-installed code breaks that assumption
Can Models Actually Find and Use an Escape?
The obvious pushback is that a container escape requires an attacker who knows what they are doing, and an agent running a data-cleaning script is not that attacker. Two things undercut it. First, the agent does not need intent; a prompt injection supplies the intent. Second, the capability question has now been measured rather than argued about.
Researchers from the University of Oxford and the UK AI Security Institute built SandboxEscapeBench, an open benchmark that measures whether a model with shell access inside a container can break out of it. The design is careful: it is a capture-the-flag evaluation on a nested sandbox architecture, so the outer layer holds the flag and carries no known vulnerabilities, and the measurement is safe to run. The escape surface it covers spans the realistic spectrum, misconfiguration, over-broad privilege allocation, kernel flaws, and runtime or orchestration weaknesses.
The headline conclusion is stated plainly in the paper: when vulnerabilities are present, models identify and exploit them. The authors' own framing is that evaluations like this are needed to confirm that sandboxing still provides the encapsulation highly capable models require, which is a polite way of saying the encapsulation is no longer something you can assume. The benchmark is published openly on GitHub, so this is a thing your platform team can run against your own harness rather than take on faith.
Put that next to the misconfiguration rate in any real fleet, the privileged container someone needed for a Docker-in-Docker build, the volume mount that made a debugging session easier, the hostPath that never got removed, and the picture resolves. You do not need a zero-day for most of these. You need a motivated process inside a container that somebody configured on a Thursday.
What Real Isolation Costs in Latency and Overhead
The reason teams reached for containers was never a considered security judgement. It was that virtual machines were slow, and agents are latency-sensitive in a way batch workloads are not: if the sandbox takes 30 seconds to come up, the agent stalls between tool calls and the whole loop becomes unusable. That objection was valid in 2015. It is now obsolete, and the numbers are not close.
The microVM survey cited above puts Firecracker's boot at roughly 125 milliseconds with under 5 MiB of memory overhead per instance, dropping to around 28 milliseconds with snapshot-restore. Firecracker achieves that by refusing to be general purpose: about 83,000 lines of Rust and five emulated devices, against QEMU's 1.7 million lines of C and hundreds of devices. The attack surface you are trusting is three orders of magnitude smaller, and the boundary underneath it is hardware virtualization enforced by the CPU rather than a policy enforced by a shared kernel.
The userspace-kernel approach is the other serious option. gVisor intercepts guest syscalls and services them in a sandboxed Go process rather than passing them to the host, reimplementing around 274 Linux syscalls while exposing only 53 host syscalls with networking disabled, or 68 with it enabled. Startup lands around 50 milliseconds. You trade some syscall-heavy performance for a very small host surface and a lighter operational footprint, which is why it tends to win for GPU inference and compute-bound work where the I/O path is not the bottleneck.
Neither number is a reason to stall a decision. A 125-millisecond boot is inside the noise of a single model call. The practical constraint is not latency any more, it is that somebody has to build and operate the thing, wire in snapshotting, manage image supply, handle networking egress policy, and keep it patched. That is platform work, and it is precisely the sort of well-bounded infrastructure mandate a senior nearshore development team can take off a product roadmap without a six-month hiring cycle.
Key Takeaways
- Firecracker boots in roughly 125ms with under 5 MiB overhead, or about 28ms with snapshot-restore; the "VMs are slow" objection no longer holds
- Firecracker is about 83,000 lines of Rust with five emulated devices, against QEMU's 1.7 million lines of C
- gVisor reimplements around 274 syscalls in userspace and exposes 53 host syscalls without networking, 68 with, at roughly 50ms startup
- The real cost is no longer latency, it is that somebody has to build, operate and patch the execution substrate
The Risk Is Not in Your Cloud, It Is on Developer Laptops
Hosted sandbox products have largely converged on the right answer, because their threat model is explicit: they run strangers' code for a living. The harder problem sits inside your own organisation, on the machines where agents actually run most of the time, engineers' laptops and your CI runners.
Coding agents have started shipping their own OS-level isolation to address exactly this. Claude Code, for instance, includes native sandboxing built on operating system primitives, Seatbelt on macOS and bubblewrap on Linux, restricting filesystem and network access at the kernel level, and it exposes that runtime so an entire process can be wrapped in the same isolation (documented in the Claude Code sandbox environments guide). That is a genuine improvement over nothing. It is also, by design, a same-kernel boundary, and the microVM survey documents a path-based bypass of exactly this class of OS sandbox via /proc/self/root/. Defence in depth, not a terminus.
The subtler failure is temporal rather than spatial. A paper on what its authors call lingering authority makes the point precisely: coding agents are typically granted broad tool access for an entire task, even when a given resource was needed for one subgoal, so a temporary capability stays exposed long after the episode that justified it closed. Their prototype reference monitor, PORTICO, compiles an explicit task contract into epoch-bound, opaque handles that are removed from the planner's interface when the subgoal closes, and rejects stale replay before side effects land. In their evaluated runs no contract-forbidden effect executed, while controlled grants still recovered boundary work that a fixed narrow permission envelope would have blocked.
That is the design principle worth stealing even if you never adopt the tool: scope capability to the subgoal, not to the session, and make expiry a property of the runtime rather than a convention in a prompt. It pairs directly with the identity and credential problems we have written about in the agent overprivilege piece and our work on credential hygiene. Isolation without capability scoping still hands a compromised agent everything it was ever granted; capability scoping without isolation just means the escape happens one layer down.
The Patch Lag Nobody on Your Team Is Tracking
Suppose you do the right thing and adopt a microVM-backed sandbox product. There is a second-order risk that almost no procurement process asks about, and a 2026 comparative study measured it.
The study reads six engine-level properties together, host attack surface, information leakage, defence-in-depth stackability, public CVE history, patch cadence, and upstream fuzzing posture, across a set of AI sandbox products (published on arXiv in June 2026). Its first finding is reassuring in a structural way: the engine classes, microVM, userspace kernel, and OCI container, separate cleanly on every architectural axis, so the class you choose really does determine your risk profile. Products within a class, however, do not separate cleanly at all.
The second finding is the operationally painful one. Engine-side patch latency aggregates to roughly zero days for coordinated disclosures, meaning the upstream projects fix things promptly. Downstream lag, the time it takes the product you actually bought to pick up that fix, ranges from zero days to over 471 days, and in some cases the study characterises the pin policy as opaque or effectively unbounded. The authors name product pin policy as the dominant operator-facing variable. Your exposure is not determined by which engine the vendor's marketing page names. It is determined by how fast they bump the version, which is a question you have to ask explicitly and contractually.
The third finding is a gap in the market worth knowing about: the study splits fuzzing investment into three tiers and notes that the strongest available combination, a microVM engine paired with continuous public fuzzing, is unoccupied. Nobody is currently in that quadrant. That is not a reason to stay on containers, it is a reason to treat the sandbox layer as something you monitor rather than something you buy and forget.
Key Takeaways
- Engine class (microVM, userspace kernel, OCI container) separates cleanly on architecture; individual products within a class do not
- Upstream engines patch coordinated disclosures near-immediately, but downstream product lag measured from 0 days to over 471 days
- Vendor version pin policy, not the engine name, is the dominant variable in your actual exposure, so put it in the contract
- The microVM-plus-continuous-public-fuzzing combination is currently unoccupied by any product studied
What This Costs to Run at Team Scale
The budget objection is easier to dispose of than the engineering one. Metered sandbox compute is priced like ordinary compute: one vendor publishes $0.01667 per vCPU-hour and $0.00833 per GB-hour, and works a concrete example where 200 sandboxes cost $2,060 per month running inside your own cloud account versus $7,200 on their managed platform (Northflank's 2026 AI sandbox pricing comparison). Set that against the fully loaded cost of the engineers whose agents are consuming it and the isolation layer is a rounding error, whichever way you buy it.
Scale is not the constraint either. The same vendor reports reaching 100,000 concurrent sandboxes in 24 seconds from cold start with zero failures in a 2026 industry scale test, at a P99 allocation latency of 566 milliseconds. Whatever your agent fleet looks like, the substrate is not what will cap it, which is consistent with the finding in our analysis of parallel agent fleets that the bottleneck sits in review and merge, not in execution capacity.
What is genuinely scarce is governance maturity, and the survey data is blunt about it. A 2026 report drawing on more than 900 executives and technical practitioners found that 81% of teams are past the planning phase into testing or production, while only 14.4% have full security approval across their agent fleet, an average of 47.1% of an organisation's agents are actively monitored or secured, and 88% of organisations reported confirmed or suspected AI agent security incidents in the preceding year (Gravitee's State of AI Agent Security 2026). The same report notes that 25.5% of deployed agents can create and task other agents, which means the blast radius of one bad execution is not bounded by the agent that started it.
Read those four numbers together and the shape of the problem is clear. Deployment is nearly universal, oversight covers less than half of it, incidents are already the norm rather than the exception, and a quarter of the fleet can spawn more fleet. That is not a tooling gap. It is an ownership gap, and ownership gaps get closed by assigning a team, not by buying a product.
A Practical Isolation Policy You Can Actually Ship
None of this requires a platform rewrite. It requires deciding, once, which execution boundary applies to which class of code, and then enforcing that decision in the harness rather than in a wiki page.
The tiering that holds up in practice has three levels. Code your own pipeline built from your own reviewed source, running against your own infrastructure, is fine in an ordinary container; that threat model has not changed. Code an agent generated, or any third-party package an agent chose to install, belongs behind a hardware boundary, a microVM, with egress allowlisted rather than open. Anything genuinely adversarial or customer-supplied, including code paths reachable from prompt-injectable content, gets a microVM plus per-subgoal capability scoping and no persistent credentials in the environment at all.
Four operational rules make the tiering real rather than aspirational. Default the sandbox to network-deny and make egress an explicit, logged allowlist, because most exfiltration paths in agent incidents are a DNS lookup and an HTTP POST away. Give every sandbox a short, enforced lifetime with no state carried across tasks, so that a compromise cannot become persistence. Never mount long-lived credentials into an execution sandbox; broker short-lived tokens scoped to the subgoal, in the spirit of the epoch-bound handle design. And ask your vendor, in writing, how quickly they pin new engine versions, because the 471-day downstream lag in the comparative study is the risk you cannot see from the outside.
Then verify it rather than assuming it. Run an escape benchmark against your own harness on a schedule, treat an unexplained egress attempt from a sandbox as a security incident with a real post-mortem, and audit which agents can spawn other agents. This is ordinary DevOps and platform work with a security lens on it, not research, and it is measurable by the end of a quarter.
Key Takeaways
- Tier by provenance: your reviewed pipeline output can stay in a container, agent-generated and agent-installed code needs a hardware boundary
- Default sandboxes to network-deny with a logged egress allowlist, and give them short enforced lifetimes with no cross-task state
- Broker short-lived, subgoal-scoped tokens instead of mounting long-lived credentials into execution environments
- Verify continuously: run escape benchmarks against your own harness and treat unexplained sandbox egress as a reportable incident
Who Builds and Runs This Layer
The uncomfortable part of this topic is that almost every engineering leader who reads it agrees with it, and then does nothing, because the work does not belong to anyone. It is not a product feature, so the product teams will not take it. It is not an application security review, so the security function can only flag it. It is infrastructure with a security requirement attached and an ongoing operational burden, which is the exact category of work that falls between org charts.
It is also, for what it is worth, a well-scoped mandate. A small senior team can stand up a microVM-backed execution substrate, wire it into the agent harness and CI, implement egress policy and token brokering, and hand back a documented, benchmarked boundary in a quarter. That is not an open-ended research programme, it is a deliverable with an acceptance test, and it survives being owned by a team that is not the product team.
That is the shape of engagement StepTo is built around. We are a senior-led nearshore partner in Serbia working with European and US clients in overlapping hours, which matters more than usual here because an execution-boundary incident is a same-day conversation, not an overnight ticket. The relevant capabilities are platform and DevOps engineering, security engineering, and cloud infrastructure, and they are the sort of thing that works far better as a standing team than as a one-off project, which is why we default to a dedicated team model rather than fixed-scope delivery for infrastructure mandates.
For clients operating under EU data rules, the isolation decision and the data residency decision are usually the same decision, because where the sandbox runs determines where the code and the data inside it run. Building it inside your own cloud account rather than a vendor's is frequently the cheaper option on the published rate card anyway, and it removes an entire category of cross-border argument from the compliance review. Our own rates are public on the pricing page if you want to size the work before talking to anyone.
Decide the Boundary Before an Agent Decides It for You
The execution boundary is one of the few problems in the agentic stack with a genuinely settled technical answer. Hardware-enforced isolation is fast enough, cheap enough and mature enough to run agent-generated code today, the benchmarks to verify your own setup are published and open, and the tiering policy fits on one page. What is missing is not technology, it is ownership: a container that shares a kernel is the default in almost every agent harness because nobody was assigned to change it, and the survey data shows oversight covering less than half of deployed agents while incidents have already become routine. The retrofit cost only rises from here, because every month the fleet grows and every new agent inherits whatever boundary was in place when it launched. Pick the tiering, enforce it in the harness rather than in a policy document, put the vendor's version pin policy in the contract, and benchmark the result. If the layer has no owner inside your organisation, that is the actual finding, and it is a solvable one, whether you staff it internally or hand it to a <a href="/nearshore-development" class="underline decoration-dotted">nearshore team</a> that can treat it as a quarter-long mandate with an acceptance test at the end.
Building a team in Eastern Europe?
StepTo helps European and US companies build senior-led nearshore engineering teams in Serbia. Let's talk about what your next engagement could look like.
Start a conversationWritten by
Igor GazivodaFounder & CEO · StepTo
Igor has 15+ years in software engineering and business development. He specializes in scaling engineering teams, nearshore strategy, and AI-driven product development. He holds a Master's in Computer Science from the University of Belgrade.
LinkedIn →