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

**Course**: Master Course
**Deep-Dive**: DD-09 — NemoClaw: The Governance-Focused Harness
**Duration**: ~30 minutes (spoken at ~140 wpm)
**Format**: Verbatim transcript with `[SLIDE N]` cues. Read aloud or use as speaker notes.

---

[SLIDE 1 — Title]

Welcome to deep-dive DD-zero-nine, NemoClaw. This is NVIDIA's hardened OpenClaw fork — NeMo Guardrails for external policy evaluation, OpenShell sandboxes for execution isolation, and policy enforced outside the agent's reach. This is the governance reference, and it is the anti-Tau. Every Course 2 attack question starts here.

This deep-dive is weighted heavier than most. 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.

[SLIDE 2 — The principle: governance outside the reach]

Here is the load-bearing principle from Module zero-point-two: 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.

Consider the naive approaches. First, a policy tool the model calls — check-policy of action. That is just another tool. A compromised agent, via injection, 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. Second, a system-prompt instruction — do not perform dangerous actions. That is a request, not a constraint. The model can ignore it. Injection can override it. There is no enforcement, only persuasion.

NemoClaw 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 proceeds or is blocked. The agent has no API to disable, configure, or influence the guardrails. They are outside its reach by construction.

[SLIDE 3 — The three layers: each outside the previous one's reach]

NemoClaw does not replace OpenClaw. It wraps it. Three layers, each outside the previous one's trust boundary.

Layer one, OpenClaw core — the agent. The loop, the forty-plus channel integrations, the memory. This is DD-zero-seven's harness, largely intact. The agent reasons, proposes actions, calls tools.

Layer two, NeMo Guardrails — the governance layer. Sits between the agent and the world. Every model call and every proposed action passes through it. Input classifiers, output classifiers, canonical policy rules. The agent cannot reach this layer — no tool to call, no config to edit, no prompt to override. The guardrails are in the call path, not in the context.

Layer three, 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. 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.

[SLIDE 4 — The three rails: how the guardrails bracket the agent]

NeMo Guardrails implements three classes of check, each mapping to a Course 2 attack vector.

The 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 — ASI zero-one. A Slack message no longer enters context with the same trust status as an operator instruction.

The 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.

The action rail. Tool calls and side-effecting actions are validated against capability policy. This is Module six'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.

[SLIDE 5 — The anti-Tau contrast: load-bearing for Course 2B]

This is the pairing that is load-bearing for the curriculum. NemoClaw and Tau, deep-dive twenty-one, are the two extremes of the governance axis.

NemoClaw is the harness with all the controls. Input rail, dialog rail, action rail, OpenShell sandbox, enforcement outside the agent's reach. The governance reference at thirty-nine out of sixty.

Tau is the harness with zero defenses. No input rail — all input enters the model's context with full trust. No dialog rail — the model's output is acted upon directly. No action rail — the agent's proposed actions execute with no external validation. No sandbox — the agent executes on the host. Tau is the deliberately vulnerable harness used as the attack lab target in Course 2B.

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 in the roster sits somewhere between these two poles. 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.

[SLIDE 6 — The score: 39/60, +4 over OpenClaw]

NemoClaw scores thirty-nine out of sixty, four points over OpenClaw's thirty-five. The plus-four comes almost entirely from the governance layer. Module six, Permission, goes to five out of five — external guardrails, the highest score in the roster on that axis. Module five, Sandbox, goes to four out of five — OpenShell, agent-governed access. Every other module is unchanged from OpenClaw.

Read this score carefully. NemoClaw does not improve the agent. It improves the boundary around the agent. The agent is OpenClaw's agent — the same loop, the same tools, the same memory. The boundary is new. That is the entire point. The plus-four is the value of governance done right, measured as the difference between an ungoverned OpenClaw agent and a governed one.

Against Tau's near-zero effective security, the difference is stark. 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.

[SLIDE 7 — The costs: the tax of governance done right]

Three costs, and all three are the inherent tax of external enforcement, not avoidable overhead.

First, latency. The governance layer adds a check to every call — input rail, dialog rail, action rail. You cannot make policy free without making it optional, and optional policy is not policy. Accept the latency as the tax, or invest in a faster governance layer — better classifiers, hardware acceleration. Do not remove the layer.

Second, 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 — a new channel without an input-rail rule inherits OpenClaw's cross-channel injection vulnerability. Treat policy maintenance as a first-class operational responsibility.

Third, inherited legibility. NemoClaw inherits OpenClaw's large codebase, so reading the whole thing is harder than reading Pi or Tau. The governance layer is the legible part; the core is not.

These are the costs of doing governance right. They are intrinsic to the pattern.

[SLIDE 8 — Anti-patterns]

Three anti-patterns.

First, 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 or ignore it. 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.

Second, treating the governance layer's latency as overhead to optimize away. The latency is the inherent cost of external enforcement. Cure: accept the latency as the tax of governance done right. If the latency is unacceptable, the requirement is a faster governance layer, not the removal of the layer.

Third, assuming a policy rule covers a new channel or tool. Every new channel needs a new input-rail rule. A policy gap is a vulnerability gap. Cure: treat policy maintenance as a first-class operational responsibility. Gate new channel and new tool registrations on a policy-rule review.

[SLIDE 9 — What you can now do]

You can now 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 course. You can distinguish the three layers — OpenClaw core, NeMo Guardrails, OpenShell — and why each must be outside the previous one's trust boundary. You can score NemoClaw thirty-nine out of sixty and explain why the plus-four over OpenClaw comes from the governance layer, not the agent. You can construct the NemoClaw-versus-Tau contrast and explain why the pairing is load-bearing for Course 2B — governance is where the enforcement layer sits relative to the agent, not a feature you add. And you can articulate the costs of external governance and why they are the inherent tax, not avoidable overhead.

The lab asks you to 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. That is the empirical anchor for the anti-Tau contrast.

Next, deep-dive DD-ten: LangGraph, the graph-based agent framework. Where NemoClaw is the governance reference for single-agent harnesses, LangGraph introduces the graph model that multi-agent orchestration builds on — and connects forward to Course four's multi-agent orchestration module.

---

*End of deep-dive DD-09. Duration: approximately thirty minutes at one-hundred-forty words per minute.*