AI Agent Sandbox: Secure Execution (2026)

A coding agent that can write code can also run it. The moment you let an agent execute a build, install a dependency, or run a test, you’re running code no human reviewed against your filesystem, your network, and your secrets. An AI agent sandbox is how you contain that risk. This guide is for platform and security engineers deciding how to run agents safely: what a sandbox actually isolates, why a plain container leaves gaps, how microVMs and gVisor differ at the kernel level, and how to operate sandboxed execution across many repos without it becoming the bottleneck.

What is an AI agent sandbox?

An AI agent sandbox is an isolated execution environment where an AI agent runs untrusted code separated from the host system, other workloads, and sensitive data: a working filesystem, a shell, and whatever runtimes it needs, but not direct access to the machine underneath, the secrets of the team next door, or an open path to your internal network.

The distinction that matters is between the agent’s reasoning and its actions. The model decides what to do; the sandbox decides what those actions are allowed to touch. When an agent clones a repo, runs npm install, and executes a test suite, every step runs arbitrary third-party code. A sandbox is the boundary that keeps a malicious package or a confused agent from reaching past the task it was given.

In practice, this looks concrete. On Tembo, each task runs in its own isolated environment with controlled network access, and your repository is cloned in for the session and torn down when it ends. The sandbox is the unit of execution, not a shared server that agents take turns using.

Why agents need sandboxing

Three failure modes make sandboxing non-optional for coding agents, and they compound.

The first is unreviewed code execution. A coding agent’s whole value is that it acts without a human in the loop for every step, and that same property means code runs before anyone reads it. Dependency trees pull in transitive packages that no one audited, and generated scripts execute against real credentials. The agent isn’t malicious, but the code it runs might be, and “we’ll review the PR later” doesn’t help once the damage happens during execution.

The second, and related, is prompt injection. OWASP ranks it the top risk in its Top 10 for LLM Applications, LLM01: a prompt injection vulnerability “occurs when user prompts alter the LLM’s behavior or output in unintended ways.” The dangerous variant for coding agents is indirect injection, where instructions ride in on external content the agent reads: a poisoned README, a crafted issue comment, a malicious dependency’s docs. You can’t fully prevent the model from being fooled, but you can make sure it’s fooled inside a box.

Third is data exfiltration. An agent with your repo cloned locally and unrestricted egress can POST your source, environment variables, or cloud credentials anywhere once steered, which is why egress control belongs in the threat model from day one, not as a later hardening step.

The throughline: the model layer is probabilistic and will occasionally do the wrong thing, so the execution layer has to be deterministic about what “the wrong thing” is allowed to reach.

Why containers aren’t enough

The instinct is to reach for a container: fast, cheap, and already in every CI pipeline. It’s also the wrong default for untrusted agent code, for one structural reason: a container shares the host kernel.

NIST’s Application Container Security Guide (SP 800-190) states it directly: “Because containers share the same kernel and can be run with varying capabilities and privileges on a host, the degree of segmentation between them is far less than that provided to VMs by a hypervisor.” The same guide adds that “the use of a shared kernel invariably results in a larger inter-object attack surface than seen with hypervisors.”

A container isolates processes with namespaces and cgroups, but every container on the host talks to the same Linux kernel: a single kernel vulnerability or container escape can reach the host, and from there every other container on it; worse still, in multi-tenant workloads running many tenants’ untrusted code against one shared kernel.

Containers still work as an inner layer for packaging tools and pinning a runtime. The problem is treating the container boundary as the security boundary for code you didn’t write. We hit this early: our write-up on building secure sandboxes with Docker and NixOS explains why client workloads that need their own services and virtualizations pushed us past a plain Docker setup toward a larger VM. The container stays in the picture; it just stops being the thing that stands between untrusted code and the host.

Isolation technologies: microVMs, gVisor, and hardened containers

If a shared kernel is the weakness, the fix is to stop sharing it. Three approaches trade isolation strength against startup cost.

MicroVMs (Firecracker, Kata Containers). A microVM gives the workload its own guest kernel behind a hardware-virtualization boundary. Firecracker, the VMM AWS built for serverless, “uses the Linux Kernel-based Virtual Machine (KVM) to create microVMs” and “excludes unnecessary devices and guest-facing functionality to reduce the memory footprint and attack surface area of each microVM,” initiating application code “in as little as 125 ms.” Kata Containers wraps the same idea in container ergonomics: “lightweight virtual machines that feel and perform like containers, but provide stronger workload isolation using hardware virtualization technology,” while staying OCI- and Kubernetes CRI-compatible.

gVisor. Google’s gVisor takes a different path: instead of booting a guest kernel, it runs “an application kernel that implements a Linux-like interface,” written in Go, that “intercepts application system calls and acts as the guest kernel, without the need for translation through virtualized hardware.” In practice, gVisor reimplements a subset of Linux, so some syscalls are unsupported or slower, but you avoid full-VM overhead.

Hardened containers. A standard container plus aggressive lockdown: tight seccomp profile, dropped capabilities, read-only root filesystem, user namespaces, no privileged mode. It raises the bar but doesn’t change the fact that the kernel is shared, so it’s best treated as defense-in-depth around a stronger boundary, not the boundary itself.

There is no single winner. The right pick depends on how much you trust the code, how much syscall surface the workload needs, and how often you spin environments up.

Defense-in-depth: limits, egress, permissions, monitoring

