Let's discuss sandbox isolation
shayon.dev
Let's discuss sandbox isolation
1–10 of 75 posts
Re: Let's discuss sandbox isolation
#2> 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!
Re: Let's discuss sandbox isolation
#3What 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.
Re: Let's discuss sandbox isolation
#4Re: Let's discuss sandbox isolation
#5I 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 ha…
Re: Let's discuss sandbox isolation
#6I 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 ha…
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...
Re: Let's discuss sandbox isolation
#7I 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 ha…
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...
Re: Let's discuss sandbox isolation
#8OK, 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…
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.
Re: Let's discuss sandbox isolation
#9Re: Let's discuss sandbox isolation
#10It’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.