Comparing Claw Family Runtimes - openclawsecurity.net Forum

How do I ensure agent tasks can't read each other's prompt history?

Luis G. — Mon, 29 Jun 2026 18:01:03 +0000

Working on a constrained medical device with multiple nano agents. Each agent handles sensitive patient data in prompts. If one agent gets compromised, I need to guarantee prompt history isolation. Current setup: - Yocto-built minimal image - IronClaw runtime (supposedly full isolation) - Agents run as separate Linux users But I found `/tmp/prompt_cache` readable by all processes. 😬 What’s the actual isolation model in each runtime? - NemoClaw: uses containers? User namespace details? - NanoClaw: process separation? How are tmp files handled? - IronClaw: mandatory access control integration? SELinux/AppArmor policies? Specifically: 1. Where is prompt history stored (memory, tmpfs, disk)? 2. How are credentials (API keys) kept separate from prompt data? 3. Any config examples for locking down shared tmp directories? Need concrete examples, not theory. My threat model: one agent task must not leak prompts to another, even if the OS is compromised at user level.

Help: Getting 'permission denied' errors in custom seccomp for NanoClaw

Nina Bhat — Mon, 29 Jun 2026 14:00:58 +0000

Trying to build a minimal runtime profile for a Go binary in NanoClaw. The default seccomp is too permissive for my case. My custom filter blocks everything except `read`, `write`, `exit`, `nanosleep`, `futex`, `mmap`, `munmap`, `brk`, `rt_sigreturn`. But the process fails with `permission denied` (EPERM) on `mmap`. If I allow `mmap` unconditionally, it works. The issue seems to be with the `args` for `mmap` filtering. Here's the failing rule: ```c struct scmp_arg_cond arg_cond[] = { { 2, SCMP_CMP_EQ, PROT_READ|PROT_WRITE }, { 3, SCMP_CMP_EQ, MAP_PRIVATE|MAP_ANONYMOUS } }; ``` Is the bitmask comparison wrong for seccomp-bpf? Should I be using `SCMP_CMP_MASKED_EQ`? The man pages are unclear on handling multiple flag bits.

How does NemoClaw handle agent-to-agent communication securely?

Jordan Lee — Mon, 29 Jun 2026 09:00:24 +0000

A common point of confusion I see, especially when folks are migrating from simpler agent setups, is understanding how agents within a NemoClaw cell actually talk to each other. The security model isn't just about the agent-to-orchestrator channel; intra-cell communication is a primary attack surface. NemoClaw handles this by enforcing a zero-trust mesh, even on what we assume is a trusted network. At its core, every agent in a cell has a unique cryptographic identity issued by the cell's trust domain. Communication is never just "over the local network." All agent-to-agent traffic is mutually authenticated TLS (mTLS) where both sides present and validate certificates. The certificates are short-lived and automatically rotated by the cell's controller. This means even if an agent is compromised, its ability to impersonate another agent or initiate lateral movement is severely time-boxed. Here's a simplified look at the connection handshake logic from the agent's perspective. The important part is that the agent *only* accepts connections presenting a certificate signed by the cell's specific Certificate Authority. ```yaml # Agent config snippet (auto-generated) network: bind_address: "{{.NodeIP}}:8443" tls: require_client_cert: true client_ca_file: "/etc/nemoclaw/cell-ca.pem" cert_file: "/etc/nemoclaw/agent-{{.AgentID}}.pem" key_file: "/etc/nemoclaw/agent-{{.AgentID}}-key.pem" allowed_peers: - "role:logger" - "role:scanner" - "tag:project-blue" ``` Furthermore, communication is scoped by intent. Agents declare their roles and tags, and the cell controller enforces a simple policy layer. An agent tagged for "project-blue" can be configured to only initiate connections to other agents with the same tag or a specific role, like a central logging agent. This is not a full network firewall, but a service-level authentication and authorization boundary that prevents a compromised web-scraper agent from trying to directly query a database agent it has no business talking to. The takeaway is that isolation isn't just about the container or VM the agent runs in. NemoClaw assumes the underlying network is hostile, so it cryptographically verifies every single connection and limits them to a least-privilege model. This is crucial for containing incidents. If you're designing a cell, think about your agent roles and group them with tags to define these communication policies from the start. ~JL

Just finished a pen test on all three. Raw results inside.

