How to run coding agents securely: sandboxes, microVMs and defaults

Coding agents stopped being autocomplete a while ago. Claude Code, Codex, GitHub Copilot's coding agent, Gemini CLI, Grok Build and orchestrators such as OpenClaw now run shell commands, install dependencies, edit files, call APIs and sometimes work unattended for hours.

That changes the threat model. One prompt injection hidden in a README, one malicious postinstall script, or one badly guessed cleanup command can leak credentials, damage a machine or open a path into your network. The working assumption across the industry is now simple: treat anything an agent runs as untrusted code, and design isolation accordingly.

This guide explains the isolation options, what the major tools do by default, and a practical setup for individuals, teams and production pipelines.

Why a plain container isn't enough

Standard Docker containers share the host's kernel. They are fine for packaging trusted software, but a kernel vulnerability or a misconfiguration (a mounted Docker socket, a privileged flag, a writable host path) can let code break out. For code written or chosen by a model, a container on its own is a weak boundary.

Isolation options, from strongest to weakest:

Tier	Technology	How it isolates	Start-up	Good for
Strongest	MicroVMs and VM-isolated sandboxes (Firecracker, Kata Containers, libkrun, Hyper-V isolation)	Each sandbox has its own guest kernel, backed by hardware virtualisation	Around a tenth of a second	Untrusted code, multi-tenant platforms, unattended agents
Strong	gVisor	A user-space kernel intercepts system calls before they reach the host	Fast, no VM boot	Kubernetes-native isolation, a solid middle ground
Medium	Hardened containers	Namespaces, cgroups, seccomp, AppArmor or SELinux, dropped capabilities, non-root	Milliseconds	Trusted repositories and internal automation
Weakest	OS-level process sandboxes (Landlock, macOS Seatbelt, bubblewrap)	Restricts files, network and system calls for one process tree	Near zero	Everyday local development, as a first layer

MicroVMs have become the default recommendation for high-risk work because each session gets its own kernel and a tiny virtual device model, which shrinks the attack surface dramatically. The hyperscalers made the same choice: AWS runs Lambda and Bedrock AgentCore on Firecracker, and Microsoft puts each Azure sandbox session inside its own Hyper-V boundary.

Isolation is only one of seven controls

A strong sandbox with open networking and real API keys inside it is still a data-exfiltration tool. Good setups layer these controls:

Compute isolation. Prefer a fresh microVM or sandbox per session. Create it, run the task, destroy it. Share nothing between users or sessions.
Default-deny network egress. Block outbound traffic, then allow only what the task needs: your package registries, your Git host, specific APIs.
Secrets stay outside. Never place long-lived keys in the sandbox's environment. Use a credential proxy or short-lived, narrowly scoped tokens, so the agent can make authenticated requests without ever seeing the secret.
Filesystem and resource limits. Read-only root filesystem; write access only to the project workspace and temporary space. Cap CPU, memory, process count and disk. Run as a non-root user with privilege escalation disabled.
Reviewable output. Changes leave the sandbox only as a diff or pull request that a person reviews. Plan, approve, then execute.
Audit logging. Record commands, network requests and file changes, and send them to the same place as your other security logs.
Policy outside the agent. Permissions and allow-lists belong to the runtime or orchestrator, never to configuration the agent itself can edit.

If you remember one sentence: microVM isolation, default-deny egress and brokered secrets together are what separate a strong setup from a comforting one.

What the major tools do by default

