# Deep-Dive DD-09 — NemoClaw: The Governance-Focused Harness

**Course**: Master Course
**Deep-Dive**: DD-09
**Duration**: 45 minutes
**Level**: Senior Engineer and above
**Prerequisites**: Modules 0–12; DD-01–08 (the harness roster to this point)

> *NVIDIA's hardened OpenClaw fork. NeMo Guardrails. OpenShell sandboxes. Policy enforced OUTSIDE the agent's reach. The governance reference. The anti-Tau.*

---

## Learning Objectives

After this deep-dive, you will be able to:

1. State NemoClaw's defining principle — governance lives beneath the agent, outside its reach — and explain why this is the load-bearing security property of the entire course.
2. Distinguish the three layers (OpenClaw core, NeMo Guardrails, OpenShell) and explain why each must be outside the previous one's trust boundary for the governance pattern to hold.
3. Score NemoClaw 39/60 and explain why the +4 over OpenClaw comes almost entirely from the governance layer (+3 Module 6, +2 Module 5), not from any improvement to the agent itself.
4. Construct the NemoClaw-vs-Tau contrast: NemoClaw is the harness with all the controls; Tau (DD-21) is the harness with zero defenses. Explain why this pairing is load-bearing for Course 2B — every attack module is scored against the question "does this harness enforce governance outside the agent's reach?"
5. Articulate the costs of external governance (latency, policy maintenance, inherited codebase legibility) and why they are the inherent tax of doing governance right rather than an avoidable overhead.

---

