NemoClaw Sandbox Escape Research: What Snyk Labs and the Community Found

NemoClaw is NVIDIA’s enterprise security wrapper for agentic AI — the sandboxed runtime environment that adds kernel-level isolation, a YAML policy engine, and a privacy router to the open-source OpenClaw agent framework. It is the most serious attempt by a major vendor to solve the agent security problem. It is also in alpha. And security researchers have found that several of its isolation boundaries can be bypassed.

This article catalogs what security researchers have found, explains the technical mechanisms behind each bypass, assesses the severity for enterprise deployments, and provides the specific mitigations available today. The primary formal research comes from Snyk Labs, published as “Escaping the Agent: On Ways to Bypass OpenClaw’s Security Sandbox” (labs.snyk.io). These findings do not mean NemoClaw is broken — they mean NemoClaw is young, and the security boundaries it advertises are not yet fully enforced in all configurations. Enterprise teams deploying NemoClaw must understand these gaps and compensate with defense-in-depth measures until NVIDIA patches them.

For the full list of known NemoClaw limitations, see our What NemoClaw Cannot Fix analysis. For the audit process that verifies NemoClaw’s security controls, see our 10-Point Security Audit Checklist. For our enterprise security assessment service, see our Security Checklist page.

The severity is high because workspaceAccess: "none" is the configuration that enterprises deploy when they want the agent to have zero filesystem access. If this setting does not actually prevent filesystem access via /tools/invoke, the security guarantee is hollow. An attacker who achieves prompt injection against the agent can instruct it to read sensitive files through tool invocation rather than direct filesystem access.

How the Attack Works

# Agent's workspace access is set to "none"
# Direct file read: BLOCKED by sandbox
Agent → read(/etc/passwd) → DENIED (Landlock)

# But /tools/invoke bypasses the sandbox boundary
Agent → POST /tools/invoke
  {
    "tool": "file_reader",
    "args": {"path": "/etc/passwd"}
  }
  → SUCCESS (tool executes outside sandbox boundary)
  → Returns file contents to agent
  → Agent includes contents in next LLM response

# The agent now has the file contents in its context
# and can exfiltrate them through any output channel

Mitigation

Until NVIDIA patches this, restrict the tools available through /tools/invoke in your YAML policy. Do not rely on workspaceAccess alone for filesystem isolation. Instead, explicitly deny all filesystem-related tools in the policy’s tools.denied list, and run NemoClaw’s host process under a restricted Linux user account with minimal filesystem permissions. This creates a defense-in-depth layer: even if the tool invocation bypasses the sandbox, the host process itself cannot read sensitive files.

sandbox:
  workspaceAccess: "none"
  tools:
    denied:
      - "file_reader"
      - "file_writer"
      - "shell_exec"
      - "*_filesystem_*"

# Additionally: run NemoClaw as a restricted user
# $ useradd -r -s /sbin/nologin nemoclaw-runner
# $ chown nemoclaw-runner:nemoclaw-runner /opt/nemoclaw/
# $ nemoclaw start --user nemoclaw-runner

The severity is medium because exploiting this requires precise timing and either a collaborating process inside the sandbox or the ability to manipulate the filesystem during the validation window. In practice, the window is measured in microseconds. But for persistent attackers with prompt injection access, the race can be attempted repeatedly until it succeeds. On a system under load where I/O operations are slower, the window is wider.

Mitigation

Mount the agent’s writable directories with nosymfollow (available on Linux 5.10+ with ext4/XFS). This prevents the kernel from following symlinks in those directories, eliminating the TOCTOU race entirely. Alternatively, use O_NOFOLLOW flags in file operations, but this requires a NemoClaw patch to change the sandbox’s open() calls. The nosymfollow mount option is the immediate mitigation you can deploy today.

# Create a dedicated filesystem for the agent's writable directory
$ mkdir -p /mnt/nemoclaw-workspace
$ mount -t tmpfs -o size=1G,nosymfollow tmpfs /mnt/nemoclaw-workspace

# Update NemoClaw config to use this directory
$ nemoclaw config set sandbox.workspace_dir "/mnt/nemoclaw-workspace"

# Verify nosymfollow is active
$ mount | grep nemoclaw-workspace
tmpfs on /mnt/nemoclaw-workspace type tmpfs (rw,nosymfollow,size=1048576k)

This gap matters most in configurations where the allowed endpoint list includes external APIs. An attacker who achieves prompt injection can craft arbitrary HTTP requests to any allowed endpoint. If the allowed endpoint is a third-party API that accepts POST requests with arbitrary bodies, the attacker can exfiltrate data by encoding it in the request body to a whitelisted destination.

Mitigation

