5 ms·

Show HN: Amla Sandbox – WASM bash shell sandbox for AI agents

146 points by souvik1997 8mo ago

WASM sandbox for running LLM-generated code safely. Agents get a bash-like shell and can only call tools you provide, with constraints you define. No Docker, no subprocess, no SaaS — just pip install amla-sandbox

touwer 8mo ago
Cool! If it is full OSS indeed
ai-christianson 8mo ago
We went down the WASM sandboxing rabbit hole at Gobii when building our agent infra. The pitch is appealing until you realize the tradeoff: you either accept a limited environment with reimplemented tools, or you emulate your way back to a full Linux system (like agentvm does at 173MB) and wonder why you didn't just start with gvisor or Firecracker. We landed on gvisor in k8s. Our agents run headless Chromium for browser automation, ffmpeg for media processing, yt-dlp, ripgrep, fzf - real tools that would be a nightmare to port or reimplement. Actual Linux with the full ecosystem, solid isolation, no emulation overhead. Interesting project though - the capability-based tool validation layer seems useful regardless of what's running underneath.
thepoet 8mo ago
This looks cool, congratulations. We investigated WASM for our use case but then turned to Apple containers which run 1:1 mapped to a microVM for local use here, which is being used by a bunch of folks https://github.com/instavm/coderunner https://github.com/instavm/coderunner We are currently also building a solution InstaVM which is ideologically the same but for cloud https://instavm.io https://instavm.io
jameslk 8mo ago
Nice! This looks like it would pair really well with something like RLM[0] which requires "symbolic" representation of the prompt and output during recursion[1] 0. https://mack.work/blog/recursive-language-models https://mack.work/blog/recursive-language-models 1. https://x.com/lateinteraction/status/2011250721681773013 https://x.com/lateinteraction/status/2011250721681773013
- souvik1997 8mo ago
  This is a really interesting direction we have been exploring too! Our approach is basically to create a file containing the prompt for each turn within the virtual filesystem. The results seem promising so far
evanjrowley 8mo ago
Is there any affiliation with AlmaLinux project?
poly2it 8mo ago
Why not just put the agent in a VM?
westurner 8mo ago
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.
- westurner 8mo ago
  From "Show HN: NPM install a WASM based Linux VM for your agents" re: https://github.com/deepclause/agentvm https://github.com/deepclause/agentvm .. https://news.ycombinator.com/item?id=46686346 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#issue-3709559065 https://github.com/container2wasm/container2wasm/issues/550#... vscode-container-wasm-gcc-example : https://github.com/ktock/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 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 https://news.ycombinator.com/item?id=46151170 : > [ llvm-memsafe-wasm , wasmtime-mte , ]
  - souvik1997 8mo ago
    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.
deleted 8mo ago
[deleted]
quantummagic 8mo ago
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.
- souvik1997 8mo ago
  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.
syrusakbary 8mo ago
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!
- souvik1997 8mo ago
  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.
  - syrusakbary 8mo ago
    > 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!)
    - souvik1997 8mo ago
      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!
      - syrusakbary 8mo ago
        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/ https://wasix.org/
taosu_yb 8mo ago
[dead]
asyncadventure 8mo ago
[dead]
sd2k 8mo ago
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 https://github.com/eryx-org/eryx [2] https://github.com/sd2k/conch https://github.com/sd2k/conch
- souvik1997 8mo ago
  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 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!
vimota 8mo ago
Sharing our version of this built on just-bash, AgentFS, and Pyodide: https://github.com/coplane/localsandbox 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!
- souvik1997 8mo ago
  Thanks for sharing localsandbox! sqlite-backed VFS for fork and resume workflows is very interesting.
deleted 8mo ago
[deleted]
sibellavia 8mo ago
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.
- souvik1997 8mo ago
  Interesting! What use cases felt too constrained? We've been mostly focused on "agent calls tools with parameters". Curious where you hit flexibility limits. Would love to see your MCP approach if you've published it anywhere.
