"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 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.
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.
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.
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.
This article is remarkably light on the deal with docker, it's basically just mentioned in passing:
> Now, on Friday, Cohen announced a deal with Docker — the company that essentially invented the container technology NanoClaw is built on, and counts millions of developers and nearly 80,000 enterprise customers — to integrate Docker Sandboxes into NanoClaw.
The only thing I am sad about: This would be extremely unlikely to happen in Europe (I built https://github.com/rcarmo/piclaw, and have had zero feels from anybody)
So I am late to the party on this; I can ABSOLUTELY see what would fuel a 48 hr code binge. I would be LIVID if a package I downloaded did such a bulk pull from my Whatsapp, and even further enraged if I found a bulk of packages integrated that led me to believe security was never a single thought.
Future innovators, don't take security for granted; someone who cares will eat your lunch.
"In researching a hiccup with performance, he stumbled across a file where the OpenClaw agent had downloaded all of his WhatsApp messages and stored them in plain, unencrypted text on his computer. Not just the work-related messages it was given explicit access to, but all of them, his personal messages too."
Now the agent can do the same thing, but it's in a container and it's doing it with a Rust binary, so you know it's safe. /s
"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?
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:
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
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.
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.
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.
This article is remarkably light on the deal with docker, it's basically just mentioned in passing:
> Now, on Friday, Cohen announced a deal with Docker — the company that essentially invented the container technology NanoClaw is built on, and counts millions of developers and nearly 80,000 enterprise customers — to integrate Docker Sandboxes into NanoClaw.
Relevant link: https://nanoclaw.dev/blog/nanoclaw-docker-sandboxes
The only thing I am sad about: This would be extremely unlikely to happen in Europe (I built https://github.com/rcarmo/piclaw, and have had zero feels from anybody)
So I am late to the party on this; I can ABSOLUTELY see what would fuel a 48 hr code binge. I would be LIVID if a package I downloaded did such a bulk pull from my Whatsapp, and even further enraged if I found a bulk of packages integrated that led me to believe security was never a single thought.
Future innovators, don't take security for granted; someone who cares will eat your lunch.
"In researching a hiccup with performance, he stumbled across a file where the OpenClaw agent had downloaded all of his WhatsApp messages and stored them in plain, unencrypted text on his computer. Not just the work-related messages it was given explicit access to, but all of them, his personal messages too."
Now the agent can do the same thing, but it's in a container and it's doing it with a Rust binary, so you know it's safe. /s
Edit: It's not Rust.
Definitely a sign of the times that (pre-edit) I thought, "oh this person's thinking of the wrong claw, IronClaw is the Rust one"
Not necessarily? You can just as easily design an agent that only has access to one chat.