## 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 |
| Score | 39/60 (+4 vs OpenClaw's 35) |

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 — and you understand why Tau (DD-21), the harness with zero defenses, is the attack lab target rather than a production candidate.

### The anti-Tau pairing

NemoClaw and Tau are the two poles of the governance axis, and the pairing is load-bearing for Course 2B. NemoClaw is the harness with all the controls: external guardrails, sandbox isolation, untrusted-tagging, harness-managed writes — every defense the course teaches, realized in one product. Tau is the harness with zero defenses: no guardrails, no sandbox, no tagging, model-initiated everything — the deliberately vulnerable harness used as the attack lab target in 2B.

The pairing teaches the central lesson of the security course: governance is not a feature you add; it is an architectural property of where the enforcement layer sits relative to the agent. NemoClaw puts it outside; Tau does not have one. Every other harness in the roster sits somewhere between these two poles. Read this deep-dive alongside DD-21 (Tau) — the contrast is the curriculum.

---

## 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. Tau is the negative proof: with no enforcement layer at all, every attack in Course 2B succeeds trivially.

---

## Architecture — How NemoClaw Wraps OpenClaw

NemoClaw does not replace OpenClaw. It wraps 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 nesting is the property. Each layer is outside the previous one's trust boundary. The agent cannot reach the guardrails; the guardrails cannot be bypassed to reach the sandbox. This is what "governance beneath the agent" means architecturally — not a layer the agent calls, but a layer the agent sits on top of and cannot see beneath.

---

## 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. Tau has no input rail — every channel input enters the model's context with full trust.

- **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. Tau has no dialog rail — the model's output is acted upon directly.

- **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. Tau has no action rail — the agent's proposed actions execute with no external validation.

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. Tau brackets nothing.

### The NemoClaw-as-fix-for-Hermes connection

NemoClaw's governance pattern is also the reference fix for Hermes's (DD-08) memory-write poisoning surface. Harness-managed writes — model proposes, harness validates — are the same principle (governance outside the agent's reach) applied to the memory write path rather than the channel/action path. The write gate is the input rail for persistent storage. Hermes omits it; NemoClaw provides the template for adding it.

---

## 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. The agent is OpenClaw's agent; the boundary is new.

Read the 39/60 against Tau's near-zero effective security score. The difference is not the agent — both have an agent that reasons and proposes. The difference is the boundary: NemoClaw wraps the agent in three external layers; Tau wraps it in nothing.

### 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.*

### Three 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. Tau realizes its inverse — no governance at all.
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.

### Three 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.

---

## The NemoClaw-vs-Tau Contrast (load-bearing for Course 2B)

This pairing is the curriculum. NemoClaw and Tau are the two extremes of the governance axis, and every attack module in Course 2B is scored against the question they pose.

| Property | NemoClaw (DD-09) | Tau (DD-21) |
| --- | --- | --- |
| Input rail | Yes — channel content tagged untrusted before model | No — all input enters context with full trust |
| Dialog rail | Yes — output checked against policy before action | No — model output acted upon directly |
| Action rail | Yes — tool calls validated against capability policy | No — agent actions execute with no validation |
| Sandbox | OpenShell — agent never touches execution directly | None — agent executes on the host |
| Enforcement location | Outside the agent's reach (in the call path) | N/A — no enforcement layer exists |
| Use in Course 2B | The reference for governance done right | The attack lab target (deliberately vulnerable) |
| Score | 39/60 (+4 over OpenClaw) | Near-zero effective security |

The lesson the pairing teaches: **governance is not a feature you add to an agent; it is an architectural property of where the enforcement layer sits relative to the agent.** NemoClaw puts it outside; Tau does not have one. Every other harness sits between. When a Course 2B attack asks "does this harness enforce governance outside the agent's reach?" — NemoClaw is the yes, Tau is the no, and most harnesses are a partial yes with a gap the attack exploits.

---

## Anti-Patterns

### Putting the policy check inside the agent
A policy tool the model calls, or a system-prompt instruction, is inside the agent's trust boundary. A compromised agent can not-call it, call it with sanitized arguments, or ignore the instruction. Cure: enforce policy in the call path between agent and world, in a layer the agent has no API to reach. This is NemoClaw's pattern.

### Treating the governance layer's latency as an overhead to optimize away
The latency is the inherent cost of external enforcement. You cannot make policy free without making it optional, and optional policy is not policy. Cure: accept the latency as the tax of governance done right. If the latency is unacceptable, the requirement is a faster governance layer (better classifiers, hardware acceleration), not the removal of the layer.

### Assuming a policy rule covers a new channel or tool
Every new channel or tool requires a new policy rule. A policy gap is a vulnerability gap — a new channel without an input-rail rule inherits OpenClaw's cross-channel injection vulnerability. Cure: treat policy maintenance as a first-class operational responsibility. New channel and new tool registrations must include a policy-rule review as a gate.

---

## Key Terms

| Term | Definition |
| --- | --- |
| **Governance beneath the agent** | The enforcement layer sits in the call path between agent and world, outside the agent's trust boundary; the agent cannot reach it to disable it (Module 0.2) |
| **NeMo Guardrails** | NVIDIA's external policy evaluation layer; input rail, dialog rail, action rail — all run outside the agent's process |
| **OpenShell** | The sandbox execution layer; the agent never touches it directly — actions go through the governed API |
| **Input rail** | Tags channel-derived content as untrusted and scans for injection before the model sees it (ASI01 fix) |
| **Dialog rail** | Checks the model's responses against policy before action (catches hijacked output regardless of how the hijack occurred) |
| **Action rail** | Validates tool calls and side-effecting actions against capability policy (Module 6 realized externally) |
| **Anti-Tau** | NemoClaw is the harness with all the controls; Tau (DD-21) is the harness with zero defenses; the pairing defines the governance axis |

---

## Lab Exercise

See `07-lab-spec.md`. You simulate a NemoClaw-style governance gate: an agent proposes actions, the governance layer evaluates each against policy, and you observe which actions are allowed and which are denied. Then you remove the governance layer (the Tau configuration) and confirm that every attack succeeds — the empirical anchor for the NemoClaw-vs-Tau contrast.

---

## References

1. **NemoClaw source** — the governance reference; NVIDIA's NeMo Guardrails and OpenShell.
2. **Module 0.2** — the governance move; the governance-beneath-the-agent principle; the lineage map (OpenClaw → NemoClaw).
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. The pairing is load-bearing for the curriculum.
8. **Course 2B** — every attack module starts from the question "does this harness enforce governance outside the agent's reach?" NemoClaw is the yes; Tau is the no; most harnesses are a partial yes with a gap.
