Top
Best
New

Posted by souvik1997 6 hours ago

Show HN: Amla Sandbox – WASM bash shell sandbox for AI agents(github.com)
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

97 points | 63 comments
simonw 3 hours ago|
This project looks very cool - I've been trying to build something similar in a few different ways (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.

souvik1997 2 hours ago||
Thanks Simon! Denobox looks very cool: Deno's permissions model is a natural fit for this.

On the licensing: totally fair point. Our intention is to open source the WASM too. 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. We wanted to ship something usable now rather than wait. Since the wasm binary runs in wasmtime within an open source harness, it is possible to audit everything going in and out of the wasm blob for security.

Genuinely open to feedback on this. If the split license is a blocker for your use cases, that's useful signal for us.

simonw 2 hours ago||
That's great to hear. The split license is a blocker for me because I build open source tools for other people to use, so I need to be sure that all of my dependencies are things I can freely redistribute to others.
souvik1997 2 hours ago||
Makes total sense. We'll prioritize getting the WASM source out. This is good signal that it matters. Will ping you when it's up!
simonw 1 hour ago||
Small suggestion: push an alpha to PyPI ASAP mainly to preserve your name there but also to make it more convenient for people to try out with `uv`.
souvik1997 44 minutes ago||
Yep, we got that sorted. Thanks for the suggestion! https://pypi.org/project/amla-sandbox/
sd2k 3 hours 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/

[2]: https://pypi.org/project/pyeryx/

[3]: https://github.com/bytecodealliance/componentize-py/

simonw 2 hours 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
simonw 1 hour ago||
It looks like there's not mechanism yet in the Python bindings for exposing callback functions to the sandboxed code - it exists in the Rust library and Python has a ExecuteRusult.callback_invocations counter so presumably this is coming soon?
sd2k 1 hour ago||
Good call, yes, I'll get that added soon!
vimota 2 hours ago|||
Simon - would love if you could take a look at Localsandbox (https://github.com/coplane/localsandbox) - it was partly inspired by your Pyodide post!
simonw 1 hour ago||
I tried it (really like the API design) but ran into a blocker:

  uv run --with localsandbox python -c '
  from localsandbox import LocalSandbox
  
  with LocalSandbox() as sandbox:
      result = sandbox.bash("echo hi")           
      print(result.stdout)                
  '
  
Gave me:

  Traceback (most recent call last):
    File "<string>", line 5, in <module>
      result = sandbox.bash("echo hi")
    File "/Users/simon/.cache/uv/archive-v0/spFCEHagkq3VTpTyStT-Z/lib/python3.14/site-packages/localsandbox/core.py", line 492, in bash
      raise SubprocessCrashed(
      ...<2 lines>...
      )
  localsandbox.exceptions.SubprocessCrashed: Node subprocess crashed: error: Failed reading lockfile at '/Users/simon/.cache/uv/archive-v0/spFCEHagkq3VTpTyStT-Z/lib/python3.14/site-packages/localsandbox/shim/deno.lock'
  
  Caused by:
      Unsupported lockfile version '5'. Try upgrading Deno or recreating the lockfile
Actually that was with Deno 2.2.10 - I ran "brew upgrade deno" and got Deno 2.6.7 and now it works!
simonw 1 hour ago||
It looks like it currently defaults to allowing networking so it can load Pyodide from npm. My preference is a sandbox with no network access at all and access only to specific files that I can configure.
vimota 1 hour ago||
Thanks for taking a look and the feedback! We run the shim with internet access (https://github.com/coplane/localsandbox/blob/main/localsandb...) but the pyodide sandbox itself doesn't run with internet access : https://github.com/coplane/localsandbox/blob/main/localsandb...
simonw 1 hour ago||
Oh neat, thanks - I'd missed that.
phickey 2 hours ago||
https://github.com/bytecodealliance/ComponentizeJS is a Bytecode Alliance project which can run JS in a SpiderMonkey-based runtime as a Wasm component
rellfy 3 hours 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
souvik1997 2 hours 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 2 hours 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 2 hours 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 2 hours 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.

rellfy 1 hour ago||
In my example above I wasn't referring to AI composing the tools, but you as the agent builder composing the tool call workflow. So, I suppose we can call it AI-time composition vs build-time composition.

For example, say you have a shell script to make a bank transfer. This just makes an API call to your bank.

You can't trust the AI to reliably make a call to your traceability tool, and then to your OTP confirmation gate, and only then to proceed with the bank transfer. This will eventually fail and be compromised.

If you're running your agent on a "composable tool runtime", rather than raw shell for tool calls, you can easily make it so the "transfer $500 to Alice" call always goes through the route trace -> confirm OTP -> validate action. This is configured at build time.

Your alternative with raw shell would be to program the tool itself to follow this workflow, but then you'd end up with a lot of duplicate source code if you have the same workflow for different tool calls.

Of course, any AI agent SDK will let you configure these workflows. But they are locked to their own ecosystems, it's not a global ecosystem like you can achieve with WASM, allowing for interop between components written in any language.

quantummagic 5 hours 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 5 hours 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 5 hours 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!

apignotti 5 hours ago||
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

syrusakbary 5 hours ago||
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 :)

apignotti 5 hours ago||
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 :-)
souvik1997 5 hours 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 5 hours 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 5 hours 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 4 hours 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/

souvik1997 2 hours ago||
We will take a look! Thanks for sharing. Dynamic linking to run pydantic/numpy/etc. would be huge!
vimota 4 hours ago||
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!

souvik1997 4 hours ago|
Thanks for sharing localsandbox! sqlite-backed VFS for fork and resume workflows is very interesting.
sd2k 4 hours 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 [2] https://github.com/sd2k/conch

souvik1997 4 hours 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

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!

sd2k 4 hours ago||
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!

souvik1997 2 hours ago||
The opus 4.5 confession is great haha. We have found Claude Code + Opus 4.5 + Rust with miri/cargo-deny/cargo-check/cargo-fmt + Python with strict type checking/pedantic lint rules/comprehensive test suites to be a winning combination. It makes AI-assisted development surprisingly viable for systems work.

Good to see that you chose a similar path for networking in eryx!

sibellavia 4 hours 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 4 hours 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.

skybrian 2 hours ago||
This is cool, but I had imagined something like a pure Typescript library that can run in a browser.
simonw 1 hour ago|
Sounds like just-bash: https://github.com/vercel-labs/just-bash
asyncadventure 5 hours ago|
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.
More comments...