NemoClaw Architecture & OpenShell Runtime
Last updated: April 1, 2026 · 12 min read
Architecture Overview — NemoClaw
NemoClaw implements five stacked security layers between the OpenClaw agent and the host infrastructure. At the foundation is NVIDIA's OpenShell secure runtime, which acts as a policy enforcement broker. Each layer — sandboxed execution, network egress control, minimal-privilege access, privacy routing, and intent verification — independently addresses a distinct attack surface in autonomous agent deployments.
The OpenShell Runtime
OpenShell is the policy enforcement kernel of NemoClaw. It is not a user-facing interface but an internal runtime that brokers every operation between the OpenClaw agent and the underlying system. Think of it as a security-focused virtual machine monitor — one that operates at the level of AI agent actions rather than CPU instructions.
OpenShell is initialized with an operator-supplied YAML policy file at agent startup. This policy file defines the complete capability envelope the agent is permitted to operate within. The policy is immutable at runtime — it cannot be modified by the agent itself, only by an operator with the appropriate credentials outside the agent session.
# Example NemoClaw operator policy (operator.yaml)
runtime: openShell
version: "1.0"
filesystem:
read: ["/home/user/project", "/tmp/nemoclaw"]
write: ["/tmp/nemoclaw/output"]
deny: ["/etc", "/root", "/home/user/.ssh"]
network:
egress:
allowlist:
- "api.openai.com"
- "integrate.api.nvidia.com"
block_all_others: true
shell:
allowed_commands: ["git", "python3", "node", "npm"]
deny_patterns: ["rm -rf", "curl * | bash", "wget * -O- | sh"]
privacy:
pii_stripping: enabled
redact_fields: [EMAIL, PHONE, SSN, API_KEY]
intent:
deny_classes: [CREDENTIAL_ACCESS, PERSISTENCE, LATERAL_MOVEMENT]Every proposed agent action is intercepted by OpenShell before execution. The runtime runs a series of checks in sequence: filesystem scope, network destination, command allowlist, PII scan, and intent classification. Only actions that pass all five checks are executed. Failed checks are logged and optionally surfaced to the operator dashboard.
Five-Layer Security Stack — Detailed Breakdown
Layer 1: Sandboxed Execution
Landlock LSM + seccomp-bpf
- •Each agent instance runs inside an isolated container with Landlock LSM rules restricting file system access to explicitly whitelisted paths.
- •Seccomp-bpf Berkeley Packet Filter profiles restrict the set of Linux system calls the agent process is permitted to invoke — blocking dangerous syscalls like ptrace, execve to unauthorized binaries, and raw socket creation.
- •Container namespacing ensures that PID, network, mount, and user namespaces are isolated per agent, preventing one agent from inspecting or influencing the memory space of another.
- •This layer addresses the most fundamental risk: direct access to the host file system or to adjacent agent processes running in the same environment.
Layer 2: Network Egress Control
Allowlist-based firewall + DNS filtering
- •All outbound network connections from the agent container are blocked by default. Destinations must be explicitly listed in the operator policy YAML under the network.egress.allowlist field.
- •DNS resolution is routed through an internal resolver that validates queries against the approved domain list before forwarding. This prevents DNS tunneling exfiltration.
- •HTTPS inspection occurs at the container boundary — the operator can configure TLS interception to inspect the payload content of approved outbound connections for anomalous data patterns.
- •This layer directly addresses the most common data exfiltration attack: a compromised agent that attempts to POST sensitive data to attacker-controlled infrastructure.
Layer 3: Minimal-Privilege Access
Per-agent capability bitmask + RBAC
- •Each agent instance is assigned a capability bitmask at initialization time, derived from the operator policy file. Capabilities define exactly which file paths, shell commands, network destinations, and model APIs the agent may use.
- •Capabilities are not inherited between agents. If a multi-agent system spawns a sub-agent, the sub-agent receives only a subset of the parent agent's capabilities, never the same or greater set.
- •This prevents lateral movement attacks: a compromised child agent cannot escalate to the capability level of the parent session even if it successfully exploits a vulnerability in the parent's logic.
- •Role-based access control rules can be optionally overlaid to map different agents to different organizational roles with pre-defined capability profiles.
Layer 4: Privacy Router
PII detection + field-level redaction
- •Before any data is transmitted to a cloud model API (OpenAI, Anthropic, NVIDIA NIM endpoints, etc.), it passes through the Privacy Router — a local inference service that identifies and strips personally identifiable information.
- •The PII detector is based on a fine-tuned NER model trained on common enterprise data patterns: names, emails, phone numbers, SSNs, credit card numbers, API keys, and private IP addresses.
- •Redacted fields are replaced with semantic placeholders (e.g., [PERSON_NAME], [API_KEY]) that preserve the grammatical structure of the context window without leaking real values.
- •This layer is particularly critical for organizations operating under GDPR, HIPAA, or CCPA, where transmitting PII to third-party cloud services without explicit consent creates regulatory liability.
Layer 5: Intent Verification
Policy engine + action classifier
- •Before each proposed action is executed, OpenShell's intent verification engine classifies the action semantically and compares it against the operator's defined intent policy.
- •The policy can specify both allowlisted intent classes (e.g., "file read in project directory") and denylisted intent classes (e.g., "credential access", "process injection", "persistence mechanisms").
- •This layer is the primary defense against prompt injection attacks: even if an attacker causes the agent to reason about a malicious action, the action must produce an in-policy intent classification for the execution to proceed.
- •Critically, this is also the current weakest layer: the intent verifier evaluates proposed actions, not the content of data returned by external tools — leaving a gap for indirect prompt injection through trusted data sources.
Architecture Summary Table
| Layer | Technology | Primary Threat Mitigated | Current Alpha Limitation |
|---|---|---|---|
| Sandboxed Execution | Landlock + seccomp-bpf | Host file system access, process injection | Container escape via kernel exploits |
| Network Egress | Allowlist firewall + DNS filter | Data exfiltration, C2 callbacks | Covert channel via allowed domains |
| Minimal Privilege | Capability bitmask + RBAC | Lateral movement, privilege escalation | Complex multi-agent policy management |
| Privacy Router | PII NER model + field redaction | Cloud PII leakage, GDPR/HIPAA exposure | False negatives on domain-specific PII |
| Intent Verification | Policy engine + action classifier | Direct prompt injection | Indirect injection via trusted data sources |
How NemoClaw Integrates with OpenClaw
NemoClaw ships as two components that together form the secure agent runtime. The first is an OpenClaw terminal plugin — a process-level interceptor that hooks into the OpenClaw subprocess execution path. The second is an OpenShell blueprint — the YAML-driven orchestration layer that configures all five security layers at startup.
When you connect an assistant using nemoclaw my-assistant connect, the plugin registers itself as the execution broker for that agent instance. All subsequent actions proposed by the agent — whether file reads, shell commands, web requests, or model API calls — flow through OpenShell before touching the host environment.
The design is intentionally transparent from the agent's perspective. The agent does not know it is running inside NemoClaw. It simply proposes actions and receives results. For in-policy actions, results return normally. For out-of-policy actions, the agent receives a configurable denial message that can be tuned to avoid revealing the details of the security boundary to a potential attacker controlling the agent's context.
Critical Architectural Gap: Indirect Prompt Injection
The intent verification layer evaluates what the agent proposes to do, not the content of data returned by external tools. This creates an unresolved attack surface:
If an attacker controls the output of a web page, API, or document that the agent queries as part of a legitimate task, they can embed instructions in that output. Those instructions enter the agent's reasoning chain as trusted context, rather than being evaluated as user instructions. The agent may then propose an "in-policy" action that achieves the attacker's goal — for example, writing specific content to a permitted file path that the attacker later reads.
Full security gap analysis and mitigations →