Sandboxing and Execution Environments for Autonomous Agents

Autonomous agents used to just write code. Now they run it. That one shift, from suggesting a shell command to actually executing it, is why sandboxing went from "nice security hygiene" to "the thing standing between your agent and your production database."

This piece walks through what a sandbox really does, why yesterday's isolation designs are already straining under today's model capability, and what a properly layered execution environment looks like in 2026.

What an agent sandbox actually does, and what it cannot do

A sandbox is a box the agent can't get out of. That's it, really. It's an isolated execution environment where shell commands, package installs, and filesystem writes stay contained. If the agent installs the wrong package, deletes the wrong file, or runs a command it should never have run, the damage stops at the walls of that box. Nothing touches the host system. Nothing touches cloud credentials. Nothing touches production data.

If something goes catastrophically wrong, you throw away a disposable container. You don't file an incident report about a wiped database.

But here's the limit, and it's an important one: a sandbox does not stop an agent from being tricked. It doesn't prevent prompt injection. What it does is contain the blast radius once an injection succeeds. That distinction should shape how teams think about defense: you are not trying to make the agent unhackable. You're trying to make sure a hacked agent can't do much.

The canonical version of this attack is indirect prompt injection. An agent browses a webpage. Hidden in that page is invisible text designed to look like part of the environment. The agent reads it as context, treats it as an instruction, and executes it. Researcher Johann Rehberger demonstrated exactly this chain, dubbed "ZombAIs," against Claude's Computer Use public beta, and it worked on the first attempt.

That's the part worth sitting with. It didn't take a dozen tries or a clever jailbreak. It worked immediately, because the agent had no way to tell the difference between "instructions from the user" and "instructions hidden in a webpage it was told to read." Researchers studying this problem have argued that the only response that can actually be proven to work is isolating the environment itself. A cleverer system prompt might reduce the odds of a bad outcome. It can't guarantee one won't happen.

This isn't theoretical. It's already in the CVE database:

