NVIDIA GTC 2026 took place this week, and Jensen Huang made plenty of announcements on stage, as usual. The one that caught my attention was NemoClaw. It reached 325 points on Hacker News and sparked quite a discussion. I took a look, and my first reaction was: finally, someone is doing this.

You probably know OpenClaw: an open-source AI assistant that runs on your own computer. It connects to everything from WhatsApp and Slack to Telegram and Discord. Its GitHub stars grew from 9,000 to 188,000 in 60 days. But it has a problem. A big one.

Security.

OpenClaw’s Problem #

OpenClaw is fairly unrestricted by default. The agent can access the file system, connect to the network, and launch processes. That might be acceptable for an individual, but consider a company environment. Your AI agent accesses customer data, calls APIs, and creates files, without a serious security layer around those actions.

There are 500,000 lines of code and more than 70 dependencies. A vulnerability in any of them could compromise the agent. Prompt injection could redirect its behavior. With broad access to the system already available, the potential damage is considerable.

This is where NVIDIA stepped in.

What Does NemoClaw Add? #

NemoClaw is a security and management layer around OpenClaw. It wraps OpenClaw rather than replacing it. Think of the way Kubernetes manages containers.

It has three main components that operate independently.

Sandbox: Deny Everything Unless It Is Allowed

The conventional approach often allows everything and blocks dangerous operations. NemoClaw takes the opposite approach: deny by default. Nothing is allowed until you explicitly permit it.

Network access? Only allowlisted domains. File-system access? Only /sandbox and /tmp. Running processes? A restricted set of binaries. Privilege escalation? Blocked entirely.

This can feel restrictive initially, but it is the right direction for security. You enable what you need, while everything else stays closed.

Policy Engine: Security the Agent Cannot Change

This is, to me, NemoClaw’s smartest feature. The policy engine runs as a separate process outside the agent’s address space. Even if the agent is fully compromised, it cannot change the security policies—or even see them.

In a conventional security layer, an application may control its own rules. But if the application is compromised, those rules can be compromised too. NemoClaw keeps the rules outside the application. Think of the principle behind SELinux: a process cannot simply remove the restrictions imposed on it.

Privacy Router: Where Does Sensitive Data Go?

The third component may be the most practical. It intercepts inference calls and routes them according to policies defined by the user.

Imagine working at a healthcare company. You could route queries containing patient data to a local Nemotron model, while sending queries that need more complex analysis to a cloud model from OpenAI, Anthropic, or another provider. Sensitive information stays inside the network, while cloud models remain available where appropriate.

Supported local models include Nemotron 3 Nano 4B, which runs on consumer RTX GPUs, Nemotron 3 Super 120B, Qwen 3.5, and Mistral Small 4.

Surprisingly Simple Setup #

One command:

Terminal window
curl -fsSL https://www.nvidia.com/nemoclaw.sh | bash

This launches an onboarding wizard that creates the sandbox, configures inference, and applies security policies. Then connect with:

Terminal window
nemoclaw my-assistant connect

Inside the sandbox, you can open the OpenClaw TUI or send messages directly from the CLI.

Are There Any Problems? #

Of course. A few things stand out.

It is in alpha. NVIDIA explicitly warns about rough edges. It is early for production use, with no independent security audit or published benchmarks yet.

It requires NVIDIA hardware. The full feature set needs an NVIDIA GPU. Infrastructure running on AMD, Apple Silicon, or CPUs alone cannot use the local-model features. That creates a significant vendor lock-in risk.

It does not provide application-layer security. NemoClaw protects infrastructure, but it does not address application-level risks such as prompt injection, skill supply-chain attacks, or manipulation of an agent’s reasoning. Using NemoClaw does not make everything safe; defense in depth is still necessary.

It adds complexity. OpenClaw is already a complex system. NemoClaw adds another layer, and every layer is another potential point of failure.

OpenClaw, NemoClaw, NanoClaw: What Is the Difference? #

The names can get confusing. Here is a quick summary.

OpenClaw on its own can be enough for an individual developer who accepts the security risks.

NemoClaw targets enterprise teams that need audit trails, compliance, and data sovereignty. But it requires NVIDIA hardware and is still in alpha.

NanoClaw is for people who want simpler, container-based isolation without NemoClaw’s complexity. It runs on any hardware.

My Take #

NemoClaw is trying to solve the right problem at the right architectural layer: a security boundary outside the agent, beyond the agent’s control. That is a sound approach.

But it is early. An alpha-stage security product is a little ironic. The NVIDIA hardware dependency also sits awkwardly with the spirit of open source. Part of OpenClaw’s appeal was that it could run anywhere; NemoClaw narrows that.

Still, as AI agents become part of real business processes, demand for these security layers will grow. What is in alpha today could become standard in six months.

At GTC, Jensen said every organization should have an OpenClaw strategy. I would put it differently: every organization should have an agent-security strategy. NemoClaw could be part of it, but it is not enough on its own.

If you want to try it, visit the GitHub repository. It uses the Apache 2.0 license and welcomes community contributions. For now, though, I would keep it in a development environment.