Course: Master Course · Deep-Dive: DD-09 · Duration: 45 min · Prerequisites: Modules 0–12, DD-01–08
NVIDIA's hardened OpenClaw fork. NeMo Guardrails. OpenShell sandboxes. Policy enforced OUTSIDE the agent's reach. The governance reference.
| Metric | Value |
|---|---|
| Parent | OpenClaw (DD-07) — the platform harness |
| Author | NVIDIA |
| Architecture | OpenClaw core + governance layer + OpenShell sandbox |
| Governance | NeMo Guardrails (external policy evaluation) |
| Sandbox | OpenShell (agent never touches it directly) |
| Contribution | The governance-beneath-the-agent pattern, realized in production |
NemoClaw is the production proof that governance belongs beneath the agent, not inside it. Its entire contribution over OpenClaw (DD-07) is a governance layer the agent cannot reach: NeMo Guardrails evaluate every model call externally; OpenShell sandboxes the agent never touches directly. NemoClaw exists to fix the trust-architecture gap that made OpenClaw vulnerable to cross-channel injection (ASI01).
This deep-dive is weighted heavier than most. Every Course 2 attack question starts here. The reason: NemoClaw is the reference for what correct governance looks like, which means it is also the reference for what every other harness is missing. If you understand why NemoClaw puts policy outside the agent's reach, you understand the failure mode of every harness that does not.
Module 0.2 states the principle: if the agent can reach the enforcement layer, a compromised agent can disable it. NemoClaw is the architecture that takes this principle seriously and builds an entire product around it.
The naive approach to agent governance puts the policy check inside the agent — a tool the model calls ("check_policy(action)") or a system-prompt instruction ("do not perform dangerous actions"). Both are catastrophically weak:
NemoClaw's architecture rejects both. Policy is enforced in the call path between agent and world, in a layer the agent cannot bypass because the agent does not control it. The agent proposes an action; NeMo Guardrails evaluates it; the action either proceeds or is blocked. The agent has no API to disable, configure, or influence the guardrails. They are outside its reach by construction.
This is the governance move (Module 0.2) made concrete: the enforcement layer sits between the agent and the side effects it wants to produce, and the agent cannot touch the enforcement layer.
NemoClaw does not replace OpenClaw. It wraps it.
┌─────────────────────────────────────┐
│ Governance Layer │
│ (NeMo Guardrails — external) │
│ policy / classifiers / denial │
└──────────────┬──────────────────────┘
│ every model call + every action
▼
channel ──► OpenClaw core ──► model ──► proposed action ──► OpenShell sandbox
(Slack, (the loop, ▲ (execution)
Teams, tools, │ agent never
Telegram, memory) │ touches it
...) │
guardrails tag channel
content as untrusted BEFORE
the model sees it
The three layers, each outside the previous one's reach:
OpenClaw core (the agent): the loop, the 40+ channel integrations, the memory. This is DD-07's harness, largely intact. The agent reasons, proposes actions, calls tools.
NeMo Guardrails (the governance layer): sits between the agent and the world. Every model call and every proposed action passes through it. It runs input classifiers (is this channel content an injection attempt?), output classifiers (is this action permitted by policy?), and canonical policy rules (never exfiltrate credentials, never write outside the sandbox). The agent cannot reach this layer — it has no tool to call, no config to edit, no prompt to override. The guardrails are in the call path, not in the context.
OpenShell sandbox (the execution layer): where proposed actions actually run. Critically, the agent never touches OpenShell directly — actions go through the governed API, which forwards only policy-approved actions to the sandbox. The agent cannot escape to the sandbox because the agent does not have a path to the sandbox; it has a path to the governance layer, which has a path to the sandbox.
NeMo Guardrails implements three classes of check, each mapping to a Course 2 attack vector:
Input rail: channel-derived content is tagged as untrusted and scanned for injection before it reaches the model. This is the fix for OpenClaw's cross-channel injection gap (ASI01). A Slack message no longer enters context with the same trust status as an operator instruction.
Dialog rail: the model's responses are checked against policy before being acted upon or returned. A model that has been hijacked into producing a dangerous action is caught here, at the output boundary, regardless of how the hijack occurred.
Action rail: tool calls and side-effecting actions are validated against capability policy. This is Module 6's risk-tiered permission model realized externally — the agent proposes, the rail disposes.
The key architectural property: all three rails run outside the agent's trust boundary. The agent cannot disable an input rail by prompt injection because the rail runs before the model is called. It cannot bypass an action rail by reasoning around it because the rail runs after the model proposes. The guardrails bracket the agent.
| Module | Score | Key decision | vs OpenClaw (35) |
|---|---|---|---|
| 1 Loop | 4 | OpenClaw core, unchanged | = |
| 2 Tools | 4 | channel-aware, governed | = |
| 3 Context | 3 | channel-mixed, but inputs tagged | = |
| 4 Memory | 3 | platform-standard | = |
| 5 Sandbox | 4 | OpenShell (agent-governed access) | +2 |
| 6 Permission | 5 | external guardrails (the reference) | +3 |
| 7 Errors | 3 | standard | = |
| 8 State | 3 | session-per-channel | = |
| 9 Verification | 2 | limited | = |
| 10 Subagents | 3 | channel-routing, governed | = |
| 11 Observability | 3 | structured | = |
| 12 Prompt | 4 | ~8k, channel-aware | = |
| TOTAL | 39/60 | +4 |
The +4 comes almost entirely from the governance layer: +3 Module 6 (external guardrails, the highest score in the roster on permission), +2 Module 5 (OpenShell sandboxing), partially offset by scoring rounding. NemoClaw does not improve the agent — it improves the boundary around the agent. That is the entire point.
NemoClaw optimizes for governance integrity — policy enforced outside the agent's reach via NeMo Guardrails, fixing OpenClaw's trust-architecture gap. It inherits OpenClaw's channel breadth (40+) and adds the security layer that makes that breadth safe: the agent cannot reach the enforcement layer to disable it, because the enforcement layer sits in the call path, not in the context. Build on NemoClaw when you need OpenClaw's reach PLUS enterprise-grade governance; it is the production reference for governance done right, and the harness every Course 2 attack module is scored against.
NemoClaw is the production proof of Module 0.2's core principle: if the agent can reach the enforcement layer, a compromised agent can disable it. NeMo Guardrails sit between agent and world — the agent cannot reach them to disable them. Every Course 2 attack question starts here: understand why NemoClaw puts policy outside the agent's reach, and you understand the failure mode of every harness that puts policy inside it (system-prompt instructions, model-called policy tools). NemoClaw is also the reference fix for Hermes's (DD-08) memory-write poisoning surface — harness-managed writes are the same principle applied to memory.
# Deep-Dive DD-09 — NemoClaw: Governance Beneath the Agent
**Course**: Master Course · **Deep-Dive**: DD-09 · **Duration**: 45 min · **Prerequisites**: Modules 0–12, DD-01–08
> *NVIDIA's hardened OpenClaw fork. NeMo Guardrails. OpenShell sandboxes. Policy enforced OUTSIDE the agent's reach. The governance reference.*
---
## The Subject
| Metric | Value |
| --- | --- |
| Parent | OpenClaw (DD-07) — the platform harness |
| Author | NVIDIA |
| Architecture | OpenClaw core + governance layer + OpenShell sandbox |
| Governance | NeMo Guardrails (external policy evaluation) |
| Sandbox | OpenShell (agent never touches it directly) |
| Contribution | The governance-beneath-the-agent pattern, realized in production |
NemoClaw is the production proof that **governance belongs beneath the agent, not inside it.** Its entire contribution over OpenClaw (DD-07) is a governance layer the agent cannot reach: NeMo Guardrails evaluate every model call externally; OpenShell sandboxes the agent never touches directly. NemoClaw exists to fix the trust-architecture gap that made OpenClaw vulnerable to cross-channel injection (ASI01).
This deep-dive is weighted heavier than most. **Every Course 2 attack question starts here.** The reason: NemoClaw is the reference for what correct governance looks like, which means it is also the reference for what every other harness is missing. If you understand why NemoClaw puts policy outside the agent's reach, you understand the failure mode of every harness that does not.
## The Core Principle — Governance Outside the Reach
Module 0.2 states the principle: **if the agent can reach the enforcement layer, a compromised agent can disable it.** NemoClaw is the architecture that takes this principle seriously and builds an entire product around it.
The naive approach to agent governance puts the policy check inside the agent — a tool the model calls ("check_policy(action)") or a system-prompt instruction ("do not perform dangerous actions"). Both are catastrophically weak:
- A **policy tool** the model calls is just another tool. A compromised agent (via injection, ASI01) can simply not call it, or call it with sanitized arguments while performing the real action elsewhere. The guard is inside the trust boundary of the thing it guards.
- A **system-prompt instruction** is a request, not a constraint. The model can ignore it. Injection can override it. There is no enforcement — only persuasion.
NemoClaw's architecture rejects both. Policy is enforced **in the call path between agent and world**, in a layer the agent cannot bypass because the agent does not control it. The agent proposes an action; NeMo Guardrails evaluates it; the action either proceeds or is blocked. The agent has no API to disable, configure, or influence the guardrails. They are outside its reach by construction.
This is the governance move (Module 0.2) made concrete: the enforcement layer sits between the agent and the side effects it wants to produce, and the agent cannot touch the enforcement layer.
## Architecture — How NemoClaw Wraps OpenClaw
NemoClaw does not replace OpenClaw. It wraps it.
```
┌─────────────────────────────────────┐
│ Governance Layer │
│ (NeMo Guardrails — external) │
│ policy / classifiers / denial │
└──────────────┬──────────────────────┘
│ every model call + every action
▼
channel ──► OpenClaw core ──► model ──► proposed action ──► OpenShell sandbox
(Slack, (the loop, ▲ (execution)
Teams, tools, │ agent never
Telegram, memory) │ touches it
...) │
guardrails tag channel
content as untrusted BEFORE
the model sees it
```
**The three layers, each outside the previous one's reach:**
1. **OpenClaw core** (the agent): the loop, the 40+ channel integrations, the memory. This is DD-07's harness, largely intact. The agent reasons, proposes actions, calls tools.
2. **NeMo Guardrails** (the governance layer): sits between the agent and the world. Every model call and every proposed action passes through it. It runs input classifiers (is this channel content an injection attempt?), output classifiers (is this action permitted by policy?), and canonical policy rules (never exfiltrate credentials, never write outside the sandbox). The agent cannot reach this layer — it has no tool to call, no config to edit, no prompt to override. The guardrails are in the call path, not in the context.
3. **OpenShell sandbox** (the execution layer): where proposed actions actually run. Critically, the agent never touches OpenShell directly — actions go through the governed API, which forwards only policy-approved actions to the sandbox. The agent cannot escape to the sandbox because the agent does not have a path to the sandbox; it has a path to the governance layer, which has a path to the sandbox.
## The Policy / Governance Layer in Depth
NeMo Guardrails implements three classes of check, each mapping to a Course 2 attack vector:
- **Input rail**: channel-derived content is tagged as untrusted and scanned for injection before it reaches the model. This is the fix for OpenClaw's cross-channel injection gap (ASI01). A Slack message no longer enters context with the same trust status as an operator instruction.
- **Dialog rail**: the model's responses are checked against policy before being acted upon or returned. A model that has been hijacked into producing a dangerous action is caught here, at the output boundary, regardless of how the hijack occurred.
- **Action rail**: tool calls and side-effecting actions are validated against capability policy. This is Module 6's risk-tiered permission model realized externally — the agent proposes, the rail disposes.
The key architectural property: **all three rails run outside the agent's trust boundary.** The agent cannot disable an input rail by prompt injection because the rail runs before the model is called. It cannot bypass an action rail by reasoning around it because the rail runs after the model proposes. The guardrails bracket the agent.
## Score: 39/60 (+4 vs OpenClaw's 35)
| Module | Score | Key decision | vs OpenClaw (35) |
| --- | --- | --- | --- |
| 1 Loop | 4 | OpenClaw core, unchanged | = |
| 2 Tools | 4 | channel-aware, governed | = |
| 3 Context | 3 | channel-mixed, but inputs tagged | = |
| 4 Memory | 3 | platform-standard | = |
| 5 Sandbox | 4 | OpenShell (agent-governed access) | **+2** |
| 6 Permission | 5 | external guardrails (the reference) | **+3** |
| 7 Errors | 3 | standard | = |
| 8 State | 3 | session-per-channel | = |
| 9 Verification | 2 | limited | = |
| 10 Subagents | 3 | channel-routing, governed | = |
| 11 Observability | 3 | structured | = |
| 12 Prompt | 4 | ~8k, channel-aware | = |
| **TOTAL** | **39/60** | | **+4** |
The +4 comes almost entirely from the governance layer: +3 Module 6 (external guardrails, the highest score in the roster on permission), +2 Module 5 (OpenShell sandboxing), partially offset by scoring rounding. NemoClaw does not improve the agent — it improves the boundary around the agent. That is the entire point.
### Architect's Verdict
> *NemoClaw optimizes for governance integrity — policy enforced outside the agent's reach via NeMo Guardrails, fixing OpenClaw's trust-architecture gap. It inherits OpenClaw's channel breadth (40+) and adds the security layer that makes that breadth safe: the agent cannot reach the enforcement layer to disable it, because the enforcement layer sits in the call path, not in the context. Build on NemoClaw when you need OpenClaw's reach PLUS enterprise-grade governance; it is the production reference for governance done right, and the harness every Course 2 attack module is scored against.*
### MLSecOps Relevance
> *NemoClaw is the production proof of Module 0.2's core principle: if the agent can reach the enforcement layer, a compromised agent can disable it. NeMo Guardrails sit between agent and world — the agent cannot reach them to disable them. Every Course 2 attack question starts here: understand why NemoClaw puts policy outside the agent's reach, and you understand the failure mode of every harness that puts policy inside it (system-prompt instructions, model-called policy tools). NemoClaw is also the reference fix for Hermes's (DD-08) memory-write poisoning surface — harness-managed writes are the same principle applied to memory.*
### 3 things NemoClaw does better
1. **Governance-beneath-the-agent**: the architectural pattern the entire course's security model depends on. Policy sits in the call path, outside the agent's trust boundary. No other harness in the roster realizes this pattern as completely.
2. **Trust-boundary fix**: NeMo Guardrails tag channel content as untrusted before the model sees it — the direct fix for OpenClaw's cross-channel injection gap (ASI01).
3. **OpenShell sandboxing**: the agent never touches the sandbox directly; it goes through the governed API. Blast radius is contained at the governance boundary, not at the host.
### 3 things to fix
1. **Latency**: the governance layer adds a check to every call (input rail, dialog rail, action rail). This is the inherent cost of external enforcement — you cannot make policy free without making it optional, and optional policy is not policy.
2. **Inherited legibility problem**: NemoClaw inherits OpenClaw's large codebase, so reading the whole thing is harder than reading Pi (DD-01) or Tau (DD-21). The governance layer is the legible part; the core is not.
3. **Policy maintenance burden**: the governance policy itself must be maintained — every new channel or tool requires a new policy rule. A policy gap is a vulnerability gap. This is the operational tax of doing governance right.
---
## References
1. **NemoClaw source** — the governance reference.
2. **Module 0.2** — the governance move; the governance-beneath-the-agent principle; the lineage map (OpenClaw → NemoClaw, Scout).
3. **Module 2.4** — untrusted-content tagging; the defense OpenClaw lacked and NemoClaw provides.
4. **Module 6** — risk-tiered permission; NemoClaw realizes it externally (the highest-scoring permission model in the roster).
5. **DD-07 (OpenClaw)** — the parent whose trust-architecture deficiency NemoClaw fixes.
6. **DD-08 (Hermes)** — whose memory-write surface NemoClaw's harness-managed-write pattern would fix (governance applied to memory, not just channels).
7. **DD-21 (Tau)** — the anti-NemoClaw: a harness with zero defenses, used as the attack lab target in Course 2B.
8. **Course 2** — every attack module starts from the question "does this harness enforce governance outside the agent's reach?" NemoClaw is the yes; most harnesses are the no.