If you are running OpenClaw agents inside Docker containers and calling that your security strategy, you are solving the wrong problem.
Containers isolate processes from the host. Agent-specific sandboxing - like what NVIDIA's NemoClaw provides through OpenShell - controls what the agent does inside the container: which endpoints it can reach, which files it can touch, which models it can call, and what happens when it tries to go off-script. These are fundamentally different layers of defense, and conflating them creates a false sense of security that gets more dangerous as your agents become more autonomous.
The Container Assumption
Most teams building with OpenClaw today follow a predictable pattern. They spin up a Docker container, mount the necessary volumes, expose a port, and let the agent run. Docker gives them namespace isolation, cgroup resource limits, and filesystem layering. This feels secure. The agent cannot escape the container. The host kernel is protected.
Except that is not where the real risk lives.
An autonomous AI agent's threat model is fundamentally different from a traditional application's. A web server inside Docker needs to be prevented from accessing the host filesystem or escalating privileges. An AI agent inside Docker needs all of that, plus constraints on behaviors that Docker was never designed to manage:
- Arbitrary outbound network requests to any internet endpoint
- Uncontrolled inference calls to any LLM provider the agent discovers
- Filesystem writes that are technically within the container but outside the agent's intended scope
- Tool invocations that chain together in ways no one anticipated
- Credential usage that expands beyond the original intent
Docker addresses exactly zero of these. A containerized OpenClaw agent has the same unrestricted network access, the same ability to call any inference endpoint, and the same filesystem freedom inside its container as an agent running on bare metal. The container boundary is real, but it is orthogonal to the actual risks of autonomous agent behavior.
What NemoClaw's Sandboxing Actually Does Differently
NemoClaw, through NVIDIA's OpenShell runtime, adds four policy layers that operate inside the container, constraining the agent's behavior at the application level rather than the infrastructure level.
1 Network Egress Policy
This is the most consequential difference. NemoClaw starts with a strict baseline: the agent can reach the OpenShell gateway and its configured inference endpoint. Everything else is blocked by default.
When the agent attempts to reach an unlisted host, OpenShell intercepts the request, blocks it, and surfaces it in a Terminal UI (TUI) for the human operator to approve or deny. Approved endpoints persist for the current session but are not written to the baseline policy.
This is not a firewall rule. It is an agent-aware, interactive approval flow. The operator sees which binary initiated the request, the destination host and port, and the HTTP method. They decide in real time whether to allow it.
Docker's network isolation, by contrast, is binary: the container either has network access or it does not. There is no concept of per-destination approval, no operator-in-the-loop, and no awareness of what the agent is trying to do or why.
2 Filesystem Confinement
NemoClaw restricts the agent to /sandbox and /tmp for read-write access, with system paths read-only. This is enforced via Landlock LSM, locked at sandbox creation time and not modifiable at runtime.
Docker volumes provide filesystem isolation from the host, but within the container, the agent has full access to everything. NemoClaw adds the inner boundary that Docker's volume mounts do not provide.
3 Seccomp System Call Filtering
NemoClaw applies a seccomp profile that blocks privilege escalation and dangerous syscalls. Docker also supports seccomp profiles, so this layer is similar in both approaches. The difference is that NemoClaw applies an agent-optimized profile by default, while Docker's default profile is designed for general-purpose containers.
4 Inference Routing
This is the layer that has no Docker equivalent whatsoever. Every inference call from the agent is intercepted by OpenShell and routed through the gateway to the configured provider. The agent never talks to an LLM directly.
This means you control which models the agent can use, you can switch models at runtime without restarting the sandbox, and you have a single audit point for every inference call. With Docker alone, the agent can call any API endpoint it has credentials for, including LLM providers you have not authorized.
Side-by-Side Comparison
| Security Concern | Docker Container Infrastructure isolation | NemoClaw Sandbox Agent-specific sandboxing |
|---|---|---|
| Host isolation | ✓ Yes - namespace + cgroup | ✓ Yes - inherits container isolation |
| Network egress control | ✕ Binary: on or off. No per-destination policy | ✓ Declarative per-host policy with interactive operator approval |
| Inference routing | ✕ None. Agent calls any LLM endpoint | ✓ All calls intercepted, routed through gateway, hot-swappable |
| Inner filesystem limits | ✕ None within the container | ✓ Landlock LSM: /sandbox and /tmp only |
| Syscall filtering | Default seccomp (generic) | ✓ Agent-optimized seccomp (privilege escalation blocked) |
| Operator visibility | ✕ Container logs only | ✓ TUI with live network activity, blocked requests, inference status |
| Policy hot-reload | ✕ Requires container restart | ✓ Network + inference policies hot-reloadable at runtime |
| Audit trail | Application-level logging (if implemented) | ✓ Infrastructure-level: every network request, every inference call logged |
Where NemoClaw Falls Short (Today)
NemoClaw is alpha software, announced at GTC 2026 in March. Before you treat it as your production security layer, consider the following:
Multi-tenant governance
NemoClaw operates at the single-sandbox level. If you have multiple teams, multiple agents, and multiple environments, you need a governance layer above NemoClaw that manages policies, permissions, and audit across tenants. NemoClaw does not provide this.
Tool-level policy
NemoClaw controls network egress and inference routing, but it does not have granular tool governance - the ability to allow, block, rate-limit, or require approval for specific tool calls based on tenant, team, risk level, or data sensitivity.
PII and content safety
NemoClaw does not scan agent inputs or outputs for PII, prompt injection, content safety violations, or grounding issues. These require dedicated guardrail engines with trained models, not network-level policies.
Production maturity
The project has active bugs on WSL2, piped installs can skip prompts, and the plugin commands are explicitly described as under active development.
The Bigger Picture: Layers of Agent Security
The honest answer is that neither Docker nor NemoClaw alone is sufficient for production enterprise agent deployments. What you actually need is a stack:
The Enterprise Agent Security Stack
NemoClaw is a welcome addition at layer two. It solves real problems that Docker cannot. But enterprises that stop at sandboxing without addressing governance, guardrails, and observability will find that their agents are confined but not governed - and confinement without governance is only half the story.
About Katonic AI
Katonic 7.0 is an enterprise AI platform built for organizations that need autonomous AI agents with full governance, security, and data sovereignty. The platform deploys entirely on your infrastructure with zero data egress. It includes 8 guardrail types powered by NVIDIA NeMo NIM models, infrastructure-layer tool governance with human-in-the-loop approvals and PII scanning, permission-aware knowledge retrieval across 50+ enterprise connectors, and complete cost attribution from day one.
To learn how Katonic approaches enterprise agent security, visit katonic.ai
