souvik1997

7 ms·

1.
by souvik1997 4mo ago
What were the annoyances you faced?
2.
by souvik1997 4mo ago
Not sure what is the aversion to libc? The code only supports Intel macOS, seemingly because Apple Silicon (arm64) macOS does not support this.
3.
by souvik1997 7mo ago
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.
4.
by souvik1997 7mo ago
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.
5.
by 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
6.
by souvik1997 8mo ago
Yep, we got that sorted. Thanks for the suggestion! https://pypi.org/project/amla-sandbox/
7.
by 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 star
8.
by 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:
9.
by souvik1997 8mo ago
We will take a look! Thanks for sharing. Dynamic linking to run pydantic/numpy/etc. would be huge!
10.
by souvik1997 8mo 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
11.
by souvik1997 8mo 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!
12.
by 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 aste
13.
by souvik1997 8mo 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 u
14.
by 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 lo
15.
by souvik1997 8mo ago
Thanks! That’s exactly the use case we built this for
16.
by 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).
17.
by 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 any
18.
by souvik1997 8mo ago
Thanks for sharing localsandbox! sqlite-backed VFS for fork and resume workflows is very interesting.
19.
by 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 reimplementin
20.
by souvik1997 8mo ago
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
21.
by 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
22.
by 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 n
23.
by 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
24.
by 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).
25.
Show HN: Amla Sandbox – WASM bash shell sandbox for AI agents(github.com)
146 points by souvik1997 8mo ago|73 comments