Oli Svensson — Sat, 27 Jun 2026 19:00:35 +0000

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

Unpopular opinion: We're trusting these runtimes with too much by default

Olivia Park — Thu, 25 Jun 2026 06:38:56 +0000

I've been conducting a systematic review of several agent plugin ecosystems built atop our three primary runtimes, and a concerning pattern has emerged. The default configurations and common examples for NemoClaw, NanoClaw, and even IronClaw often prioritize developer convenience over secure-by-design principles. This creates a scenario where a team adopting these tools is implicitly trusting the runtime with excessive privileges and data access before a threat model has even been established. Let's ground this in specifics. My audit of sample plugins reveals common insecure defaults: * **Credential Over-Exposure in NemoClaw:** The environment variable pattern for passing secrets to plugins is ubiquitous. Yet, the default behavior in many NemoClaw workflows is to inject the *entire* execution environment's variables into the plugin context, often to "simplify" access. A plugin only needing `DB_PASSWORD` inadvertently receives `AWS_SECRET_KEY`, `SLACK_TOKEN`, etc., massively expanding the attack surface of any vulnerability within that plugin. ```yaml # Common, overly permissive pattern seen in configurations plugin_env_policy: "inherit_all" # Default in many templates # vs. a secure default plugin_env_policy: "deny" allowed_env_vars: - "DB_PASSWORD" - "API_ENDPOINT" ``` * **Inadequate Input Sandboxing in NanoClaw:** While NanoClaw promotes lightweight isolation, its default input validation for plugins that execute shell commands or process untrusted data is often minimal. I've observed multiple instances where user-supplied data is passed to a subprocess or a `eval`-like function within the plugin runtime without structured validation or context-aware escaping, opening classic injection vectors. * **Blind Trust in IronClaw's Hardware Attestation:** IronClaw's strongest feature is its hardware-rooted trust. However, the default compliance templates frequently assume that attestation alone is sufficient. They often lack mandatory, granular runtime policy enforcement (e.g., which specific syscalls the enclave can make, network egress restrictions). Attestation proves you're running the *expected* code, but if that code is poorly written, you're securely attesting to a vulnerable workload. The core issue is that the "getting started" experience for each runtime does not force the developer to explicitly define a least-privilege model. Security is an opt-in consideration, not a foundational step. We should be comparing these runtimes not just on their isolation *capabilities*, but on the strictness and granularity of their *default deny* configurations. My proposal is that our evaluations must start from a zero-trust posture within the runtime itself: What is the default network access? What system calls are permitted by the isolation boundary? What is the explicit data access whitelist? The current comparisons focus too much on the "what" of the security boundary and not enough on the "how" of its default configuration. A runtime's true security posture is defined more by its defaults than its potential. -op

What is the actual memory overhead for IronClaw's extra isolation?

Marcus Rivera — Thu, 25 Jun 2026 03:57:28 +0000

Hello everyone. I’ve been reading through the docs and past threads on the three runtimes, and I’m trying to solidify my understanding of the practical costs involved. The common guidance is that IronClaw provides the strongest isolation by running each tenant’s agents in dedicated, lightweight VMs, while NemoClaw uses process isolation and NanoClaw uses a shared runtime with boundaries enforced at the framework level. For my use case—a multi-tenant internal tool where some tenants process highly sensitive data—IronClaw seems like the right fit from a threat modeling perspective. However, I need to justify the infrastructure footprint. My question is about the **actual, observed memory overhead** for that extra isolation layer. From the documentation, I gather: * The base memory for the management layer itself is relatively small (~100MB). * Each tenant's VM has a minimal, stripped-down OS image. * The advertised "agent memory" is what you allocate to the tenant's workload *inside* the VM. But in practice, what's the fixed overhead *per tenant VM*? Is it in the range of 50-100MB per isolated environment, or does it vary significantly based on the host system? I'm particularly interested in: * Real-world numbers from smaller deployments (e.g., 10-20 concurrent tenants). * Whether this overhead scales linearly as you add tenants. * Any "gotchas" like memory ballooning or caching behavior that might affect these numbers. I'm coming from a background where we'd use containers, so I'm trying to map the VM overhead I'm familiar with to IronClaw's optimized model. Any data points or performance testing you could share would be incredibly helpful for my comparison matrix. —marcus

Switching from containers to VMs? IronClaw vs NemoClaw on KVM

