NVIDIA NemoClaw: a security layer for autonomous AI agents
NVIDIA NemoClaw is an open-source stack that adds enterprise security controls to OpenClaw, an autonomous AI agent framework. Jensen Huang described OpenClaw as potentially "the largest, most successful open-source project in history," and NemoClaw is NVIDIA's answer to the obvious follow-up question: how do you deploy these agents safely in a production environment?
The security problem with autonomous agents
OpenClaw agents can be given a goal and will figure out and execute the steps to achieve it independently, including reading files, writing code, making network requests, and calling external APIs. That autonomy is what makes them powerful. It is also what makes them difficult to trust in any environment where security, data privacy, or system integrity matters.
NemoClaw addresses this by wrapping the agent in a safety sandbox with a strict, default-deny policy engine. Every action the agent attempts, from reading a file path to reaching an external endpoint, is intercepted and checked against explicit policies before it executes.
Architecture
The sandbox
The sandbox is the central component of NemoClaw's security model.
It contains three sub-components: a Sandbox Supervisor that acts as the policy engine, a monitored Tool Generation and Code Execution environment where the agent can create and run scripts, and the Agent itself. Any action that escapes the sandbox boundaries is blocked before it reaches the host system.
OpenShell and blueprints
NVIDIA OpenShell is the secure runtime that hosts the OpenClaw agent. The agent's deployment is defined and orchestrated by a Python script called a blueprint, which specifies the sandbox configuration, inference model setup, and security policies. The blueprint-driven approach makes deployments repeatable and auditable.
Policy enforcement
Policies are declarative and default-deny. If the agent attempts any action not explicitly permitted, such as accessing a network endpoint not covered by an existing policy, OpenShell intercepts the request and surfaces it in a Terminal User Interface (TUI) where a human operator can approve or deny it.
This human-in-the-loop design gives operators granular control. The agent remains productive but only within the boundaries its supervisors have explicitly defined and approved.
Setup
Prerequisites
A working NemoClaw instance requires an NVIDIA Developer account for API key access, and either a local machine with NVIDIA drivers, CUDA, and Docker installed or a cloud GPU environment. The path of least resistance is Brev.dev, which NVIDIA uses as its preferred launch platform.
Provisioning the instance
From the NVIDIA NemoClaw page, clicking Try It Now redirects to a pre-configured launch page on Brev. New Brev accounts include free credits sufficient to run this tutorial.
Leave the default configuration and click Deploy Launchable. Provisioning takes several minutes. Once the instance is running, connect to it using the brev shell command shown on the instance page:
Installing NemoClaw
Run the installation script:
A common failure at this step is the OpenShell CLI not installing from GitHub releases.
The fix is to install the CLI manually using the quick-install command from the OpenShell GitHub releases page:
After completing this, re-run the nemoclaw.sh script and the installation proceeds.
Configuration wizard
The installation script launches a guided wizard. It runs preflight checks, confirms Docker is running, and prompts for a sandbox name (the default my-assistant is fine). It then asks for an NVIDIA API key, which can be generated at build.nvidia.com/settings/api-keys.
The wizard offers a list of inference models. NVIDIA's recommended choice is Nemotron S Super 120B. After selecting a model, the wizard offers to apply policy presets for common services like pypi, npm, and telegram. Accepting these presets pre-approves network access to their registries and APIs, reducing the number of manual approvals needed later.
Running the agent
Connecting to Telegram
NemoClaw includes a Telegram bridge for interacting with the agent through a chat interface. Export the bot token from BotFather as an environment variable:
Start all services including the Telegram bridge:
A series of green [services] status lines confirms everything is running.
The OpenShell TUI
In a second terminal connected to the Brev instance, launch the OpenShell monitoring interface:
This shows the status of active sandboxes and surfaces any pending policy requests. When the agent attempts a network call not covered by an existing policy, it appears here as pending. Press a to approve or r to reject.
Practical example: Hacker News fetching via cron
Asking the agent via Telegram to fetch the latest Hacker News articles every three minutes and forward them triggers a flood of new policy requests in the OpenShell TUI. Each network endpoint the agent needs, including the Hacker News API and any dependencies, must be approved individually. After approvals, the agent may need to be re-prompted in Telegram before it retries the now-permitted calls.
The agent eventually sets up the cron job and begins sending articles. The process, however, requires sustained manual supervision.
Assessment
What works
The sandboxing architecture is thorough. The default-deny policy system, declarative approvals, and the ability to inspect every action before execution provide a level of control that consumer AI tools do not offer. For any organization where the security of an autonomous agent is a genuine constraint, this approach is meaningful.
What needs work
The current implementation has significant rough edges. Installation requires manual intervention. The gateway service and Telegram bridge both encountered failures during testing that needed workarounds. The inference speed with the Nemotron model was slow, with some responses taking minutes. Most significantly, the manual approval requirement for every new network endpoint means the operator is effectively supervising every step the agent takes, which diminishes the value of having an autonomous agent.
Policy presets help, but any task involving novel endpoints requires repeated round-trips between the Telegram chat and the TUI. This friction will need to be reduced substantially for NemoClaw to be practical for complex, multi-step tasks.
Final thoughts
NemoClaw's security model is its strongest contribution. The framework demonstrates a credible approach to making autonomous agents deployable in environments that require audit trails, access controls, and human oversight. The blueprint system and declarative policies are well-designed foundations.
The platform is early. Stability, performance, and the operator experience all need refinement before it is ready for production use beyond developer experimentation. For teams evaluating enterprise AI agent security today, NemoClaw is worth watching and testing, but it is not yet ready to be relied upon.
Documentation and deployment instructions are available on the NVIDIA NemoClaw page.
This work is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International License.