NemoClaw on DGX Spark: deployment and security plan
Advanced10 min readPrivate / Local AI

NemoClaw on DGX Spark: deployment and security plan

Plan and evaluate OpenClaw, Hermes, or Deep Agents Code inside NVIDIA OpenShell on DGX Spark: current onboarding, policy layers, routed inference, and required acceptance evidence.

What you should be able to do

NemoClaw is a reference stack for agents inside OpenShell. Its policy layers reduce some risks but do not certify an agent, local model, or DGX Spark deployment as safe or production-ready.

Saved only in this browser.
In this article

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:

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 isIt is not
A reference stack + CLI for sandboxed agentsA compliance certification
OpenShell-backed isolation with policy hooksA 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 releasesA 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:

  1. Pulls or confirms dependencies (Node.js, OpenShell, NemoClaw CLI) as needed.
  2. Sets up managed vLLM (or the playbook’s current local inference path) on the Spark.
  3. Selects an installer-recommended default local model and a starter policy / sandbox profile.
  4. 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-smi and docker info before 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.

LayerProtectsCurrent mutability
FilesystemReads/writes outside allowed paths and protected runtime stateRequires sandbox recreation
NetworkUnauthorized outbound connections and data exfiltrationHot-reloadable through policy changes or operator approval
ProcessPrivilege escalation, fork bombs, and dangerous syscallsRequires sandbox recreation
InferenceCredential exposure and unauthorized model accessChangeable 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”

ChoiceWhen it fits
OpenClaw (default)You want a multi-channel gateway UX; Control UI / channels are part of the product story
HermesYou want a self-hosted runtime oriented to tools, memory, cron, and webhook-style integration (including n8n-style plumbing elsewhere in the stack)
Deep Agents CodeYou need the Tested, terminal-only LangChain path documented by NemoClaw and can accept the matrix’s remaining live-acceptance caveats
OpenShell aloneYou 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

FailureWhat goes wrongControl
Onboarding on a dirty hostAgent may inherit sensitive files via broad mountsClean test environment for first bring-up
Over-broad network allowPrompt injection → exfil via HTTPTight egress policy; approve new destinations deliberately
Unauthenticated local vLLMOther LAN users query your private modelBind privately; authenticate; firewall
Channel without pairing rulesStrangers trigger tool useOpenClaw/Hermes allowlists, pairing, mention rules
Treating alpha software as finishedBreakage or changed behavior on updatePin versions; read release/security notes; stage upgrades
No human gate on actionsAgent sends mail / merges / deletesRequire 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:

LayerExample
InferenceLocal vLLM (Express Install or hand-rolled) on Spark; later TP across two Sparks
AgentOpenClaw or Hermes inside OpenShell via NemoClaw
Automationn8n (or similar) on LAN calling Hermes/OpenClaw webhooks for deterministic plumbing
HumansApproval 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)

  1. Update DGX OS; confirm nvidia-smi and Docker GPU access.
  2. Follow Express Install on the Spark playbook; record the installer-selected model id and policy profile.
  3. Use Web UI / TUI only with non-sensitive prompts until filesystem and network policies are reviewed.
  4. Add one channel or one internal HTTP tool, not five.
  5. 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.
  6. 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.

Read next

Continue through the same learning path with the next practical articles.