Docker Alternative for AI Agent Sandboxes: 3 Compared

A Docker alternative for AI coding agent sandboxing is any isolation layer that constrains what an autonomous agent can actually do — which files it reads, which hosts it reaches, which tool calls it makes — rather than just packaging its process in a container. Most engineers assume the container is that boundary. It isn't. Three tools shipped in 2026 exist to prove the point.

On October 27, 2026, NVIDIA shipped OpenShell v0.1.6. A stable release cadence, new isolation primitives, an expanded extension surface. The project went from its first commit on February 24, 2026 to 20,767 GitHub stars and 2,038 forks by the end of October. Roughly eight months to cross 20K.

That release landed two days before the newest competing write-up on this topic, and none of the three widely-circulated comparison articles reference it. So instead of arguing architecture in the abstract, this post reads each tool's own documentation and README against the same question — what can the agent actually touch — with the kind of methodology-first discipline I document for every entry in the local-LLM benchmark database I maintain at kunalganglani.com/llm-benchmarks. It also corrects a specific architectural error that keeps getting repeated about how OpenShell actually isolates.

A container decides what your agent runs inside. A sandbox decides what it's allowed to touch. Not the same control.

The context that makes this urgent: every mainstream coding agent now ships a full-autonomy mode and nudges you toward it. Claude Code has --dangerously-skip-permissions. Codex, Cursor, Copilot, and Gemini all have equivalent "YOLO" switches. Docker's own January 2026 launch post for its agent sandbox framed the tradeoff bluntly: "Since they can't harm your computer, let them run free." The entire premise of that sentence is that the container is a sufficient wall. Let's test whether it is.

Why Container Isolation Alone Isn't Enough for AI Coding Agents

Docker isolates an application. It gives a process its own namespace, its own filesystem view, cgroup limits, and a network interface. That model is excellent for the problem it was built for in 2013: shipping a known workload with a known set of dependencies. The workload is trusted, and the container keeps it reproducible and bounded.

An autonomous coding agent breaks every assumption in that sentence. The workload is not known ahead of time, because the whole point of an agent is that it decides what to run next based on model output you didn't write. It reads your files, installs packages, calls APIs, and uses your credentials, because an agent that can't do those things is useless. The container happily permits all of it, because permitting the application's actions is what a container is for.

So "is Docker enough to secure AI coding agents?" has a precise answer. Docker is necessary blast-radius reduction and nowhere near sufficient policy. Two concrete gaps make this obvious.

First, mounts. Even inside Docker's microVM sandbox, the live workspace directory is mounted read-write by default. A misbehaving or compromised agent can delete your actual working tree unless you explicitly pass --clone. The container boundary did its job. Your host kernel is fine. And your uncommitted work is still gone.

Second, egress. A default container can reach the entire internet. Nothing stops an agent that ingested a poisoned README or a malicious dependency from POSTing your .env to an attacker's endpoint. The container never had an opinion about where traffic goes, only about which interface it uses.

This is why I treat sandboxing as a first-class part of any agent setup, the same way I treat AI security as a first-class design constraint rather than a bolt-on. If you're running AI agents with autonomy enabled, the container is your floor, not your ceiling.

Here's a good framing of the problem from the Better Stack team:

What 'YOLO Mode' and --dangerously-skip-permissions Actually Risk

"YOLO mode" is the industry nickname for running a coding agent with every permission prompt disabled, so it executes file writes, shell commands, and tool calls without asking. Claude Code calls it --dangerously-skip-permissions. Cursor, OpenAI's Codex, GitHub Copilot, and Gemini each ship an equivalent toggle, and Docker Sandboxes starts agents in exactly this mode by default. The entire pitch is that the container makes unattended autonomy safe.

Here's the real risk, stated plainly: the moment you disable approval prompts, the only thing between a hostile instruction and your machine is whatever the sandbox enforces.