turnsout 8mo ago
This is really awesome. I want to give my agent access to basic coding tools to do text manipulation, add up numbers, etc, but I want to keep a tight lid on it. This seems like a great way to add that functionality!
- souvik1997 8mo ago
  Thanks! That’s exactly the use case we built this for
behnamoh 8mo ago
> What you don't get: ...GPU access... So no local models are supported.
- souvik1997 8mo ago
  The sandbox doesn’t run models. it runs agent-generated code and constrains tool calls. The model runs wherever you want (OpenAI, Anthropic, local Ollama, whatever).
benatkin 8mo ago
The readme exaggerates the threat of agents shelling out and glosses over a serious drawback of itself. On the shelling out side, it says "One prompt injection and you're done." Well, you can run a lot of these agents in a container, and I do. So maybe you're not "done". Also it's rare enough that this warning exaggerates - Claude Code has a yolo mode and outside of that, it has a pretty good permission system. On glossing over the drawback: "The WASM binary is proprietary—you can use it with this package but can't extract or redistribute it separately." And who is Amla Labs? FWIW the first commit is in 2026 and the license is in 2025.
- souvik1997 8mo ago
  Fair points. On containers: yes, running in Docker/Firecracker works. The "one prompt injection and you’re done" framing is hyperbolic for containerized setups. The pitch is more relevant for people running agents in their local environment without isolation, or who want something lighter than spinning up containers per execution. On the licensing: completely valid concern. We are a new company (just two cofounders right now) and the binary is closed for now only because we need to clean up the source code before releasing it as open-source. The Python SDK and capability layer are MIT. I get that "trust us" isn’t compelling for a security product from an unknown entity, but since the Wasm binary runs within wasmtime (one of the most popular Wasm runtimes) and you can audit everything going in and out of it, the security story should hopefully be more palatable while we work on open sourcing the Wasm core. The 2025/2026 date discrepancy is just me being sloppy with the license
