NVIDIA's NemoClaw is an open-source stack for running OpenClaw agents inside sandboxed containers with kernel-level isolation. It's good infrastructure engineering. But infrastructure isolation and agent security are different problems, and solving one doesn't solve the other.
What is NemoClaw?
NemoClaw combines the NVIDIA OpenShell runtime with container sandboxing to give OpenClaw agents a controlled execution environment. It enforces security through four layers: network filtering (blocks unauthorized egress), filesystem restrictions (agents can only touch /sandbox and /tmp), process isolation (no privilege escalation), and inference routing (all model calls go through NVIDIA's cloud gateway).
The architecture has four components: a TypeScript CLI plugin for lifecycle management, versioned Python blueprints for orchestration, the sandboxed OpenShell container itself, and an inference gateway that routes model calls through NVIDIA's API using their nemotron-3-super-120b-a12b model. Policies are declarative and hot-reloadable. Enforcement uses Linux primitives (Landlock, seccomp, and network namespaces), so it's at the kernel level, not the prompt level.
The lockdown paradox
NemoClaw's approach is to restrict what the agent can access at the OS level: block network egress, lock the filesystem, prevent privilege escalation. This is solid infrastructure security. But there's a tension at the core of it.
OpenClaw is designed to be a general-purpose autonomous agent with broad tool access. That's the whole point: it can write code, browse the web, manage files, call APIs. If you lock it down to /sandbox and /tmp with no outbound network access, you've neutered the thing you deployed it for. At that point, you might be better off just writing a script.
The real question isn't “how do we prevent the agent from doing anything dangerous?” It's “how do we let the agent do useful work while controlling what it's allowed to do, who authorized it, and whether its reasoning has been compromised?”
That's a different category of problem. And it's what Tropic is built for.
Three layers of agent security
Tropic approaches agent security through three layers that operate above the runtime:
1. Controls: what the agent can do
Configurable access to commands, tools, and system capabilities. Not a binary allow/deny at the OS level, but granular policies that let you say: “this agent can use the shell, but not rm -rf” or “this agent can make HTTP requests, but only to these domains.” Tropic's ALLOW / REQUIRE CONFIRM / DENY policies are enforced through the gateway before every tool call, and benchmarked against adversarial scenarios to verify they hold under pressure.
2. Authority: what permissions the agent has
The scope and permissions layer. What credentials does the agent have access to? What APIs can it authenticate against? What data can it read or write? Tropic manages this through encrypted credential stores (AES-256-GCM), per-instance secret sync, and scoped API key management. The agent gets exactly the access it needs. No ambient authority, no shared credentials between instances.
3. Influence: whether the agent's reasoning is intact
The hardest layer. Even with perfect controls and authority, an agent can be compromised through prompt injection, memory poisoning, or context manipulation. Tropic addresses this through continuous vulnerability scanning, determinism benchmarks that test policy adherence under adversarial conditions, and audit logging that captures every tool call with full input/output for forensic analysis. If the agent's behaviour drifts from expected patterns, you see it.
NemoClaw operates below all three of these layers. It secures the container, the box the agent runs in. Tropic secures the agent itself: what it does, what it's authorized to do, and whether it's been manipulated into doing something it shouldn't.
How they work together
| Layer | NemoClaw | Tropic |
|---|---|---|
| Runtime / infrastructure | Kernel sandbox (Landlock, seccomp) | Isolated VMs, provisioning, WireGuard VPN |
| Controls | Binary network/fs allow/deny | Granular tool/command policies with CONFIRM tier |
| Authority | - | Encrypted credentials, scoped API keys, per-instance secrets |
| Influence | - | Vulnerability scanning, determinism benchmarks, audit logs |
| Observability | - | Real-time tool call logs, live tail, forensic audit trail |
| Integrations | - | WhatsApp, Telegram, Google Sheets, skills marketplace |
| Cost management | - | Credit metering, per-model pricing, idle detection |
Running NemoClaw on Tropic gives you defense in depth: kernel-level container isolation from NemoClaw, plus configurable agent controls, authority management, and influence monitoring from Tropic. NemoClaw makes the box secure. Tropic makes the agent accountable.
Resource considerations
NemoClaw requires significantly more resources than vanilla OpenClaw: 4+ vCPUs, 16 GB RAM (8 GB minimum), and 40 GB storage for the Docker-based sandbox. On Tropic, NemoClaw instances use a larger VM class compared to the standard 2 vCPU / 2 GB configuration, which means higher credit consumption. The tradeoff is an additional hardware-enforced isolation layer that can't be prompt-injected away.
Getting started
NemoClaw is currently in alpha. Interfaces may change and there are rough edges. But the security model is sound. If you're deploying agents that handle sensitive data or operate in regulated environments, the combination of container-level isolation (NemoClaw) with agent-level security (Tropic) is the right approach.
Tropic supports NemoClaw.
Deploy NemoClaw-sandboxed OpenClaw agents with Tropic's configurable controls, authority management, influence monitoring, and full audit trail. Select “NemoClaw” as the runtime when provisioning a new cloud VM.