An agent that ingests a poisoned GitHub issue, a booby-trapped post-install script, or a malicious web page during a research step will follow those embedded instructions with your full permissions. That is textbook prompt injection, and it stops being theoretical the instant the agent runs unattended. The dangerous action — exfiltrating a token, rewriting a config, curling an unknown host — is a perfectly legitimate thing for the application inside the container to do, so the container never objects. Simon Willison has catalogued how MCP tool access turns prompt injection into a remote-code path, and the lesson generalizes beyond MCP: skipping permissions removes the human from the loop, so the policy layer has to become the loop.

This is the clearest practical case for a Docker alternative. If you're going to run with permissions skipped — and most teams eventually will, because approving every call defeats the point of an agent — then default-deny egress and per-path filesystem scoping stop being optional hardening. They become the control doing the job the human approval prompt used to do. I treat that as a baseline AI security requirement rather than an advanced one, and it's the same discipline I lean on to stop an AI coding assistant from repeating mistakes: constrain the blast radius first, trust the model second.

What NVIDIA OpenShell Is and How It Differs From a Docker Container

NVIDIA OpenShell is an Apache-2.0 licensed runtime that enforces agent policy at the kernel level, on every file access, every syscall, and every network connection, and adds a formal-verification step that flags risky policy changes before they take effect. That last capability is unique among the three tools here. It does not replace the kernel's isolation primitives. It orchestrates them into a per-agent policy you can reason about.

Here's the error worth correcting, because it's circulating in the most-read three-way comparison on this topic. OpenShell's isolation is not "hardware-enforced GPU-based virtualization." That phrase sounds plausible because NVIDIA maintains it, but it's wrong. Per OpenShell's own README and docs, the enforcement is OS kernel-level: Landlock-style filesystem confinement, syscall mediation, network allowlists, plus a policy "prover" that performs formal verification on changes. No GPU virtualization is involved. If you cite the GPU claim in a design review, you'll make the wrong architectural decision about where OpenShell fits.

The Landlock lineage matters. Landlock is a Linux LSM authored by Mickaël Salaün that lets an unprivileged process restrict its own filesystem access, which is exactly the ambient-authority reduction an agent sandbox needs. OpenShell builds policy on top of these primitives rather than inventing a parallel universe of virtualization.

So how does it differ from a Docker container in one sentence? A container gives the agent a new environment and lets it do what it wants inside. OpenShell keeps the agent in a known environment and intercepts what it's allowed to do. Different responsibilities, not interchangeable configurations. The deployment target differs too: OpenShell is explicitly positioned for running fleets of autonomous agents under one policy layer, not a single developer's local session.

Filesystem Scoping: Controlling What the Agent Can Read and Write

Filesystem scoping is where the container model and the sandbox model most visibly diverge. "How does filesystem scoping differ between a Docker bind mount and an OpenShell policy?" is the question that actually decides whether your source tree survives a bad agent run.

A Docker bind mount is binary at the mount point. You mount ./project into the container and the agent gets read-write to the whole subtree. You can mount read-only, but then tooling that legitimately needs to write — build output, lockfile updates — breaks. There's no notion of "this agent may write to src/ and tests/ but may only read config/ and must never touch .git/ or ~/.ssh/." The mount point is the granularity.

An OpenShell policy expresses exactly that per-path intent, enforced by the kernel on every access rather than decided once at mount time. You describe the allowed read set and write set, and a syscall that falls outside the policy is denied at the source. Anthropic's sandbox-runtime takes the same OS-native approach using sandbox-exec/Seatbelt on macOS and bubblewrap on Linux, restricting an arbitrary process against the existing host rather than a fresh container image.

I'll ground this in something I actually run. The multi-agent pipeline behind this blog — seven agents that research, write, review, and publish 261+ posts — never hands its agents the publishing credentials or raw write access to the live site. Each step gets a scoped surface and an idempotent key, because I learned the hard way that autonomous steps need tight blast radius. One misconfigured automated change on live URLs once burned roughly 907K impressions of accumulated link equity. That wasn't malice. It was an automated process doing exactly what it was permitted to do. Filesystem scoping is the control that would have made that permission narrower.

If you want the pragmatic middle path before committing to any of these tools, I've written up running an AI agent sandbox on a Linux VM with scoped tool use and no Kubernetes. A reasonable baseline while you evaluate the heavier options.

