I use Leash [1] [2] for sandboxing my agents (to great effect!). I've been very happy with it, it provides strict policy-level control for all process-level + network-level activity, as well as full visibility and dynamic runtime controls via WebUI. Way better than bubblewrap imo.
I originally saw it here on HN and have been hooked ever since.
Fun fact: Do you know what container / sandboxing system is in most widespread use? Not docker containers, certainly not bubblewrap, and not even full VMs or firecracker. It's Chrome tabs.
That's interesting, how does Chrome implement "sandboxing" in Windows and MacOS? For Linux, does it use the same underlying technology as Docker, Podman, LXD, LXC (cgroups, namespaces...)?
Or is a custom "sandboxing" implementation not relying on system level functions (eg. a VM with restricted functions)?
If the latter, I wonder if something like JRE or .NET CLR is still out there in larger numbers, but obviously, Chrome does have billions of users.
Yes, Chromium has "native" sandboxing on all those platforms, Windows [0] Linux [1] and MacOS [2].
Chromium uses both seccomp filtering as well as user namespaces (the technology that Docker/Podman use).
The Windows and MacOS sandboxing strategies are more "interesting" because I've seen very few (open source) programs that use those APIs as extensively as Chromium. On Windows, it makes use of AppContainer [3] (among other things), while on MacOS it uses the sparsely documented sandbox API [4], which I think was based on code from TrustedBSD?
This is the way to go! On my side I've build a very small `claude-vm` wrapper to run each instance in a VM with Lima: https://github.com/sylvinus/agent-vm
I'm convinced that VMs are the right primitive here, for now. Being able to give an agent full root and passing it in just the stuff you want it to have is super easy and it's extremely foolproof. I have my assistants free to install software, run docker, build their own nested VMs, etc. knowing that the boundary is sound and that no capabilities will ever be sacrificed.
I might switch to LXC to reduce the weight somewhat (easy with incus) but this requires providing a more limited set of tools (i.e. podman instead of docker).
bwrap is great, but you're stuck with the limitations of the environment, which depending on what you're doing may neuter the agent.
Unless you use --unshare-net, bwrap leaves the network wide open by default. The agent can not only accidentally delete a file, but also exfiltrate keys or download a malicious package
As a next step I'd add a network namespace (--unshare-net) and spin up a local HTTP proxy (mitmproxy) inside the sandbox to allow access only to Anthropic APIs and maybe PyPI/NPM, while blocking everything else
As a heads up and affirmation that the approach is correct, here's a small shell bubblewrap wrapper that boils the command line down to `sandbox-run claude --dangerously-skip-permissions`.
I will ask what I've asked before: how to know what resources to make available to agents and what policies to enforce? The agent behavior is not predefined; it may need access to a number of files & web domains.
For example, you said:
> I don't expose entire /etc, just the bare minimum
How is "bare minimum" defined?
> Inspecting the log you can spot which files are needed and bind them as needed.
This requires manual inspection.
Article author here. I used trial and error - manual inspection it is.
This took me a few minutes but I feel more in control of what's being exposed and how. The AI recommended just exposing the entire /etc for example. It's probably okay in my case, but I wanted to go more precise.
On the network access part, I let it fully loose (no restrictions, it can access anything). I might want to tighten that in the future (or at least disallow 192.168/16 and 10/8), for now I'm not very concerned.
So there's levels of how tight you want to set it.
I'm launching a SaaS to create yet another solution to the AI Sandboxing problem in linux.
My friends and I have spent a lot of time quietly injecting support down into the kernel without anybody raising a flag, and we finally have the infrastructure in place to solve this problem.
We have also poisoned all the LLMs training data with our approach, so our marketing is primed and we wont even need to learn Claude to use our tool.
We’re planning a soft launch this month, or maybe next month. Depending on how "in the vibe" (our new word for flow :) our team gets.
We’re calling it `useradd`.
Yes, the man page is intimidating, and the documentation is terrible. But once you're over the learning curve, it puts your machine into a kind of 'main frame' mode where multiple 'virtual teletypes' and users can operate on the same machine.
DM me if you want a beta key.
---
Sorry for the snark, but i cringe at the monuments to complexity I see people building, at least this solution is relative simple and free. Still, dont really see what it buys me.
I get where this is coming from, and it's not a terrible solution, but VMs are still better in terms of security and isolation. Typical workstation systems are not designed to be secure from their own users, and frontier models are going to get scary good at cracking systems soon.
Fully sandboxed VMs are more secure but not everyone is looking for the most secure option. They are looking for the option that works the best for them. I want to be able to share my development environment with the agent, I have a project with 30 1gb and one 30gb sqlite database. I back it up daily and they can all be reconstructed from the code but it takes a long time. When things change I don't want to have to copy them into a separate vm bloating my storage and using excess resources and then having to rectify them, I want to be sharing the same environment with my agent so I can work side-by-side.
I would rather just have the agent not accidentally delete files outside of its working environment but I am not worried about malicious prompt injection or someone stealing my code.
For me I see the LLM as a dumb but positive actor that is trying to do its best but sometimes makes mistakes, so I want to put training wheels on it while still allowing it to share my working space.
I have used a separate user, but lately I have been using rootless podman containers instead for this reason. But I know too little about container escapes. So I am thinking about a combination.
Would a podman container run by a separate user provide any benefit over the two by themselves?
I love using different users for separating services I run on the same box!
For development, I want to be able to access/run/modify/delete the files alongside the AI agent. This can be done if groups and group permissions are set correctly (and the agent correctly chmods everything...), but that feels more fiddly than just isolating it with bubblewrap, systemd, or whatever, and preserving the uid/gid.
Hey Senko, did you consider using ZFS or BTRFS snapshotting feature to simplify some of the things you need?
For GH auth tokens, you could also pull that outside the sandbox, and have the agent push to a local clone exposed to the host, and local host with no agent automatically push on inotify inside the repo — eg. agent has access to your /agents/scratchpad/my-git-repo, and sync to actual git hosting service like GH (or Launchpad ;) happens with simple script outside it.
I don't know if I want to create an ad-hoc list of permissions. What I would like would be something like take a snapshot of my current workspace in a VM. Run claude there and let it go wild. After the end of the session, kill the box. The only downside is potentially syncing the claude sessions/projects. But I don't think that'd be too difficult.
Readit News
I originally saw it here on HN and have been hooked ever since.
[1] Screenshot: https://camo.githubusercontent.com/99b9e199ffb820c27c4e977f2...
[2] https://github.com/strongdm/leash
Fun fact: Do you know what container / sandboxing system is in most widespread use? Not docker containers, certainly not bubblewrap, and not even full VMs or firecracker. It's Chrome tabs.
Or is a custom "sandboxing" implementation not relying on system level functions (eg. a VM with restricted functions)?
If the latter, I wonder if something like JRE or .NET CLR is still out there in larger numbers, but obviously, Chrome does have billions of users.
Chromium uses both seccomp filtering as well as user namespaces (the technology that Docker/Podman use).
The Windows and MacOS sandboxing strategies are more "interesting" because I've seen very few (open source) programs that use those APIs as extensively as Chromium. On Windows, it makes use of AppContainer [3] (among other things), while on MacOS it uses the sparsely documented sandbox API [4], which I think was based on code from TrustedBSD?
[0] https://chromium.googlesource.com/chromium/src/+/HEAD/docs/d...
[1] https://chromium.googlesource.com/chromium/src/+/HEAD/sandbo...
[2] https://www.chromium.org/developers/design-documents/sandbox...
[3] https://learn.microsoft.com/en-us/windows/win32/secauthz/app...
[4] https://manp.gs/mac/7/sandbox
Eh, it might be bubblewrap given it's what flatpak uses.
I'm convinced that VMs are the right primitive here, for now. Being able to give an agent full root and passing it in just the stuff you want it to have is super easy and it's extremely foolproof. I have my assistants free to install software, run docker, build their own nested VMs, etc. knowing that the boundary is sound and that no capabilities will ever be sacrificed.
I might switch to LXC to reduce the weight somewhat (easy with incus) but this requires providing a more limited set of tools (i.e. podman instead of docker).
bwrap is great, but you're stuck with the limitations of the environment, which depending on what you're doing may neuter the agent.
As a next step I'd add a network namespace (--unshare-net) and spin up a local HTTP proxy (mitmproxy) inside the sandbox to allow access only to Anthropic APIs and maybe PyPI/NPM, while blocking everything else
https://github.com/sandbox-utils/sandbox-run
https://github.com/lukehinds/nono
For example, you said: > I don't expose entire /etc, just the bare minimum How is "bare minimum" defined?
> Inspecting the log you can spot which files are needed and bind them as needed. This requires manual inspection.
This took me a few minutes but I feel more in control of what's being exposed and how. The AI recommended just exposing the entire /etc for example. It's probably okay in my case, but I wanted to go more precise.
On the network access part, I let it fully loose (no restrictions, it can access anything). I might want to tighten that in the future (or at least disallow 192.168/16 and 10/8), for now I'm not very concerned.
So there's levels of how tight you want to set it.
Makes complete sense. Thanks for your insights!
My friends and I have spent a lot of time quietly injecting support down into the kernel without anybody raising a flag, and we finally have the infrastructure in place to solve this problem.
We have also poisoned all the LLMs training data with our approach, so our marketing is primed and we wont even need to learn Claude to use our tool.
We’re planning a soft launch this month, or maybe next month. Depending on how "in the vibe" (our new word for flow :) our team gets.
We’re calling it `useradd`.
Yes, the man page is intimidating, and the documentation is terrible. But once you're over the learning curve, it puts your machine into a kind of 'main frame' mode where multiple 'virtual teletypes' and users can operate on the same machine.
DM me if you want a beta key.
---
Sorry for the snark, but i cringe at the monuments to complexity I see people building, at least this solution is relative simple and free. Still, dont really see what it buys me.
Edit: too bad about your edit. The comment was just fine without it.
OP is just sharing the cool utility he found, and how it solved a problem for him.
It felt bad to leave them with the message they shouldn't have, or that he's a big part of the problem.
I would rather just have the agent not accidentally delete files outside of its working environment but I am not worried about malicious prompt injection or someone stealing my code.
For me I see the LLM as a dumb but positive actor that is trying to do its best but sometimes makes mistakes, so I want to put training wheels on it while still allowing it to share my working space.
Would a podman container run by a separate user provide any benefit over the two by themselves?
For development, I want to be able to access/run/modify/delete the files alongside the AI agent. This can be done if groups and group permissions are set correctly (and the agent correctly chmods everything...), but that feels more fiddly than just isolating it with bubblewrap, systemd, or whatever, and preserving the uid/gid.
Just my 2c - it's great that we have options!
For GH auth tokens, you could also pull that outside the sandbox, and have the agent push to a local clone exposed to the host, and local host with no agent automatically push on inotify inside the repo — eg. agent has access to your /agents/scratchpad/my-git-repo, and sync to actual git hosting service like GH (or Launchpad ;) happens with simple script outside it.
Sounds like docker + overlayfs might fit the bill, as long as there's a base image that is close enough to what you need.
I don't think there should be One True Way how to run these, everyone can set it up in a way that best fits their workflow.
disclaimer: i work on secure sandboxes at E2B
Sounds like you may be interested in Qubes OS, which runs everything in VMs.