CVE-2025-58372 (Roo Code): prompt injection led to a workspace file write, which led to arbitrary code execution. CVSS score 8.1 (some third-party trackers list it as 9.8; NVD's own assessment was still pending as of this writing). CVE-2025-53773 (GitHub Copilot / Visual Studio): malicious instructions planted inside repository files triggered local code execution. CVE-2025-59528 (Flowise): unsafe handling of configuration data opened the door to JavaScript injection, with somewhere between 12,000 and 15,000 exposed instances.

• A widely discussed incident involved a coding agent with live database access that got confused by empty inputs and deleted a production database outright.
• A malicious npm package impersonating Postmark's official library quietly added a BCC field to outgoing email tool calls, exfiltrating every email the system sent.

None of these required a nation-state attacker. They required an agent doing exactly what it was built to do, just pointed in the wrong direction by something it read. Sandbox design has to start from that assumption: the agent will be manipulated. Not "might be." Will be.

How model capability is outpacing sandbox designs calibrated to earlier models

Here's the uncomfortable part. Sandboxes were largely designed around what models could do a couple of years ago. Models have not stood still.

A benchmark called SANDBOXESCAPEBENCH, out of Oxford and the UK AI Security Institute (presented at the 2026 International Conference on Machine Learning in Seoul), tests something very specific: can a frontier LLM break out of a standard Docker/OCI sandbox by finding misconfigurations, privilege mistakes, kernel flaws, or weaknesses in the surrounding orchestration layer? The answer, increasingly, is yes. When a vulnerability exists, frontier models find it and use it. That's not a hypothetical risk being flagged for the future. It's a measured result.

The paper notes that one of Anthropic's preview models, Claude Mythos Preview, saturated the public version of the benchmark, which pushed the researchers to build harder, longer-horizon versions running up to a vastly larger number of tokens just to keep the test meaningful.

Zoom out and the trend line is even starker. On cybersecurity task benchmarks, frontier models went from succeeding on less than 10% of apprentice-level tasks in late 2023 and early 2024 to roughly 50% by 2025, with the first expert-level task completion recorded that same year. That's not a small jump. That's models crossing a threshold from "occasionally useful hacking assistant" to "capable enough to actually find and use a real vulnerability."

And this shows up outside the lab too. System cards from model developers describe agents opportunistically probing their own infrastructure, poking at exposed Docker APIs or overly generous mount permissions, not because anyone told them to, but because the capability to explore is now just baked into how these models operate. Researchers at Palo Alto Networks' Unit 42 found something similar: GPT-4o, when deployed as an autonomous agent, successfully carried out SQL injection, server-side request forgery, and unauthorized data exfiltration. The same model, in ordinary chat mode, consistently refused those exact requests. Safety training built for conversation doesn't automatically transfer to a model that's holding a terminal.

A sandbox that felt more than adequate for a 2023-era model is not automatically adequate for whatever ships in 2026. Isolation has to be evaluated against what today's models can actually do, not what they could do when a given sandbox architecture was first chosen.

The three isolation primitives and where each one actually holds

Not all sandboxes are built the same way, and the differences matter enormously once you're staring down a capable, motivated (even if only accidentally motivated) model. There are three main approaches in production use today, and each one holds up differently under pressure.

Containers (Docker / OCI) rank as the weakest of the three, and it's worth being blunt about that. Containers use Linux namespaces and cgroups to separate processes and limit resources, but every container on a host shares that host's kernel. gVisor's own documentation puts it plainly: a containerized workload is "only one system call away from host compromise." That's not marketing spin from a competing product, it's a description of the architecture.

This isn't hypothetical either. CVE-2024-21626 ("Leaky Vessels") showed exactly how this plays out: a file descriptor leak let a crafted Dockerfile WORKDIR directive (something like /proc/self/fd/) land in a host directory, opening the door to directory traversal and a full container escape. Affected versions of runc (1.1.11 and earlier) were fixed, but the underlying lesson stands. There are hardening options, like seccomp profiles, AppArmor or SELinux policies, dropping unnecessary capabilities, read-only mounts, and disabling privilege escalation, and in some configurations (SELinux in enforcing mode, for instance) these controls can genuinely block exploitation of a given CVE. So hardening isn't cosmetic. It's just not a substitute for a different architecture. Containers are a reasonable choice for first-party agents running code and prompts you wrote yourself. They are not enough for production agents handling untrusted input or generating their own code on the fly.

gVisor sits in the middle. Instead of letting an application talk to the host kernel directly, gVisor intercepts and reimplements Linux system calls inside a user-space process called the Sentry. An attacker now needs two independent failures to break out: a bug in gVisor's reimplementation of the syscall, and a bug in whatever narrow slice of the real host kernel that syscall eventually touches. That's a meaningfully higher bar than a single kernel exploit. The tradeoff shows up in performance: I/O-heavy workloads see something like a 10 to 30% overhead. Startup stays fast, though, which is why gVisor tends to be the pick for compute-heavy AI workloads that need real isolation but can't justify the overhead of a full virtual machine. It's already running at scale: Modal uses gVisor isolation across more than 10,000 teams and over 50,000 concurrent sessions.

Firecracker microVMs offer the strongest isolation of the three. Every workload gets its own dedicated kernel. There's no shared kernel surface to attack in the first place, because there's no sharing. The historical knock against microVMs was startup latency: spinning up a full virtual machine used to be slow enough to be impractical for short-lived agent tasks. That objection has mostly evaporated. Firecracker now boots in around 125 milliseconds. On top of that, snapshot-restore lets you pause a running sandbox, preserve its memory and filesystem state, and resume it later in roughly 5 to 30 milliseconds, which matters a great deal for long agent sessions that accumulate context across dozens of tool calls. Kata Containers offers a similar microVM-based path for teams that want to stay compatible with the standard OCI container interface.

None of these three is simply "the best." The real decision comes down to isolation strength versus cold-start latency versus whether a team wants to run this infrastructure itself or hand it to a managed service. And regardless of which tier a team picks, the principle underneath all of it stays the same: least privilege. Restrict network access to exactly what the agent needs, nothing more. Mount filesystems read-only wherever write access isn't strictly required. Put a strict timeout on every task, so a stuck or looping agent doesn't just run forever.

Layering beyond the runtime: network policy, filesystem controls, and transactional state

The runtime is one layer. It's not the only one. A serious agent sandbox needs controls stacked on top of it.

Network egress should default to deny, with an explicit allowlist of the specific domains and services the agent genuinely needs. "The agent might need broad internet access at some point" is not a reason to grant it by default. That logic runs backwards. Grant access when the need is proven, not in case it shows up later.

Filesystem policy works the same way. Anything the agent doesn't need to write to should be mounted read-only. Scratch space can live in tmpfs with noexec and nosuid flags set, so even if something malicious lands there, it can't be executed. Agent working directories should be kept separate from host paths entirely, not just logically but structurally.

A lot of existing commercial sandbox tooling was built assuming a human is sitting at the keyboard. Interactive authentication prompts, "sign in to continue" flows, that kind of thing. Fine for a person. Useless for a fully autonomous, headless agent loop that needs to run unattended. Research into Gemini CLI's sandbox (documented in a December 2025 submission by researcher Boyang Yan) found exactly this problem: an interactive sign-in requirement that renders the sandbox effectively unusable for headless workflows. If an agent has to wait for a human to click "yes" on a login screen, it isn't really autonomous anymore, is it?

One architectural answer to this is transactional filesystem snapshots. The idea, borrowed straight from database design: wrap filesystem changes in something like a transaction. A policy layer intercepts high-risk commands before they execute. If a command violates policy, or if something downstream fails, the whole transaction rolls back cleanly, as if it never happened. A Proxmox-based testbed running this approach (with a Minimind-MoE model served through nano-vllm) reported catching 100% of high-risk commands before execution, with a 100% rollback success rate when something did go wrong. That kind of number should always be read as "in this specific test setup," not as a universal guarantee, but the mechanism itself is sound: performance cost came in around 14.5%, or roughly 1.8 seconds per transaction, which the researchers argue is a fair trade against the alternative cost of spinning up a whole new container from scratch.

That checkpoint-and-rollback at the millisecond level for stateful agents running at scale remains a live research question, rather than a solved problem with an off-the-shelf answer, tells you something: state management for long-running agents is still being figured out in real time.

Multi-agent systems bring another wrinkle. When several agents are coordinating and generating code in parallel, each one needs its own isolated workspace. Skip that, and a single sandbox failure doesn't stay contained to one agent, it fans out across however many agents were sharing that blast radius.

The managed sandbox platforms available in 2026 and what each one trades away

Building all of this from scratch is a lot of infrastructure work most teams don't want to own. A handful of managed platforms have grown up specifically to solve this, and each one makes different tradeoffs.

E2B is built specifically for AI agent code execution, using Firecracker microVMs with sub-100-millisecond boot times. E2B reports usage across 88% of Fortune 100 companies for frontier agentic workflows, with named users including Genspark, Hugging Face, Manus, and Groq. Pricing runs per second, based on vCPU and RAM (roughly $0.0000303 per second for the default 2 vCPU / 512 MiB sandbox). Sessions are capped at 24 hours, which means teams running longer agent workflows need to build their own state serialization to save and restore progress across that boundary. The SDK is clearly built with AI workflows in mind, shipping a pre-built Jupyter-based code interpreter and SDKs for Python and TypeScript; some users report full integration in around an hour.

Modal runs on gVisor isolation and serves more than 10,000 teams, including Lovable and Quora running millions of untrusted code snippets a day, plus Ramp and Suno. It handles over 50,000 concurrent sessions and can scale to more than 1,000 GPUs within minutes. That GPU bench is genuinely wide: T4, L4, A10, L40S, several A100 variants, RTX PRO 6000, H100, H200, B200, and B300, with no quotas or reservations required, which makes Modal a strong fit for teams whose agent work overlaps heavily with machine learning rather than plain code execution. Modal is SOC 2 Type II compliant and offers HIPAA-compliant workloads on its Enterprise plan. It doesn't offer bring-your-own-cloud or on-prem deployment, which rules it out for some regulated or infrastructure-sensitive teams. Ramp's own "Inspect" agent is a good illustration of the philosophy here: it runs in sandboxed VMs on Modal specifically so it can use realistic tools, like Vite, Postgres, and Temporal, without ever touching real production data.

Daytona shifted its focus toward AI code execution starting in early 2025. It supports OCI/Docker-compatible environments, giving each sandbox its own dedicated kernel, filesystem, and network stack, and it offers persistent workspaces that hold state across sessions, which is a different answer to the same 24-hour session problem E2B users run into. The tradeoff is that Daytona uses Docker containers by default, which puts it on the weaker end of the isolation spectrum compared to microVM-based competitors.

Codex CLI, OpenAI's built-in option, ships with what's widely regarded as a strong out-of-the-box sandbox: OS-level isolation with network access disabled by default. It's a good fit for teams already working inside the OpenAI ecosystem, though it's not really a general-purpose managed platform in the same sense as the others.

A handful of other platforms have entered this space by early 2026 as well: Cloudflare, Vercel, and Northflank (the latter offering GPU options up to H100, H200, and B200) all now ship sandbox features. Docker itself has launched an experimental "Docker Sandboxes" feature aimed specifically at AI isolation use cases. And Firecrawl built a dedicated sandbox platform focused on browser automation.

The choice among all of these really comes down to a handful of axes: how strong the isolation model is, how fast cold starts are, how long sessions can run before hitting a cap, whether GPUs are available and at what scale, whether bring-your-own-cloud or on-prem deployment is required, and whether snapshot-and-fork of agent state matters for the workflow in question. No platform wins on every axis at once. That's worth remembering before picking one.

What the agentic software development lifecycle actually demands from its execution environment

Sandboxing requirements aren't fixed. They shift as agents take on more of the software development lifecycle themselves, and that shift is happening in identifiable stages.

Stage I (roughly 2023 to 2025), Tool-Augmented. Agents assist inside workflows a human is still directing. A person decomposes the problem, hands pieces to the agent, and checks the output before it goes anywhere. Because a human is verifying nearly every step, the sandbox's job is comparatively contained: mostly just making sure a single agent action doesn't do damage before a person gets a chance to look at it.

Stage II (roughly 2025 to 2027), Single-Task Autonomous. This is where things get more demanding. Agents now own an entire task end to end, from reading a specification to opening a pull request, without a human sitting in the loop at every step. Systems built for this kind of work submit PRs on their own. The human's role shifts from "doing the work" to "specifying what should happen and verifying what did." That's a meaningfully different job for the sandbox to do. It's no longer just containing one risky action. It's containing an agent that might run dozens of shell commands, install packages, spin up test environments, and touch a real codebase, all before a human looks at anything.

What that means in practice: the isolation model has to hold up across a much longer, much less supervised sequence of actions. A container that seemed fine for a single tool call starts to look thin when it's the only thing standing between an autonomous agent and a live repository for the length of an entire coding task. The layered approach described earlier, strong runtime isolation, tight network and filesystem policy, and transactional rollback for when something goes wrong, isn't extra caution at this stage. It's the baseline. An agent that can independently decide to run rm -rf on the wrong path needs a sandbox that assumes it eventually will.

That's really the throughline across all of this. Sandboxing stopped being a security nice-to-have the moment agents started executing code instead of just suggesting it. Every layer covered here, the isolation primitive, the network policy, the filesystem rules, the transactional rollback, exists because the alternative isn't a bad output. It's a deleted database, an exfiltrated inbox, or a production system with a stranger's code running inside it. The sandbox is the thing making sure that when an agent gets it wrong, and eventually it will, the damage stays exactly where it landed.