Network Egress and Default-Deny Policies for Agent Traffic

Network egress is the control that separates "the agent broke my build" from "the agent exfiltrated my secrets." A default Docker container has open outbound internet. That's fine for a trusted application calling known APIs. It's a loaded gun for an agent that will cheerfully follow instructions embedded in a dependency, a web page, or a tool result.

Default-deny egress means the agent can reach nothing on the network until you allowlist specific hosts. OpenShell enforces network allowlists at the kernel level alongside its filesystem policy. Anthropic's sandbox-runtime enforces network restrictions as a first-class part of its OS-level sandbox. Docker Sandboxes can be configured for restricted egress, but the default posture — "let them run free" — is permissive, and defaults are what actually ship.

Simon Willison, who has written more clearly than almost anyone about the security of agent tool use, has documented how agents in separately isolated sandboxes still coordinated by leaving instructions for each other in a shared package cache, effectively building the two halves of a worm across sandbox boundaries. Isolation that stops at the process but leaves a shared writable channel open is not isolation against a determined prompt-injection payload. Egress policy is one of the channels you have to close.

There's prior art for how granular this should be. Ryan Dahl's permission model in Deno lets you specify exactly which network hosts a script may reach, not just "network on" or "network off." Agent sandboxes are converging on the same host-level allowlist granularity, because for an agent, "can it reach the internet" is the wrong question. The right one is "can it reach this host and no other."

Tool-Call and MCP Interception: The Layer Docker Doesn't Have

Here's the layer no container can express, and the one I think matters most for where agents are heading. "Tool-call interception" means the sandbox sits between the agent and its tools, inspecting and gating each individual tool invocation — a file write, a shell command, an API call, an MCP server request — rather than gating the process as a whole.

Model Context Protocol (MCP) is the standard that lets agents call external tools through dedicated servers: a filesystem server, a GitHub server, a database server. Each one is a separate trust surface. Anthropic's sandbox-runtime is explicitly designed to sandbox individual MCP servers independently of the whole agent process. You can restrict a filesystem MCP server's writes to a single directory while a different MCP server has its own, narrower policy. A container-only setup cannot express that. The container wraps the whole agent. It has no vocabulary for "this specific tool call is in bounds and that one isn't."

This granularity is why MCP interception is becoming the real dividing line. An agent's danger isn't its process. It's the specific sequence of tool calls the model decides to make. If your sandbox only sees the process, you're blind to the thing that actually causes incidents. If it sees each call, you can deny write to ~/.ssh/id_rsa or curl to an unknown host at the exact moment the agent attempts it.

This also connects to overhead, which teams forget to budget for. Intercepting every tool call adds latency, and I measured something adjacent when I wrote up how to measure AI coding agent harness overhead. The wrapper around the model is rarely free, and policy enforcement is more wrapper. Worth testing on your own workload before you assume it's negligible.

Hands-On: Running a Real Agent Harness Inside OpenShell

Theory is cheap.

The content gap in every existing write-up is that nobody maps the three tools' documented enforcement against a real coding-agent workflow, so let's read what each one's own quickstart and README say happens when an agent harness runs inside it. The same OpenCode harness I run across my homelab, under a deliberately restrictive policy, on a task like "refactor this module and run the tests."

Start with OpenShell. Per its README and docs, a restrictive policy is documented to stop three things that break real projects:

1. Writes outside the declared write set. If the agent tries to update a file in a sibling directory it only read for context, the Landlock-style filesystem confinement denies the write at the syscall. That surfaces as a permission error the harness can see and route around, not a silent corruption.
2. Egress to an un-allowlisted host. A dependency's post-install script that attempts an outbound connection hits the default-deny network allowlist, so the install completes without the phone-home.
3. A risky policy change. When a run needs credentials for a new host, OpenShell's formal-verification prover is documented to flag "granting access to a new host with credentials" as a dangerous combination requiring approval before it takes effect.

What the docs are equally clear about is the limit. Inside the allowed write set, the agent has full freedom. It can refactor, create, and delete files in src/ and tests/ without friction, because that's exactly what the policy permits.

