Let's discuss sandbox isolation
shayon.dev

・

64 points

・

shayonj

・

4 hours ago

20 comments

simonw ・ 2 hours ago

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!

pash ・ 2 hours ago

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

  • scosman ・ 20 minutes ago

    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.

  • simonw ・ an hour ago

    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.

grouchypumpkin ・ an hour ago

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.

  • diacritical ・ an hour ago

    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.

mcfig ・ 2 hours ago

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.

CuriouslyC ・ an hour ago

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.

  • yoyohello13 ・ 44 minutes ago

    But managing granular permissions is hard. The common denominator with all these discussions is people want to apply the minimal amount of thinking possible.

    • jbverschoor ・ 39 minutes ago

      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.

int0x29 ・ an hour ago

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

noperator ・ 26 minutes ago

> 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