Posted by afshinmeh 2 days ago
Watch the demo: https://www.youtube.com/watch?v=wZiPm9BOPCg
Zerobox follows the same sandboxing policy as Deno which is deny by default. The only operation that the command can run is reading files, all writes and network I/O are blocked by default. No VMs, no Docker, no remote servers.
Want to block reads to /etc?
zerobox --deny-read=/etc -- cat /etc/passwd
cat: /etc/passwd: Operation not permitted
Zerobox wraps any commands/programs, runs an MITM proxy and uses the native sandboxing solutions on each operating system (e.g BubbleWrap on Linux) to run the given process in a sandbox. The MITM proxy has two jobs: blocking network calls and injecting credentials at the network level.
Think of it this way, I want to inject "Bearer OPENAI_API_KEY" but I don't want my sandboxed command to know about it, Zerobox does that by replacing "OPENAI_API_KEY" with a placeholder, then replaces it when the actual outbound network call is made, see this example:
zerobox --secret OPENAI_API_KEY=$OPENAI_API_KEY --secret-host OPENAI_API_KEY=api.openai.com -- bun agent.ts
The next thing I'm exploring is `zerobox claude` or `zerobox openclaw` which would wrap the entire agent and preload the correct policy profiles.
I'd love to hear your feedback, especially if you are running AI Agents (e.g. OpenClaw), MCPs, AI Tools locally.
There are dozens of projects like this emerging right now. They all share the same challenge: establishing credibility.
I'm loathe to spend time evaluating them unless I've seen robust evidence that the architecture is well thought through and the tool has been extensively tested already.
My ideal sandbox is one that's been used by hundreds of people in a high-stakes environment already. That's a tall order, but if I'm going to spend time evaluating one the next best thing is documentation that teaches me something about sandboxing and demonstrates to me how competent and thorough the process of building this one has been.
UPDATE: On further inspection there's a lot that I like about this one. The CLI design is neat, it builds on a strong underlying library (the OpenAI Codex implementation) and the features it does add - mainly the network proxy being able to modify headers to inject secrets - are genuinely great ideas.
Care to elaborate on the kind of "credibility" to be established here? All these bazillion sandboxing tools use the same underlying frameworks for isolation (e.g., ebpf, landlock, VMs, cgroups, namespaces) that are already credible.
Most people are building on top of Apple's sandbox-exec which is itself almost entirely undocumented!
Agreed. I'm sure a number of these sandboxing solutions are vibe-coded, which makes your concerns regarding misconfigurations even more relevant.
I appreciate that alternate sandboxing tools can reduce some of the heavier parts of docker though (i.e. building or downloading the correct image)
How would you compare this tool to say bubblewrap https://github.com/containers/
the deny-by-default network policy also matters specifically for agent use: without it there is nothing stopping a tool call from exfiltrating context window contents to an arbitrary endpoint. most sandboxes focus on filesystem isolation and treat network as an afterthought.
Real secrets are never readable by any processes inside the sandbox:
```
zerobox -- echo $OPENAI_API_KEY
ZEROBOX_SECRET_a1b2c3d4e5...
```
I am currently working on a mitm proxy for use with devcontainers to try to implement this pattern, but I'm certainly not the only one!
MITM proxy is nice idea to avoid leaking secrets. Isn’t it very brittle though? Anthropic changes some URL-s and it’ll break.
Re the URLs, I agree, that's why I added wildcard support, e.g. `*.openai.com` for secret injection as well as network call filtering.
Some of my use cases are very latency sensitive. What sort of overhead are you seeing?
Also, I'm literally wrapping Claude with zerobox now! No latency issues at all.
Especially for your application that you any kind of Apple framework.
--allow-net=api.openai.com # Explicitly allow access to that host
--allow-write=config.txt # Explicitly allow write to that file```
zerobox -- curl https://example.com
Could not resolve host: example.com
```
I'd feel safer with default-deny on reads as well, but I know from past experience that this gets tricky fast - tools like Node.js and uv and Python all have a bunch of files they need to be able to read that you might not predict in advance.
Might still be possible to do that in a DX-friendly way though, if you make it easy to manually approve reads the first time and use that to build a profile that can be reused on subsequent command invocations.
```
zerobox --deny-read=/ -- cat /etc/passwd
```
That being said, what the default DX shouldl be? What paths to deny by default? That's something I've been thinking about and I'd love to hear your thoughts.
That's why rather than a default set I'm interested in an option where I get to approve things on first run - maybe something like this:
zerobox --build-profile claude-profile.txt -- claude
claude wants to read ~/.claude/config.txt
A) allow that file, D) allow full ~/.claude directory, X) exit
zerobox --profile claude-profile.txt -- claude
Related, a direct comparison to other sandboxes and what you offer over those would be nice