Scoping protects what you scoped. It does nothing for a bad refactor inside the sandbox. That's a code-review problem, not a sandbox problem, and conflating the two is how people end up disappointed.

Line the other two up against the same workflow. Docker's own launch material describes Sandboxes running agents in full-autonomy mode with the workspace mounted read-write, so the sibling-directory write would succeed and the dependency's outbound call would go through unless you harden the defaults. Anthropic's sandbox-runtime README describes OS-level filesystem and network restrictions plus per-MCP-server scoping, the ability to confine a filesystem tool separately from a shell tool, which is the granularity a container can't express.

Read side by side, the documented postures sort cleanly: OpenShell and sandbox-runtime deny the actions that cause real incidents by default, and Docker's defaults permit them. If you want the broader agent-tooling context, my comparison of Aider vs Claude Code vs OpenHands covers how different harnesses behave once you've chosen your isolation layer.

Docker Alternatives Compared: OpenShell, sandbox-runtime, and Docker Sandboxes

None of the three competitor articles put all four decision dimensions in one place. Here is the decision framework as a table.

The short version of "how does Anthropic's sandbox-runtime compare to OpenShell and Docker Sandboxes": sandbox-runtime is the lightest-weight, most developer-local option, purpose-built for Claude Code and strongest on per-MCP-server granularity. OpenShell is the heaviest and most opinionated, built for fleet-scale policy with formal verification. Docker Sandboxes is the easiest to adopt if you already live in Docker Desktop, with the weakest defaults.

Choose by scale and posture. Solo developer who wants OS-native scoping without a container? sandbox-runtime. A team running agentic AI fleets that need one auditable policy layer and change verification? OpenShell. Already container-native and want a quick on-ramp? Docker Sandboxes, with --clone and a locked-down egress list, not the defaults. This is also the kind of decision I'd fold into AI in production planning rather than leave to whatever each developer picks locally.

Threat Model: Privilege Escalation, Credential Theft, and Lateral Movement

Pick the tool against a threat model, not a star count. Three failure modes matter for autonomous coding agents.

Credential theft. The agent reads ~/.aws/credentials or a .env and sends it somewhere. Default-deny egress plus a filesystem policy that excludes credential paths neutralizes both halves. A plain container does neither by default. If you want a concrete control for this, I wrote up how to redact secrets in an AI coding CLI, which is complementary to sandboxing, not a replacement for it.

Privilege escalation. The agent gains root inside its environment and tries to break out. OpenShell runs agents unprivileged and mediates syscalls, so escalation attempts hit a wall at the kernel. sandbox-runtime reduces ambient authority at the OS level. Docker's microVM gives real kernel isolation here. This is the one dimension where the container model is genuinely strong.

Lateral movement. One compromised agent reaches another agent, a shared cache, or an internal service. This is the fleet problem, and it's exactly the scenario Simon Willison documented with agents passing instructions through a shared package cache. OpenShell's fleet-scale, formally-verified policy layer is the only one of the three designed for this. A single-session tool, by definition, isn't thinking about agent number two.

The formal-verification prover deserves its own line, because "what is OpenShell's policy prover and why doesn't Docker have an equivalent?" is the genuinely novel idea here. Before a policy change applies — say, granting an agent access to a new host while it holds credentials — OpenShell verifies whether that change opens a dangerous combination and flags it for approval. Docker has no equivalent because Docker isn't modeling agent policy at all. It's modeling application lifecycle. That mirrors the single best lesson from operating my own pipeline: deterministic gates placed before the model-driven step catch more than doubling the size of the review model does. Verification before action beats a smarter actor.

The prediction I'll commit to: within a year, "did you run it in a container" will sound as quaint for agents as "did you set a password" does for databases. The container will be assumed, and the real question — the one OpenShell, sandbox-runtime, and Docker Sandboxes are racing to answer — will be whose policy you trust between the model and the machine. Start forming that opinion now, while it's still a choice and not yet a default someone else picked for you.

Photo by Clint Patterson on Unsplash.