# Teaching Script — DD-07: OpenClaw **Course**: Master Course · **Deep-Dive**: DD-07 · **Duration**: 60 min · **Word count**: ~2,800 > Verbatim teaching transcript. ~140 wpm delivery. Cues map to the slide deck (03-slide-deck.html). --- [SLIDE 1 — Title] Welcome to Deep-Dive Seven: OpenClaw, platform harness and trust architecture. This is the breadth play — three hundred and sixty-eight thousand stars, forty-plus messaging channels, NVIDIA and Microsoft partnerships. It was the number-one platform harness by total usage until Hermes overtook it on OpenRouter in May twenty-twenty-six. But this deep-dive is not about the star count. It is about the trust-architecture gap — the defining vulnerability that birthed two independent governance forks, NemoClaw by NVIDIA and Scout by Microsoft. Two well-funded teams, working independently, both concluded the same thing: OpenClaw's trust architecture is unfixable in place. That is the strongest possible signal that the architecture, not the implementation, is the problem. And that is the lesson we are here to score. [SLIDE 2 — Thesis] Here is the thesis. Breadth compounds the trust problem. Every channel OpenClaw adds raises Module Two — tool breadth, the integration surface, the reach. And simultaneously, every channel raises the injection surface that depresses Module Six. The thirty-five out of sixty is not a failure of execution. It is the structural cost of the breadth play without a trust architecture. Let me say that again because it is the whole deep-dive. Adding a channel is not free. Each new channel is a new untrusted input source. A public Slack, a Telegram group, a spoofed email — each is an injection vector the CLI harnesses do not have. The CLI harnesses have one input surface: the terminal operator. OpenClaw has forty-plus. And OpenClaw's architecture does not distinguish between them. The defining vulnerability: channel messages — untrusted, attacker-controllable — enter the model's context with the same trust status as operator instructions. No tags, no boundary, no isolation. The model cannot tell the difference between "do this" said by you, the operator, and "do this" said by a stranger in a public Slack channel. That is cross-channel injection, ASI-zero-one, and it is the highest-severity finding in the platform-harness category. [SLIDE 3 — The trust gap] Let me sharpen this, because there is a subtlety that is easy to miss. OpenClaw's system prompt — about eight thousand tokens — is channel-aware. It knows how to format a Slack message differently from a Telegram message. It knows the conventions of each platform. That is real engineering, and it is what makes OpenClaw good at breadth. But the prompt is not trust-aware. It does not tell the model that the Slack message is untrusted data. It formats the message; it does not classify it. Channel awareness without trust awareness is the half-measure. And here is the critical point: even if the prompt did say "treat this Slack message as untrusted," that would be a prompt instruction — and a prompt instruction is exactly what an injected message can override. You cannot fix a trust problem by asking the model nicely to treat content as untrusted. The fix has to be architectural. [SLIDE 4 — ASI01] Let me make the attack concrete, because the severity is what makes this the central lesson. The attacker does not need to compromise the operator. That is the key insight. In the CLI harnesses — Pi, Aider, OpenCode, Codex, Gemini — the attacker needs to get the operator to open a malicious file, or visit a malicious repo, or paste malicious content. The operator is the channel. In OpenClaw, the attacker does not need the operator at all. They need only to send a message in a channel the agent monitors. A public Slack channel. A Telegram group. A spoofed email. Each is an injection surface, and each message enters the model's context with full authority. Forty-plus channels means forty-plus injection surfaces, all entering with the same trust status as a direct instruction from you. That is why this is the highest-severity finding in the platform-harness category. The attack surface is not a flaw in one channel — it is the architecture. [SLIDE 5 — Two governance forks] Now the evidence. Two independent governance forks. NemoClaw, built by NVIDIA. Scout, built by Microsoft. Both addressed the same deficiency. Both added a trust boundary at the adapter — tagging channel-derived content as untrusted before it reaches the model. Here is why this matters. If the trust gap were a bug — a missing feature, an oversight — then NemoClaw and Scout would be pull requests. "Hey OpenClaw, here is the fix, please merge." They are not pull requests. They are forks. Two well-funded teams, working independently, both concluded that the fix requires re-architecting the message pipeline. That is not how you respond to a bug. That is how you respond to an architectural deficiency. The forks are the evidence. When two large vendors independently build the same fix, the deficiency is real, and it is structural. This is the strongest signal we have in the entire course that the architecture, not the implementation, is the problem. [SLIDE 6 — The score] Here is the twelve-module audit. Thirty-five out of sixty. Let me walk you through the shape. OpenClaw scores well where breadth pays. Module Two, tools: four. Forty-plus integrations — no competitor matches the reach. Module Twelve, prompt: four. About eight thousand tokens, channel-aware. Module One, loop: four. Platform-adapted ReAct, standard pattern, well-executed. Then the losses. Module Five, sandbox: two. Weak. And here is the subtle point — a container cannot fix this. A container bounds the blast radius of tool execution, but the trust gap is in the context, not the filesystem. You can run OpenClaw in a locked-down container and the cross-channel injection still works, because the injection enters through the context window, not through the filesystem. Module Six, permission: two. Per-channel permissions exist, but they do not compose into a cross-channel trust model. A Slack message and a Teams message can both invoke the same high-risk tools. There is no "this came from a public channel, downgrade trust" mechanism. Total: thirty-five. The wins are on breadth. The losses are on trust. And the thirty-five is structural — it is the cost of the tradeoff, not a failure to execute well. [SLIDE 7 — Anti-patterns] Three anti-patterns to flag, because each one misunderstands the tradeoff. First: "three hundred sixty-eight thousand stars means OpenClaw is the best platform harness." No. Stars measure attention, not architecture. This is Module zero-point-two anti-pattern number one. OpenClaw's stars tell you it got attention and adoption. The existence of NemoClaw tells you the architecture has a real deficiency that two well-funded teams independently forked to fix. Hermes's OpenRouter overtake in May twenty-twenty-six is the trajectory signal. Rank by design intent, not by stars. Second: "channel awareness in the prompt solves the trust problem." No. We covered this. Channel awareness without trust awareness is the half-measure. And a prompt instruction is exactly what an injected message can override. The fix must be architectural — tag at the adapter, enforce in the harness — not lexical. Third: "the trust gap is a bug that can be patched." No. Two independent governance forks are the evidence against this. If the gap were patchable, NemoClaw and Scout would be pull requests, not forks. The fix requires re-architecting the message pipeline: tag channel-derived content as untrusted at the adapter, carry the tag through to the model's context, and let the harness enforce what untrusted content can do. That is a structural change. [SLIDE 8 — Three fixes] If you are going to build on OpenClaw — or evaluate a platform harness — here are the three fixes that constitute the NemoClaw pattern. One: add cross-channel trust boundaries. Tag channel-derived content as untrusted at the adapter, before it enters the message pipeline. Carry the tag through to the model's context. And enforce it in the harness — the harness decides what untrusted content can and cannot do, not the model. This is the architectural fix. It is why NemoClaw exists. Two: add per-channel capability scoping. A Slack message from a public channel should not exercise the same capabilities as a direct operator message. Downgrade trust by channel type. Public channels get read-only capabilities; direct messages get more; operator instructions get full. The trust hierarchy is per-channel-type, not flat. Three: add injection detection on channel inputs before they reach the model. A pre-filter at the adapter — a classifier, a guardrail, a heuristic check. This is not a substitute for the architectural fix, but it adds defense in depth. The key: it runs at the adapter, in the harness, not as a prompt instruction the model can be talked out of. [SLIDE 9 — Objectives] To wrap: by the end of this deep-dive you should be able to apply the six-phase methodology to OpenClaw and produce a scored card. Defend breadth as a strategy — and state why it compounds the trust problem rather than solving it. Explain the trust-architecture gap and why it enables cross-channel injection, ASI-zero-one. Articulate why two independent governance forks are evidence that the fix is architectural, not a patch. Distinguish channel-aware prompt design, which OpenClaw has, from trust-aware prompt design, which it lacks. And state the three fixes that constitute the NemoClaw pattern: cross-channel trust boundaries at the adapter, per-channel capability scoping by channel type, and injection detection before the model. Breadth is a real strategy. The thirty-five is the structural cost. Two forks are the evidence. That is OpenClaw. --- **End of teaching script.** Transitions to lab (07-lab-spec.md) where students model the trust gap, the cross-channel injection attack, and the NemoClaw-pattern fix.