Run NanoClaw in Docker Sandboxes
nanoclaw.dev
Run NanoClaw in Docker Sandboxes
1–10 of 64 posts
Re: Run NanoClaw in Docker Sandboxes
#2Re: Run NanoClaw in Docker Sandboxes
#3All the sandboxing stuff is neat but the weakest link in these claw setups is not root access on the machine but root access to your life (Gmail, calendar, etc)
But I fundamentally agree that there is just too much overlap between what makes claws useful and what makes them insecure.
Re: Run NanoClaw in Docker Sandboxes
#4It's also the first project I've used where Claude Code is the setup and configuration interface. It works really well, and it's fun to add new features on a whim.
Re: Run NanoClaw in Docker Sandboxes
#5This threat model is concerned with running arbitrary code generated by or fetched by an AI agent on host machines which contain secrets, sensitive files, and/or exfoliate data, apps, and systems which should not be lost.
What about the threat model where an agent deletes your entire inbox? Or sends your calendar events to a server after prompt injection? Bank transfers of the wrong amount to the wrong address etc. all these are allowed under the sandboxing model.
We need fine grained permissions per-task or per-tool in addition to sandboxing. For example: "this request should only ever read my gmail and never write, delete, or move emails".
Sandboxes do not solve permission escalation or exfiltration threats.
Re: Run NanoClaw in Docker Sandboxes
#6All the sandboxing stuff is neat but the weakest link in these claw setups is not root access on the machine but root access to your life (Gmail, calendar, etc)
access control, provisioning, and delegation have been solved for a very long time now.
Re: Run NanoClaw in Docker Sandboxes
#7It does not really matter.
IMHO, until you figure out useful ways to spend tokens to do useful tasks the runtime should be a second thought.
As far as security goes, running LLM in a container in just simply not enough. What matters is not what files it can edit on your machine but what information it can access. And the access in this case as far as these agents are concerned is basically everything. If this does not scare you you should not be thinking about containers.
Re: Run NanoClaw in Docker Sandboxes
#8You must explicitly state what your threat model is when writing about security tooling, isolation, and sandboxing. This threat model is concerned with running arbitrary code generated by or fetched by an AI agent on host machines which contain secrets, sensitive files, and/or exfoliate data, apps, and systems which should not be lost. What about the threat model where an agent deletes your entire inbox? Or sends you…
My posts about these aspects of agent security get zero engagement (not even a salty "vibe slop" comment, lol), so ironically security is the thing everyone's talking about, but most people don't know enough to understand what they need.
Re: Run NanoClaw in Docker Sandboxes
#9I like NanoClaw a lot. I found OpenClaw to be a bloated mess, NanoClaw implementation is so much tighter. It's also the first project I've used where Claude Code is the setup and configuration interface. It works really well, and it's fun to add new features on a whim.
Re: Run NanoClaw in Docker Sandboxes
#10You must explicitly state what your threat model is when writing about security tooling, isolation, and sandboxing. This threat model is concerned with running arbitrary code generated by or fetched by an AI agent on host machines which contain secrets, sensitive files, and/or exfoliate data, apps, and systems which should not be lost. What about the threat model where an agent deletes your entire inbox? Or sends you…
The Security Model: Design for Distrust
I wrote about this in Don’t Trust AI Agents: when you’re building with AI agents, they should be treated as untrusted and potentially malicious. Prompt injection, model misbehavior, things nobody’s thought of yet. The right approach is architecture that assumes agents will misbehave and contains the damage when they do…