Local models reduce one risk class: prompts and documents need not leave your LAN for inference. They do not reduce another: an agent with tools can still read files, open network connections, and take actions you did not intend.
NVIDIA NemoClaw is an open-source reference stack for running agents more safely inside NVIDIA OpenShell sandboxes, with guided onboarding, network policy, lifecycle management, and routed inference. On supported DGX platforms, the current installer may offer an Express path to managed local inference.
As of 10 August 2026, NVIDIA’s canonical platform-support matrix labels NemoClaw an alpha, early-preview project with best-effort maintainer response and no production SLA. OpenShell’s own repository likewise labels the runtime alpha and describes its current operating model as one developer, one environment, and one gateway. Evaluate both accordingly, even where an individual capability or platform row is marked Tested.
Official entry points:
- Spark playbook: build.nvidia.com/spark/nemoclaw
- Source and issues: github.com/NVIDIA/NemoClaw
- Docs hub: docs.nvidia.com/nemoclaw
- OpenShell: github.com/NVIDIA/OpenShell
Related context: what DGX Spark is, local inference reality, private AI deployment patterns.
NemoClaw and OpenShell reduce blast radius; they do not eliminate agent risk. Both projects are alpha software, and NVIDIA’s own Spark playbook frames the experience as a demo path with residual risks: data leakage, malicious code execution, unintended actions, and prompt injection. Use a clean environment for first install. Do not connect production credentials, customer databases, or privileged cloud accounts until policy, logging, and human gates are deliberate.
What NemoClaw is (and is not)
| It is | It is not |
|---|---|
| A reference stack + CLI for sandboxed agents | A compliance certification |
| OpenShell-backed isolation with policy hooks | A guarantee against prompt injection |
| Routed inference to controlled backends (including local vLLM on Spark) | A requirement to use only one agent product forever |
| An alpha, early-preview stack with versioned releases | A drop-in replacement for your IAM and DLP program |
Supported agents (per NemoClaw README; verify current docs on install day):
- OpenClaw, the default multi-channel agent gateway
- Hermes Agent, the Nous Research self-hosted runtime for terminal, messaging, tools, and memory
- LangChain Deep Agents Code, a terminal-oriented coding runtime with no in-sandbox gateway or dashboard
NVIDIA’s current support matrix lists all three agents as Tested. That does not mean production-ready: the matrix says broader live-runtime acceptance and terminal-agent diagnostics for Deep Agents Code remain tracked work, and it does not assert production parity between Hermes and OpenClaw.
You choose an agent for channel UX and tool philosophy; NemoClaw’s job is the sandbox envelope and onboarding path around it.
Current onboarding on DGX Spark (concept)
The current OpenClaw quickstart installs from NVIDIA’s hosted script and then completes setup through nemoclaw onboard. On a supported DGX Spark with current DGX OS, the installer can offer Express managed local inference. Conceptually, onboarding:
- Pulls or confirms dependencies (Node.js, OpenShell, NemoClaw CLI) as needed.
- Sets up managed vLLM (or the playbook’s current local inference path) on the Spark.
- Selects an installer-recommended default local model and a starter policy / sandbox profile.
- Creates the sandbox and exposes the interface supported by the chosen agent. OpenClaw and Hermes have dashboard paths; Deep Agents Code is terminal-oriented and has no in-sandbox gateway or dashboard.
Do not hardcode a model name into architecture docs as eternal truth. Express Install’s listed default can change between playbook revisions. Say “installer-recommended local model,” record the exact id from the installer output in your runbook, and re-check build.nvidia.com/spark/nemoclaw when you rebuild.
Custom onboarding remains available when you need a different agent, inference provider, or policy posture. For Hermes, current NVIDIA documentation recommends the nemohermes onboard alias and also supports nemoclaw onboard --agent hermes. Set NEMOCLAW_AGENT=hermes when selecting Hermes through the hosted installer. Confirm the live Hermes quickstart on install day.
Prerequisites (Spark playbook)
- DGX Spark with keyboard/monitor or SSH.
- Fresh, updated DGX OS.
- Working GPU visibility and Docker (playbook expects modern Docker; verify with
nvidia-smianddocker infobefore debugging NemoClaw).
Optional later: messaging channels (for example Telegram) and web search APIs. Those expand the network policy surface. Treat them as a second change window, not a default.
Policy layers: the part that matters
OpenShell’s README describes four sandbox policy domains: filesystem, network, process, and inference. Current NemoClaw security documentation describes five protection layers by adding gateway authentication, the control-plane boundary that governs which devices and clients can reach the gateway or dashboard. It is a related security layer, not a fifth sandbox policy domain.
| Layer | Protects | Current mutability |
|---|---|---|
| Filesystem | Reads/writes outside allowed paths and protected runtime state | Requires sandbox recreation |
| Network | Unauthorized outbound connections and data exfiltration | Hot-reloadable through policy changes or operator approval |
| Process | Privilege escalation, fork bombs, and dangerous syscalls | Requires sandbox recreation |
| Inference | Credential exposure and unauthorized model access | Changeable through NemoClaw’s inference-switching command |
Gateway authentication protects access to the gateway and dashboard surfaces when present. NVIDIA currently documents it as set during image build or onboarding, not as a hot-reloadable sandbox policy.
Design implications:
- Decide filesystem mounts before you create the sandbox you will keep. “We’ll open the home directory later” is how local agents inherit every SSH key on the box.
- Use network policy as a living allowlist: messaging webhooks, search APIs, and internal HTTP endpoints should be explicit. Keep the OpenShell gateway and any forwarded dashboard on loopback or another deliberately access-controlled boundary; gateway authentication alone is not sufficient protection for a publicly exposed agent dashboard.
- Route inference through the controlled path so the agent cannot silently point at a public API with confidential prompts unless you allow that provider.
- Read NVIDIA’s network policies and security best practices before you loosen Balanced/default presets.
A sandbox does not mean an empty audit trail. Define who can read agent logs, how long tool traces live, and whether channel transcripts are retained. Local inference with cloud channels can still exfiltrate content through the channel.
OpenClaw vs Hermes vs “just OpenShell”
| Choice | When it fits |
|---|---|
| OpenClaw (default) | You want a multi-channel gateway UX; Control UI / channels are part of the product story |
| Hermes | You want a self-hosted runtime oriented to tools, memory, cron, and webhook-style integration (including n8n-style plumbing elsewhere in the stack) |
| Deep Agents Code | You need the Tested, terminal-only LangChain path documented by NemoClaw and can accept the matrix’s remaining live-acceptance caveats |
| OpenShell alone | You need the alpha sandbox runtime without NemoClaw’s onboarding and blueprint; assess its current single-player operating boundary explicitly |
NemoClaw is optional glue, not a religion. The non-negotiable piece for production-shaped demos is policy + routed inference + least-privilege tools, regardless of which agent binary sits inside.
Upstream Hermes quickstarts and OpenClaw security docs still apply inside the sandbox: channel allowlists, pairing, and group mention rules matter because tools can include shell, files, and browser. OpenShell constrains the host; it does not invent good channel hygiene for you. Confirm current agent docs on install day: OpenClaw docs, official Hermes docs, and the current NemoClaw Hermes quickstart.
Failure modes and operational limits
| Failure | What goes wrong | Control |
|---|---|---|
| Onboarding on a dirty host | Agent may inherit sensitive files via broad mounts | Clean test environment for first bring-up |
| Over-broad network allow | Prompt injection → exfil via HTTP | Tight egress policy; approve new destinations deliberately |
| Unauthenticated local vLLM | Other LAN users query your private model | Bind privately; authenticate; firewall |
| Channel without pairing rules | Strangers trigger tool use | OpenClaw/Hermes allowlists, pairing, mention rules |
| Treating alpha software as finished | Breakage or changed behavior on update | Pin versions; read release/security notes; stage upgrades |
| No human gate on actions | Agent sends mail / merges / deletes | Require approval for high-impact tools |
Review the current NemoClaw release notes and SECURITY.md, pin the tested release, and use the documented private reporting channel for security issues.
How this fits a larger private stack
NemoClaw on one Spark is often step one of a longer architecture:
| Layer | Example |
|---|---|
| Inference | Local vLLM (Express Install or hand-rolled) on Spark; later TP across two Sparks |
| Agent | OpenClaw or Hermes inside OpenShell via NemoClaw |
| Automation | n8n (or similar) on LAN calling Hermes/OpenClaw webhooks for deterministic plumbing |
| Humans | Approval gates for CRM writes, outbound mail, production shell |
None of those layers is mandatory as a single vendor story. The durable rule is: deterministic glue outside the model, judgment inside the agent, policy around both. Capstone sketches that combine Spark clustering, local OpenAI-compatible serving, n8n, and Hermes are architecture options, not a requirement to run every component on day one.
Suggested first path (Spark)
- Update DGX OS; confirm
nvidia-smiand Docker GPU access. - Follow Express Install on the Spark playbook; record the installer-selected model id and policy profile.
- Use Web UI / TUI only with non-sensitive prompts until filesystem and network policies are reviewed.
- Add one channel or one internal HTTP tool, not five.
- Write a one-page runbook: how to stop or destroy the sandbox, revoke channel tokens, snapshot or restore supported state, and use the installed agent-specific uninstall command safely. Current Hermes documentation uses
nemohermes uninstall. - Only then point the agent at private corpora, and keep inference reality limits in mind if quality fails.
Acceptance checks before “real” data
- Filesystem mounts match the intended allowlist (no accidental home-directory share).
- Network policy denies unexpected egress; a test curl to a non-allowed host fails.
- Inference traffic goes to the routed local backend you configured, not an accidental public API key path.
- Channel pairing / allowlists reject an unknown sender.
- You can stop or destroy the sandbox and run the documented uninstall path, then inventory remaining containers, providers, credentials, and preserved state.
Current NVIDIA uninstall documentation says nemohermes uninstall --yes removes active NemoClaw runtime resources but preserves rebuild-backups/, backups/, and sandboxes.json by default. The preserved registry records are not automatically usable after reinstall because uninstall removes the gateway, provider registrations, and images they referenced. Do not treat preserved metadata as a recovery plan without reviewing the current host-files and state reference.
Use --destroy-user-data only when you intend to delete those preserved backups and registry metadata. --yes accepts the uninstall prompts; it does not purge preserved user data by itself. Test the exact version-pinned command in a clean environment and inspect what remains. This article has not executed that teardown path.
Do not do this yet
- Do not paste production API keys into chat with a coding agent that is “helping install” without redaction rules (upstream starter prompts warn about this for a reason).
- Do not assume sandboxed means safe for regulated health/legal decisioning.
- Do not skip network policy because “it’s only on the LAN.”
- Do not document a specific default model name as the forever architecture standard.
NVIDIA documents NemoClaw on Spark as an alpha, early-preview way to place supported agents behind OpenShell with routed inference. Validate that complete path, including denial, teardown, and recovery tests, before describing your deployment as working.