muktharbuilds 8mo ago
thats great one i am definetly ussing this
simonw 8mo ago
This project looks very cool - I've been trying to build something similar in a few different ways (https://github.com/simonw/denobox https://github.com/simonw/denobox is my most recent attempt) but this is way ahead of where I've got, especially given its support for shell scripting. I'm sad about this bit though: > Python code is MIT. The WASM binary is proprietary—you can use it with this package but can't extract or redistribute it separately.
- sd2k 8mo ago
  I posted this elsewhere in the thread, and don't want to spam it everywhere (or take away from Amla!), but you might be interested in eryx [1] - the Python bindings [2] get you a similar Python-in-Python sandbox based on a WASI build of CPython (props to the componentize-py [3] people)! [1]: https://github.com/sd2k/eryx/ https://github.com/sd2k/eryx/ [2]: https://pypi.org/project/pyeryx/ https://pypi.org/project/pyeryx/ [3]: https://github.com/bytecodealliance/componentize-py/ https://github.com/bytecodealliance/componentize-py/
  - simonw 8mo ago
    That's really cool. Any chance you could add SQLite? % uv run --with pyeryx python Installed 1 package in 1ms Python 3.14.0 (main, Oct 7 2025, 16:07:00) [Clang 20.1.4 ] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import eryx >>> sandbox = eryx.Sandbox() >>> result = sandbox.execute(''' ... print("Hello from the sandbox!") ... x = 2 + 2 ... print(f"2 + 2 = {x}") ... ''') >>> result ExecuteResult(stdout="Hello from the sandbox!\n2 + 2 = 4", duration_ms=6.83, callback_invocations=0, peak_memory_bytes=Some(16384000)) >>> sandbox.execute(''' ... import sqlite3 ... print(sqlite3.connect(":memory:").execute("select sqlite_version()").fetchall()) ... ''').stdout Traceback (most recent call last): File "<python-input-6>", line 1, in <module> sandbox.execute(''' ~~~~~~~~~~~~~~~^^^^ import sqlite3 ^^^^^^^^^^^^^^ print(sqlite3.connect(":memory:").execute("select sqlite_version()").fetchall()) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ''').stdout ^^^^ eryx.ExecutionError: Traceback (most recent call last): File "<string>", line 1, in <module> File "<string>", line 125, in _eryx_exec File "<user>", line 2, in <module> File "/python-stdlib/sqlite3/__init__.py", line 57, in <module> from sqlite3.dbapi2 import * File "/python-stdlib/sqlite3/dbapi2.py", line 27, in <module> from _sqlite3 import * ModuleNotFoundError: No module named '_sqlite3' Filed a feature request here: https://github.com/eryx-org/eryx/issues/28 https://github.com/eryx-org/eryx/issues/28
messh 8mo ago
Docker and vms are not the only options though... you can use bubblewrap and other equivalents for mac
- souvik1997 8mo ago
  True. bubblewrap and similar (Landlock, sandbox-exec on Mac) are solid lightweight options. The main difference is they still expose a syscall interface that you then restrict, vs WASM where capabilities are opt-in from zero. Different starting points, similar goals. Some advantages of building the sandbox in wasm, aside from the security benefits, are complete execution reproducibility. amla-sandbox controls all external side effects, leaving the wasm core as just "pure computation", which makes recording traces and replaying them very easy. It's great for debugging complex workflows.
rellfy 8mo ago
I really like the capability enforcement model, it's a great concept. One thing this discussion is missing though is the ecosystem layer. Sandboxing solves execution safety, but there's a parallel problem: how do agents discover and compose tools portably across frameworks? Right now every framework has its own tool format and registry (or none at all). WASM's component model actually solves this — you get typed interfaces (WIT), language interop, and composability for free. I've been building a registry and runtime (also based on wasmtime!) for this: components written in any language, published to a shared registry, runnable locally or in the cloud. Sandboxes like amla-sandbox could be a consumer of these components. https://asterai.io/why https://asterai.io/why
- souvik1997 8mo ago
  The ecosystem layer is a hard but very important problem to solve. Right now we define tools in Python on the host side, but I see a clear path to WIT-defined components. The registry of portable tools is very compelling. Will checkout asterai, thanks for sharing!
- skybrian 8mo ago
  Exposing tools to the AI as shell commands works pretty well? There are many standards to choose from for the actual network API.
  - rellfy 8mo ago
    Shell commands work for individual tools, but you lose composability. If you want to chain components that share a sandboxed environment, say, add a tracing component alongside an OTP confirmation layer that gates sensitive actions, you need a shared runtime and typed interfaces. That's the layer I'm building with asterai: standard substrate so components compose without glue code. Plus, having a central ecosystem lets you add features like the traceability with almost 1 click complexity. Of course, this only wins long term if WASM wins.
    - skybrian 8mo ago
      How does the AI compose tools? Asking it to write a script in some language that both you and the AI know seems like a pretty natural approach. It helps if there's an ecosystem of common libraries available, and that's not so easy to build. I'm pretty happy with Typescript.
skybrian 8mo ago
This is cool, but I had imagined something like a pure Typescript library that can run in a browser.
- simonw 8mo ago
  Sounds like just-bash: https://github.com/vercel-labs/just-bash https://github.com/vercel-labs/just-bash
tgtweak 8mo ago
is a wasm sandbox as secure as a container or vm?
- souvik1997 8mo ago
  If I had to rank these, in order of least to most secure, it would be container < VM < WASM. WASM has: - Bounds checked linear memory - No system calls except what you explicitly grant via WASI - Much smaller attack surface VMs have: - Hardware isolation, separate kernel - May have hypervisor bugs leading to VM escape (rare in practice though) Some problems with containers: - Shared host kernel (kernel exploit = escape) - Seccomp/AppArmor/namespaces reduce attack surface but don't eliminate it - Larger attack surface (full syscall interface) - Container escapes are a known class of vulnerability
- PufPufPuf 8mo ago
  In theory it's more secure. Containers and VMs run on real hardware, containers usually even on the real kernel (unless you use something like Kata). WASM doesn't have any system interface by default, you have full control over what it accesses. So it's similar to JVM for example.

146 points by souvik1997 8mo ago

touwer 8mo ago

Cool! If it is full OSS indeed

ai-christianson 8mo ago

We went down the WASM sandboxing rabbit hole at Gobii when building our agent infra. The pitch is appealing until you realize the tradeoff: you either accept a limited environment with reimplemented tools, or you emulate your way back to a full Linux system (like agentvm does at 173MB) and wonder why you didn't just start with gvisor or Firecracker. We landed on gvisor in k8s. Our agents run headless Chromium for browser automation, ffmpeg for media processing, yt-dlp, ripgrep, fzf - real tools that would be a nightmare to port or reimplement. Actual Linux with the full ecosystem, solid isolation, no emulation overhead. Interesting project though - the capability-based tool validation layer seems useful regardless of what's running underneath.

thepoet 8mo ago

This looks cool, congratulations. We investigated WASM for our use case but then turned to Apple containers which run 1:1 mapped to a microVM for local use here, which is being used by a bunch of folks https://github.com/instavm/coderunner https://github.com/instavm/coderunner We are currently also building a solution InstaVM which is ideologically the same but for cloud https://instavm.io https://instavm.io

jameslk 8mo ago

Nice! This looks like it would pair really well with something like RLM[0] which requires "symbolic" representation of the prompt and output during recursion[1] 0. https://mack.work/blog/recursive-language-models https://mack.work/blog/recursive-language-models 1. https://x.com/lateinteraction/status/2011250721681773013 https://x.com/lateinteraction/status/2011250721681773013

souvik1997 8mo ago
This is a really interesting direction we have been exploring too! Our approach is basically to create a file containing the prompt for each turn within the virtual filesystem. The results seem promising so far

evanjrowley 8mo ago

Is there any affiliation with AlmaLinux project?

poly2it 8mo ago

Why not just put the agent in a VM?

westurner 8mo ago

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.

westurner 8mo ago
From "Show HN: NPM install a WASM based Linux VM for your agents" re: https://github.com/deepclause/agentvm https://github.com/deepclause/agentvm .. https://news.ycombinator.com/item?id=46686346 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#issue-3709559065 https://github.com/container2wasm/container2wasm/issues/550#... vscode-container-wasm-gcc-example : https://github.com/ktock/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 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 https://news.ycombinator.com/item?id=46151170 : > [ llvm-memsafe-wasm , wasmtime-mte , ]
- souvik1997 8mo ago
  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.

deleted 8mo ago

[deleted]

quantummagic 8mo ago

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.

souvik1997 8mo ago
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.

syrusakbary 8mo ago

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!

souvik1997 8mo ago
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.
- syrusakbary 8mo ago
  > 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!)
  - souvik1997 8mo ago
    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!
    - syrusakbary 8mo ago
      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/ https://wasix.org/

taosu_yb 8mo ago

[dead]

asyncadventure 8mo ago

[dead]

sd2k 8mo ago

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 https://github.com/eryx-org/eryx [2] https://github.com/sd2k/conch https://github.com/sd2k/conch

souvik1997 8mo ago
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 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!

vimota 8mo ago

Sharing our version of this built on just-bash, AgentFS, and Pyodide: https://github.com/coplane/localsandbox 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!

souvik1997 8mo ago
Thanks for sharing localsandbox! sqlite-backed VFS for fork and resume workflows is very interesting.

deleted 8mo ago

[deleted]

sibellavia 8mo ago

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.

souvik1997 8mo ago
Interesting! What use cases felt too constrained? We've been mostly focused on "agent calls tools with parameters". Curious where you hit flexibility limits. Would love to see your MCP approach if you've published it anywhere.

turnsout 8mo ago

This is really awesome. I want to give my agent access to basic coding tools to do text manipulation, add up numbers, etc, but I want to keep a tight lid on it. This seems like a great way to add that functionality!

souvik1997 8mo ago
Thanks! That’s exactly the use case we built this for

behnamoh 8mo ago

> What you don't get: ...GPU access... So no local models are supported.

souvik1997 8mo ago
The sandbox doesn’t run models. it runs agent-generated code and constrains tool calls. The model runs wherever you want (OpenAI, Anthropic, local Ollama, whatever).

benatkin 8mo ago

The readme exaggerates the threat of agents shelling out and glosses over a serious drawback of itself. On the shelling out side, it says "One prompt injection and you're done." Well, you can run a lot of these agents in a container, and I do. So maybe you're not "done". Also it's rare enough that this warning exaggerates - Claude Code has a yolo mode and outside of that, it has a pretty good permission system. On glossing over the drawback: "The WASM binary is proprietary—you can use it with this package but can't extract or redistribute it separately." And who is Amla Labs? FWIW the first commit is in 2026 and the license is in 2025.

souvik1997 8mo ago
Fair points. On containers: yes, running in Docker/Firecracker works. The "one prompt injection and you’re done" framing is hyperbolic for containerized setups. The pitch is more relevant for people running agents in their local environment without isolation, or who want something lighter than spinning up containers per execution. On the licensing: completely valid concern. We are a new company (just two cofounders right now) and the binary is closed for now only because we need to clean up the source code before releasing it as open-source. The Python SDK and capability layer are MIT. I get that "trust us" isn’t compelling for a security product from an unknown entity, but since the Wasm binary runs within wasmtime (one of the most popular Wasm runtimes) and you can audit everything going in and out of it, the security story should hopefully be more palatable while we work on open sourcing the Wasm core. The 2025/2026 date discrepancy is just me being sloppy with the license

muktharbuilds 8mo ago

thats great one i am definetly ussing this

simonw 8mo ago

This project looks very cool - I've been trying to build something similar in a few different ways (https://github.com/simonw/denobox https://github.com/simonw/denobox is my most recent attempt) but this is way ahead of where I've got, especially given its support for shell scripting. I'm sad about this bit though: > Python code is MIT. The WASM binary is proprietary—you can use it with this package but can't extract or redistribute it separately.

sd2k 8mo ago
I posted this elsewhere in the thread, and don't want to spam it everywhere (or take away from Amla!), but you might be interested in eryx [1] - the Python bindings [2] get you a similar Python-in-Python sandbox based on a WASI build of CPython (props to the componentize-py [3] people)! [1]: https://github.com/sd2k/eryx/ https://github.com/sd2k/eryx/ [2]: https://pypi.org/project/pyeryx/ https://pypi.org/project/pyeryx/ [3]: https://github.com/bytecodealliance/componentize-py/ https://github.com/bytecodealliance/componentize-py/
- simonw 8mo ago
  That's really cool. Any chance you could add SQLite? % uv run --with pyeryx python Installed 1 package in 1ms Python 3.14.0 (main, Oct 7 2025, 16:07:00) [Clang 20.1.4 ] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import eryx >>> sandbox = eryx.Sandbox() >>> result = sandbox.execute(''' ... print("Hello from the sandbox!") ... x = 2 + 2 ... print(f"2 + 2 = {x}") ... ''') >>> result ExecuteResult(stdout="Hello from the sandbox!\n2 + 2 = 4", duration_ms=6.83, callback_invocations=0, peak_memory_bytes=Some(16384000)) >>> sandbox.execute(''' ... import sqlite3 ... print(sqlite3.connect(":memory:").execute("select sqlite_version()").fetchall()) ... ''').stdout Traceback (most recent call last): File "<python-input-6>", line 1, in <module> sandbox.execute(''' ~~~~~~~~~~~~~~~^^^^ import sqlite3 ^^^^^^^^^^^^^^ print(sqlite3.connect(":memory:").execute("select sqlite_version()").fetchall()) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ''').stdout ^^^^ eryx.ExecutionError: Traceback (most recent call last): File "<string>", line 1, in <module> File "<string>", line 125, in _eryx_exec File "<user>", line 2, in <module> File "/python-stdlib/sqlite3/__init__.py", line 57, in <module> from sqlite3.dbapi2 import * File "/python-stdlib/sqlite3/dbapi2.py", line 27, in <module> from _sqlite3 import * ModuleNotFoundError: No module named '_sqlite3' Filed a feature request here: https://github.com/eryx-org/eryx/issues/28 https://github.com/eryx-org/eryx/issues/28

messh 8mo ago

Docker and vms are not the only options though... you can use bubblewrap and other equivalents for mac

souvik1997 8mo ago
True. bubblewrap and similar (Landlock, sandbox-exec on Mac) are solid lightweight options. The main difference is they still expose a syscall interface that you then restrict, vs WASM where capabilities are opt-in from zero. Different starting points, similar goals. Some advantages of building the sandbox in wasm, aside from the security benefits, are complete execution reproducibility. amla-sandbox controls all external side effects, leaving the wasm core as just "pure computation", which makes recording traces and replaying them very easy. It's great for debugging complex workflows.

rellfy 8mo ago

I really like the capability enforcement model, it's a great concept. One thing this discussion is missing though is the ecosystem layer. Sandboxing solves execution safety, but there's a parallel problem: how do agents discover and compose tools portably across frameworks? Right now every framework has its own tool format and registry (or none at all). WASM's component model actually solves this — you get typed interfaces (WIT), language interop, and composability for free. I've been building a registry and runtime (also based on wasmtime!) for this: components written in any language, published to a shared registry, runnable locally or in the cloud. Sandboxes like amla-sandbox could be a consumer of these components. https://asterai.io/why https://asterai.io/why

souvik1997 8mo ago
The ecosystem layer is a hard but very important problem to solve. Right now we define tools in Python on the host side, but I see a clear path to WIT-defined components. The registry of portable tools is very compelling. Will checkout asterai, thanks for sharing!
skybrian 8mo ago
Exposing tools to the AI as shell commands works pretty well? There are many standards to choose from for the actual network API.
- rellfy 8mo ago
  Shell commands work for individual tools, but you lose composability. If you want to chain components that share a sandboxed environment, say, add a tracing component alongside an OTP confirmation layer that gates sensitive actions, you need a shared runtime and typed interfaces. That's the layer I'm building with asterai: standard substrate so components compose without glue code. Plus, having a central ecosystem lets you add features like the traceability with almost 1 click complexity. Of course, this only wins long term if WASM wins.
  - skybrian 8mo ago
    How does the AI compose tools? Asking it to write a script in some language that both you and the AI know seems like a pretty natural approach. It helps if there's an ecosystem of common libraries available, and that's not so easy to build. I'm pretty happy with Typescript.

skybrian 8mo ago

This is cool, but I had imagined something like a pure Typescript library that can run in a browser.

simonw 8mo ago
Sounds like just-bash: https://github.com/vercel-labs/just-bash https://github.com/vercel-labs/just-bash

tgtweak 8mo ago

is a wasm sandbox as secure as a container or vm?

souvik1997 8mo ago
If I had to rank these, in order of least to most secure, it would be container < VM < WASM. WASM has: - Bounds checked linear memory - No system calls except what you explicitly grant via WASI - Much smaller attack surface VMs have: - Hardware isolation, separate kernel - May have hypervisor bugs leading to VM escape (rare in practice though) Some problems with containers: - Shared host kernel (kernel exploit = escape) - Seccomp/AppArmor/namespaces reduce attack surface but don't eliminate it - Larger attack surface (full syscall interface) - Container escapes are a known class of vulnerability
PufPufPuf 8mo ago
In theory it's more secure. Containers and VMs run on real hardware, containers usually even on the real kernel (unless you use something like Kata). WASM doesn't have any system interface by default, you have full control over what it accesses. So it's similar to JVM for example.