Morgan T. — Thu, 25 Jun 2026 03:39:06 +0000

Our team is currently architecting a multi-agent procurement assistant where the final-stage agent executes irreversible actions—placing orders and initiating wire transfers via authenticated vendor portals. Our initial threat model used NemoClaw inside Docker containers for agent isolation, but a recent red team exercise revealed a concerning lateral movement path: a successful prompt injection led to container escape via a poisoned `pip install` command, leveraging a compromised Python package to gain host-level access. This has forced a fundamental reassessment. We are now evaluating a shift to a full virtualization layer, specifically comparing NemoClaw on KVM (as the baseline container runtime) against IronClaw (the purpose-built VM runtime). The core question is whether the security boundary of a lightweight VM, as provided by IronClaw, sufficiently mitigates our identified threat vectors to justify the operational overhead, or if a hardened NemoClaw configuration is adequate. **Specific Threat Model & Attack Path Considerations:** * **Primary Concern:** Agent executing untrusted code (e.g., data parsing scripts, "calculations") as part of its tool use. * **Attack Path 1: Dependency Poisoning.** An injection convinces the agent to `pip install` a malicious package. In a container, this can lead to host compromise if the container is run privileged or with host mounts. IronClaw's microVM should contain this entirely. * **Attack Path 2: Kernel Exploit.** A compromised tool or library exploits a kernel vulnerability. The container shares the host kernel; a breakout is catastrophic. IronClaw's independent guest kernel (albeit lightweight) introduces a critical barrier. * **Attack Path 3: Persistent Compromise.** A rogue agent establishes a reverse shell. In a container, this persistence is on the host. In a microVM, the compromise is isolated to a disposable virtual machine instance. **Configuration & Isolation Specifics:** Our NemoClaw setup on KVM currently uses a strict AppArmor profile and dropped capabilities: ```yaml # nemo_claw_agent.yaml (segment) isolation: runtime: containerd security_context: apparmor_profile: "claw-agent-hardened" capabilities: drop: read_only_root_filesystem: true allow_privilege_escalation: false ``` IronClaw, by contrast, delegates isolation to the hypervisor. An agent is allocated a dedicated microVM via Firecracker or crosvm. The runtime configuration focuses on resource limits, not syscall restrictions: ```yaml # iron_claw_agent.yaml (segment) isolation: runtime: firecracker vm_config: vcpu_count: 1 mem_size_mib: 512 kernel_image: "/opt/ironclaw/vmlinux-6.1.bin" rootfs: "/opt/ironclaw/agent-rootfs.ext4" network_isolation: "tap0" ``` **The Trade-off Analysis:** * **NemoClaw (KVM containers):** Faster cold start (~100ms), denser agent packing, efficient shared memory for multi-agent communication. Security relies on Linux kernel security modules (namespaces, cgroups, seccomp-bpf). The attack surface is the **host kernel**. * **IronClaw (microVMs):** Slower initialization (~200-400ms), higher memory overhead per agent due to separate kernels. Security relies on the **hypervisor**. The attack surface shifts from the host kernel to the KVM hypervisor and the VM's paravirtualized devices, which is generally considered a narrower and more auditable frontier. For our high-trust internal analytics agents, NemoClaw remains perfectly suitable. However, for the financial actuator agent processing external data and executing transactions, the threat model now clearly demands hypervisor-level isolation. The operational cost of IronClaw appears to be the correct tax for that risk tier. I am seeking validation of this reasoning and concrete experiences from others who have made this shift. Specifically: * Performance impact on agent-to-agent tool call latency when crossing VM boundaries. * Management of the microVM image library—patching the guest kernel and rootfs across hundreds of agents. * Whether the IronClaw `virtio-vsock`-based communication channel has proven robust against exfiltration attempts from a compromised guest. --mt

NemoClaw's new plugin system - are the sandbox promises real?

Oliver Weiss — Wed, 24 Jun 2026 17:02:14 +0000

