> 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.
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).
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.
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.
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.
The interesting thing in that thread is how many people have landed on isolation as a workaround while still lacking a real control plane on top of it. Containers reduce blast radius, but they don’t answer approvals, policy, or auditability. That’s the gap I keep seeing in these setups. I've found a software, called Daedalab, that instead of sandboxing AI puts deterministic control on agents actions.
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.
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.
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.
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.
> 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.
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?
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.
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.
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 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.
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
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.
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.
34 comments
[ 5.2 ms ] story [ 69.7 ms ] thread> 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!
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).
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
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.
[0] https://codeberg.org/Grauwolf/sandbox-run
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.
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.
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
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.
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.
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?
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.
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.
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
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.
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
[1] https://git.sr.ht/~alip/syd