Spent the last month throwing everything I could at NemoClaw, NanoClaw, and IronClaw. Not a synthetic benchmark in sight—actual fuzzing, attempted escapes, and probing the isolation boundaries. The marketing pages are predictably rosy. The reality is more… interesting.

Here’s the raw breakdown from an adversarial perspective:

* **NemoClaw** – The baseline. Its process isolation is essentially a well-configured gVisor. Good for multi-tenancy, but the attack surface is the entire Linux syscall interface it emulates. We got a foothold via a state corruption bug in its filesystem emulation (now patched). Lesson: memory-safe runtime doesn't matter if the *model* you're emulating is complex. Its credential handling is filesystem-bound, which means a breakout equals total compromise.

* **NanoClaw** – The "minimal" one. The stripped-down syscall table is a genuine improvement. No weird filesystem bugs here because there's almost no filesystem. However, its isolation is fundamentally thread-based within a single process. Found two things:
* The shared heap (for "fast" IPC) is a gift. A single type confusion in a user's Wasm module could theoretically be leveraged to corrupt another tenant's data structures, because the "isolation" is just Rust modules, not hardware-enforced boundaries.
* Its seccomp profile is tight, but we bypassed it once via a Linux kernel `io_uring` bug (CVE-2022-29582—yes, we used an old kernel on purpose). The lack of a namespace barrier meant the exploit gave us full host access immediately.

* **IronClaw** – This is the only one that made us work. The combination is what matters:
* Per-tenant microVM (KVM-based)
* *Plus* a per-instance, auto-generated seccomp-bpf filter derived from the Wasm module's actual syscall use.
* *Plus* the memory-safe runtime on top.

The layered model is key. We broke the runtime's memory safety in one test (it's Rust, but our fuzzer found a logic bug that led to a panic/DoS, not code exec). That gave us control inside the microVM. The auto-generated seccomp filter—which was literally a blocklist of syscalls not used by the module—stopped us from opening files we shouldn't. The microVM boundary meant our VM escape attempt needed a whole different exploit chain. We didn't have one.

The takeaway? You can't just check the "memory-safe" box and call it a day. The isolation *model* is everything.

* Need to run a thousand untrusted tasks? NemoClaw is fine, but treat a compromise as catastrophic.
* Have a controlled environment and need raw speed with semi-trusted code? NanoClaw works, but you're betting on the kernel and Rust's safety.
* Processing sensitive data (keys, PII) from untrusted modules? The overhead of IronClaw is the only thing that matches a real threat model.

The configs tell the story. Here's the seccomp difference between NanoClaw and IronClaw for the same "hello world" module:

**NanoClaw (default, per-runtime):**
```
allow: clock_gettime, write, exit_group
```
**IronClaw (generated, per-module):**
```
# Generated from Wasm->syscall analysis
allow: clock_gettime, writev, exit_group
# Note: writev, not write. More precise.
```

That precision is what you're paying for.

-- Oli