{ "module": "DD-09 — NemoClaw: The Governance-Focused Harness", "course": "Master Course", "version": "1.0.0", "duration_minutes": 30, "total_questions": 15, "bloom_distribution": { "target": "20% recall / 40% application / 40% analysis", "actual": { "recall": 3, "application": 6, "analysis": 6 } }, "passing_score_percent": 70, "questions": [ { "id": "Q01", "bloom": "recall", "type": "multiple_choice", "prompt": "What is NemoClaw's defining architectural principle?", "options": [ "The agent calls a policy tool before every action to check whether it is permitted.", "Governance lives BENEATH the agent, OUTSIDE its reach: NeMo Guardrails evaluate every call externally, and the agent cannot reach the enforcement layer to disable it.", "The system prompt instructs the model not to perform dangerous actions.", "The agent runs inside a container, and all actions are logged for audit." ], "answer_index": 1, "rationale": "NemoClaw's defining principle is governance-beneath-the-agent (Module 0.2): the enforcement layer sits in the call path between agent and world, outside the agent's trust boundary. The agent has no API to disable, configure, or influence the guardrails. This is contrasted with the naive approaches: a policy tool the model calls (option 1 — inside the trust boundary, can be not-called), a system-prompt instruction (option 3 — a request not a constraint), and container logging (option 4 — observability, not enforcement). Only option 2 places the enforcement outside the agent's reach by construction." }, { "id": "Q02", "bloom": "recall", "type": "multiple_choice", "prompt": "NemoClaw scores 39/60, which is +4 over its parent OpenClaw's 35. Where does the +4 come from?", "options": [ "Improvements to the agent's reasoning loop (+4 Module 1).", "A larger context window and better memory management (+4 Module 4).", "The governance layer: +3 Module 6 (external guardrails — highest permission score in the roster) and +2 Module 5 (OpenShell sandboxing), partially offset by rounding. NemoClaw does not improve the agent — it improves the boundary around the agent.", "Better observability and error handling (+2 Module 11, +2 Module 7)." ], "answer_index": 2, "rationale": "The +4 comes almost entirely from the governance layer: Module 6 (Permission) goes to 5/5 — external guardrails, the highest score in the roster on that axis; Module 5 (Sandbox) goes to 4/5 — OpenShell, agent-governed access. Every other module is unchanged from OpenClaw (the agent is OpenClaw's agent). NemoClaw does not improve the agent — it improves the boundary around the agent. 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." }, { "id": "Q03", "bloom": "recall", "type": "multiple_choice", "prompt": "NemoClaw is described as 'the anti-Tau.' Tau (DD-21) is which of the following?", "options": [ "A governance-first harness like NemoClaw but built by a different vendor.", "A harness with zero defenses: no input rail, no dialog rail, no action rail, no sandbox — the deliberately vulnerable harness used as the attack lab target in Course 2B.", "The successor to NemoClaw with improved guardrails.", "A single-agent harness with the same governance layer as NemoClaw but fewer channels." ], "answer_index": 1, "rationale": "Tau (DD-21) is the anti-NemoClaw: a harness with zero defenses. No input rail (all input enters context with full trust), no dialog rail (output acted on directly), no action rail (actions execute unvalidated), no sandbox (agent executes on the host). Tau is the deliberately vulnerable harness used as the attack lab target in Course 2B. The NemoClaw-vs-Tau pairing is load-bearing for the curriculum: NemoClaw is the harness with all the controls; Tau is the harness with none. The pairing teaches that governance is where the enforcement layer sits relative to the agent, not a feature you add." }, { "id": "Q04", "bloom": "application", "type": "multiple_choice", "prompt": "An attacker sends an injection payload via a Slack channel into an OpenClaw (DD-07) agent, and it succeeds — the Slack content had the same trust status as an operator instruction. The same payload is sent into a NemoClaw agent. Why does it fail?", "options": [ "NemoClaw's agent is a smarter model that resists injection better.", "NemoClaw's input rail tags channel-derived content as untrusted and scans for injection BEFORE the model sees it. The Slack content no longer enters context with the same trust status as an operator instruction — it is tagged, demoted, and scanned at the input boundary.", "NemoClaw blocks all Slack messages by default.", "NemoClaw's system prompt instructs the model to ignore channel content." ], "answer_index": 1, "rationale": "The input rail is the fix for OpenClaw's cross-channel injection gap (ASI01). In OpenClaw, channel content (Slack, Teams, etc.) enters the model's context with the same trust status as an operator instruction — there is no trust boundary. In NemoClaw, the input rail runs BEFORE the model is called: channel-derived content is tagged as untrusted, demoted in the instruction hierarchy, and scanned for injection signatures. The payload is caught at the input boundary, before the agent ever sees it. The model is the same (OpenClaw core); the boundary is new. Option 4 (system prompt) is the naive approach NemoClaw explicitly rejects — a request, not a constraint." }, { "id": "Q05", "bloom": "application", "type": "multiple_choice", "prompt": "A teammate proposes adding agent governance as a 'check_policy(action)' tool the model calls before side-effecting actions. Using NemoClaw's principle, what is the error?", "options": [ "No error — this is exactly how NemoClaw works.", "The tool is inside the agent's trust boundary. 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. Cure: enforce policy in the call path between agent and world, in a layer the agent has no API to reach.", "The tool should be renamed to 'validate_action' to sound more authoritative.", "The tool should be called after the action rather than before." ], "answer_index": 1, "rationale": "The 'putting the policy check inside the agent' anti-pattern. A policy tool the model calls is just another tool. A compromised agent can not-call it (the injection suppresses the check), or call it with sanitized arguments while performing the real dangerous action through a different path. The guard is inside the trust boundary of the thing it guards — the agent can reach it, so a compromised agent can disable it (Module 0.2's principle). NemoClaw's cure: enforce policy in the call path between agent and world, in a layer the agent has no API to disable, configure, or influence. The guardrails are in the call path, not in the context." }, { "id": "Q06", "bloom": "application", "type": "multiple_choice", "prompt": "You are extending a NemoClaw deployment with a new channel integration (a new messaging platform). What must you do to maintain the governance guarantee, and why?", "options": [ "Nothing — the governance layer automatically covers all new channels.", "Add a new input-rail policy rule for the new channel, because every new channel requires a new policy rule. A new channel without an input-rail rule inherits OpenClaw's cross-channel injection vulnerability — channel content would enter the model with full trust. Gate new channel registrations on a policy-rule review.", "Disable the governance layer for the new channel to avoid latency.", "Add the channel to the system prompt so the model knows about it." ], "answer_index": 1, "rationale": "The policy maintenance burden is one of NemoClaw's inherent costs. Every new channel requires a new input-rail policy rule: the rail must know to tag the new channel's content as untrusted and scan it for injection. A new channel without a rule is a policy gap, and a policy gap is a vulnerability gap — the new channel's content would enter the model with full trust, exactly the OpenClaw vulnerability NemoClaw was built to fix. The cure is operational: treat policy maintenance as a first-class responsibility and gate new channel/tool registrations on a policy-rule review. Option 1 is the 'assuming a policy rule covers a new channel' anti-pattern." }, { "id": "Q07", "bloom": "application", "type": "multiple_choice", "prompt": "A client complains that NemoClaw's governance layer adds unacceptable latency to every call and asks you to make the policy checks 'optional' or 'best-effort' to speed things up. What is the error, and what is the correct response?", "options": [ "Agree — make the checks optional so the agent can skip them when speed matters.", "The error is treating governance latency as avoidable overhead. You cannot make policy free without making it optional, and optional policy is not policy. The correct response: accept the latency as the inherent tax of external enforcement, or invest in a faster governance layer (better classifiers, hardware acceleration). Do not remove or make the layer optional.", "Agree — move the checks into the system prompt so they run only when the model decides.", "Agree — remove the action rail only, since the input and dialog rails are sufficient." ], "answer_index": 1, "rationale": "The 'treating governance latency as overhead to optimize away' anti-pattern. The latency is the inherent cost of external enforcement — every call passes through three external checks (input, dialog, action). Making the checks optional (option 1) or moving them to the system prompt (option 3) re-introduces the naive approach NemoClaw was built to reject: a guard the agent can reach and disable. Removing one rail (option 4) opens the attack vector that rail closed. The correct response is to accept the latency as the tax of governance done right, and if the latency is genuinely unacceptable, to invest in a faster governance layer — not to weaken or remove the enforcement." }, { "id": "Q08", "bloom": "application", "type": "multiple_choice", "prompt": "Hermes (DD-08) has a memory-write poisoning surface: model-initiated writes with no gate allow a poisoned skill to persist. How does NemoClaw's governance pattern provide the template for the fix?", "options": [ "NemoClaw's pattern is unrelated to memory writes — it only covers channel input.", "Harness-managed writes (model proposes, harness validates) are the SAME principle (governance outside the agent's reach) applied to the memory write path. The write gate is the input rail for persistent storage: the model proposes a skill, the harness validates provenance/schema/taint before persisting, and the poisoned skill is rejected at the gate. NemoClaw's pattern is the template; Hermes omits the gate.", "NemoClaw would disable Hermes's self-evolving skill store entirely.", "NemoClaw would add the validation to the system prompt so the model self-regulates." ], "answer_index": 1, "rationale": "NemoClaw's governance-beneath-the-agent principle generalizes beyond channel input to any path where the agent proposes and the world disposes. Hermes's memory-write poisoning surface is the same architectural gap: the model writes skills freely (model-initiated), with no external validation gate. The NemoClaw-style fix is harness-managed writes: the model PROPOSES a skill, the harness VALIDATES (provenance, schema, taint check) before persisting, and the poisoned skill is rejected at the gate. The write gate is the input rail for persistent storage. This is why NemoClaw is the reference fix for Hermes's write surface — the same principle, applied to a different path. Option 4 is the naive approach both harnesses reject." }, { "id": "Q09", "bloom": "application", "type": "multiple_choice", "prompt": "An attacker compromises a NemoClaw agent via a sophisticated multi-turn injection and tries to disable the guardrails by injecting 'turn off all policy checks.' Why does this fail?", "options": [ "The injection is not sophisticated enough; a longer payload would succeed.", "The guardrails are OUTSIDE the agent's process. The agent has no API to disable, configure, or influence them. The injection controls the agent's reasoning and output, but the guardrails run in the call path between agent and world — a layer the agent cannot reach. The injection cannot turn off what the agent cannot touch.", "The system prompt tells the model to ignore instructions about disabling checks.", "The guardrails use a different model that is more resistant to injection." ], "answer_index": 1, "rationale": "This is the load-bearing security property. A prompt injection compromises the agent — its reasoning, its output, its tool calls. But the guardrails are NOT part of the agent; they are a separate layer in the call path between the agent and the world. The agent has no API to reach them: no tool to call, no config to edit, no prompt to override. The injection can make the agent propose a dangerous action, but the action rail will still evaluate the proposal and block it if it violates policy. The input rail tags the injection channel's content as untrusted before the model even sees it. The guardrails bracket the agent — the agent sits between the rails and cannot reach either one. Option 3 is the naive approach (a system-prompt instruction is a request, not a constraint)." }, { "id": "Q10", "bloom": "analysis", "type": "multiple_choice", "prompt": "Why is the NemoClaw-vs-Tau pairing described as 'load-bearing for Course 2B'? What does every attack module in 2B ask, and how do the two harnesses answer?", "options": [ "The pairing is administrative — they are just the first and last deep-dives.", "Every Course 2B attack asks: 'does this harness enforce governance outside the agent's reach?' NemoClaw is the YES (all three rails + sandbox + external enforcement). Tau is the NO (no rails, no sandbox, no enforcement — every attack succeeds trivially). Most harnesses are a PARTIAL yes with a gap the attack exploits. The pairing defines the governance axis every other harness sits between and teaches that governance is architectural (where the enforcement sits), not a feature.", "The pairing matters because NemoClaw and Tau use the same model.", "The pairing matters because Tau was built to defeat NemoClaw's guardrails." ], "answer_index": 1, "rationale": "The pairing is load-bearing because it defines the two extremes of the governance axis that every Course 2B attack is scored against. NemoClaw is the yes: external guardrails, sandbox, enforcement outside the agent's reach — every defense the course teaches, in one product. Tau is the no: no enforcement layer at all — the deliberately vulnerable attack lab target. Every other harness sits between these poles. The pairing teaches the central lesson: 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. An attack that asks 'does this harness enforce governance outside the agent's reach?' gets a clear yes (NemoClaw), a clear no (Tau), or a partial yes with a gap (most harnesses) — and the gap is what the attack exploits." }, { "id": "Q11", "bloom": "analysis", "type": "multiple_choice", "prompt": "Why does the teaching document claim that NemoClaw 'does not improve the agent — it improves the boundary around the agent'? What is the significance of this distinction?", "options": [ "It means NemoClaw's agent is worse than OpenClaw's because resources are spent on governance.", "The agent (OpenClaw core: loop, tools, memory) is unchanged from DD-07. NemoClaw's entire contribution is the governance layer and sandbox that WRAP the agent. The significance: security is a property of the BOUNDARY (where enforcement sits relative to the agent), not of the agent's reasoning. You can take the same agent and make it safe by wrapping it, or vulnerable by not wrapping it (Tau). This is why governance is architectural, not a model-capability issue.", "It means NemoClaw should be redesigned to improve the agent instead.", "It means the boundary and the agent are unrelated and can be developed independently." ], "answer_index": 1, "rationale": "The distinction is load-bearing. NemoClaw's agent IS OpenClaw's agent — the same loop, the same forty-plus channel integrations, the same memory, the same model. NemoClaw's entire contribution (the +4) is the governance layer (NeMo Guardrails) and the sandbox (OpenShell) that wrap the agent. The significance: security is a property of the BOUNDARY — where the enforcement layer sits relative to the agent — not of the agent's reasoning capability. You can take the exact same agent and make it safe by wrapping it in external governance (NemoClaw), or make it completely vulnerable by wrapping it in nothing (Tau). This is why the course insists governance is architectural (a property of the boundary) rather than a model-capability issue (making the agent 'smarter' does not make it safe). The boundary, not the agent, is the security surface." }, { "id": "Q12", "bloom": "analysis", "type": "multiple_choice", "prompt": "Why can the agent not disable an input rail by prompt injection, AND why can it not bypass an action rail by reasoning around it? Explain the bracketing property.", "options": [ "The agent can disable both if the injection is sophisticated enough.", "The input rail runs BEFORE the model is called — the agent (and any injection compromising it) has not executed yet when the rail fires, so the injection cannot reach a layer that runs before the agent. The action rail runs AFTER the model proposes but BEFORE the tool executes — the agent's reasoning produces a proposal, but the rail evaluates it before execution, so the agent has no path from reasoning to action that skips the rail. The guardrails BRACKET the agent: one before, one after, neither reachable.", "The input rail is in the system prompt and the action rail is a tool the model calls.", "Both rails run inside the agent but are protected by encryption." ], "answer_index": 1, "rationale": "The bracketing property is the key architectural insight. The input rail runs BEFORE the model is called: it tags and scans input before the agent ever sees it. An injection that compromises the agent cannot disable the input rail because the rail has already fired by the time the agent (and the injection) runs — the injection cannot reach backward to a layer that already executed. The action rail runs AFTER the model proposes but BEFORE the tool executes: the agent's reasoning produces a proposal, but the rail evaluates the proposal against policy before any execution occurs. The agent has no path from reasoning to execution that skips the rail — the rail is in the call path. Together, the rails bracket the agent: the input rail before, the action rail after, neither reachable by the agent. Option 3 describes the naive approaches NemoClaw rejects." }, { "id": "Q13", "bloom": "analysis", "type": "multiple_choice", "prompt": "A colleague argues: 'NemoClaw's 39/60 proves governance is too expensive — we get only +4 points for all that latency and maintenance.' Using the teaching document's reasoning, what is the error in this assessment?", "options": [ "The colleague is correct — +4 is not worth the cost.", "The error is reading the +4 as a marginal score rather than the GOVERNANCE REFERENCE. The +4 on Modules 5 and 6 makes NemoClaw the highest-scoring harness on permission (5/5) in the entire roster — the reference every other harness is measured against. The latency and maintenance are the inherent tax of being the reference, not an inefficient overhead. The 39/60 total is structurally constrained by inheriting OpenClaw's unchanged core; the governance layer is the differentiator that earns reference status.", "The score should be recalculated to 45/60 to reflect the governance value.", "The colleague is wrong because 39/60 is actually the highest score in the roster." ], "answer_index": 1, "rationale": "The error is reading the +4 as a marginal return rather than recognizing what it buys: the highest permission score (5/5 on Module 6) in the entire roster, making NemoClaw the governance reference every other harness is scored against. The +4 is concentrated on the two safety axes (Module 5 Sandbox, Module 6 Permission) — exactly the axes that define governance. The latency and policy maintenance are not inefficient overhead; they are the inherent tax of external enforcement (you cannot make policy free without making it optional). The 39/60 total is structurally constrained because NemoClaw inherits OpenClaw's unchanged core (the agent is the same); the governance layer is the differentiator. Reference status is earned on an axis (Module 6: 5/5), not on the total. A harness with better governance would score higher, but none in the roster does." }, { "id": "Q14", "bloom": "analysis", "type": "multiple_choice", "prompt": "Why does the course describe governance as 'an architectural property of where the enforcement layer sits relative to the agent' rather than 'a feature you add to an agent'? Trace the argument through the naive approaches and NemoClaw's alternative.", "options": [ "Governance is a feature — you add it to the agent's tool set.", "The naive approaches (policy tool, system-prompt instruction) ADD governance as a feature INSIDE the agent — but anything inside the agent's trust boundary can be reached and disabled by a compromised agent (Module 0.2). NemoClaw's alternative makes governance ARCHITECTURAL: the enforcement layer sits in the call path between agent and world, a location the agent cannot reach by construction. The difference is not better policy logic; it is WHERE the policy lives relative to the agent. Tau (no enforcement layer anywhere) is the negative proof. Governance is a property of the architecture, not a capability of the agent.", "Governance is a model capability — a smarter model governs itself.", "Governance is a configuration setting applied at deployment time." ], "answer_index": 1, "rationale": "The argument is architectural. The naive approaches (a policy tool the model calls, a system-prompt instruction) treat governance as a feature added inside the agent. But anything inside the agent's trust boundary can be reached by the agent — and a compromised agent (via injection) can disable, bypass, or ignore it. Module 0.2's principle: if the agent can reach the enforcement layer, a compromised agent can disable it. NemoClaw's alternative is architectural: the enforcement layer sits in the call path BETWEEN agent and world, a location the agent cannot reach by construction (no API, no config, no prompt override). The difference between NemoClaw and the naive approaches is not better policy logic — it is WHERE the policy lives relative to the agent. Tau (no enforcement layer at all) is the negative proof that the location is what matters. Governance is a property of the architecture (the boundary), not a capability of the agent (its reasoning)." }, { "id": "Q15", "bloom": "analysis", "type": "multiple_choice", "prompt": "NemoClaw inherits OpenClaw's large codebase, which creates an 'inherited legibility problem' — the governance layer is legible, but the core is not. Why does the teaching document list this as a cost worth accepting rather than a reason to build a governance-first harness from scratch?", "options": [ "The legibility problem is a deal-breaker; you should build from scratch.", "Building from scratch would mean re-implementing OpenClaw's 40+ channel integrations, loop, and memory — a massive effort that duplicates existing capability. Wrapping OpenClaw (inheriting the core, adding the governance layer) gives you the channel breadth AND the governance in one product. The legibility cost (the core is hard to read) is accepted because the governance layer — the security-critical part — IS legible. You audit the boundary; you trust the core as a tested platform. The cost is the right trade-off for production governance.", "The legibility problem does not matter because the governance layer is all you need to read.", "NemoClaw should be rewritten in a more legible language." ], "answer_index": 1, "rationale": "The trade-off is deliberate. Building a governance-first harness from scratch would require re-implementing OpenClaw's entire value proposition — the forty-plus channel integrations, the ReAct loop, the memory system — before adding any governance. That duplication is a massive effort and a source of new bugs. NemoClaw's approach (wrap OpenClaw: inherit the tested core, add the governance layer) gives you the channel breadth AND the governance in one product, at the cost of inheriting a codebase that is hard to read in full. The cost is accepted because the security-critical part — the governance layer (NeMo Guardrails, OpenShell) — IS legible and is the part that must be audited. The core is treated as a tested platform component (like an OS kernel): you do not audit every line, you trust the boundary interface. For production governance, wrapping a proven platform is the right engineering trade-off; building from scratch is only preferred if the platform's trust assumptions are unacceptable." } ] }