Docker Sandboxes (sbx)

Operating Systems & Open Source Virtualization
1

I don’t trust agents. The pitch is that you should let a non-deterministic process touch your shell, your repo, and your cloud creds. Last week somebody let an agent delete his entire stack. This week the agent is the terminal. Hard pass on the default config.

Started looking around for security options that weren’t just “ask the AI pretty please don’t break my shit.” Docker Sandboxes (sbx) is a tool I’ve found that makes that posture better. It’s not a perfect solution and has some rough edges but you can massage most of them out.

What sbx actually is

It’s a microVM per agent. Not a container, a real hypervisor boundary, separate kernel, isolated Docker daemon inside. Your workspace is mounted in at the same absolute path, so paths in error messages still match your host. Everything else stops at the VM.

Three things matter for the security story:

  • Network is deny-by-default. All HTTP/HTTPS traffic routes through a host-side proxy with an allow-list. Raw TCP/UDP/ICMP is dropped at the network layer. SSH out of the box: blocked. You allow what you need with sbx policy allow network.

  • Credentials never enter the VM. The proxy injects auth headers on the way out. The agent process can’t read your API key, can’t cat it from /proc/self/environ, can’t exfiltrate it. It just makes requests and the proxy attaches the header.

  • Docker is real Docker. The agent gets its own daemon. It can docker build, pull images, run containers, do anything Docker does, without any of it touching your host daemon or images.

Inside the VM the agent has root. That’s fine — the VM is the boundary.

The shared workspace is still shared

One thing the docs are upfront about and worth repeating: the workspace mount is live. The agent edits the same files you see. That includes Git hooks, Makefile, package.json scripts, CI configs, anything that runs implicitly. Git hooks live in .git/ and don’t show up in git diff. Review accordingly. The sandbox isolates the agent from your machine; it doesn’t isolate you from the agent’s edits to your repo.

What’s janky

There is a difference in scope philosophy between my goals and the Docker project. The Docker developers are building Sandboxes to be a YOLO machine, connect an agent to a codebase, turn it loose, walk away. They’re replacing existing tooling guardrails and exchanging them for the sandbox boundary. My problem with that approach is that I’m looking to increase the security of coding agents, not replace existing security with a different layer.

This is beta software and it shows.

  • Private registry pulls are a WIP with no ETA.

  • User-level agent config doesn’t persist (~/.claude). This is by “design” but makes customization difficult.

  • uvx is broken inside the sandbox. Use uv tool run instead.

SkitzoClaw: The solution to jank

Repo: https://github.com/VisibleSampling/DockerSBX

sbx’s kit system lets you declare extra capabilities (or a whole agent) in a YAML spec. Mixin kits stack on top of an existing agent; agent kits define one from scratch. SkitzoClaw is a mixin on the claude agent that tightens it down further:

  • Boots Claude Code in plan mode - read and propose, don’t execute, until told to do so.

  • Network restricted to Anthropic endpoints. No package installs at runtime, no random GET to a vendor blog, nothing.

  • Anthropic API key injected via service auth. SSO works on first start; auto-SSO across sessions doesn’t, you log in once.(Another broken feature)

  • Strips co-authored-by from commits.

  • Blocks the agent from reading files in .gitignore (.env, etc). This is a deterrent, not a guarantee, shell access means a motivated agent can route around it.

  • Bakes in Ansible + ansible-lint, Python 3 / pip / uv, build-essential, vim at install time.

The whole thing is one spec.yaml plus a files/ tree. The kit format is good. Declarative, easy to reason about, easy to share.

Verdict

sbx is the right shape. MicroVM isolation, proxy-based credential injection, deny-by-default network, isolated Docker daemon, these are the primitives this should have been built on from the start, instead of the “trust the agent and hope” model that ships everywhere else. The kit system is a clean way to declare capabilities and share configurations.

It’s beta. The rough edges are real. But the bones are right, and the security model is the first one I’ve seen for agentic tooling that I’d actually let near a real machine.

I’m not going unattended. The point isn’t to remove the operator, the point is to keep the blast radius contained when the model does something stupid. sbx does that.

1 Like