A strong isolation boundary is the foundation, not the whole house: even with solid kernel isolation, data leaks the first time an injection lands if the network is wide open. Layer these controls on top of whichever boundary you choose.

Start with resource limits, capping CPU, memory, disk, and process counts per sandbox to contain runaway builds and blunt denial-of-service from a fork bomb in a dependency’s install script. Then add network egress control: default-deny outbound traffic and allowlist only the endpoints a task genuinely needs, your package registry, and your Git host. Egress control is the highest-leverage move against exfiltration, since it cuts off the attacker’s exit path even after they have steered the agent.

• Permission scoping. Give each task the narrowest credentials that let it finish, scoping repository tokens to the repos in play rather than a single broad credential that every sandbox inherits.
• Monitoring and audit. Log what the agent ran, what it reached, and what changed, so you can answer the question that matters after an incident: what did it actually touch?

The most underrated control is the output gate: the orchestration layer decides how results leave the sandbox. We enforce this structurally: each agent runs in its own sandbox, and changes can only exit as pull requests, a natural checkpoint for human review. (More in our coding agent orchestration writeup.) The agent works behind the boundary, but its changes reach your codebase only through a PR that a human can reject.

Build vs buy: sandbox platforms

You can assemble this yourself or adopt a platform. Building gives full control: a Firecracker or Kata setup with your own orchestration, egress rules, and snapshotting, but the cost is real and ongoing: you now own kernel patching, image lifecycle, autoscaling, and per-tenant isolation guarantees.

Several projects sit at the infrastructure layer if you go the buy-the-primitive route. E2B is an open-source (Apache-2.0) cloud giving agents Firecracker microVMs with Python and JavaScript SDKs. Northflank runs agent workloads with microVM isolation through Kata, Firecracker, and gVisor, deployable into your own cloud. The Kubernetes community’s Agent Sandbox project, under SIG Apps, brings sandbox primitives to the cluster teams already running. All three solve the execution-primitive problem well, but leave everything above it: orchestrating which agent runs where, governing permissions across repos, routing work from your issue tracker, gating outputs behind human review.

For a single agent, that gap is minor; across an org running many agents over many repos, it’s most of the work. Our guide on self-hosting a coding agent walks through that build-vs-buy calculus, including the deployment and security trade-offs of keeping the whole stack inside your perimeter.

Running coding agents in secure sandboxes at scale, in your own cloud

This is where the sandbox stops being primitive and becomes part of an operating model. We’re a model-agnostic orchestration platform for coding agents across Claude Code, Cursor, Codex, and others, and the secure sandbox is where every task actually runs.

The isolation model is VM-first. Every session runs in its own isolated, ephemeral sandbox, spun up for the session and destroyed when it’s done, with no code or state persisting after execution. (Full details in our sandbox docs.) No two sessions share the same VM, giving multi-tenant work a hardware-virtualization boundary by default rather than a shared kernel, with full nested virtualization for Docker-in-Docker. For teams with strict requirements, we can enforce a VM-only posture, so untrusted code never runs without that boundary.

Defense-in-depth sits on top: controlled network access, isolation level configurable at the org or task level, and outputs that leave only as pull requests you can reject or amend from Linear, Slack, or GitHub. Because we’re model-agnostic, the same governance applies no matter which agent ran the task.

Where all this runs matters most for security-conscious teams. We can self-host inside your own cloud account, behind your VPC, so your code, credentials, and data never leave your network, collapsing the exfiltration question from “do we trust the vendor’s egress controls” to “this runs in our perimeter.” We’re independently audited for SOC 2 Type II, ISO 27001, ISO 42001, GDPR, and HIPAA, with reports available under NDA, as detailed on our security page. The sandbox isolates the code; running it in your own cloud isolates the whole system.

Run agents in isolation, in your own cloud

Sandboxing is not optional for coding agents. The model will occasionally run something it shouldn’t, and the only reliable answer is an execution boundary strong enough that “occasionally wrong” stays contained. That means a real isolation boundary, defense-in-depth around it, and a place to run it that you control.

To run coding agents in isolated, ephemeral VM sandboxes with permission scoping and human-in-the-loop review, start free on Tembo or book a demo to see self-hosted execution inside your own VPC.

Frequently asked questions

What is an AI agent sandbox? An isolated execution environment where an AI agent runs untrusted code separated from the host system, other workloads, and sensitive data, with no direct access to the underlying machine or an open path to your network.

Why isn’t a Docker container enough to sandbox an AI agent? Containers share the host kernel, so a kernel exploit or container escape reaches the host and every other container on it. They’re a fine inner packaging layer, but a microVM or equivalent should be the security boundary.

MicroVM vs gVisor: which is better for agent sandboxing? MicroVMs like Firecracker give each workload its own guest kernel behind hardware virtualization, the stronger boundary, with startup around 125 ms. gVisor intercepts syscalls in userspace, avoiding a full VM boot and trading some syscall coverage for lower overhead. Pick microVMs for high-assurance work; gVisor when your workload tolerates its syscall surface.

Is there an open-source AI agent sandbox? Yes. E2B is open source under Apache-2.0, gVisor and Kata Containers are open-source isolation runtimes, and the Kubernetes Agent Sandbox project brings sandbox primitives to clusters, though you own kernel patching and multi-tenant isolation yourself.

How do you stop a sandboxed agent from exfiltrating data? Default-deny egress, scoped credentials, per-sandbox resource limits, and an output gate so changes leave only as reviewable pull requests. Self-hosting inside your own VPC removes the external network path entirely.