The first half of the article says "namespaces, cgroups, and seccomp aren't 'security boundaries' because if the kernel had a bug it could be used to escape from a sandbox". Then in the second half it says "use gvisor and do all this other stuff to avoid these problems." This presentation feels kind of dishonest to me because the article avoids acknowledging the obvious question: "well what if gvisor has a bug then?" I mean, sure, another layer of sandboxing that is simpler than the other layers probably increases security, but let's not pretend like these are fundamentally different approaches.
Let's discuss sandbox isolation
31–40 of 75 posts
Re: Let's discuss sandbox isolation
#32The first half of the article says "namespaces, cgroups, and seccomp aren't 'security boundaries' because if the kernel had a bug it could be used to escape from a sandbox". Then in the second half it says "use gvisor and do all this other stuff to avoid these problems." This presentation feels kind of dishonest to me because the article avoids acknowledging the obvious question: "well what if gvisor has a bug then?"…
It touches in the gvisor section around the trade-off that the surface area for gvisor is smaller. There are trade offs. It’s not dishonest.
Re: Let's discuss sandbox isolation
#33OK, let’s survey how everybody is sandboxing their AI coding agents in early 2026. What I’ve seen suggests the most common answers are (a) “containers” and (b) “YOLO!” (maybe adding, “Please play nice, agent.”). One approach that I’m about to try is Sandvault [0] (macOS only), which uses the good old Unix user system together with some added precautions. Basically, give an agent its own unprivileged user account and…
Containers here, though I don't run Claude Code within containers, nor do I pass `--dangerously-skip-permissions`. Instead, I provide a way for agents to run commands within containers.
These containers only have the worker agent's workspace and some caching dirs (e.g. GOMODCACHE) mounted, and by default have `--network none` set. (Some commands, like `go mod download`, can be explicitly exempted to have network access.)
I also use per-skill hooks to enforce more filesystem isolation and check if an agent attempts to run e.g. `go build`, and tell it to run `aww exec go build` instead. (AWW is the name of the agent workflow system I've been developing over the past month—"Agent Workflow Wrangler.")
This feels like a pragmatic setup. I'm sure it's not riskless, but hopefully it does enough to mitigate the worst risks. I may yet go back to running Claude Code in a dedicated VM, along with the containerized commands, to add yet another layer of isolation.
Re: Let's discuss sandbox isolation
#34[deleted]
Re: Let's discuss sandbox isolation
#35Unikernel/libos is relevant
Re: Let's discuss sandbox isolation
#36OK, let’s survey how everybody is sandboxing their AI coding agents in early 2026. What I’ve seen suggests the most common answers are (a) “containers” and (b) “YOLO!” (maybe adding, “Please play nice, agent.”). One approach that I’m about to try is Sandvault [0] (macOS only), which uses the good old Unix user system together with some added precautions. Basically, give an agent its own unprivileged user account and…
Shell over MCP, with multiple options for sandbox. Includes Docker, Podman, Modal, E2B, and WASM: https://github.com/Kiln-AI/Kilntainers Can run anything from a busybox in WASM to a full cloud VM. Agent just sees a shell.
This seems to be billed as a MCP server for making sandbox containers... right? Doesn't this kind of miss the whole point?
"Make me a sandbox for yourself! Make sure its really secure!"
Re: Let's discuss sandbox isolation
#37A VM is table stakes for isolation. Nothing OS-level is going to prevent breaking out, the attack surface is too big and none of the common OSes are hardened enough. But also missing here is the firewall, which you need to prevent both data exfil and remote code execution from prompt injection. And the final part that's missing, is segregating all credentials from the agent's execution environment, which I don't think there's any existing solution for yet. Likely this will be either MCPs, or transparent proxies with policy engines that execute requests from tool calls.
Re: Let's discuss sandbox isolation
#38OK, let’s survey how everybody is sandboxing their AI coding agents in early 2026. What I’ve seen suggests the most common answers are (a) “containers” and (b) “YOLO!” (maybe adding, “Please play nice, agent.”). One approach that I’m about to try is Sandvault [0] (macOS only), which uses the good old Unix user system together with some added precautions. Basically, give an agent its own unprivileged user account and…
I use KVM/QEMU on Linux. I have a set of scripts that I use to create a new directory with a VM project and that also installs a debian image for the VM. I have an ./pull_from_vm and ./push_to_vm that I use to pull and push the git code to and from the vm. As well as a ./claude to start claude on the vm and a ./emacs to initialize and start emacs on the vm after syncing my local .spacemacs directory to the vm (I like…
You might like this (disclaimer my project):
Re: Let's discuss sandbox isolation
#39Earlier quoted context omitted.
I'm mainly addressing sandboxing by running stuff in Claude Code for web, at which point it's Anthropic's problem if they have a sandbox leak, not mine. It helps that most of my projects are open source so I don't need to worry about prompt injection code stealing vulnerabilities. That way the worst that can happen would be an attack adding a vulnerability to my code that I don't spot when I review the PR. And turnin…
hey fren, try this: https://github.com/smol-machines/smolvm I already have a couple folks using it for claude: https://github.com/smol-machines/smolvm/discussions/3
If you could make your tool work with PVM that would be amazing
Re: Let's discuss sandbox isolation
#40A VM is table stakes for isolation. Nothing OS-level is going to prevent breaking out, the attack surface is too big and none of the common OSes are hardened enough. But also missing here is the firewall, which you need to prevent both data exfil and remote code execution from prompt injection. And the final part that's missing, is segregating all credentials from the agent's execution environment, which I don't thin…
The final part is a long solved problem, pass in mock tokens, pass all requests through a proxy, only swap in the real tokens if the request matches whatever filtering requirements you have.