[chaosprint]

"The stronger boundary protects the machine while the agent is coding, testing and improvising. It does not protect the rest of the world from the permissions you have already granted. A better-isolated runtime will not stop the bot from spraying outbound messages, sending a stupid email, or otherwise turning your authority into a minor public nuisance."

from:

https://entropytown.com/articles/2026-03-12-openclaw-sandbox...

plus, any idea why not podman or firecracker?

[dbmikus]

From the article, it looks like they integrated with Docker because someone at Docker reached out about collaborating on the integration.

Regarding security, I think you need three things:

  1. You need the agent to run inside a sandbox.
  2. You need a safe perimeter or proxy that can apply deterministic filtering rules on what makes it into the AI agent's sandbox and the HTTP requests and responses that agent sends out from the sandbox.
  3. The bot should have its own email accounts, or maybe be configured to only send/read from certain email addresses

I'm working on a product that makes it as easy to spin up remote agent sandboxes as it is to git push and git pull. Then when we get that working well we're putting a proxy around each sandbox to let users control filtering rules.

I personally see a future where there are many different types of *Claws, coding agents, etc. and I think they need a new "operating system", so to speak.

Self-plug at the end: https://github.com/gofixpoint/amika. The OSS part of my startup, focused on sandbox coding agents right now :)

PS: I enjoyed the entropytown.com blog! bookmarking it

[decodebytes]

If anyone happens to be interested in sandboxing, a community of us are building https://nono.sh

For what it's worth, it's not just whipped up in claude, a lot of us have a long background in security - I originally created sigstore.dev and was a distinguished engineer at red hat where I built and contributed to a lot of open source security work.

Comes and check it out, any support is appreciated as there is a lot of noise around with all these projects going through weekly hype cycles.

[djhn]

It’s sad that it’s come to this, but your addendum with credentials and a non-slop declaration worked. Three years ago it would have seemed unnecessarily self-aggrandizing. Today I wouldn’t have clicked the link without it.

[nonameiguess]

That seems to be a tough question to answer. My first instinct was to say there isn't a meaningful difference since they're both using the same runtime (runc) and have an identical CLI. I hoped maybe the source code for this project would be helpful, but the installer script isn't in the repo, and when I download it to inspect, it's not consistent on its own name, links out to documentation that doesn't exist, and seems to be calling docker subcommands that don't exist, at least not in any version of docker I have.

It appears that docker now offers a "sandbox" subcommand specifically meant for fencing AI agents inside of micro VMs instead of containers at all: https://docs.docker.com/ai/sandboxes/. This is the page the installer script meant to link to but got wrong. If you type docker --help, this doesn't show up as an available subcommand but apparently it is. The documentation says you need Docker Desktop 4.58+, which the installer script is again wrong about, saying you need 4.40+, and it is only available on Mac and Windows, not Linux.

This does sound more or less the same as firecracker, but firecracker only runs on Linux, so I suppose it didn't meet this guy's requirement that he probably uses a Mac.