I had the same idea, forcing the agent to execute code inside a WASM instance, and I've developed a few proof of concepts over the past few weeks. The latest solution I adopted was to provide a WASM instance as a sandbox and use MCP to supply the tool calls to the agent. However, it hasn't seemed flexible enough for all use cases to me. On top of that, there's also the issue of supporting the various possible runtimes.
While I think that with their current choice for the runtime will hit some limitations (aka: not really full Python support, partial JS support), I strongly believe using Wasm for sandboxing is the way for the future of containers.
At Wasmer we are working hard to make this model work. I'm incredibly happy to see more people joining on the quest!
Browserpod is great, been following it for a bit. Keep the good work up!
The main issue that I see with Browserpod is very similar to Emscripten: it's designed to work mainly in the browser, and not outside.
In my view, where Wasm really shines, is for enabling containers that work seamlessly in any of this environments: browsers, servers, or even embedded in apps :)
It is true that BrowserPod is currently focused on browsers environment, but there is nothing preventing the technology from running on native as well. It would requite some work, but nothing truly challenging :-)
Appreciate your support! We deliberately chose a limited runtime (quickjs + some shell applets). The tool parameter constraint enforcement was more important to us than language completeness. For agent tool calling, you don't really need NumPy and Pandas.
Wasmer is doing great work—we're using wasmtime on the host side currently but have been following your progress. Excited to see WASM sandboxing become more mainstream for this use case.
Fair point. We get around this by "yielding" back from the Wasm runtime (in a coroutine style) so that the "host" can do network calls or other IO on behalf of the Wasm runtime. But it would be great to do this natively within Wasm!
We implemented all the system calls necessary to make networking work (within Wasm), and dynamic linking (so you could import and run pydantic, numpy, gevent and more!)
Cool to see more projects in this space! I think Wasm is a great way to do secure sandboxing here. How does Amla handle commands like grep/jq/curl etc which make AI agents so effective at bash but require recompilation to WASI (which is kinda impractical for so many projects)?
I've been working on a couple of things which take a very similar approach, with what seem to be some different tradeoffs:
- eryx [1], which uses a WASI build of CPython to provide a true Python sandbox (similar to componentize-py but supports some form of 'dynamic linking' with either pure Python packages or WASI-compiled native wheels)
- conch [2], which embeds the `brush` Rust reimplementation of Bash to provide a similar bash sandbox. This is where I've been struggling with figuring out the best way to do subcommands, right now they just have to be rewritten and compiled in but I'd like to find a way to dynamically link them in similar to the Python package approach...
One other note, WASI's VFS support has been great, I just wish there was more progress on `wasi-tls`, it's tricky to get network access working otherwise...
Great question. We cheated a bit; we didn't compile the GNU coreutils to wasm. Instead, we have Rust reimplementations of common shell commands. It allows us to focus on the use cases agents actually care about instead of reimplementing all of the corner cases exactly.
curl is interesting. We don't include it currently but we could do it without too much additional effort.
Networking isn't done within the wasm sandbox; we "yield" back to the the caller using what we call "host operations" in order to perform any IO. This keeps the Wasm sandbox minimal and as close to "pure compute" as possible. In fact, the only capabilities we give the WASI runtime is a method to get the current time and to generate random numbers. Since we intercept all external IO, random number generation, time, and the Wasm runtime is just for pure computation, we also get perfect reproducibility. We can replay anything within the sandbox exactly.
Your approach with brush is interesting. Having actual bash semantics rather than "bash-like" is a real advantage for complex scripts. The dynamic linking problem for subcommands is a tough one; have you looked at WASI components for this? Feels like that's where it'll eventually land but the tooling isn't there yet.
Will check out eryx and conch. Thanks for sharing!
Hah, that is exactly the same approach I landed on. Fortunately the most common tools either seem to have Rust ports or are fairly easy to port 80% of the functionality! Conch's Wasm file is around ~3.5MB and only has a few tools though so I can see it growing. I think for the places where size really matters (e.g. the web) it should be possible to split it using the component model and `jco` (which I think splits Wasm components into modules along interface boundaries, and could defer loading of unused modules) but I haven't got that far yet.
I did something very similar to you for networking in eryx too (no networking in conch yet); defined an `eryx:net` interface in WIT and reimplemented the `urllib` module using host networking, which most downstream packages (httpx, requests, etc) use far enough down the stack. It's a tradeoff but I think it's pretty much good enough for most use cases like this, and gives the host full control which is great.
Oh full transparency, the vast majority of conch and eryx were written by Opus 4.5. Being backed by wasmtime and the rather strict Rust compiler is definitely a boon here!
One nice thing about using AgentFS as the VFS is that it's backed by sqlite so it's very portable - making it easy to fork and resume agent workflows across machines / time.
I really like Amla Sandbox addition of injecting tool calls into the sandbox, which lets the agent generated code interact with the harness provided tools. Very interesting!
Sure, but every tool that you provide access to, is a potential escape hatch from the sandbox. It's safer to run everything inside the sandbox, including the called tools.
That's definitely true. Our model assumes tools run outside the sandbox on a trusted host—the sandbox constrains which tools can be called and with what parameters. The reason for this is most "useful" tools are actually just some API call over the network (MCP, REST API, etc.). Then you need to get credentials and network access into the sandbox, which opens its own attack surface. We chose to keep credentials on the host and let the sandbox act as a policy enforcement layer: agents can only invoke what you've explicitly exposed, with the constraints you define.
Really appreciate the pragmatic approach here. The 11MB vs 173MB difference with agentvm highlights an important tradeoff: sometimes you don't need full Linux compatibility if you can constrain the problem space well enough. The tool-calling validation layer seems like the sweet spot between safety and practical deployment.
> The sandbox runs inside WebAssembly with WASI for a minimal syscall interface. WASM provides memory isolation by design—linear memory is bounds-checked, and there's no way to escape to the host address space. The wasmtime runtime we use is built with defense-in-depth and has been formally verified for memory safety.
> On top of WASM isolation, every tool call goes through capability validation: [...]
> The design draws from capability-based security as implemented in systems like seL4—access is explicitly granted, not implicitly available. Agents don't get ambient authority just because they're running in your process.
agentvm looks very cool! They are taking a different approach - full Linux VM emulated in WASM. It's very impressive technically.
We differentiate from agentvm by being lightweight (~11 MB Wasm binary, compared to 173 MB for agentvm). Though there is still a lot we can learn from agentvm, thank you for sharing their project.
Thank you! When I started working on agentvm my original goal was similar to yours, build a kind of Mingw or Cygwin for WASM. However, I quickly learned that this wouldn't really be feasible with reasonable amounts of time/token spend, mostly due to issues like having to find a way to make fork work, etc. I am no expert for WASM or Linux system programming, but it's been a lot of fun working on this stuff. I hope that the WASI standard and runtimes become more mature, as I feel that WASM sandboxes make a lot of sense in environments where containers are not an option.
Thanks for sharing the context! The fork problem is gnarly. Makes sense that full Linux emulation was the path forward for your use case.
Agreed on WASI maturity. We're hoping the component model lands in a stable form soon. Would love to see the ecosystem converge so these approaches can interoperate.
> Don't there need to be per- CPU/RAM/GPU quotas per WASM scope/tab? Or is preventing DOS with WASM out of scope for browsers?
> IIRC, it's possible to check resource utilization in e.g. a browser Task Manager, but there's no way to do `nice` or `docker --cpu-quota` or `systemd-nspawn --cpu-affinity` to prevent one or more WASM tabs from DOS'ing a workstation with non-costed operations.
I had the same idea, forcing the agent to execute code inside a WASM instance, and I've developed a few proof of concepts over the past few weeks. The latest solution I adopted was to provide a WASM instance as a sandbox and use MCP to supply the tool calls to the agent. However, it hasn't seemed flexible enough for all use cases to me. On top of that, there's also the issue of supporting the various possible runtimes.
This is great!
While I think that with their current choice for the runtime will hit some limitations (aka: not really full Python support, partial JS support), I strongly believe using Wasm for sandboxing is the way for the future of containers.
At Wasmer we are working hard to make this model work. I'm incredibly happy to see more people joining on the quest!
Hi, if you like the idea of Wasm sandboxing you might be interested in what we are working on: BrowserPod :-)
https://labs.leaningtech.com/blog/browserpod-beta-announceme...
https://browserpod.io
Browserpod is great, been following it for a bit. Keep the good work up!
The main issue that I see with Browserpod is very similar to Emscripten: it's designed to work mainly in the browser, and not outside.
In my view, where Wasm really shines, is for enabling containers that work seamlessly in any of this environments: browsers, servers, or even embedded in apps :)
It is true that BrowserPod is currently focused on browsers environment, but there is nothing preventing the technology from running on native as well. It would requite some work, but nothing truly challenging :-)
Appreciate your support! We deliberately chose a limited runtime (quickjs + some shell applets). The tool parameter constraint enforcement was more important to us than language completeness. For agent tool calling, you don't really need NumPy and Pandas.
Wasmer is doing great work—we're using wasmtime on the host side currently but have been following your progress. Excited to see WASM sandboxing become more mainstream for this use case.
> For agent tool calling, you don't really need NumPy and Pandas.
That's true, but you'll likely need sockets, pydantic or SQLAlchemy (all of of them require heavy support on the Wasm layer!)
Fair point. We get around this by "yielding" back from the Wasm runtime (in a coroutine style) so that the "host" can do network calls or other IO on behalf of the Wasm runtime. But it would be great to do this natively within Wasm!
Might be worth taking a look at WASIX [1]
We implemented all the system calls necessary to make networking work (within Wasm), and dynamic linking (so you could import and run pydantic, numpy, gevent and more!)
[1] https://wasix.org/
Cool to see more projects in this space! I think Wasm is a great way to do secure sandboxing here. How does Amla handle commands like grep/jq/curl etc which make AI agents so effective at bash but require recompilation to WASI (which is kinda impractical for so many projects)?
I've been working on a couple of things which take a very similar approach, with what seem to be some different tradeoffs:
- eryx [1], which uses a WASI build of CPython to provide a true Python sandbox (similar to componentize-py but supports some form of 'dynamic linking' with either pure Python packages or WASI-compiled native wheels) - conch [2], which embeds the `brush` Rust reimplementation of Bash to provide a similar bash sandbox. This is where I've been struggling with figuring out the best way to do subcommands, right now they just have to be rewritten and compiled in but I'd like to find a way to dynamically link them in similar to the Python package approach...
One other note, WASI's VFS support has been great, I just wish there was more progress on `wasi-tls`, it's tricky to get network access working otherwise...
[1] https://github.com/eryx-org/eryx [2] https://github.com/sd2k/conch
Great question. We cheated a bit; we didn't compile the GNU coreutils to wasm. Instead, we have Rust reimplementations of common shell commands. It allows us to focus on the use cases agents actually care about instead of reimplementing all of the corner cases exactly.
For `jq` specifically we use the excellent `jaq_interpret` crate: https://crates.io/crates/jaq-interpret
curl is interesting. We don't include it currently but we could do it without too much additional effort.
Networking isn't done within the wasm sandbox; we "yield" back to the the caller using what we call "host operations" in order to perform any IO. This keeps the Wasm sandbox minimal and as close to "pure compute" as possible. In fact, the only capabilities we give the WASI runtime is a method to get the current time and to generate random numbers. Since we intercept all external IO, random number generation, time, and the Wasm runtime is just for pure computation, we also get perfect reproducibility. We can replay anything within the sandbox exactly.
Your approach with brush is interesting. Having actual bash semantics rather than "bash-like" is a real advantage for complex scripts. The dynamic linking problem for subcommands is a tough one; have you looked at WASI components for this? Feels like that's where it'll eventually land but the tooling isn't there yet.
Will check out eryx and conch. Thanks for sharing!
Hah, that is exactly the same approach I landed on. Fortunately the most common tools either seem to have Rust ports or are fairly easy to port 80% of the functionality! Conch's Wasm file is around ~3.5MB and only has a few tools though so I can see it growing. I think for the places where size really matters (e.g. the web) it should be possible to split it using the component model and `jco` (which I think splits Wasm components into modules along interface boundaries, and could defer loading of unused modules) but I haven't got that far yet.
I did something very similar to you for networking in eryx too (no networking in conch yet); defined an `eryx:net` interface in WIT and reimplemented the `urllib` module using host networking, which most downstream packages (httpx, requests, etc) use far enough down the stack. It's a tradeoff but I think it's pretty much good enough for most use cases like this, and gives the host full control which is great.
Oh full transparency, the vast majority of conch and eryx were written by Opus 4.5. Being backed by wasmtime and the rather strict Rust compiler is definitely a boon here!
Sharing our version of this built on just-bash, AgentFS, and Pyodide: https://github.com/coplane/localsandbox
One nice thing about using AgentFS as the VFS is that it's backed by sqlite so it's very portable - making it easy to fork and resume agent workflows across machines / time.
I really like Amla Sandbox addition of injecting tool calls into the sandbox, which lets the agent generated code interact with the harness provided tools. Very interesting!
Thanks for sharing localsandbox! sqlite-backed VFS for fork and resume workflows is very interesting.
Sure, but every tool that you provide access to, is a potential escape hatch from the sandbox. It's safer to run everything inside the sandbox, including the called tools.
That's definitely true. Our model assumes tools run outside the sandbox on a trusted host—the sandbox constrains which tools can be called and with what parameters. The reason for this is most "useful" tools are actually just some API call over the network (MCP, REST API, etc.). Then you need to get credentials and network access into the sandbox, which opens its own attack surface. We chose to keep credentials on the host and let the sandbox act as a policy enforcement layer: agents can only invoke what you've explicitly exposed, with the constraints you define.
Really appreciate the pragmatic approach here. The 11MB vs 173MB difference with agentvm highlights an important tradeoff: sometimes you don't need full Linux compatibility if you can constrain the problem space well enough. The tool-calling validation layer seems like the sweet spot between safety and practical deployment.
From the README:
> Security model
> The sandbox runs inside WebAssembly with WASI for a minimal syscall interface. WASM provides memory isolation by design—linear memory is bounds-checked, and there's no way to escape to the host address space. The wasmtime runtime we use is built with defense-in-depth and has been formally verified for memory safety.
> On top of WASM isolation, every tool call goes through capability validation: [...]
> The design draws from capability-based security as implemented in systems like seL4—access is explicitly granted, not implicitly available. Agents don't get ambient authority just because they're running in your process.
From "Show HN: NPM install a WASM based Linux VM for your agents" re: https://github.com/deepclause/agentvm .. https://news.ycombinator.com/item?id=46686346 :
>> How to run vscode-container-wasm-gcc-example with c2w, with joelseverin/linux-wasm?
> linux-wasm is apparently faster than c2w.
container2wasm issue #550: https://github.com/container2wasm/container2wasm/issues/550#...
vscode-container-wasm-gcc-example : https://github.com/ktock/vscode-container-wasm-gcc-example
Cloudflare Runners also run WASM; with workerd:
cloudflare/workerd : https://github.com/cloudflare/workerd
...
"Cage" implements ARM64 MTE Memory Tagging Extensions support for WASM with LLVM emscripten iirc:
- "Cage: Hardware-Accelerated Safe WebAssembly" (2024) https://news.ycombinator.com/item?id=46151170 :
> [ llvm-memsafe-wasm , wasmtime-mte , ]
agentvm looks very cool! They are taking a different approach - full Linux VM emulated in WASM. It's very impressive technically.
We differentiate from agentvm by being lightweight (~11 MB Wasm binary, compared to 173 MB for agentvm). Though there is still a lot we can learn from agentvm, thank you for sharing their project.
Thank you! When I started working on agentvm my original goal was similar to yours, build a kind of Mingw or Cygwin for WASM. However, I quickly learned that this wouldn't really be feasible with reasonable amounts of time/token spend, mostly due to issues like having to find a way to make fork work, etc. I am no expert for WASM or Linux system programming, but it's been a lot of fun working on this stuff. I hope that the WASI standard and runtimes become more mature, as I feel that WASM sandboxes make a lot of sense in environments where containers are not an option.
Thanks for sharing the context! The fork problem is gnarly. Makes sense that full Linux emulation was the path forward for your use case.
Agreed on WASI maturity. We're hoping the component model lands in a stable form soon. Would love to see the ecosystem converge so these approaches can interoperate.
Nice! Fork is actually already working on Wasmer thanks to WASIX :) (and sockets, subprocesses, ...).
Let me know if you need any help using it!
"Rethinking Code Refinement: Learning to Judge Code Efficiency" https://news.ycombinator.com/item?id=42097656
eWASM has costed opcodes. The EVM virtual machine has not implemented eWASM.
Costed opcodes in WASM for agents could incentivize efficiency
re: wasm-bpf and eWASM and the BPF verifier: https://news.ycombinator.com/item?id=42092120
ewasm docs > Gas Costs > "Gas costs of individual instructions" https://ewasm.readthedocs.io/en/mkdocs/determining_wasm_gas_...
Browser tabs could show CPU, RAM, GPU utilization;
From "The Risks of WebAssembly" (2022) https://news.ycombinator.com/item?id=32765865 :
> Don't there need to be per- CPU/RAM/GPU quotas per WASM scope/tab? Or is preventing DOS with WASM out of scope for browsers?
> IIRC, it's possible to check resource utilization in e.g. a browser Task Manager, but there's no way to do `nice` or `docker --cpu-quota` or `systemd-nspawn --cpu-affinity` to prevent one or more WASM tabs from DOS'ing a workstation with non-costed operations.
Presumably workerd supports resource quotas somehow?
From 2024 re: Process isolation in browsers : https://news.ycombinator.com/item?id=40861851 :
> From "WebGPU is now available on Android" [...] (2022) :
>> What are some ideas for UI Visual Affordances to solve for bad UX due to slow browser tabs and extensions?
>> UBY: Browsers: Strobe the tab or extension button when it's beyond (configurable) resource usage thresholds
>> UBY: Browsers: Vary the {color, size, fill} of the tabs according to their relative resource utilization