NemoClaw is not a competitor to OpenClaw, but a sandbox around it. What that sandbox really does as of October 2026, what it leaves open, and how to harden a self-hosted agent whichever option you choose.
Update October 2026: What changed since the first version
- I had called NemoClaw "enterprise-ready". Too generous: NVIDIA itself describes it as an early-preview reference stack for a trusted operator on one host, not a multi-tenant enterprise control plane.
- OpenShell is not an OpenClaw component but NVIDIA's sandbox runtime. OpenClaw can now also use it directly as a sandbox backend.
- My list of OpenClaw defaults is outdated: on a regular host the gateway binds to loopback, most channels answer unknown senders with a pairing code,
openclaw security auditchecks the configuration, and sessions are written to disk, now in one SQLite database per agent (older ones as JSONL). The sandbox, however, is still off by default. - I cannot find automatic PII filtering in the current NemoClaw docs. What is documented: secret redaction and a secret scanner for memory files.
- Besides Linux, the prerequisites now list macOS (Apple Silicon) and WSL2 as "tested with limitations". Node.js 22.19+ instead of v20.
What OpenClaw, OpenShell and NemoClaw Are Today
OpenClaw (formerly Clawdbot, then Moltbot) is a self-hosted gateway that connects chat channels such as WhatsApp, Telegram or Slack to an AI agent. According to its own docs, the agent can run shell commands, read and write files, access network services and send messages to anyone (if given channel access). On top come skills from the ClawHub marketplace. In February 2026 founder Peter Steinberger joined OpenAI; according to his announcement, the project is to move to a foundation and stay open. Over 390,000 GitHub stars: not a niche project.
OpenShell is NVIDIA's open-source runtime for agent sandboxes: network namespaces, seccomp, Landlock, a proxy that every outbound connection has to pass through, and inference routing so API keys stay on the host.
NemoClaw is NVIDIA's reference stack on top, presented at GTC on March 16, 2026. A CLI plus a versioned blueprint uses nemoclaw onboard to build a hardened OpenShell sandbox for OpenClaw, and by now also for Hermes and LangChain Deep Agents Code. Current state: v0.0.130 from October 1, 2026, still early preview. The model remains your choice, from NVIDIA via Anthropic and OpenAI to local models through Ollama.
The Office Analogy
The analogy also shows the limit: no turnstile stops the employee from believing a scammer on the phone.
The Threat Model: An Agent With All Three Legs
A self-hosted assistant is almost by definition the lethal trifecta. It reads your mail, calendar and files: private data. It processes messages from group chats, web pages and skill descriptions: untrusted content. And its whole purpose is external communication: sending messages, calling APIs, fetching URLs. For a messaging agent, the third leg is not a side effect. It is the product.
OpenClaw's own docs put it soberly: most failures are not exotic exploits but "someone messaged the bot and the bot did what they asked". The order of defense there: identity first (who can talk to the bot), then scope (where it can act), the model last, assuming it can be manipulated. That is exactly the "architecture over prompts" stance that runs through this series.
What Actually Happened in 2026
- ClawHavoc (February): Koi Security audited 2,857 skills on ClawHub and found 341 malicious ones, 335 of them from a single campaign. A fake "Prerequisites" section tricked users into installing malware such as Atomic Stealer. OpenClaw has since been scanning skills with VirusTotal, but says itself: a skill that uses natural language to instruct the agent to do something malicious won't trigger a virus signature.
- CVE-2026-25253 (CVSS 8.8, fixed in 2026.1.29): The Control UI took a
gatewayUrlfrom the query string and sent the gateway token there without asking. One click on a crafted link was enough to take over the gateway, even when bound to loopback, because the victim's browser opens the connection. - Claw Chain (May, fixed in 2026.4.22): Four chainable flaws, three of them in OpenClaw's OpenShell sandbox backend and MCP loopback, including a race condition that allowed writes to be redirected out of the sandbox; the fourth sits in the exec allowlist. Starting point: code execution inside the sandbox, for example via a malicious plugin or prompt injection.
- CVE-2026-24222 (NemoClaw, fixed in v0.0.18): Prompt injection could make the agent read and exfiltrate insufficiently shielded host environment variables.
- The big picture: The OpenClaw repo lists more than 700 published security advisories, 14 of them critical (as of October 6, 2026). That also speaks for a working disclosure process, but it means: patch it like a browser.
Two lessons. First: the sandbox is code itself and has bugs. Plan for the case where it breaks. Second: the chains start where untrusted content meets the agent or its user, at a skill, a link, an injected message. I described exactly this pattern in The Year AI Agents Became the Attack Surface.
What NemoClaw Mitigates and What It Doesn't
Map the controls onto the three legs of the trifecta and a clear picture emerges. The basis is NVIDIA's own security posture docs, which are open about residual risks.
| Leg | What NemoClaw does | What stays open |
|---|---|---|
| External communication | Egress is deny-by-default. Unknown destinations land in the terminal UI for approval, and rules can be restricted to individual binaries, HTTP methods and paths. Strong | According to NVIDIA, every allowed endpoint is a potential exfiltration path. The default "Balanced" tier opens npm, PyPI, Hugging Face and Homebrew. Endpoints without L7 inspection are only checked by host, port and binary. And the chat channels are an exit themselves. Open |
| Private data | Keys for models and MCP servers stay on the host; the agent only talks to inference.local. System paths are read-only; essentially only /sandbox and /tmp are writable. Strong |
Anything you put in the agent's workspace, it can read and pass on. Its OpenClaw configuration remains writable for it, and the scanner does not detect Base64-encoded secrets. Open |
| Untrusted content | Little. A scanner prevents the agent from writing 14 known credential patterns into memory files. | Prompt injection via messages, web pages and skills works unchanged. NemoClaw keeps no plugin allowlist of its own. Open |
| Host (blast radius) | seccomp, Landlock, privilege drop, no gcc and no netcat in the image. Strong |
Landlock runs "best effort" and is silently skipped on kernels older than 5.13. Agent, gateway and supervisor share one UID. |
Bottom line: NemoClaw answers very well what a compromised agent can do on my host and with my keys. It does not answer how I prevent it from being compromised. In trifecta terms: NemoClaw protects credentials, not data, and cuts the communication leg only as far as you keep the allowlist tight.
Hardening Checklist, Whichever You Choose
- Patch it like a browser. At least OpenClaw 2026.4.22 and NemoClaw v0.0.18, preferably the current version of each.
- Keep the gateway private. Bind to loopback, token auth, DM pairing, respond in groups only on mention. Remote access via SSH tunnel or Tailscale, never public. Careful: according to the OpenClaw docs, container images default to an exposed bind.
- Run
openclaw security auditregularly, not just at setup. Configurations drift. - Turn on the sandbox. In OpenClaw it is off by default; once enabled via
agents.defaults.sandbox, the Docker backend starts without network. But only tool execution moves; the gateway with the chat channels stays on the host. With NemoClaw: the "Restricted" tier instead of the "Balanced" default, approvals one by one rather than wholesale. - Keep tools per agent minimal. Whoever reads untrusted content gets no
exec, no file access, notools.elevated. The hardened baseline is a good starting point. - Put a reader agent in front. An agent without tools summarizes mail and web pages; only the summary goes to the agent with permissions. OpenClaw recommends this itself. The summary still remains untrusted.
- Keep secrets out of the agent's reach. No
.envfiles in the workspace, separate accounts and a separate number for the bot, tokens with minimal scopes. - Treat skills like dependencies. Read
SKILL.mdbefore installing, never run "prerequisites" from a skill description. The VirusTotal scan is one layer, not a free pass. - Keep an eye on memory. The secret scanner keeps keys out, not poisoned facts. How cheap memory poisoning is, I showed with two chat messages.
- Set a spend limit at the provider. NemoClaw does not cap token costs.
- Recreate after a suspicion. Recreate the sandbox from trusted state, rotate keys. In NemoClaw, approved endpoints only disappear when you destroy and recreate the sandbox;
nemoclaw <sandbox> rebuildcarries the current policy, approvals included.
When Neither Is Enough
Both projects state their limit openly: one trust boundary per gateway for OpenClaw, one trusted operator per host for NemoClaw. That is why neither is enough in four cases:
- Several users who don't trust each other. Anyone who can message an OpenClaw agent with tools shares its permissions. NemoClaw does not separate tenants either. Solution: separate gateways, OS users or hosts.
- Enterprise requirements. According to NVIDIA's enterprise readiness page, SSO is roadmap-only, operator RBAC and tenant isolation are out of scope, and audit export, SIEM and fleet policy are manual work. For a team with compliance obligations, NemoClaw is a building block, not a platform.
- An agent that needs all three legs with sensitive data. If the same agent reads customer mail, writes to the CRM and sends mail, no sandbox helps: the exfiltration path is an allowed function. Split the task into agents that each lack one leg, and put a human approval in front of every outbound action.
- No patch process. If nobody reads the advisories, an always-on agent with shell access is a risk that no configuration compensates for.
My Decision Guide
Experiment on your own machine, no real accounts
OpenClaw with the sandbox enabled and the hardened baseline is enough. NemoClaw is worth it if you want to get to know egress allowlists in day-to-day use.
Always-on assistant with real accounts on a server
NemoClaw on the "Restricted" tier, or OpenShell directly if you need your own images and policies. Plus the complete checklist above.
Team, customer data, compliance
Architecture first: separate the trifecta legs per task, approvals for outbound actions, your own monitoring. NemoClaw can be the sandbox layer in that, not the security concept.
You can place your own agent with my agent security self-assessment.
Conclusion
The question "OpenClaw or NemoClaw?" is still the wrong question, just differently than I thought in spring. NemoClaw is not "the secure OpenClaw" but a good network and credential boundary around an agent whose decisions remain manipulable. That limits the blast radius. But it does not replace the question I ask everyone who deploys an agent: if it follows an injection, what can it actually do?
You can't prompt your way out of the lethal trifecta, and you can't sandbox your way out of it alone either. A sandbox cuts one leg at best, and only as far as you maintain the allowlist. The rest you have to build through architecture. What that looks like is in the defense playbook for AI agents and in the review of 247 papers on agent security.
Sources (as of October 6, 2026): NVIDIA NemoClaw docs: Ecosystem, Security Posture, Filesystem Controls, Enterprise Readiness, Release Notes; OpenClaw docs: Trust Model, Sandboxing, Prompt Injection; OpenClaw security advisories.
Tools Used:
Running a self-hosted agent, or planning one, and want to know what it could do in a worst case? Get in touch, I help with threat modeling, hardening and architecture.