Minimize the allowed_endpoints list to the absolute minimum required. Remove any endpoint that accepts arbitrary input from external sources. Use NemoClaw’s seccomp profile to restrict which binaries can make network calls — deny curl, wget, and python3 as network-capable binaries, leaving only the specific tool binary as the sole network client. This does not fully solve the issue but reduces the attack surface from “any process” to “only the designated tool binary.”

sandbox:
  seccomp:
    network_binaries_allowed:
      - "/opt/nemoclaw/tools/market_api_tool"
    network_binaries_denied:
      - "/usr/bin/curl"
      - "/usr/bin/wget"
      - "/usr/bin/python3"
      - "/usr/bin/nc"

The prompt injection bypass is the most concerning finding because it is not a bug in NemoClaw’s code — it is a fundamental limitation of the security model. NemoClaw’s sandbox controls what system resources the agent can access. It does not control what the LLM decides to do with those resources. If the LLM is tricked by a prompt injection into believing it should read and transmit a file, and the sandbox permissions allow reading that file and reaching that endpoint, the sandbox has technically not been violated — the agent is operating within its permissions. The violation is at the intent level, not the capability level.

Combined Mitigation Strategy

1. Minimize permissions. Apply the principle of least privilege ruthlessly. Every tool, filesystem path, and network endpoint in the policy should be justified. If an agent does not need network access, deny it entirely. If it needs one endpoint, allow only that endpoint.
2. Restrict executable binaries. Use seccomp to deny execution of general-purpose network tools (curl, wget, python3, nc) inside the sandbox. Only allow the specific tool binaries the agent requires.
3. Monitor tool invocation patterns. Set up alerting for unusual /tools/invoke calls — file reads of paths not typically accessed, network requests to allowed endpoints with unusually large payloads, or tool invocations at unusual times.
4. Run NemoClaw behind a reverse proxy with request logging. Log all outbound requests from the NemoClaw host to allowed endpoints. Review for data exfiltration patterns: large POST bodies, base64-encoded content, or requests that do not match the expected API call format.
5. Accept the alpha risk. NemoClaw is in alpha. NVIDIA explicitly states to “expect rough edges.” These findings are consistent with alpha-quality software. If your risk tolerance requires production-grade sandbox isolation, NemoClaw is not there yet. Layer it with Docker containers, network segmentation, and external monitoring to compensate.

The r/LocalLLaMA subreddit has been a primary forum for NemoClaw early adopters. Several community members reported that sandbox isolation was bypassed on RTX 5090 systems running NemoClaw with local vLLM inference. The specific issues include sandbox processes accessing host GPU memory mappings that should be isolated, and network namespace leaks where the sandboxed agent could observe host network interfaces.

Separately, multiple users reported HTTP CONNECT proxy 403 errors when the sandboxed agent attempted to establish connections through the privacy router’s proxy mechanism. These 403 errors indicate that the proxy is rejecting requests, but the error handling exposes information about the proxy’s configuration (endpoint whitelist entries, proxy port) that an attacker could use to craft more targeted bypass attempts.

These community reports are harder to verify than the Snyk Labs findings because they do not include reproducible proof-of-concept code. However, the pattern is consistent: NemoClaw’s sandbox isolation is implemented through kernel features (Landlock, seccomp, namespaces) that behave differently depending on kernel version, GPU driver version, and hardware configuration. A sandbox that works correctly on one system may have gaps on another. This is the cost of alpha software — the edge cases have not been fully mapped.

Broader Ecosystem Concerns: Malicious Skills and UX Gaps

The sandbox escape findings exist within a broader context of ecosystem-level security concerns. Particula.tech reported that after OpenClaw hit 250K GitHub stars, approximately 20% of its community-contributed skills were found to contain malicious code — backdoors, data exfiltration routines, or privilege escalation payloads. This is why NemoClaw’s sandbox matters even with known bypasses: the threat surface is not just theoretical prompt injection but actively malicious code in the skill supply chain.

TechPlanet covered this gap directly in “NemoClaw: Securing OpenClaw Agents with Sandboxed Inference” — the argument being that NemoClaw’s sandbox, even in alpha, provides the containment layer that bare OpenClaw completely lacks against malicious skills.

Yes, with qualifications. NemoClaw with these known vulnerabilities is still materially more secure than bare OpenClaw with no sandbox at all. The question is not “Is NemoClaw perfectly secure?” (it is not) but “Is NemoClaw better than the alternative?” (it is). The 42,665 exposed OpenClaw instances with no authentication, no sandbox, and no policy engine represent a far worse security posture than NemoClaw with known, mitigatable bypass paths.

The practical guidance for enterprise teams is layered defense. Do not treat NemoClaw as a complete security solution. Treat it as one layer in a defense-in-depth stack that includes host hardening, network segmentation, output monitoring, and incident response procedures. NemoClaw raises the bar from “trivially exploitable” to “requires meaningful effort and specific attack chains.” That is valuable, even if it is not sufficient alone.