Defaults matter, because most people never change them. Here is how the widely used agents approach isolation today (check each vendor's documentation for the latest details before relying on them):

Tool	Where it runs	Isolation	Network	Secrets
GitHub Copilot coding agent	Cloud, inside GitHub Actions	Ephemeral environment per session, destroyed afterwards	Firewall on by default; package registries allowed	Repository and organisation secrets are not available; only secrets added to a dedicated Copilot environment
OpenAI Codex (cloud)	OpenAI-managed containers	Isolated container per task, preloaded with your repo	Setup phase can install dependencies; the agent phase is offline by default	Removed before the agent phase starts
Google Jules	Google Cloud VM	Repository cloned into an isolated VM that is destroyed when the task ends	Managed by Google	Stay in Google's environment, not on your machine
Gemini API code execution	Google-hosted sandbox	Python-only sandbox for model-written code	No network access	Not applicable; you can't install your own packages, and each run is capped at 30 seconds
Gemini CLI	Your machine	Optional sandbox: macOS Seatbelt profiles, or Docker/Podman containers	Depends on the profile	Your responsibility
Grok Build	Your machine	Optional OS-level sandbox (Landlock on Linux, Seatbelt on macOS); off by default, with workspace, read-only and strict profiles	Strict and read-only profiles block child network access on Linux only	Your responsibility; custom profiles can deny paths such as `.env` or key files
Claude Code	Your machine or CI	Built-in sandbox using OS primitives (bubblewrap on Linux, Seatbelt on macOS), plus a permission system for tools	Proxy with domain allow-list when sandboxed	Your responsibility; deny rules can block sensitive files
OpenClaw	Your machine (self-hosted gateway)	Tool execution can run in a Docker sandbox; opt-in	Sandbox containers default to no network	Stay on your machine, which widens the blast radius if the gateway is compromised

Two patterns stand out:

Cloud agents (Copilot, Codex cloud, Jules) isolate by default because the vendor runs the infrastructure. Your job is mostly scoping: which repositories they can touch, which secrets they get, and whether outbound network access is allowed.
Local agents (Gemini CLI, Grok Build, Claude Code, OpenClaw) run with your user's permissions unless you switch sandboxing on. Out of the box, they can usually read everything you can read, including SSH keys and cloud credentials.

A lesson from OpenClaw: the sandbox is only as good as its configuration

OpenClaw is a popular open-source, self-hosted agent gateway that connects messaging apps to coding agents. It supports Docker sandboxing for tool execution, with hardening such as read-only root filesystems and dropped capabilities. Security researchers have nevertheless shown that if an attacker can influence the sandbox configuration, they can add a bind mount for the Docker socket and escape to the host by starting a privileged container.

The general lessons apply to every setup:

Never mount the Docker socket into an agent sandbox. It is equivalent to root on the host.
Validate sandbox configuration as carefully as you validate user input, and keep it out of the agent's reach.
Treat "elevated" or "exec on host" escape hatches as high-privilege features that need explicit approval every time.

Local sandboxes for developers

For work on your own machine, a sensible progression:

Turn on the built-in sandbox in whichever agent you use, and keep tool permissions on "ask" for anything outside the workspace.
Deny sensitive paths explicitly: ~/.ssh, cloud credential folders, .env files, private keys.
Move to a microVM sandbox for longer or unattended runs. Docker Sandboxes, for example, runs agents such as Claude Code, Codex, Copilot and Gemini inside a dedicated microVM per session, mounts only the project workspace, applies network policies, and uses a proxy so the agent never sees your credentials. Docker has also introduced Cloud Sandboxes so the same setup can move from a laptop to the cloud for parallel tasks.
Use a separate machine or VM for untrusted repositories. Cloning an unknown project and letting an agent "just run the tests" is exactly how malicious install scripts get executed.

Managed sandboxes for teams and products

If you build agents into your own product, or run many agents in parallel, use a platform designed for it rather than rolling your own. The options fall into two groups.

Hyperscaler sandboxes fit best when you are already standardised on one cloud, because they plug into its identity, networking, logging and data-residency controls:

AWS Bedrock AgentCore: one Firecracker microVM per session, sessions up to eight hours, memory cleared when the session ends.
Microsoft Azure: Azure Container Apps dynamic sessions run each session in its own Hyper-V sandbox from pre-warmed pools, with Python, Node.js and full shell runtimes; outbound networking can be disabled per session pool. The newer ACA Sandboxes add default-deny egress with a proxy-enforced allow-list, plus snapshot-based suspend and resume so an agent can pause a long task and continue later. Azure Logic Apps uses the same technology for the code interpreters in its agent workflows.
Google Cloud: managed sandboxes in the Gemini Enterprise Agent Platform run model-generated code with configurable machine sizes.

Specialist sandbox platforms are built for agents first, with SDKs, fast start-up, snapshots and usage-based pricing:

Platform	Isolation	Worth knowing
E2B	Firecracker microVMs	Agent-native Python and TypeScript SDKs; widely used for code interpreters
Daytona	Containers by default (Sysbox, where root inside the sandbox maps to an unprivileged host user); Kata Containers or dedicated VMs for stronger isolation	Very fast start-up and long-lived workspaces; configurable network firewall; choose the stronger isolation option for untrusted code
Modal	gVisor	Python-first serverless platform with GPUs and autoscaling
Vercel Sandbox	One Firecracker microVM per sandbox	Millisecond start-up; the microVM, not the container inside it, is the security boundary
Cloudflare Sandboxes	Isolated container environments on Cloudflare's network	Persistent Linux environments driven from Workers, with files, shell and background processes
Northflank	Your choice of Kata Containers, Firecracker or gVisor	Can run in your own cloud account (bring your own cloud)
Fly.io Sprites	Firecracker microVM with its own kernel on every tier	Persistent disks and idle-based billing
Runloop	MicroVM-isolated devboxes	Suspend and resume, snapshot branching, VPC deployment on enterprise plans

A note on that table: "sandbox" means very different things across vendors. A container with a shared kernel, a gVisor sandbox and a microVM are all marketed with the same word. Ask every provider three questions before you sign: what is the actual isolation boundary, is outbound network denied by default, and how do secrets reach the code without being readable inside it?

Self-hosted options (Kubernetes with gVisor or Kata Containers, or your own Firecracker hosts) make sense when code and data must not leave your network or region, which is common in finance, healthcare and the public sector.

Choose by isolation tier, egress control and secrets handling first. Start-up speed and price matter, but they are easier to fix later than a weak boundary.

Recommended setups

Individual developer, trusted repository Built-in sandbox on, workspace-only write access, sensitive paths denied, permission prompts for network and anything outside the project. Review every diff.

Unattended, parallel or higher-risk work MicroVM per session, default-deny egress with an allow-list, credential proxy or short-lived tokens, ephemeral environments, output only as pull requests.

Self-hosted gateways such as OpenClaw Enable the Docker sandbox, apply container hardening (read-only root, all capabilities dropped, no privilege escalation, non-root user), scope the workspace tightly, never expose the Docker socket, and require approval for elevated execution.

Teams and production pipelines A managed or self-hosted microVM platform, policy as code, full audit logging to your SIEM, branch protection so agents can never merge their own changes, and human review gates before production. This connects directly to the governance model we describe in The AI-native SDLC: how to adopt it without losing control.

Principles that outlast the tools

Assume the model will occasionally do the wrong thing, or be tricked into it.
Match isolation strength to how much you trust the code and how valuable the things it can reach are.
Independent layers (compute, network, secrets, human review) beat any single technology.
Prefer short-lived, reviewable sessions that are destroyed at the end over long-lived agents with standing privileges.

A well-designed sandbox costs a few days of engineering. A breakout costs far more.

Frequently asked questions

Is Docker enough to sandbox an AI coding agent?

For trusted code it can be, with hardening: non-root user, read-only root filesystem, dropped capabilities, seccomp, and no Docker socket. For untrusted or model-written code, prefer a microVM or gVisor, because containers share the host kernel.

What is the safest way to give a coding agent API keys?

Don't put them in the sandbox. Use a credential proxy or short-lived, narrowly scoped tokens, so the agent can make authenticated requests without being able to read or leak the secret itself.

Do cloud coding agents like GitHub Copilot or Codex need extra sandboxing?

They already run in isolated, short-lived environments managed by the vendor. Your main controls are scoping repository access and secrets, keeping outbound network access restricted, and requiring human review of pull requests before merge.

Should coding agents have internet access?

Only as much as the task needs. Default-deny outbound traffic and allow specific destinations such as your package registries and Git host. Open internet access is the easiest route for data exfiltration after a prompt injection.

How we can help

We design and build secure agent infrastructure: sandbox and microVM runtimes, egress and credential brokering, audit logging, and the review gates around them, in your cloud or on sovereign in-region GPU capacity. A typical starting point is a short Architecture Sprint that reviews how your teams run agents today and delivers a target setup with a rollout plan.

Want a second opinion on your setup? Book a consultation.

Sources

Docker: Docker Sandboxes, Why microVMs, Cloud Sandboxes
GitHub: Responsible use of Copilot coding agent
OpenAI: Codex cloud internet access, Agent approvals & security
Google: Gemini API code execution, Gemini CLI sandboxing, Jules
xAI: Grok Build sandbox
OpenClaw: Sandboxing, A Security Analysis of the OpenClaw AI Agent Framework
AWS: Bedrock AgentCore isolated sessions
Microsoft: Dynamic sessions in Azure Container Apps, ACA Sandboxes, Run untrusted AI agent code with Azure Container Apps Sandboxes (InfoQ)
Google Cloud: Agent Platform sandboxes
Specialist platforms: E2B vs Daytona (Northflank), Daytona on GitHub, Vercel Sandbox, Cloudflare Sandboxes GA, Northflank isolation options, Fly.io: agent sandbox providers compared