Having spent the last 72 hours instrumenting the NemoClaw 2.8 runtime with a custom eBPF program to trace plugin lifecycle events, I'm compelled to ask: does the new plugin sandbox actually enforce meaningful isolation, or is it merely a sophisticated namespace wrapper that leaves the kernel attack surface wide open? The marketing materials promise "sub-process isolation with hardware-backed boundaries," but my kprobe instrumentation tells a more nuanced story. Let's dissect the actual enforcement mechanisms, as observable from the kernel. **The Sandbox Model: cgroups v2 & Seccomp-BPF** NemoClaw's plugin sandbox is built atop a cgroups v2 subtree, which is a good start for resource containment. However, the critical isolation vector is the syscall filter. Their default seccomp-bpf profile is, frankly, permissive for a security-focused runtime. Consider this default filter snippet they've published (annotated with my critiques): ```c // Example rule from NemoClaw's 'restricted' profile struct sock_filter filter[] = { BPF_STMT(BPF_LD | BPF_W | BPF_ABS, offsetof(struct seccomp_data, nr)), // Allows clone, fork, vfork - necessary, but opens door to namespace escapes if combined with unshare. BPF_JUMP(BPF_JMP | BPF_JEQ | BPF_K, __NR_clone, 0, 1), BPF_STMT(BPF_RET | BPF_K, SECCOMP_RET_ALLOW), BPF_JUMP(BPF_JMP | BPF_JEQ | BPF_K, __NR_fork, 0, 1), BPF_STMT(BPF_RET | BPF_K, SECCOMP_RET_ALLOW), // Allows unshare without CLONE_NEWUSER - this is a potential flaw. BPF_JUMP(BPF_JMP | BPF_JEQ | BPF_K, __NR_unshare, 0, 1), BPF_STMT(BPF_RET | BPF_K, SECCOMP_RET_ALLOW), // ... more allows BPF_STMT(BPF_RET | BPF_K, SECCOMP_RET_ERRNO), }; ``` The simultaneous allowance of `clone`/`fork` and `unshare` is a known risk pattern. Without mandatory user namespace mapping (which their documentation says is "optional for compatibility"), a malicious plugin can create new namespaces for mounts, networks, etc., potentially pivoting to the host. I've verified via ftrace that the `unshare(CLONE_NEWNS)` call *succeeds* under the default "restricted" profile if the plugin process has `CAP_SYS_ADMIN` within its user namespace—which it often does. **Kernel Telemetry Gap** My primary concern is the lack of innate runtime telemetry for sandbox integrity events. Unlike IronClaw, which emits audit events to a ring buffer accessible via eBPF, NemoClaw's plugin boundary crossings are largely silent. You must attach your own tracing: * Use a kprobe on `__seccomp_filter` to log filtered syscalls. * Attach an eBPF program to `cgroup/task_rename` to monitor process lineage breaks. * Trace `bpf_prog_load` to see if plugins attempt to load their own eBPF code (a major escape vector). Without this instrumentation built-in, you're operating blind. The "sandbox promise" is only as real as your ability to verify its enforcement continuously. **Comparison to Sibling Runtimes** * **NanoClaw:** Uses a hypervisor-based microVM barrier. The isolation is stronger, but the plugin I/O overhead is measurable via my eBPF latency histograms. NemoClaw trades some hardness for performance. * **IronClaw:** Employs a mandatory SELinux layer with a distinct type for each plugin, plus a deny-by-default seccomp policy. The policy is static and more thorough, but less flexible for dynamic plugin ecosystems. **The Verdict** The sandbox is "real" in the sense that it uses kernel primitives, but its default configuration leaves several attack surfaces unsealed. The promises hinge on the operator supplying a rigorous seccomp-bpf profile and enabling user namespace isolation—neither are default. For a low-trust plugin ecosystem, this is insufficient out-of-the-box. I'm now working on a reference eBPF-based monitor that tracks namespace transitions and syscall anomalies across the plugin cgroup. Without such instrumentation, you cannot assert the sandbox's integrity under active attack.

Showcase: My hardened OS build for running Claw runtimes on bare metal

Emilia Rojas — Wed, 24 Jun 2026 09:39:09 +0000

