> But the practical limitation is language support. You cannot run arbitrary Python scripts in WASM today without compiling the Python interpreter itself to WASM along with all its C extensions. For sandboxing arbitrary code in arbitrary languages, WASM is not yet viable.
Is the support for Python code provided as a Rust library by any chance, where you could do something like pass in a simple python function, run it in wasmer, and then get back the result? I know a lot of complications would come into play around supporting C-based dependencies and support for the WASM APIs for stuff like I/O, but I recently was looking into this for a use case where the goal is to be able to prevent stuff like direct use of I/O in favor of only supporting a few specific APIs provided directly to a WASM engine for the code it's executing, and the conclusion I reached was that the only viable options for that currently available would require either shelling out to something external or manually loading in a WASM-compiled interpreter and implementing the glue code to use that to execute Python myself.
Totally fair! I definitely understand the struggle of having more things that you want to do than time to work on them, and it's better to focus on the priorities and do them well than rush things just to get more of them done faster. Thanks for the response though; there's enough stuff happening in the WASM ecosystem that I don't always have confidence about whether I missed something!
Can you clarify what your disagreement is? The statement you're responding to seems to be that you can't necessarily run arbitrary code in arbitrary languages because it's only possible if the runtime is supported, and you're giving examples of two specific languages that had explicit extra work done to support them, which sounds pretty much exactly like what they're stating.
From what I can tell, the point they're making is that if you want a sandbox that you can put whatever you want into and have it work without it having explicit support provided for that language in the form of recompiling the runtime, it's not going to work. If someone is expecting to be able to throw stuff they already have into a sandbox as-is and have it work, WASM is not what they're looking for (at least not today).
It used Python as an example of why "For sandboxing arbitrary code in arbitrary languages, WASM is not yet viable." - but Python in WASM works really well, as do other languages where the interpreter can be compiled to WASM.
So while the statement is technically true that you can't run "arbitrary code in arbitrary languages", the practical reality is that for many languages WASM is a great solution despite that.
Looking again at the article though, it seems like they've added a paragraph after that references your response. The paragraph you quoted from isn't marked as edited, so I'm not sure if this was there before, but at least right now there's additional context coming immediately after your quote that I feel like conveys more nuance than it seems like you're addressing:
> For sandboxing arbitrary code in arbitrary languages, WASM is not yet viable. For sandboxing code you control the toolchain for, it is excellent.
That sounds pretty definitively like they're saying it is a great practical solution for many cases, not "ruling it out" like you mentioned in your top-level comment. It sounds more like they're saying it's not currently a black-box that you can run arbitrary code in, which is what some people might want in a sandbox.
> It sounds more like they're saying it's not currently a black-box that you can run arbitrary code in, which is what some people might want in a sandbox.
Yes, that's exactly what they are saying and it's true.
My comment (which they took on board) was to point out that, despite that, Python and JavaScript in WASM works really well if you take the extra steps of including a WASM-compiled build of the relevant interpreters.
I stand by my advice in this line:
> So don't rule out WASM as a target for running non-compiled languages, it can work pretty well!
You shouldn't rule out WASM for this purpose! I think it's likely people could read their original article and come to the wrong conclusion about that.
> I think it's likely people could read their original article and come to the wrong conclusion about that.
Fair enough; I think that's the part that I was missing. I might have been biased from having looked into this for Python recently and having a fairly high confidence in what those extra steps are, which could have made me overlook that others might not realize that those extra steps are even possible.
That is a good call out and I missed to consider the options you pointed. When I am back on keyboard I will add an updated note with a link to your comment. Thank you!
OK, 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 interact with it via sudo, SSH, and shared directories.
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 this because of customized emacs muscle memory and because I worry that emacs can execute arbitrary code if I use it to ssh to the VM client from my host).
I try not to run LLM's directly on my own host. The only exception I have is that I do use https://github.com/karthink/gptel on my own machine, because it is just too damn useful. I hope I don't self own myself with that someday.
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 turning off outbound networking should protect against code stealing too... but I allow access to everything because I don't need to worry about code stealing and that way Claude can install things and run benchmarks and generally do all sorts of other useful bits and pieces.
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.
The sandboxing options are set when you connect the MCP to the agent, not by the agent passing params about its own sandbox.
There’s a misconception about the right security boundary for agents. The agent code needs secrets (API keys, prompts, code) and the network (docs, other use cases). Wrapping the whole agent in a container puts secrets, network access, and arbitrary agent cli execution into the same host OS.
If you sandbox just the agent’s CLI access, then it’s can’t access its own API keys/code/host-OS/etc.
There's an intermediate step, which is to use a combination of claude code sandboxing (bubblewrap), plus some pre tool hooks to look for sketchy commands, but it's still interactive and probably not the right longterm approach.
But I use that specifically to run 'user-emulation' stories where an agent starts in their own `~/` environment with my tarball at ~/Downloads/app.tar.gz, and has to find its way through the docs / code / cli's and report on the experience.
Is there anything more secure than Qubes, assuming enough hardware resources? I'm asking about existing solutions, not theoretical ones. Given its track record so far, I'm betting not, but I'd love to be proven wrong. Adding sandboxing within a VM or hardening it should add more security, but overall I think this is the right approach for anyone who can afford a decent computer.
The attack surface of Xen, the current hypervisor of Qubes, is smaller compared to browsers and OSes that have 0days pathed several times a year. Even most Xen vulns don't affect Qubes.
I just can't imagine putting my whole digital life in one "normal" OS and hoping that the OS or browser security will keep me safe. I'm mentioning the browser because a lot what used to be in the OS is now in the browser, so it's functionally like another OS.
From a usability point of view it's also useful as I can have different environments. Not only different tools in each VM which means I can pretty much forget about dependency issues, but also different data in each VM. If I wanted, I could run any agent or malware on a VM and the exposure would only be whatever data I chose to put in that VM.
Of course, if you're not passing data between certain VMs, you could use different computers for an even better security.
WebAssembly is particularly attractive for agentic coding because prompting it to write Zig or C is no harder than prompting it to write JavaScript. So you can get the authoring speed of a scripting language via LLMs but the performance close to native via wasm.
This is the approach I’m using for my open source project qip that lets you pipeline wasm modules together to process text, images & data: https://github.com/royalicing/qip
qip modules follow a really simple contract: there’s some input provided to the WebAssembly module, and there’s some output it produces. They can’t access fs/net/time. You can pipe in from your other CLIs though, e.g. from curl.
I have example modules for markdown-to-html, bmp-to-ico (great for favicons), ical events, a basic svg rasterizer, and a static site builder. You compose them together and then can run them on the command line, in the browser, or in the provided dev server. Because the module contract is so simple they’ll work on native too.
An advantage of running a coding agent in a VM is that to answer your question, it can install arbitrary software into the VM. (For example, running apt-get or using curl to install a specialized tool.) WebAssembly seems suitable for more specialized agents where you already know what software it will need?
The difference between gVisor and a microVM isn't very large.
gVisor can even use KVM.
What gVisor doesn't have is the big Linux kernel, it attempts to roll a subset of it on its own in Go. And while doing so it allows for more convenient (from the host side) resource management.
Imagine taking the Linux kernel and starting to modify it to have a guest VM mode (memory management merged with the host, sockets passed through, file systems coupled closer etc). As you progress along that axis you will eventually end up as a gVisor clone.
Ultimately what all these approaches attempt to do is to narrow the interface between the jailed process as the host kernel. Because the default interface is vast. Makes you wonder if we will ever have a kernel with a narrow interface by default, a RISC-like syscall movement for kernels.
Its worth pointing out another boundary: speculative execution. If sensitive data is in process memory with a WASM VM it can be read even if the VM doesn't expose it. This is also true of multiple WASM VMs running for different parties. For WASM isolation to work the VM needs to be in a seperate process
QubesOS was built to give sandboxes kernel isolation via a hypervisor.
It’s not surprising that most people don’t know about it, because QubesOS as a daily driver can be painful. But with some improvements, I think it’s the right way to do it.
Just posted about Qubes a minute after you did, but I don't find it painful or even time consuming. Initially there was a learning curve, but even if the security of Qubes became the same as the security of a baremetal OS, I would still use it.
When I'm trying to get some software up and running, I've had issues with Debian many times, as well as with Fedora. Rarely with both. With Qubes after a few minutes of trying on Debian and running into some obscure errors, I can just say "fuck it" and try with Fedora, or vice versa. Over the years it has saved me more time than the time I've invested it learning how Qubes works or dealing with Qubes-specific issues.
I also don't have to care about polluting my OS with various software and running into a dependency hell.
If a VM crashes or hangs, it's usually OK, as it's just a VM.
It's much easier to run Whonix or VPNs without worrying for IP leaks.
If and when I decide to upgrade, I'll also ask in the forums. Not all hardware supports all the features required for the security. Some hardware just doesn't play nice for one reason or another.
On my desktop I have an 8th gen Intel CPU with a motherboard that had good reviews for working well with Qubes. Nothing fancy. I rarely use CPU-heavy software, though. If I'm crunching some numbers like password cracking, I just assign a few more cores to a VM (VM is a "qube" with lowercase "q" in Qubes's terminology) than usual and let it run for a few days. But I rarely do that and when I did, I wasn't pressed for time, so I haven't had the need to optimize or bench anything so far. I can't speak as to how it would perform vs a baremetal OS. Probably worse, but not by much.
RAM is far more important, as least to me. 32 GB is what I consider the minimum for me, but I prefer 64 or more, as it lets me be more relaxed with how many VMs I have running. I'm usually at 30-40 GB used with ~20 VMs. But when I'm experimenting with something, I can run a bunch of other stuff and not run out.
Through trial and error I figured out what amount of RAM works for what types of VMs based on the usage. A VM with 1.5 GB RAM can open 50 or more tabs if you have JS off, or 2-3 shitty JS-ridden SPA vomit-inducing sites before it starts to lag. The good thing is that if a VM lags, only that VM lags; Qubes itself and other VMs don't.
With 16 GB you'd be fine, but you'll have to care more about how much RAM each VM has. For system VMs like network or USB VMs, or VMs you use for a specific purpose only it's easy to figure out the required RAM. Some may need as little as 300-400 MB.
Videos play fine on VLC with the integrated GPU. I have the same issues with VLC as I've had on baremetal Linux OSes on other computers, like stuttering for a few seconds after seeking backwards or not playing 1080p H.265 videos smoothly.
I don't have a dedicated GPU. I don't game or mine crypto or use CAD or run or train AI models. So I can't comment on anything GPU-related, such as drivers or passthrough or performance.
I have a few laptops with Qubes that I use from time to time. The oldest is an x230 Thinkpad from ~2012 with 16 GB RAM. I don't use it as a daily driver, though, just for a few specific things. As a daily driver 16 GB RAM would annoy me a bit, but I'd still make it work if that was my only chance.
It's amazing how many different implementations of sandboxes have popped up in the past few weeks.
I'm CTO at Buildkite, have been noodling on one with a view to have an environment that can run CI workloads and Agentic ones https://github.com/buildkite/cleanroom
Heya! nice to see you here. In retrospect it feels like CI companies and environments are very well suited for sandboxes since a lot of the problems overlap around ephemeral workloads, running untrusted code, fast cold starts, multi-tenancy isolation. Also, loved Buildkite at a past job! Looking forward to following cleanroom
That’s a good shout! I have been curious as well and did some experiments. Also left out GPU sandboxing from the post as well. Maybe will reflect in a part II post.
I appreciate the details in this, but I also notice it is very machine-focused. When a user wants to sandbox an AI agent, they don’t just want their local .ssh keys protected. They also want to be able to control access to a lot of off-machine resources - e.g. allowing the agent to read github issues and sometimes also make some kinds of changes.
A 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.
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.
We've been working on exactly this at Islo. Zero-setup microVM sandboxes with isolated networking by default, plus an approval workflow layer so agents can request capabilities and humans approve/deny in real-time.
The credential problem is handled through proxy middleware - agents never see real tokens, requests get routed through policy-checked proxies that inject credentials only for approved operations.
Yeah, it's hard to hit the right balance with nuance around these and you're spot on. What I meant to get at was the specific difference in default modes where gVisor's systrap intercepts syscalls via seccomp traps and handles them entirely in a user-space Go kernel, so there's no hardware isolation boundary in the memory/execution sense. A microVM puts the guest in a VT-x/EPT-isolated address space, which is a qualitative difference in what enforces the boundary (perhaps?)
Whereas yeah, you can run gVisor in KVM mode where it does use hardware virtualization, and at that point the isolation boundary is much closer to a microVM's. I believe the real difference then becomes more about what's on either side of that boundary where gVisor gives you a memory-safe Go kernel making ~70 host syscalls, a microVM gives you a full guest Linux kernel behind a minimal VMM. So at least in my mind it comes down to a bit of around different trust chains, not necessarily one strictly stronger than the other.
I see this "hardware isolation" benefit of virtual machines brought up a lot, but if you look a little deeper into it, putting that label exclusively on VMs is very much unfair.
Just like containers, VMs are very loosely defined and, under the hood, composed of mechanisms that can be used in isolation (paging, trapping, IOMMU vs individual cgroups and namespaces). It's those mechanisms that give you the actual security benefits.
And most of them are used outside of VMs, to isolate processes on a bare kernel. The system call/software interrupt trapping and "regular" virtual memory of gVisor (or even a bare Linux kernel) are just as much of a "hardware boundary" as the hyper calls and SLAT virtual memory are in the case of VMs, just without the hacks needed to make the isolated side believe it's in control of real hardware. One traps into Sentry, the other traps into QEMU, but ultimately, both are user-space processes running on the host kernel. And they themselves are isolated, using the same very primitives, by the host kernel.
As you clarified here, the real difference lies in what's on the other side of these boundaries. gVisor will probably have some more overhead, at least in the systrap mode, as every trapped call has to go through the host kernel's dispatcher before landing in Sentry. QEMU/KVM has this benefit of letting the guest's user-space call the guest kernel directly, and only the kernel typically can then call QEMU. The attack surface, too, differs a lot in both cases. gVisor is a niche Google project, KVM is a business-critical component of many public cloud providers.
It may sound like I'm nitpicking, but I believe that it's important to understand this to make an informed decision and avoid the mistake of stacking up useless layers, as it is plaguing today's software engineering.
Thanks for your reply and post by the way! I was looking for something like gVisor.
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.
It only mentions 'user' isolation once in a table?
Giving agents their own user account is my go-to solution and solves all my practical problems with by far the oldest, well documented, and simplest isolation mechanism.
Sandbox isolation is only slightly important, you don't need to make it fancy, just a plain old VM. The really important thing is how you control capabilities you give for the agent to act on your behalf.
But managing granular permissions is hard. The common denominator with all these discussions is people want to apply the minimal amount of thinking possible.
> compute isolation means nothing if the sandbox can freely phone home.
Here's a project I've been working on to address the network risk. Uses nftables firewall allowing outbound traffic only to an explicit pinned domain allowlist (continuously refreshes DNS resolutions in the background).
Sharing my 5 cents on the matter: in another world, gaming, where embedding scripting languages is done for modding, I hope to see WASM take off as a way for modern modders to get into game development.
I've seen smaller developers experimenting with this, but haven't heard of larger orgs doing it, possibly because UGC took the place of modders as well, and I come from an older world where what developers of my time 20 years ago would have had their hands on was an actual SDK that wasn't a part of a long microtransaction pipeline.
In my org's case, where we built an entire game engine off Lua, and previously had done Lua integration in the Source Engine, I would have loved to have had sandboxing from the start rather than trying to think about security after the fact.
To the article's point: even if you were to sandboxing today in those environments, I suspect you'd be faster than some of the fastest embedded scripting languages because they're just that slow.
I disagree with this section about WebAssembly:
> But the practical limitation is language support. You cannot run arbitrary Python scripts in WASM today without compiling the Python interpreter itself to WASM along with all its C extensions. For sandboxing arbitrary code in arbitrary languages, WASM is not yet viable.
There are several versions of the Python interpreter that are compiled to WASM already - Pyodide has one, and WASM is a "Tier 2" supported target for CPython: https://peps.python.org/pep-0011/#tier-2 - unofficial builds here: https://github.com/brettcannon/cpython-wasi-build/releases
Likewise I've experimented with running various JavaScript interpreters compiled to WASM, the most popular of those is probably QuickJS. Here's one of my many demos: https://tools.simonwillison.net/quickjs (I have one for MicroQuickJS too https://tools.simonwillison.net/microquickjs )
So don't rule out WASM as a target for running non-compiled languages, it can work pretty well!
I also disagree with that.
Wasmer can run now Python server-side without any restrictions (including gevent, SQLAlchemy and native modules!) [1] [2]
Also, cool things are coming on the JS land running on Wasmer :)
[1] https://wasmer.io/posts/greenlet-support-python-wasm
[2] https://wasmer.io/posts/python-on-the-edge-powered-by-webass...
Is the support for Python code provided as a Rust library by any chance, where you could do something like pass in a simple python function, run it in wasmer, and then get back the result? I know a lot of complications would come into play around supporting C-based dependencies and support for the WASM APIs for stuff like I/O, but I recently was looking into this for a use case where the goal is to be able to prevent stuff like direct use of I/O in favor of only supporting a few specific APIs provided directly to a WASM engine for the code it's executing, and the conclusion I reached was that the only viable options for that currently available would require either shelling out to something external or manually loading in a WASM-compiled interpreter and implementing the glue code to use that to execute Python myself.
Not right now but we would love to provide it.
We have been super busy lately, but when we have a chance we will work on it!
Totally fair! I definitely understand the struggle of having more things that you want to do than time to work on them, and it's better to focus on the priorities and do them well than rush things just to get more of them done faster. Thanks for the response though; there's enough stuff happening in the WASM ecosystem that I don't always have confidence about whether I missed something!
Without any restrictions except, well, performance, and still a fair amount of library choices. It’s just easier to use Go (TinyGo, actually) instead.
Wasmer looks v cool. I must check it out
Can you clarify what your disagreement is? The statement you're responding to seems to be that you can't necessarily run arbitrary code in arbitrary languages because it's only possible if the runtime is supported, and you're giving examples of two specific languages that had explicit extra work done to support them, which sounds pretty much exactly like what they're stating.
From what I can tell, the point they're making is that if you want a sandbox that you can put whatever you want into and have it work without it having explicit support provided for that language in the form of recompiling the runtime, it's not going to work. If someone is expecting to be able to throw stuff they already have into a sandbox as-is and have it work, WASM is not what they're looking for (at least not today).
It used Python as an example of why "For sandboxing arbitrary code in arbitrary languages, WASM is not yet viable." - but Python in WASM works really well, as do other languages where the interpreter can be compiled to WASM.
So while the statement is technically true that you can't run "arbitrary code in arbitrary languages", the practical reality is that for many languages WASM is a great solution despite that.
Looking again at the article though, it seems like they've added a paragraph after that references your response. The paragraph you quoted from isn't marked as edited, so I'm not sure if this was there before, but at least right now there's additional context coming immediately after your quote that I feel like conveys more nuance than it seems like you're addressing:
> For sandboxing arbitrary code in arbitrary languages, WASM is not yet viable. For sandboxing code you control the toolchain for, it is excellent.
That sounds pretty definitively like they're saying it is a great practical solution for many cases, not "ruling it out" like you mentioned in your top-level comment. It sounds more like they're saying it's not currently a black-box that you can run arbitrary code in, which is what some people might want in a sandbox.
> It sounds more like they're saying it's not currently a black-box that you can run arbitrary code in, which is what some people might want in a sandbox.
Yes, that's exactly what they are saying and it's true.
My comment (which they took on board) was to point out that, despite that, Python and JavaScript in WASM works really well if you take the extra steps of including a WASM-compiled build of the relevant interpreters.
I stand by my advice in this line:
> So don't rule out WASM as a target for running non-compiled languages, it can work pretty well!
You shouldn't rule out WASM for this purpose! I think it's likely people could read their original article and come to the wrong conclusion about that.
> I think it's likely people could read their original article and come to the wrong conclusion about that.
Fair enough; I think that's the part that I was missing. I might have been biased from having looked into this for Python recently and having a fairly high confidence in what those extra steps are, which could have made me overlook that others might not realize that those extra steps are even possible.
That is a good call out and I missed to consider the options you pointed. When I am back on keyboard I will add an updated note with a link to your comment. Thank you!
OK, 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 interact with it via sudo, SSH, and shared directories.
0. https://github.com/webcoyote/sandvault
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 this because of customized emacs muscle memory and because I worry that emacs can execute arbitrary code if I use it to ssh to the VM client from my host).
I try not to run LLM's directly on my own host. The only exception I have is that I do use https://github.com/karthink/gptel on my own machine, because it is just too damn useful. I hope I don't self own myself with that someday.
You might like this (disclaimer my project):
https://github.com/jgbrwn/vibebin
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 turning off outbound networking should protect against code stealing too... but I allow access to everything because I don't need to worry about code stealing and that way Claude can install things and run benchmarks and generally do all sorts of other useful bits and pieces.
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
Tool is already configured with paravirtualization on the linux path
Unfortunately, the ecosystem and tooling is not there for macOS full paravirtualization yet
Oh neat yeah I only care about Linux pvm. Assuming we still have to have already installed the PVM kernel and other pvm-related prereqs or?
Looked into Apples container framework first (for proper isolation) but switched to Docker sandboxes since they switched to mircoVMs too: https://docs.docker.com/ai/sandboxes/#why-use-docker-sandbox...
Quite similar to how Im using docker for a few years
https://github.com/jrz/container-shell
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.
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!"
The sandboxing options are set when you connect the MCP to the agent, not by the agent passing params about its own sandbox.
There’s a misconception about the right security boundary for agents. The agent code needs secrets (API keys, prompts, code) and the network (docs, other use cases). Wrapping the whole agent in a container puts secrets, network access, and arbitrary agent cli execution into the same host OS.
If you sandbox just the agent’s CLI access, then it’s can’t access its own API keys/code/host-OS/etc.
My app is a macOS terminal wrapper with nice GUI for sandbox-exec and network sandbox. I just added a vertical tabs option too. https://multitui.com
There's an intermediate step, which is to use a combination of claude code sandboxing (bubblewrap), plus some pre tool hooks to look for sketchy commands, but it's still interactive and probably not the right longterm approach.
Sandvault author here: thanks for the shout-out!
I would add that in addition to Unix permissions, sandvault also utilizes macOS sandbox-exec to further limit the blast radius.
Dedicate user account.
That's not to say I don't use bwrap.
But I use that specifically to run 'user-emulation' stories where an agent starts in their own `~/` environment with my tarball at ~/Downloads/app.tar.gz, and has to find its way through the docs / code / cli's and report on the experience.
I use either QEMU VMs or my own sandbox-run [0] (a bubblewrap wrapper) for isolation, depending on the use case.
[0] https://codeberg.org/Grauwolf/sandbox-run
I've been using nsjail, which i guess employs several of these techniques.
Is there anything more secure than Qubes, assuming enough hardware resources? I'm asking about existing solutions, not theoretical ones. Given its track record so far, I'm betting not, but I'd love to be proven wrong. Adding sandboxing within a VM or hardening it should add more security, but overall I think this is the right approach for anyone who can afford a decent computer.
The attack surface of Xen, the current hypervisor of Qubes, is smaller compared to browsers and OSes that have 0days pathed several times a year. Even most Xen vulns don't affect Qubes.
I just can't imagine putting my whole digital life in one "normal" OS and hoping that the OS or browser security will keep me safe. I'm mentioning the browser because a lot what used to be in the OS is now in the browser, so it's functionally like another OS.
From a usability point of view it's also useful as I can have different environments. Not only different tools in each VM which means I can pretty much forget about dependency issues, but also different data in each VM. If I wanted, I could run any agent or malware on a VM and the exposure would only be whatever data I chose to put in that VM.
Of course, if you're not passing data between certain VMs, you could use different computers for an even better security.
Took a quick look, and indeed sounds like QubesOS is the ultimate sandbox for developers in the age of LLMs.
WebAssembly is particularly attractive for agentic coding because prompting it to write Zig or C is no harder than prompting it to write JavaScript. So you can get the authoring speed of a scripting language via LLMs but the performance close to native via wasm.
This is the approach I’m using for my open source project qip that lets you pipeline wasm modules together to process text, images & data: https://github.com/royalicing/qip
qip modules follow a really simple contract: there’s some input provided to the WebAssembly module, and there’s some output it produces. They can’t access fs/net/time. You can pipe in from your other CLIs though, e.g. from curl.
I have example modules for markdown-to-html, bmp-to-ico (great for favicons), ical events, a basic svg rasterizer, and a static site builder. You compose them together and then can run them on the command line, in the browser, or in the provided dev server. Because the module contract is so simple they’ll work on native too.
An advantage of running a coding agent in a VM is that to answer your question, it can install arbitrary software into the VM. (For example, running apt-get or using curl to install a specialized tool.) WebAssembly seems suitable for more specialized agents where you already know what software it will need?
The difference between gVisor and a microVM isn't very large.
gVisor can even use KVM.
What gVisor doesn't have is the big Linux kernel, it attempts to roll a subset of it on its own in Go. And while doing so it allows for more convenient (from the host side) resource management.
Imagine taking the Linux kernel and starting to modify it to have a guest VM mode (memory management merged with the host, sockets passed through, file systems coupled closer etc). As you progress along that axis you will eventually end up as a gVisor clone.
Ultimately what all these approaches attempt to do is to narrow the interface between the jailed process as the host kernel. Because the default interface is vast. Makes you wonder if we will ever have a kernel with a narrow interface by default, a RISC-like syscall movement for kernels.
Its worth pointing out another boundary: speculative execution. If sensitive data is in process memory with a WASM VM it can be read even if the VM doesn't expose it. This is also true of multiple WASM VMs running for different parties. For WASM isolation to work the VM needs to be in a seperate process
QubesOS was built to give sandboxes kernel isolation via a hypervisor.
It’s not surprising that most people don’t know about it, because QubesOS as a daily driver can be painful. But with some improvements, I think it’s the right way to do it.
Just posted about Qubes a minute after you did, but I don't find it painful or even time consuming. Initially there was a learning curve, but even if the security of Qubes became the same as the security of a baremetal OS, I would still use it.
When I'm trying to get some software up and running, I've had issues with Debian many times, as well as with Fedora. Rarely with both. With Qubes after a few minutes of trying on Debian and running into some obscure errors, I can just say "fuck it" and try with Fedora, or vice versa. Over the years it has saved me more time than the time I've invested it learning how Qubes works or dealing with Qubes-specific issues.
I also don't have to care about polluting my OS with various software and running into a dependency hell.
If a VM crashes or hangs, it's usually OK, as it's just a VM.
It's much easier to run Whonix or VPNs without worrying for IP leaks.
This is great insight - using Qubes as a "Super-OS" over other OSes. How does it fly performance-wise, what HW are you on or recommend ?
Sorry for the late reply.
I can't recommend specific HW as I'm not using anything new or beefy and I'm not running any CPU or GPU intensive things on Qubes.
There's the Qubes Hardware Compatibility List (HCL) where people have added their hardware:
https://www.qubes-os.org/hcl/
If and when I decide to upgrade, I'll also ask in the forums. Not all hardware supports all the features required for the security. Some hardware just doesn't play nice for one reason or another.
On my desktop I have an 8th gen Intel CPU with a motherboard that had good reviews for working well with Qubes. Nothing fancy. I rarely use CPU-heavy software, though. If I'm crunching some numbers like password cracking, I just assign a few more cores to a VM (VM is a "qube" with lowercase "q" in Qubes's terminology) than usual and let it run for a few days. But I rarely do that and when I did, I wasn't pressed for time, so I haven't had the need to optimize or bench anything so far. I can't speak as to how it would perform vs a baremetal OS. Probably worse, but not by much.
RAM is far more important, as least to me. 32 GB is what I consider the minimum for me, but I prefer 64 or more, as it lets me be more relaxed with how many VMs I have running. I'm usually at 30-40 GB used with ~20 VMs. But when I'm experimenting with something, I can run a bunch of other stuff and not run out.
Through trial and error I figured out what amount of RAM works for what types of VMs based on the usage. A VM with 1.5 GB RAM can open 50 or more tabs if you have JS off, or 2-3 shitty JS-ridden SPA vomit-inducing sites before it starts to lag. The good thing is that if a VM lags, only that VM lags; Qubes itself and other VMs don't.
With 16 GB you'd be fine, but you'll have to care more about how much RAM each VM has. For system VMs like network or USB VMs, or VMs you use for a specific purpose only it's easy to figure out the required RAM. Some may need as little as 300-400 MB.
Videos play fine on VLC with the integrated GPU. I have the same issues with VLC as I've had on baremetal Linux OSes on other computers, like stuttering for a few seconds after seeking backwards or not playing 1080p H.265 videos smoothly.
I don't have a dedicated GPU. I don't game or mine crypto or use CAD or run or train AI models. So I can't comment on anything GPU-related, such as drivers or passthrough or performance.
I have a few laptops with Qubes that I use from time to time. The oldest is an x230 Thinkpad from ~2012 with 16 GB RAM. I don't use it as a daily driver, though, just for a few specific things. As a daily driver 16 GB RAM would annoy me a bit, but I'd still make it work if that was my only chance.
It's amazing how many different implementations of sandboxes have popped up in the past few weeks.
I'm CTO at Buildkite, have been noodling on one with a view to have an environment that can run CI workloads and Agentic ones https://github.com/buildkite/cleanroom
Heya! nice to see you here. In retrospect it feels like CI companies and environments are very well suited for sandboxes since a lot of the problems overlap around ephemeral workloads, running untrusted code, fast cold starts, multi-tenancy isolation. Also, loved Buildkite at a past job! Looking forward to following cleanroom
The entire kernel on every arch is 40 million lines, but the kernel running on your desktop is probably less than 2 million of those lines.
Good write up. I was hoping to see V8 isolates (Cloudflare workers) as part of the comparison at I've always found that interesting.
That’s a good shout! I have been curious as well and did some experiments. Also left out GPU sandboxing from the post as well. Maybe will reflect in a part II post.
I appreciate the details in this, but I also notice it is very machine-focused. When a user wants to sandbox an AI agent, they don’t just want their local .ssh keys protected. They also want to be able to control access to a lot of off-machine resources - e.g. allowing the agent to read github issues and sometimes also make some kinds of changes.
A 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.
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.
This is going to be an interesting space to watch I think and big part of offering sandbox as a service basically for enterprise and saas needs.
I believe deno literally shipped that final part a few weeks back.
We've been working on exactly this at Islo. Zero-setup microVM sandboxes with isolated networking by default, plus an approval workflow layer so agents can request capabilities and humans approve/deny in real-time.
The credential problem is handled through proxy middleware - agents never see real tokens, requests get routed through policy-checked proxies that inject credentials only for approved operations.
Happy to share more: https://islo.dev
Is there only a cloud-based mode for Islo, or can I run this entirely on my laptop?
This is unreachable?
> The trade-off versus gVisor is that microVMs have higher per-instance overhead but stronger, hardware-enforced isolation.
Having worked on kernel and hypervisor code, I really don't see much of a difference in terms of isolation. Could you elaborate on this?
Yeah, it's hard to hit the right balance with nuance around these and you're spot on. What I meant to get at was the specific difference in default modes where gVisor's systrap intercepts syscalls via seccomp traps and handles them entirely in a user-space Go kernel, so there's no hardware isolation boundary in the memory/execution sense. A microVM puts the guest in a VT-x/EPT-isolated address space, which is a qualitative difference in what enforces the boundary (perhaps?)
Whereas yeah, you can run gVisor in KVM mode where it does use hardware virtualization, and at that point the isolation boundary is much closer to a microVM's. I believe the real difference then becomes more about what's on either side of that boundary where gVisor gives you a memory-safe Go kernel making ~70 host syscalls, a microVM gives you a full guest Linux kernel behind a minimal VMM. So at least in my mind it comes down to a bit of around different trust chains, not necessarily one strictly stronger than the other.
I see this "hardware isolation" benefit of virtual machines brought up a lot, but if you look a little deeper into it, putting that label exclusively on VMs is very much unfair.
Just like containers, VMs are very loosely defined and, under the hood, composed of mechanisms that can be used in isolation (paging, trapping, IOMMU vs individual cgroups and namespaces). It's those mechanisms that give you the actual security benefits.
And most of them are used outside of VMs, to isolate processes on a bare kernel. The system call/software interrupt trapping and "regular" virtual memory of gVisor (or even a bare Linux kernel) are just as much of a "hardware boundary" as the hyper calls and SLAT virtual memory are in the case of VMs, just without the hacks needed to make the isolated side believe it's in control of real hardware. One traps into Sentry, the other traps into QEMU, but ultimately, both are user-space processes running on the host kernel. And they themselves are isolated, using the same very primitives, by the host kernel.
As you clarified here, the real difference lies in what's on the other side of these boundaries. gVisor will probably have some more overhead, at least in the systrap mode, as every trapped call has to go through the host kernel's dispatcher before landing in Sentry. QEMU/KVM has this benefit of letting the guest's user-space call the guest kernel directly, and only the kernel typically can then call QEMU. The attack surface, too, differs a lot in both cases. gVisor is a niche Google project, KVM is a business-critical component of many public cloud providers.
It may sound like I'm nitpicking, but I believe that it's important to understand this to make an informed decision and avoid the mistake of stacking up useless layers, as it is plaguing today's software engineering.
Thanks for your reply and post by the way! I was looking for something like gVisor.
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.
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.
It only mentions 'user' isolation once in a table?
Giving agents their own user account is my go-to solution and solves all my practical problems with by far the oldest, well documented, and simplest isolation mechanism.
Sandbox isolation is only slightly important, you don't need to make it fancy, just a plain old VM. The really important thing is how you control capabilities you give for the agent to act on your behalf.
But managing granular permissions is hard. The common denominator with all these discussions is people want to apply the minimal amount of thinking possible.
1) can access/write local files?
2) can access/write a specific folder?
3) can access network?
4) can access gateway/internet?
5) can access local network? (vlans would help here)
6) give access to USB devices
7) needs access to the screen? -> giveframebuffer access / drawing primitive
8) Need to write? Use an overlay FS that can be checked by the host and approved
9) sub processes can never escalate permissions
By default: nothing. But unfortunately, it’s always by default allow.
Also, make it simple to remove the permissions again.
> compute isolation means nothing if the sandbox can freely phone home.
Here's a project I've been working on to address the network risk. Uses nftables firewall allowing outbound traffic only to an explicit pinned domain allowlist (continuously refreshes DNS resolutions in the background).
https://github.com/noperator/cagent
Unikernel/libos is relevant
Sharing my 5 cents on the matter: in another world, gaming, where embedding scripting languages is done for modding, I hope to see WASM take off as a way for modern modders to get into game development.
I've seen smaller developers experimenting with this, but haven't heard of larger orgs doing it, possibly because UGC took the place of modders as well, and I come from an older world where what developers of my time 20 years ago would have had their hands on was an actual SDK that wasn't a part of a long microtransaction pipeline.
In my org's case, where we built an entire game engine off Lua, and previously had done Lua integration in the Source Engine, I would have loved to have had sandboxing from the start rather than trying to think about security after the fact.
To the article's point: even if you were to sandboxing today in those environments, I suspect you'd be faster than some of the fastest embedded scripting languages because they're just that slow.
Flight Simulator uses WASM.
[dead]