I read the thesis on arxiv. Do you see any limitations from using Xen instead of KVM? I think that was the biggest surprise for me as I have very rarely seen teams build on Xen.
I'd say the limitation has been that sometimes we have to implement things by hand. But it has enabled us to do things that others can't achieve since KVM is a singular stack in many ways. For example, VFIO-PCI is largely the same across all VMMs, but we have true full control over the PCI passthrough on our platform which has allowed us to do things KVM VMMs can't.
Hey @clawsyndicate I'd love to learn more about your use case. We are working on a product that would potentially get you the best of both worlds (microVM security and containers/gVisor scalability). My email is in my profile.
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
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.
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.
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.
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.
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
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).
I read the thesis on arxiv. Do you see any limitations from using Xen instead of KVM? I think that was the biggest surprise for me as I have very rarely seen teams build on Xen.
reply