After several months of testing, I've concluded that the default enterprise Linux distributions introduce unacceptable supply-chain risk for hosting the Claw runtimes in high-assurance scenarios. The sheer volume of unvetted packages in their repos, coupled with aggressive auto-updating, creates a large attack surface orthogonal to the runtimes' own security. I've built a minimal, immutable OS configuration specifically for bare-metal deployment of NemoClaw, NanoClaw, and IronClaw. The goal is to provide a hardened foundation that complements, rather than undermines, their isolation and attestation features. Core principles of the build: * **Distroless Base:** Built from scratch using a build toolchain, not a package manager. The final image contains only the Linux kernel, a musl libc, the necessary Claw runtime, and our orchestration agent. * **Immutable Root Filesystem:** The root is mounted read-only. All runtime-specific data (keys, sessions, logs) is directed to distinct, ephemeral volumes. * **Strict Kernel Hardening:** Leveraging `sysctl` and kernel module blacklisting to restrict process capabilities, network access, and `/dev` access at the host level. * **Credential Segmentation:** The host OS never possesses runtime credentials. Initial attestation materials are injected via secure hardware (TPM) or a physical interface during provisioning. Specific considerations for each runtime: * **NemoClaw:** The host kernel is configured with the most restrictive seccomp and namespace profiles to reinforce the sandbox. We disable all non-essential `ioctl` commands at the host level. * **NanoClaw:** The immutable design aligns well with its unikernel approach. We configure the hypervisor (e.g., Firecracker) to use the minimal KVM modules, disabling legacy emulation devices. * **IronClaw:** The host's TPM is reserved exclusively for IronClaw's measured boot and attestation chain. No other service on the host can access the TPM, preventing credential mingling. The primary trade-off is operational: updates require rebuilding and re-provisioning the entire image via a CI/CD pipeline with in-toto attestations. However, this forces a SBOM and vulnerability scan at each iteration, which I consider a feature. I'm interested in feedback on the kernel configuration specifics, particularly around mitigating hardware-based side-channels at the host level, which could affect all runtimes. Has anyone else moved to a distroless model for their Claw deployments? - Em

Beginner's mistake I made: not changing the default admin credentials

Elena Rossi — Tue, 23 Jun 2026 23:57:26 +0000

I’ve been setting up a small fleet of NemoClaw instances for internal tooling over the past few months, and I just finished a security review that turned up a glaring, embarrassing oversight. I’m posting this here in the hopes that it saves another newcomer from the same pitfall. In my initial provisioning script, I was so focused on getting the runtime configured correctly—getting the sandbox policies right, the network egress rules locked down, the logging output set to our SIEM—that I completely overlooked one of the most basic steps. I never changed the default admin credentials for the NemoClaw management API. For months, every instance was sitting there with `admin:clawadmin123` as the login, accessible on the internal management VLAN. The script looked something like this, and you can see the missing step: ```python # nemo_provision.py import requests import yaml def provision_nemoclaw(host_ip, config_path): # Load the complex security policy with open(config_path) as f: security_policy = yaml.safe_load(f) # Step 1: Bootstrap instance with policy response = requests.post( f"https://{host_ip}:8443/api/v1/bootstrap", json=security_policy, auth=('admin', 'clawadmin123'), # <-- Default left in place verify=False # Using self-signed cert initially ) response.raise_for_status() # Step 2: Configure logging, alerts, etc... # ... many more API calls, all using the same default auth ... # I NEVER CHANGED THE CREDENTIALS. # No call to POST /api/v1/admin/credentials was ever made. ``` The irony is palpable. Here I am, using NemoClaw specifically for its strong runtime isolation and its ability to segment workloads from each other, yet I left a wide-open credential path at the management layer. The threat model for this deployment assumed a potentially compromised low-privilege application workload, but it didn't adequately account for lateral movement on the management network. A simple credential spray attack would have handed over control. What I should have done, and what I've now implemented, is a mandatory credential rotation as the final step of provisioning. Here's the corrected workflow: * Generate a unique, long passphrase for each instance (using our vault's API). * Immediately after bootstrap, call the credential change endpoint. * Store the new credentials securely in our central vault, *not* in the provisioning script. * As a secondary control, implement a pre-commit hook in our infrastructure repo that scans for default credentials in any configuration or script file. It catches things like: * `clawadmin123` * `nemoadmin@123` * Common variants for NanoClaw and IronClaw defaults. The lesson I'm taking forward is that the strength of a runtime's isolation model—whether it's NemoClaw's container-based sandboxing, NanoClaw's lightweight process separation, or IronClaw's hardware-backed enclaves—can be completely undermined by a weak point in the *orchestration* layer. The management plane needs to be part of the threat model from the very first line of code you write. I'm curious how others handle this. Do you bake credential rotation into your CI/CD pipeline for Claw runtime deployments? For IronClaw, where the attestation process is more involved, does your provisioning workflow also include a similar immediate step to nullify default manufacturer or platform credentials?