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

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!