NVIDIA NemoClaw

NemoClaw does not replace your agent, it builds a wall around it. You keep OpenClaw, Hermes or LangChain Deep Agents exactly as you know them, and the trait that decides it daily is that nothing about the agent changes; isolation happens underneath, not in the prompt. What you give up is reach, since no browser tool ships with it.

Primary testing is Linux and DGX Spark, with macOS and Windows Subsystem for Linux documented as carrying limitations, so a mixed laptop fleet notices. Pick it when your agents already run on Linux and you would rather not write the isolation yourself. Pick OpenClaw alone when you want it unencumbered.

The weakness is the boundary. Protection holds where the managed entrypoints run, and the documentation lists bypassing them as out of scope, so a process avoiding that route is not covered by the controls the page spends its length describing. Encoded or obfuscated secrets are also out of scope, because the scanning is regular expressions and regular expressions do not decode.

Read the scope section before trusting the word sandbox in a meeting. What it does right: the key never enters the box. The agent addresses inference.local while the host holds the credential and upstream endpoint, so a compromised agent walks away with a hostname.

1. Filesystem confinement uses Landlock alongside container mounts, fixed when the sandbox is created, so a running agent cannot widen its own boundary without a restart. 2. Process limits come from the container runtime security context, with capabilities dropped at the entrypoint. 3. Egress passes a gateway operating at layer four or, with the protocol set to rest, inspecting HTTP, and each rule names which executables may reach that destination. 4. An unlisted destination is blocked and raised to the operator, whose approval survives only for that instance.

Enforcement below the agent rather than inside its instructions is the correct place for it.

This is demand generation wearing a reference architecture. The stack costs nothing, the supported platform table puts DGX Spark and DGX Station into an express path, and managed local inference is first-class. Every improvement in how safely agents run makes running them on this vendor's silicon easier to defend to a security team, which is the entire return.

Pricing power is not the question; durability is. Reference stacks from very large vendors get folded into a product line or quietly archived, and this one is labelled early preview. Likely path: absorption into the NeMo family rather than a standalone roadmap. Position: take the ideas, expect the name to change.

One host, one operator, and the vendor says so first. The overview declares an early-preview stack for a single trusted operator, explicitly not a hosted service, not a multi-tenant control plane and not an identity system, so there is no single sign-on, no user provisioning and no consolidated log across sixty engineers. Each machine is configured by whoever is sitting at it.

The dollar figure is zero and the dollar figure was never the constraint. Nothing runs headless in our pipelines, so it adds nothing to review. Setup wants Docker, Node 22.19 and administrator rights on every laptop. Not yet, and revisit when a fleet story ships.

Apache-2.0, and the knobs are where I can reach them. Sandboxes are registered in ~/.nemoclaw/sandboxes.json, rules go in through nemoclaw with a policy add subcommand, and the shipped preset names read like an honest inventory of where agents actually go: github, npm, pypi, huggingface, slack, jira, local-inference. NEMOCLAW_AGENT selects which runtime starts, and onboarding from a Dockerfile of mine replaces the managed image entirely.

Tools come through authenticated servers rather than raw keys pasted into agent config, which is the right trade even though a broker now decides what I can reach. It is stricter than what I would have built, and better than what I would have built.