AI Agent Sandboxing: The Complete 2026 Production Guide

March 2026 • 13 min read

Running AI coding agents in production without proper sandboxing is like giving a new hire root access on their first day. The agent might be brilliant, but it operates without the institutional knowledge of what not to touch. One misunderstood instruction, one hallucinated command, and your production database is truncated, your credentials are exposed, or your infrastructure is reconfigured in ways that take days to unwind.

This guide covers three battle-tested approaches to sandboxing AI agents, from heavyweight isolation to lightweight containment, and shows you how to layer them for defense-in-depth.

Approach 1: MicroVMs for Maximum Isolation

MicroVMs provide the strongest isolation available. Technologies like Firecracker (developed by AWS for Lambda and Fargate) and Kata Containers run each agent session inside a lightweight virtual machine with its own kernel, memory space, and network stack. If the agent is fully compromised, the attacker is trapped inside a VM with no path to the host.

Firecracker VMs boot in approximately 125 milliseconds and consume as little as 5MB of memory overhead. This makes them practical even for interactive agent sessions. The workflow looks like this:

# Create a Firecracker microVM for the agent session
firectl --kernel=vmlinux --root-drive=agent-rootfs.ext4 \
  --cpu-count=2 --mem-size=2048 \
  --network-interface=tap0/aa:bb:cc:dd:ee:ff

# Inside the VM: mount project code as read-write
mount -o bind /workspace /home/agent/project

# Run the AI agent inside the VM
claude-code --project /home/agent/project

The trade-off is operational complexity. You need to manage VM images, handle networking between the VM and host, and deal with file synchronization for the project directory. For teams already running Kubernetes, Kata Containers integrates as a RuntimeClass, making adoption smoother.

Best for: Teams running agents on untrusted codebases, CI/CD pipelines where agents execute arbitrary code, and any scenario where a full compromise of the agent environment is a realistic threat model.

Approach 2: gVisor for Practical Security

gVisor sits between full VMs and standard containers. It implements a user-space kernel (called Sentry) that intercepts all system calls from the containerized application and re-implements them in a sandboxed environment. The host kernel never directly serves the agent's syscalls.

This approach blocks entire categories of kernel exploits that could allow container escape. If the agent tries to use a syscall that gVisor does not implement, the call fails safely rather than reaching the host kernel.

# Run a Docker container with gVisor runtime
docker run --runtime=runsc \
  --mount type=bind,src=/projects/myapp,dst=/workspace \
  --network=agent-net \
  --memory=4g \
  --cpus=2 \
  agent-sandbox:latest \
  claude-code --project /workspace

gVisor integrates directly with Docker and Kubernetes (via the runsc runtime), making it a drop-in upgrade from standard containers. The performance overhead is modest -- typically 5-15% for most workloads, with higher overhead for syscall-heavy operations like heavy file I/O.

Best for: Teams that want significantly better isolation than standard containers without the operational complexity of managing VMs. Excellent as a default runtime for all agent workloads.

Approach 3: Hardened Containers

Standard Docker containers share the host kernel and rely on Linux namespaces and cgroups for isolation. While this is weaker than microVMs or gVisor, a properly hardened container provides meaningful security for most agent use cases.

The key hardening measures:

# Hardened container for AI agent
docker run \
  --security-opt=no-new-privileges \
  --security-opt=seccomp=agent-seccomp.json \
  --security-opt=apparmor=agent-profile \
  --read-only \
  --tmpfs /tmp:size=512m \
  --cap-drop=ALL \
  --cap-add=CHOWN --cap-add=SETUID --cap-add=SETGID \
  --network=none \
  --mount type=bind,src=/projects/myapp,dst=/workspace \
  --user 1000:1000 \
  agent-sandbox:latest

This configuration drops all Linux capabilities except the minimum required, enables seccomp to restrict available syscalls, uses AppArmor for mandatory access control, makes the root filesystem read-only, runs as a non-root user, and disables network access entirely (you can selectively re-enable it with an egress proxy).

Network Egress Controls

Regardless of which isolation approach you use, controlling network egress is critical. A compromised agent's first action is typically to exfiltrate data -- credentials, source code, proprietary information -- to an external endpoint.

Implement an allowlist proxy that only permits outbound connections to:

• Package registries: npm, PyPI, crates.io, Maven Central (and your private registries)
• AI API endpoints: api.anthropic.com, api.openai.com (whichever your agent uses)
• Version control: github.com, gitlab.com (if the agent needs to push/pull)
• Nothing else. Block all other outbound connections by default.

Use a transparent proxy like Squid or a service mesh sidecar to enforce these rules at the network level. The agent's configuration should not be able to override network policy.

File System Restrictions and Config Protection

Beyond containerization, you need granular control over what the agent can read and write:

• Project directory: Read-write access, scoped to the specific project
• Config files: Read-only access to .env, .gitconfig, SSH configs. Better yet, do not mount them at all -- inject only the specific values the agent needs as environment variables
• System directories: No access. The agent does not need /etc, /usr/bin, or any system paths beyond the tools explicitly provided in the container image
• Temp directories: Provide a size-limited tmpfs mount so the agent cannot fill your disk

For Claude Code specifically, you can use the --allowedTools flag to restrict which tools the agent can use, and the .claude/settings.json file to define permitted and denied directories at the project level.

Credentials and Audit Trails

Never give agents long-lived credentials. Use short-lived tokens that expire at the end of the agent session. For cloud providers, use STS (Security Token Service) to generate temporary credentials scoped to the minimum required permissions. For git operations, use deploy keys with read-only access unless the agent explicitly needs to push.

Every agent action should be logged to an immutable audit trail. Capture:

• All file reads, writes, and deletes with full paths and timestamps
• All shell commands executed, with arguments and exit codes
• All network connections attempted, including blocked ones
• All API calls made by the agent, with request and response metadata

Ship these logs to a centralized system (ELK, Datadog, CloudWatch) where they cannot be tampered with by the agent. When something goes wrong -- and eventually it will -- you need to reconstruct exactly what happened.

Production AI agent sandboxing is not a single technology choice. It is a defense-in-depth strategy that combines VM or container isolation, network controls, filesystem restrictions, credential management, and comprehensive logging. Start with hardened containers and network egress controls (they provide the highest security-to-effort ratio), then layer on gVisor or microVMs as your threat model demands.