Everyone's talking about the SOC2 and PCI-DSS compliance checklists for the runtimes like they're a security feature. They're not. They're a sales feature. A compliance checkbox tells you nothing about whether your specific implementation is actually secure.

The real engineering is in the isolation boundaries and how credentials leak. Let's compare.

**NemoClaw (Docker)**
* Isolation: Depends on your Docker daemon configuration and host kernel. A --privileged flag or a misconfigured seccomp profile blows the whole model.
* Credential handling: Your agent can see everything in its container. If you bake secrets into the image or pass them via env vars, any process breakout gets them. The only safe way is a sidecar like Vault Agent injecting into memory, which is extra work you must engineer.

**NanoClaw (gVisor)**
* Isolation: User-space kernel. A container breakout lands in a minimal syscall emulation layer, not the host. This is a concrete, engineered barrier.
* Credential handling: Same problem as above for secrets *inside* the sandbox. The advantage is that a compromised agent has a much harder time sniffing host credentials or other pods' data. The threat model shifts to protecting the sandbox's own memory.

**IronClaw (MicroVM)**
* Isolation: Full VM boundary via Firecracker. This is the hardware-enforced wall. The overhead is higher, but the isolation is categorical.
* Credential handling: You can use traditional cloud instance patterns. Attach an IAM role to the VM, use the metadata service. The VM boundary protects those host credentials from other runtimes on the same metal.

Choosing based on a compliance checklist is asking for trouble. You choose based on your actual threat model:
* Are you running untrusted code from third parties? You need IronClaw.
* Are you segmenting internal services where a compromise is unlikely but you want a containment barrier? NanoClaw is likely sufficient and more efficient.
* Are you only worried about dependency conflicts and basic process isolation for trusted code? NemoClaw with a hardened daemon config might work.

Forget the checklist. Look at the runtime spec. Here's what matters in your OpenClaw config:

```yaml
runtime: ironclaw
hardening:
strip_agent_capabilities: true # Drops ALL except needed net bind
readonly_root_filesystem: true
credential_source: vault://openclaw/creds # Uses VM-injected temp token, not file
```

That's engineering. The rest is paperwork.