Safe Code Execution Inside Isolated Agent Environments

Safe code execution inside isolated agent environments requires layered controls. Firecracker micro-VM isolation for AI agents gives each workload its own kernel behind a hardware virtualisation boundary, making it a minimum for hostile code and sensitive multi-tenant deployments. Network egress policy and credential injection are still needed as separate controls, because a stronger kernel boundary cannot stop exfiltration through connections the environment allows.

Why code execution is the highest-stakes capability an agent can have

Code execution turns an agent’s instructions into actions that can reach source code, cloud credentials, or a production network without line-by-line human review. A coding agent may refactor a repository, while a research agent executes generated Python and a customer assistant runs SQL. The tasks differ, but the trust distinction holds. Accepting code as useful model output does not establish that its runtime behaviour is safe.

Once arbitrary code runs, other controls depend on what that code can read, change, or contact. Instructions about acceptable behaviour cannot substitute for enforced limits when the agent is compromised. The architectural consequence is direct. The execution environment is the primary control over what the agent is permitted to do.

The five concrete threats that define the agent code execution attack surface

This threat model covers execution-time threats. A poisoned code comment, malicious file, or adversarial tool response can inject instructions into an agent’s context regardless of its sandbox tier. Isolation limits the damage those instructions can cause. Input validation, tool call allowlists, and output auditing address that separate layer.

The first execution threat is filesystem access outside the intended scope. Unrestricted code can read .env files or ~/.ssh/id_rsa and modify source files in parent directories. A folder restriction expressed only as agent policy is not OS enforcement. The second threat is arbitrary network egress, which allows data exfiltration, remote attacker instructions, and unauthorized API calls even when the code has not escaped.

The third threat is that code can reach the host kernel through syscalls. Workloads that share a kernel leave the host open to kernel exploits, rogue capabilities, and mis-mounted sockets. The Linux kernel exposes hundreds of syscalls across tens of millions of lines of C, and container escape CVEs appear regularly. The risk remains even when an attack needs a vulnerability.

The fourth threat is cross-tenant data leakage. Namespace restrictions may suit low-risk workloads, but compliance-sensitive multi-tenancy requires stronger separation between one user’s code and another’s data. The fifth threat is that code can read secrets through environment variables or /proc. Kernel-level separation can protect secrets outside the guest, but it cannot hide credentials placed on purpose inside its environment.

What runtime isolation options exist for running untrusted AI agents in production

Level 1 consists of OS process sandboxes, including Seatbelt on macOS and bubblewrap or Landlock on Linux. These use kernel permission primitives to restrict filesystem access and, through policy, some network access without virtualisation. They offer near-zero overhead and require no image build. The host kernel remains shared, so this tier reduces the impact of mistakes without providing a boundary suitable for hostile or multi-tenant code.

Level 2 consists of shared-kernel containers, including Docker and Podman. Namespaces restrict visibility, while cgroups constrain CPU and memory use. Explicit configuration can narrow filesystem and network scope. Kernel exposure remains the central limitation. This tier suits trusted internal code that passed CI/CD.

Level 3 introduces a user-space kernel such as gVisor. It intercepts and re-implements syscalls rather than allowing sandboxed code to call the host kernel directly, closing a common container escape path. Its cold-start overhead is low enough for cloud services that need stronger separation without hardware virtualisation. Compatibility is the trade-off at this tier. Gaps in syscall emulation can affect Linux software, and tenants are still less well separated than they would be behind a hardware boundary.

Level 4 uses hardware microVMs, including Firecracker, Kata Containers, and libkrun. Each workload receives its own kernel running through KVM, so compromising the guest kernel does not itself cross the hypervisor boundary. This supports separation across all five execution threats, although allowed egress and guest-visible secrets still need independent controls. Firecracker takes approximately 125ms to boot and has approximately 5MB of memory overhead. Docker Sandboxes, an experimental feature targeting AI coding agents, moved from containers toward microVMs during development, illustrating the stronger boundary this threat model demands.

Level 5 groups forward-looking library OS and confidential-computing approaches, including Microsoft LiteBox, AMD SEV-SNP, and Intel TDX. Confidential computing addresses a different trust condition, in which even the infrastructure operator must not read sensitive contents. LiteBox was experimental as of February 2026, with a North API implemented in a systems programming language, no stable release, and no reported production usage.

How to read your own risk model and match it to a tier

If the code comes from the team’s engineers and has passed CI/CD, then an OS process sandbox or shared-kernel container is probably adequate. If the agent generates code for data tasks, then gVisor or a microVM becomes necessary as the risk increases. Provenance sets the first branch of the decision. User-uploaded binaries, unvetted PyPI packages, or an untrusted model serving an untrusted user warrant an assumption of hostile code and a hardware microVM minimum.

If the host contains reachable cloud credentials, source code, or other tenants’ data, then the minimum rises to microVM isolation regardless of who wrote the code. The consequence of escape changes the answer. If the deployment is multi-tenant, then one user’s generated code must be separated structurally from another’s data. Namespace isolation is insufficient for compliance-sensitive deployments.

Operational capacity then determines how that boundary is delivered. Running a fleet and scheduler gives the team the most control but more work, while a managed primitive cuts that work but may come with limits set by the vendor. Neither choice replaces the security decision itself. Egress policy and credential handling must be evaluated separately from the isolation tier.

What production tools and platforms have chosen at each tier — and why

