Let's discuss sandbox isolation
41 points
2 hours ago
| 4 comments
| shayon.dev
| HN
simonw
39 minutes 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!

reply
syrusakbary
19 minutes ago
[-]
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...

reply
shayonj
17 minutes ago
[-]
Wasmer looks v cool. I must check it out
reply
shayonj
23 minutes ago
[-]
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!
reply
int0x29
3 minutes 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
reply
pash
29 minutes 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 either (a) “containers”, or (b) “YOLO!” (maybe adding, “Please play nice, agent.”).

One interesting 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

reply
simonw
11 minutes 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.

reply
mcfig
25 minutes 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.
reply