souvik1997

Amazing! Great to hear you've already thought about this

Looks cool!

One aspect of multi-user agent security, which I think is underexplored, is how context from a higher-privileged session might "leak" into a lower privileged session. Suppose the CEO of a company uses your shared openclaw agent and the agent writes sensitive data (investor emails, for example) to its memory. My understanding is this is not protected by Alter. Then a contractor uses the same agent and can read that same memory. It seems to me that a better agent harness for this kind of multi-user use case is needed; the standard ones like openclaw and claude code simply are not designed for it. Would love your thoughts!

What were the annoyances you faced?

Not sure what is the aversion to libc? The code only supports Intel macOS, seemingly because Apple Silicon (arm64) macOS does not support this.

Edera looks very cool! Awesome team too.

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.

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

Yep, we got that sorted. Thanks for the suggestion! https://pypi.org/project/amla-sandbox/

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.

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

We will take a look! Thanks for sharing. Dynamic linking to run pydantic/numpy/etc. would be huge!

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!

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!

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!

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.

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

Thanks! That’s exactly the use case we built this for

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).

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.

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

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!

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.

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!

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.

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.

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.