41–50 of 75 posts
Earlier quoted context omitted.
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
Unfortunately, the ecosystem and tooling is not there for macOS full paravirtualization yet
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 thin…
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.
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…
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 ha…
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).
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
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 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...
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…
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 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...
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.