Claude Code implements process-level isolation for shell commands using Seatbelt or bubblewrap. Its sandbox is off by default, and file tools, MCP servers, and hooks run outside that shell boundary. Scope is as important as the underlying primitive. Its @anthropic-ai/sandbox-runtime package can wrap an entire process in the same isolation, but is a beta research preview whose configuration format may change.

OpenSandbox, open-sourced by Alibaba Cloud in March 2026, offers gVisor as a backend, preserving operational familiarity while reducing host syscall exposure. Gemini CLI supports Docker, Podman, gVisor through runsc, and LXC on Linux with TOML policies. Its gVisor backend can be selected through GEMINI_SANDBOX or settings.json.

AWS Bedrock AgentCore, generally available in October 2025, uses Firecracker isolation for proprietary, session-scoped environments with configurable VPC/PrivateLink networking. Its design targets short and interactive sessions. NVIDIA OpenShell instead targets long-running agent fleets with policy-restricted egress through a policy layer supporting Docker, Podman, MicroVM, and Kubernetes. The backend still determines the isolation boundary. OpenHands similarly uses a workspace abstraction across Docker, Apptainer, remote-API, and cloud workspaces, with KVM passthrough available as a sandbox-level option in self-hosted/Enterprise deployments.

The two controls that operate independently of the isolation tier — network egress and credential injection

An agent can HTTP-POST secrets to an attacker-controlled server without exploiting a kernel or escaping a container. Permitted outbound traffic is enough for that attack. Blocking curl and wget does not close the route because generated code can make the same request. The structural control is network namespace isolation combined with an explicit egress policy, enforced by a firewall or proxy outside the sandbox boundary.

A secret placed in an environment variable remains available to compromised code, even inside a hardware microVM. A local TLS-terminating proxy or credential broker can instead inject credentials at the boundary, allowing authenticated calls without exposing the raw secret. Credentials are cleared on sandbox exit.

Anthropic’s secure-deployment documentation assigns isolation, network egress, and git credentials to the deployment’s responsibilities. Its proxy recommendation expresses the same architectural division. The runtime constrains execution, the network layer constrains destinations, and the credential boundary constrains secret visibility.

Why multi-tenant agent fleets make microVM isolation a floor, not an option

Even when an agent is trusted, another customer’s environment must be kept safe from that agent’s generated code. Shared containers have a common kernel, where an exploit, rogue capability, or mis-mounted socket can break tenant separation. Hardware isolation gives each tenant’s workload its own kernel behind a hypervisor boundary. For compliance-sensitive fleets, that separation is a structural requirement.

The guest must also have no control over how resource limits are enforced. Strict CPU, memory, and network limits enforced at the hypervisor layer stop runaway code from using up another tenant’s resources. Instructions to behave responsibly cannot provide that guarantee. The per-user agent model follows naturally, with each user receiving an isolated environment whose lifecycle can be managed independently.

An agent retaining files, credentials, and memory across sessions accumulates more sensitive state than a disposable task runner. That creates an operational tension as well as a security requirement. A persistent environment needs strong isolation, but it can be kept without keeping its compute active all the time.

Snapshot-restore as the mechanism that makes persistent microVM agents economically viable

Snapshot-restore separates an agent’s retained state from its active execution. Idle agents are evicted to snapshot storage and restored when needed, rather than occupying compute throughout their lifetime. Disk growth follows the agent’s actual changes. A session that dirties a bounded number of chunks adds a bounded amount of new disk data even when the guest sees a much larger virtual disk.

The same mechanism applies to waits during execution. When a tool call or human-in-the-loop step requires an external signal, the harness snapshots execution state, terminates the process, and restores it when the signal arrives. Compute drops to zero during that wait. Files, credentials, installed packages, and browser sessions survive because their persistent state is captured in the snapshot.

Host count therefore follows active concurrency. Most agents are idle most of the time, so a scheduler that treats inactivity as storage demand avoids provisioning active compute for every user. Storage cost depends on activity, regardless of the size of the provisioned disk. This is the mechanism that makes per-user microVM isolation economically viable at fleet scale, rather than an assumption that stronger isolation must be cheap on its own.

Choosing your isolation tier — a decision framework by threat, not by feature list

If the agent runs internal code on a host without sensitive data, an OS process sandbox is a proportionate development floor because filesystem scope is the principal concern. Shared-kernel containers are also suitable for trusted code that passed CI/CD when resource controls are needed. If the agent runs LLM-generated code in a single-tenant environment, gVisor is a reasonable middle tier because it interposes on host syscalls. Compatibility remains part of that decision.

If the workload includes hostile binaries, untrusted packages, or generated code serving untrusted users, hardware microVM isolation is the minimum because process restrictions leave the host kernel shared. The consequence of escape determines the required boundary. Firecracker provides a concrete way to give each agent its own isolated kernel without relying on container separation.

If even the infrastructure operator must not read regulated data, confidential computing is the right choice because ordinary tenant isolation leaves that operator trust risk in place. Maturity must be assessed for the chosen implementation. Every tier still needs explicit egress policy and credential injection at the boundary, while snapshot-restore cuts the cost of keeping isolated agents between active sessions.

The decision is not made only at launch. As an agent gains broader tool access and weeks of accumulated state, both its reachable systems and the consequences of compromise grow. An isolation tier adequate for a short-lived task may no longer be adequate for the persistent agent that replaces it.