Course: 2B — Securing & Attacking Harnesses and LLMs Deep-Dive: SDD-B08 · Duration: 45 minutes · Level: Senior Engineer and above Prerequisites: Course 2B B0–B2; Course 1 Module 0.2 and DD-09 (NemoClaw); SDD-B01–SDD-B07
NeMo Guardrails is the programmable guardrail layer behind NemoClaw — the production proof that governance belongs beneath the agent. It enforces policy between the user and the model through five rail types: input, output, dialog, retrieval, and execution. Its strength is that it is programmable, multi-rail, and production-deployed. Its attack surface is that the rails are themselves evaluated by models — so they are subject to the same injection risks they are built to stop. The guardrail is a model, and models are injectable. This deep-dive covers the framework, the governance architecture it enables, and how to red-team a NeMo-guardrailed system.
After completing this deep-dive, you will be able to:
Course 1 Module 0.2 established the governance-beneath-the-agent principle: if the agent can reach the enforcement layer, a compromised agent can disable it. DD-09 (NemoClaw) was the production proof — NeMo Guardrails evaluate every model call externally, and the agent never touches the guardrail layer directly. NemoClaw's entire contribution over its parent was this governance layer, and it scored +4 specifically because the guardrails sat outside the agent's reach.
This deep-dive takes the governance framework behind NemoClaw and analyzes it the way a red-team must: as a system with its own attack surface. NeMo Guardrails is not a magic boundary that stops all disallowed content — it is a programmable layer of model-evaluated classifiers and actions, and because the classifiers are models, they carry the same vulnerabilities the underlying model does. An input rail that uses an embedding model to detect toxic content can be evaded by an adversarial input crafted against that embedding model. An output rail that uses an LLM to classify the response can be manipulated if the response it is checking contains a prompt injection targeting the rail's own classifier. The guardrail is a model, and models are injectable.
This is the load-bearing insight of the deep-dive, and it connects directly to B2's thesis (no single layer suffices) and to the SDD-B04–SDD-B06 analysis (every defense layer — CrabTrap's judge, IronCurtain's deterministic policy, the model's refusal training — has a residual). NeMo Guardrails is the strongest production realization of the governance-beneath-the-agent principle, and it still has residuals. The red-team's job is to find them, measure them, and ensure the layered architecture bounds them.
Three sub-sections, fifteen minutes each:
The five rail types, the configuration, the external evaluation architecture.
NeMo Guardrails (NVIDIA) is an open-source framework that adds a programmable guardrail layer to LLM-based conversational applications. It sits in the request and response path between the user and the model. Its unit of enforcement is the rail — a configurable check that runs at a specific stage of the conversation and either allows the stage to proceed, modifies the input or output, or blocks it. The framework defines five rail types, each governing a different stage:
The five rails cover the full conversation lifecycle: what comes in, what goes out, how the conversation flows, what is retrieved, and what is executed. A NeMo-guardrailed system configures each rail type with the policies appropriate to its deployment, and the framework enforces them externally — the agent does not run the rails; the guardrail layer does, and the agent cannot reach them.
NeMo's rails are configured in Colang — a domain-specific language NeMo introduced for conversational flow definition — and in Python for the action implementations. A rail is defined by its type, its triggering condition, and the action (or classifier) it runs. The policy is code, not a fixed filter: a deployer writes the rails their deployment requires, and the framework evaluates them.
This programmability is the core architectural decision, and it is what distinguishes NeMo from a fixed output filter or a provider-side safety classifier. A fixed filter stops what its designer anticipated; a programmable rail stops what the deployer's policy specifies, and the policy can be as specific as the deployment requires — "this customer-service agent must never discuss pricing for competitors" is a rail a fixed filter cannot express but a Colang dialog rail can. The trade-off is that programmable policy is only as good as the policy author: a missing rail is a missing control, and the framework does not infer the policy the deployer should have written.
The load-bearing architectural property — the one that made NemoClaw the governance reference — is that the rails are evaluated externally to the agent. The guardrail layer is a separate process the agent calls through; the agent does not host the rails, does not run them, and cannot reach them to disable or modify them. When the agent makes a model call, the call passes through the guardrail layer, which runs the input rails, forwards to the model if they pass, runs the output rails on the response, and returns the guarded result.
This is the realization of the Course 1 Module 0.2 principle: if the agent can reach the enforcement layer, a compromised agent can disable it. By placing the rails outside the agent's process boundary, NeMo ensures that a model that has been manipulated (by a prompt injection, a jailbreak) cannot turn off its own guardrails. The agent can be fully compromised and the guardrails still run, because the guardrails are not the agent's code to control. This is why NemoClaw's governance scored +4 over its parent: the governance layer was external, and external enforcement is the architecture that holds when the agent itself is the threat.
Programmable, multi-rail, production-deployed — and how NemoClaw uses it.
The first strength. A NeMo rail is a programmable check written in Colang and Python, evaluated against the deployer's policy. This means the guardrail layer can express deployment-specific constraints a fixed filter cannot: industry-specific compliance rules, brand-specific content policies, application-specific conversation boundaries. A banking agent's rails can enforce "never disclose account numbers in the output" with a specific regex and a model-based classifier; a medical agent's rails can enforce "never provide a diagnosis without the disclaimer" as a dialog rail that checks the conversation state.
The programmability also means the guardrail layer is auditable: the rails are code in version control, reviewable like any other security control. A fixed provider-side safety classifier is a black box — you cannot inspect what it stops or what it lets through. A NeMo rail is a code review away from verification. This is the governance advantage: the policy is legible to the security and compliance processes that must assess it (B11).
The second strength. The five rail types cover the full conversation lifecycle, and a well-configured NeMo deployment uses multiple rails in sequence — the defense-in-depth thesis (B2) realized at the guardrail layer. An input rail catches the jailbreak before the model sees it. If the input rail's classifier misses it (a residual — see B08.3), the model may comply, but the output rail checks the response before it reaches the user. If the attack is an indirect injection via retrieved content, the retrieval rail is the layer that governs it. If the attack targets a tool call, the execution rail is the layer that catches the disallowed invocation.
This multi-layer structure is why NeMo is stronger than a single-checkpoint guardrail. Each rail is a classifier with its own false-negative rate; the composition's overall bypass rate is the product of the individual rates (under independence assumptions), which is why layered defenses reach single-digit bypass rates where single defenses sit near the baseline (SDD-B03's measurement). The catch — and this is B08.3's subject — is that the rails are not independent when they share an underlying model surface, and the composition is only as strong as its weakest shared dependency.
The third strength. NeMo Guardrails is not a research prototype; it is a production-deployed framework NVIDIA maintains and ships, and it is the guardrail layer NemoClaw (Course 1 DD-09) is built on. NemoClaw's architect's verdict was that it "optimizes for governance integrity — policy enforced outside the agent's reach" and is "the production reference for governance done right." The +4 score over OpenClaw came almost entirely from the governance layer: external guardrails evaluating every model call, plus OpenShell sandboxing the agent never touches directly.
The NemoClaw reference matters because it demonstrates the architecture at production scale. A governance pattern that works in a demo but not under real load is not a governance pattern — it is a demo. NeMo's production deployment, and NemoClaw's use of it, is the evidence that external guardrail enforcement scales to a real agent with a real tool surface and real adversarial traffic. This is the deployment maturity that makes NeMo the reference framework, not just an option.
The governance-beneath-the-agent architecture buys the property that matters most: the guardrails run even when the agent is compromised. A prompt injection that takes over the model cannot disable the input rails, because the rails are not the model's code. A jailbreak that makes the model produce disallowed content cannot turn off the output rails, because the output rails are evaluated by a separate process the model's output merely passes through.
What it does not buy is invulnerability. The guardrails are evaluated by models — embedding models for similarity checks, LLM-based classifiers for content categorization, the same class of model that the underlying agent uses. And models are injectable. The external architecture protects the guardrails from being disabled by a compromised agent; it does not protect the guardrails from being evaded by an input crafted against the guardrail's own model surface. That is the attack surface B08.3 covers.
The rails are model-evaluated, so they are injectable. The bypass vectors and the residuals.
Here is the central insight of this deep-dive, and it is the one that determines how a red-team approaches a NeMo-guardrailed system. The guardrails are evaluated by models. An input rail that detects toxicity uses an embedding model or a classifier; an output rail that checks for leaked data uses an LLM-based check; a dialog rail that determines whether a query is on-topic uses a model-based canonical-form matching. These models are themselves subject to prompt injection, adversarial inputs, and the full range of model-level attacks covered in SDD-B06.
The external architecture protects the guardrails from being disabled — a compromised agent cannot reach the rail process to turn it off. But it does not protect the rail's classifier from being evaded. An attacker who crafts an input that the underlying model would comply with AND that the input rail's classifier does not flag has bypassed the guardrail without ever touching the rail process. The guardrail ran; it simply classified the adversarial input as benign, because its classifier is a model and the input was crafted against that model's blind spots.
This is the same structural property as the model-layer finding from SDD-B06: a pattern-calibrated classifier has a novel-pattern bypass. The input rail's toxicity classifier was trained on known toxic patterns; an adversarial input crafted to avoid those patterns evades it. The output rail's LLM-based check can be manipulated if the response it is checking contains a prompt injection targeting the rail's own classifier model — the model evaluating the output is itself susceptible to injection in the text it is evaluating.
The specific attack surfaces, by rail type:
Each bypass vector is a measurable residual. The red-team does not assert "the guardrail can be bypassed" — it measures the bypass rate over N attempts, under fixed parameters, the way InjecAgent (SDD-B03) measures injection rates. The rail's residual is the false-negative rate of its classifier against the attack class, and the layered composition's overall residual is the probability that an attack passes every rail in the chain.
The measurement methodology follows SDD-B03 and SDD-B06: run the attack N times under fixed parameters (rail configuration, underlying model version, temperature), count the successes, report the rate. For a NeMo-guardrailed system, the measurement has layers: the input-rail bypass rate (what fraction of adversarial inputs pass the input rail), the output-rail bypass rate (what fraction of disallowed responses pass the output rail), and the end-to-end bypass rate (what fraction of attacks produce a disallowed output to the user, having passed every rail in the chain).
The end-to-end rate is the finding that matters. A 5% input-rail bypass rate and a 5% output-rail bypass rate compose (under independence) to a roughly 0.25% end-to-end rate — but the rails are not independent when they share an underlying model surface, and the composition is weaker than the independence calculation suggests if the same adversarial technique evades both. The red-team's measurement must test the composition, not just the individual rails, because the real attack passes the whole chain.
The synthesis ties NeMo back to B2's thesis and the SDD-B04–SDD-B06 progression. NeMo Guardrails is the strongest production realization of the governance-beneath-the-agent principle, and it is a layer — not a boundary. The rails are model-evaluated, so they are injectable; each rail type has its bypass vector; the composition has a residual. This is the same conclusion every defense layer reached: CrabTrap's judge is injectable (SDD-B04), IronCurtain's deterministic policy has compilation residuals (SDD-B05), the model's refusal training falls in 5 queries (SDD-B06), and NeMo's guardrails have classifier-evasion residuals (this deep-dive).
The prescription is the one the course has been building: layered defense, where each layer's bypass is bounded by the others. NeMo's input rails raise the bar and provide signal; the output rails catch what the input rails miss; the retrieval and execution rails govern the indirect-injection and tool-call surfaces; and beneath all of it, the deterministic boundary (IronCurtain-style) provides the limit the probabilistic rails cannot. A NeMo deployment that relies on the guardrails alone — without the deterministic boundary, without the harness controls from B4 — has the residuals this deep-dive measures. A NeMo deployment composed with the layered architecture has each residual bounded by the others, and that is the architecture that holds.
"NeMo's guardrails stop all disallowed content." Cure: the rails are model-evaluated classifiers with false-negative surfaces. Each rail type has a bypass vector (input-rail adversarial evasion, output-rail classifier-targeting injection, dialog-rail canonical-form confusion, retrieval-rail indirect-injection passthrough, execution-rail argument manipulation). The guardrails are a layer; the deterministic boundary (IronCurtain-style) is the limit they cannot provide.
"The rails run outside the agent, so they can't be bypassed." Cure: external enforcement protects the rails from being DISABLED by a compromised agent; it does not protect the rail's classifier from being EVADED by an input crafted against the classifier's model surface. The guardrail ran; it classified the adversarial input as benign, because its classifier is a model and the input was crafted against its blind spots.
"I got one input past the input rail." Cure: a single bypass is an anecdote. Measure the bypass RATE over N attempts under fixed parameters (rail config, model version, temperature), per SDD-B03 and SDD-B06. Report the per-rail rate AND the end-to-end composition rate. No rate, no finding.
"The input rail has a 5% bypass rate; the output rail has 5%; so the system is at 0.25%." Cure: the rails are not independent when they share an underlying model surface. An adversarial technique that evades the input rail's classifier may also evade the output rail's classifier if both use the same model class. Measure the end-to-end composition directly — the real attack passes the whole chain, not one rail in isolation.
"We configured input and output rails; that's enough." Cure: indirect injection arrives via retrieved content (SDD-B03) and tool-call manipulation via the execution surface (SDD-B04). A NeMo deployment without retrieval rails is open to indirect injection; without execution rails, it is open to tool-argument manipulation. All five rail types cover the conversation lifecycle; omitting any leaves its stage unguarded.
"The framework lets us write any rail." Cure: programmability means the policy is only as good as the policy author. A missing rail is a missing control, and the framework does not infer the policy the deployer should have written. Audit the rail configuration the way any security control is audited (B11); a rail set that omits the deployment-specific constraints is a rail set with gaps.
| Term | Definition |
|---|---|
| NeMo Guardrails | NVIDIA's open-source programmable guardrail framework; enforces policy between user and model through five rail types, evaluated externally to the agent |
| Input rails | Run on the user's input before it reaches the model; check for disallowed content (toxicity, jailbreak patterns, PII, off-topic); first line of defense against prompt injection |
| Output rails | Run on the model's output before it reaches the user; check for leaked data, harmful content, hallucinations; catches a model that complied despite the input rails |
| Dialog rails | Govern conversation flow; determine if a request is on-topic, match canonical forms, steer along allowed paths; enforce "this agent only discusses X" |
| Retrieval rails | Run on retrieved content in a RAG pipeline before it feeds the model; govern indirect prompt injection (SDD-B03) by filtering/quarantining untrusted chunks |
| Execution rails | Govern tool/action execution; check the tool, arguments, and result; prevent disallowed tool invocation or argument manipulation (SDD-B04) |
| Colang | NeMo's domain-specific language for conversational flow and rail definition; policy is code, not a fixed filter |
| Governance-beneath-the-agent | The Course 1 Module 0.2 principle: enforcement must sit outside the agent's reach, so a compromised agent cannot disable it; NeMo's external evaluation realizes it |
| Rail residual | A rail's false-negative rate against an attack class; the measurable bypass probability, measured over N attempts like InjecAgent (SDD-B03) |
| Guardrail is a model | The load-bearing vulnerability: rails are evaluated by models (embedding models, LLM classifiers), so they are subject to the same injection/evasion risks as the model they guard |
See 07-lab-spec.md. The lab has you build a simulated NeMo-style guardrail layer (five rail types with model-evaluated classifiers), craft adversarial inputs targeting each rail's classifier surface, measure the per-rail and end-to-end bypass rates over N attempts, and demonstrate the defense-in-depth composition. Python 3.10+ with type hints; no GPU; the rail classifiers and the underlying model are simulated so the lab runs deterministically offline.
github.com/NVIDIA/nemo-guardrails.# Deep-Dive SDD-B08 — NeMo Guardrails: The Production Guardrail Framework **Course**: 2B — Securing & Attacking Harnesses and LLMs **Deep-Dive**: SDD-B08 · **Duration**: 45 minutes · **Level**: Senior Engineer and above **Prerequisites**: Course 2B B0–B2; Course 1 Module 0.2 and DD-09 (NemoClaw); SDD-B01–SDD-B07 > *NeMo Guardrails is the programmable guardrail layer behind NemoClaw — the production proof that governance belongs beneath the agent. It enforces policy between the user and the model through five rail types: input, output, dialog, retrieval, and execution. Its strength is that it is programmable, multi-rail, and production-deployed. Its attack surface is that the rails are themselves evaluated by models — so they are subject to the same injection risks they are built to stop. The guardrail is a model, and models are injectable. This deep-dive covers the framework, the governance architecture it enables, and how to red-team a NeMo-guardrailed system.* --- ## Learning Objectives After completing this deep-dive, you will be able to: 1. Explain what NeMo Guardrails is: a programmable guardrail layer that enforces policy between the user and the model through five rail types (input, output, dialog, retrieval, execution), configured in Colang and Python, evaluated externally to the agent. 2. Describe how NeMo enforces policy: the rails sit in the request and response path, the agent cannot reach them to disable them (the governance-beneath-the-agent principle from Course 1 Module 0.2), and each rail is a classifier or action that gates a stage of the conversation. 3. Analyze the strengths: programmable (policy is code, not a fixed filter), multi-rail (defense-in-depth across the conversation lifecycle), and production-deployed (the reference framework NemoClaw builds on). 4. Analyze the attack surface: the rails are themselves evaluated by models (embedding models, LLM-based classifiers), so they are subject to the same prompt-injection and adversarial-input risks the model they guard is — the guardrail is a model, and models are injectable. 5. Apply red-team techniques to a NeMo-guardrailed system: probing the input rails with adversarial payloads, exploiting the rail-classifier's own model surface, testing the dialog and retrieval rails for bypass, and measuring rail-residual rates the way InjecAgent (SDD-B03) measures injection rates. 6. Map the NeMo architecture to B2's defense-in-depth thesis and the Course 1 Module 0.2 governance principle: external enforcement is necessary but not sufficient — the rails are a layer, and every layer has a residual. --- ## Why this deep-dive exists Course 1 Module 0.2 established the governance-beneath-the-agent principle: if the agent can reach the enforcement layer, a compromised agent can disable it. DD-09 (NemoClaw) was the production proof — NeMo Guardrails evaluate every model call externally, and the agent never touches the guardrail layer directly. NemoClaw's entire contribution over its parent was this governance layer, and it scored +4 specifically because the guardrails sat outside the agent's reach. This deep-dive takes the governance framework behind NemoClaw and analyzes it the way a red-team must: as a system with its own attack surface. NeMo Guardrails is not a magic boundary that stops all disallowed content — it is a programmable layer of model-evaluated classifiers and actions, and because the classifiers are models, they carry the same vulnerabilities the underlying model does. An input rail that uses an embedding model to detect toxic content can be evaded by an adversarial input crafted against that embedding model. An output rail that uses an LLM to classify the response can be manipulated if the response it is checking contains a prompt injection targeting the rail's own classifier. The guardrail is a model, and models are injectable. This is the load-bearing insight of the deep-dive, and it connects directly to B2's thesis (no single layer suffices) and to the SDD-B04–SDD-B06 analysis (every defense layer — CrabTrap's judge, IronCurtain's deterministic policy, the model's refusal training — has a residual). NeMo Guardrails is the strongest production realization of the governance-beneath-the-agent principle, and it still has residuals. The red-team's job is to find them, measure them, and ensure the layered architecture bounds them. Three sub-sections, fifteen minutes each: - **B08.1 — What NeMo Guardrails Is.** The five rail types, the Colang configuration, the external evaluation architecture, and how it enforces policy between user and model. - **B08.2 — Strengths and the Governance Architecture.** Programmable, multi-rail, production-deployed; the governance-beneath-the-agent principle realized; how NemoClaw uses it. - **B08.3 — The Attack Surface and Red-Teaming.** The rails are model-evaluated, so they are injectable; the specific bypass vectors per rail type; how to measure rail residuals; the defense-in-depth synthesis. --- # B08.1 — What NeMo Guardrails Is *The five rail types, the configuration, the external evaluation architecture.* ## The five rail types NeMo Guardrails (NVIDIA) is an open-source framework that adds a programmable guardrail layer to LLM-based conversational applications. It sits in the request and response path between the user and the model. Its unit of enforcement is the *rail* — a configurable check that runs at a specific stage of the conversation and either allows the stage to proceed, modifies the input or output, or blocks it. The framework defines five rail types, each governing a different stage: - **Input rails.** Run on the user's input before it reaches the model or any downstream processing. They check the incoming message for disallowed content (toxicity, jailbreak patterns, PII, off-topic queries), and can block or transform the input. This is the first line of defense — the rail that intercepts a prompt injection before the model sees it. - **Output rails.** Run on the model's output before it is returned to the user. They check the response for disallowed content (leaked sensitive data, harmful instructions, hallucinated citations), and can block or replace it. This is the rail that catches a model that complied with an injection despite the input rails. - **Dialog rails.** Govern the conversation flow — determining whether the user's request is on-topic, whether it matches a canonical form the agent is allowed to handle, and steering the conversation along allowed paths. Dialog rails are what let a NeMo-guardrailed system enforce "this agent only discusses X; everything else is deflected." - **Retrieval rails.** Run on retrieved content in a RAG pipeline — checking the chunks coming back from the retrieval store before they are fed into the model's context. This is the rail that governs indirect prompt injection (SDD-B03): the retrieved content is untrusted input, and the retrieval rail can filter or quarantine it. - **Execution rails.** Govern the execution of tools and actions the model calls — checking the tool, the arguments, and the result before the action proceeds or the result returns to the model. This is the rail that prevents a manipulated model from invoking a disallowed tool or passing disallowed arguments (the function-call attack surface from B4 and SDD-B04). The five rails cover the full conversation lifecycle: what comes in, what goes out, how the conversation flows, what is retrieved, and what is executed. A NeMo-guardrailed system configures each rail type with the policies appropriate to its deployment, and the framework enforces them externally — the agent does not run the rails; the guardrail layer does, and the agent cannot reach them. ## Colang and the programmable policy NeMo's rails are configured in Colang — a domain-specific language NeMo introduced for conversational flow definition — and in Python for the action implementations. A rail is defined by its type, its triggering condition, and the action (or classifier) it runs. The policy is code, not a fixed filter: a deployer writes the rails their deployment requires, and the framework evaluates them. This programmability is the core architectural decision, and it is what distinguishes NeMo from a fixed output filter or a provider-side safety classifier. A fixed filter stops what its designer anticipated; a programmable rail stops what the deployer's policy specifies, and the policy can be as specific as the deployment requires — "this customer-service agent must never discuss pricing for competitors" is a rail a fixed filter cannot express but a Colang dialog rail can. The trade-off is that programmable policy is only as good as the policy author: a missing rail is a missing control, and the framework does not infer the policy the deployer should have written. ## The external evaluation architecture The load-bearing architectural property — the one that made NemoClaw the governance reference — is that the rails are evaluated *externally* to the agent. The guardrail layer is a separate process the agent calls through; the agent does not host the rails, does not run them, and cannot reach them to disable or modify them. When the agent makes a model call, the call passes through the guardrail layer, which runs the input rails, forwards to the model if they pass, runs the output rails on the response, and returns the guarded result. This is the realization of the Course 1 Module 0.2 principle: if the agent can reach the enforcement layer, a compromised agent can disable it. By placing the rails outside the agent's process boundary, NeMo ensures that a model that has been manipulated (by a prompt injection, a jailbreak) cannot turn off its own guardrails. The agent can be fully compromised and the guardrails still run, because the guardrails are not the agent's code to control. This is why NemoClaw's governance scored +4 over its parent: the governance layer was external, and external enforcement is the architecture that holds when the agent itself is the threat. --- # B08.2 — Strengths and the Governance Architecture *Programmable, multi-rail, production-deployed — and how NemoClaw uses it.* ## Programmable policy is code, not a fixed filter The first strength. A NeMo rail is a programmable check written in Colang and Python, evaluated against the deployer's policy. This means the guardrail layer can express deployment-specific constraints a fixed filter cannot: industry-specific compliance rules, brand-specific content policies, application-specific conversation boundaries. A banking agent's rails can enforce "never disclose account numbers in the output" with a specific regex and a model-based classifier; a medical agent's rails can enforce "never provide a diagnosis without the disclaimer" as a dialog rail that checks the conversation state. The programmability also means the guardrail layer is auditable: the rails are code in version control, reviewable like any other security control. A fixed provider-side safety classifier is a black box — you cannot inspect what it stops or what it lets through. A NeMo rail is a code review away from verification. This is the governance advantage: the policy is legible to the security and compliance processes that must assess it (B11). ## Multi-rail is defense-in-depth across the conversation lifecycle The second strength. The five rail types cover the full conversation lifecycle, and a well-configured NeMo deployment uses multiple rails in sequence — the defense-in-depth thesis (B2) realized at the guardrail layer. An input rail catches the jailbreak before the model sees it. If the input rail's classifier misses it (a residual — see B08.3), the model may comply, but the output rail checks the response before it reaches the user. If the attack is an indirect injection via retrieved content, the retrieval rail is the layer that governs it. If the attack targets a tool call, the execution rail is the layer that catches the disallowed invocation. This multi-layer structure is why NeMo is stronger than a single-checkpoint guardrail. Each rail is a classifier with its own false-negative rate; the composition's overall bypass rate is the product of the individual rates (under independence assumptions), which is why layered defenses reach single-digit bypass rates where single defenses sit near the baseline (SDD-B03's measurement). The catch — and this is B08.3's subject — is that the rails are not independent when they share an underlying model surface, and the composition is only as strong as its weakest shared dependency. ## Production-deployed and the NemoClaw reference The third strength. NeMo Guardrails is not a research prototype; it is a production-deployed framework NVIDIA maintains and ships, and it is the guardrail layer NemoClaw (Course 1 DD-09) is built on. NemoClaw's architect's verdict was that it "optimizes for governance integrity — policy enforced outside the agent's reach" and is "the production reference for governance done right." The +4 score over OpenClaw came almost entirely from the governance layer: external guardrails evaluating every model call, plus OpenShell sandboxing the agent never touches directly. The NemoClaw reference matters because it demonstrates the architecture at production scale. A governance pattern that works in a demo but not under real load is not a governance pattern — it is a demo. NeMo's production deployment, and NemoClaw's use of it, is the evidence that external guardrail enforcement scales to a real agent with a real tool surface and real adversarial traffic. This is the deployment maturity that makes NeMo the reference framework, not just an option. ## What external enforcement buys — and what it does not The governance-beneath-the-agent architecture buys the property that matters most: the guardrails run even when the agent is compromised. A prompt injection that takes over the model cannot disable the input rails, because the rails are not the model's code. A jailbreak that makes the model produce disallowed content cannot turn off the output rails, because the output rails are evaluated by a separate process the model's output merely passes through. What it does not buy is invulnerability. The guardrails are evaluated by models — embedding models for similarity checks, LLM-based classifiers for content categorization, the same class of model that the underlying agent uses. And models are injectable. The external architecture protects the guardrails from being *disabled* by a compromised agent; it does not protect the guardrails from being *evaded* by an input crafted against the guardrail's own model surface. That is the attack surface B08.3 covers. --- # B08.3 — The Attack Surface and Red-Teaming *The rails are model-evaluated, so they are injectable. The bypass vectors and the residuals.* ## The load-bearing vulnerability: the guardrail is a model Here is the central insight of this deep-dive, and it is the one that determines how a red-team approaches a NeMo-guardrailed system. The guardrails are evaluated by models. An input rail that detects toxicity uses an embedding model or a classifier; an output rail that checks for leaked data uses an LLM-based check; a dialog rail that determines whether a query is on-topic uses a model-based canonical-form matching. These models are themselves subject to prompt injection, adversarial inputs, and the full range of model-level attacks covered in SDD-B06. The external architecture protects the guardrails from being disabled — a compromised agent cannot reach the rail process to turn it off. But it does not protect the rail's classifier from being evaded. An attacker who crafts an input that the underlying model would comply with AND that the input rail's classifier does not flag has bypassed the guardrail without ever touching the rail process. The guardrail ran; it simply classified the adversarial input as benign, because its classifier is a model and the input was crafted against that model's blind spots. This is the same structural property as the model-layer finding from SDD-B06: a pattern-calibrated classifier has a novel-pattern bypass. The input rail's toxicity classifier was trained on known toxic patterns; an adversarial input crafted to avoid those patterns evades it. The output rail's LLM-based check can be manipulated if the response it is checking contains a prompt injection targeting the rail's own classifier model — the model evaluating the output is itself susceptible to injection in the text it is evaluating. ## Bypass vectors per rail type The specific attack surfaces, by rail type: - **Input rails — adversarial-input evasion.** The input rail's classifier (embedding model, toxicity detector, jailbreak-pattern matcher) has its own false-negative surface. An input crafted to avoid the classifier's known patterns — the context-specific attack technique from SDD-B06, applied to the rail's classifier rather than the underlying model — evades the rail. The red-team probes the input rail directly: submit adversarial variants, measure the rail's false-negative rate over N attempts, and identify the inputs that pass the rail AND trigger the underlying model. - **Output rails — classifier-targeting injection.** The output rail checks the model's response. If the response contains a prompt injection targeting the output rail's classifier model (e.g., embedded instructions that cause the classifier to categorize the response as benign), the rail can be manipulated. The red-team submits inputs designed to produce responses that contain rail-targeting injections, and measures whether the output rail is fooled. - **Dialog rails — canonical-form confusion.** The dialog rail matches the user's request to a canonical form to determine if it is on-topic. An adversarial request engineered to match an allowed canonical form while carrying a disallowed intent (the same indirection technique as indirect injection, SDD-B03) can pass the dialog rail. The red-team probes the canonical-form matcher with requests that are semantically disallowed but superficially on-topic. - **Retrieval rails — indirect-injection passthrough.** The retrieval rail governs content coming back from the retrieval store. If the rail does not adequately quarantine or filter untrusted retrieved content, an indirect injection embedded in a retrieved chunk passes through to the model (SDD-B03). The red-team poisons the retrieval store with injection payloads and measures the retrieval rail's filtering rate. - **Execution rails — tool-argument manipulation.** The execution rail checks the tool and arguments the model calls. If the rail validates the tool name but not the arguments (or validates the arguments with a weak check), a manipulated model can call an allowed tool with disallowed arguments. The red-team tests the execution rail with argument-level manipulation, per SDD-B04's function-call attack surface. Each bypass vector is a measurable residual. The red-team does not assert "the guardrail can be bypassed" — it measures the bypass rate over N attempts, under fixed parameters, the way InjecAgent (SDD-B03) measures injection rates. The rail's residual is the false-negative rate of its classifier against the attack class, and the layered composition's overall residual is the probability that an attack passes every rail in the chain. ## Measuring rail residuals The measurement methodology follows SDD-B03 and SDD-B06: run the attack N times under fixed parameters (rail configuration, underlying model version, temperature), count the successes, report the rate. For a NeMo-guardrailed system, the measurement has layers: the input-rail bypass rate (what fraction of adversarial inputs pass the input rail), the output-rail bypass rate (what fraction of disallowed responses pass the output rail), and the end-to-end bypass rate (what fraction of attacks produce a disallowed output to the user, having passed every rail in the chain). The end-to-end rate is the finding that matters. A 5% input-rail bypass rate and a 5% output-rail bypass rate compose (under independence) to a roughly 0.25% end-to-end rate — but the rails are not independent when they share an underlying model surface, and the composition is weaker than the independence calculation suggests if the same adversarial technique evades both. The red-team's measurement must test the composition, not just the individual rails, because the real attack passes the whole chain. ## The defense-in-depth synthesis The synthesis ties NeMo back to B2's thesis and the SDD-B04–SDD-B06 progression. NeMo Guardrails is the strongest production realization of the governance-beneath-the-agent principle, and it is a layer — not a boundary. The rails are model-evaluated, so they are injectable; each rail type has its bypass vector; the composition has a residual. This is the same conclusion every defense layer reached: CrabTrap's judge is injectable (SDD-B04), IronCurtain's deterministic policy has compilation residuals (SDD-B05), the model's refusal training falls in 5 queries (SDD-B06), and NeMo's guardrails have classifier-evasion residuals (this deep-dive). The prescription is the one the course has been building: layered defense, where each layer's bypass is bounded by the others. NeMo's input rails raise the bar and provide signal; the output rails catch what the input rails miss; the retrieval and execution rails govern the indirect-injection and tool-call surfaces; and beneath all of it, the deterministic boundary (IronCurtain-style) provides the limit the probabilistic rails cannot. A NeMo deployment that relies on the guardrails alone — without the deterministic boundary, without the harness controls from B4 — has the residuals this deep-dive measures. A NeMo deployment composed with the layered architecture has each residual bounded by the others, and that is the architecture that holds. --- ## Anti-Patterns ### Treating the guardrails as a boundary rather than a layer "NeMo's guardrails stop all disallowed content." Cure: the rails are model-evaluated classifiers with false-negative surfaces. Each rail type has a bypass vector (input-rail adversarial evasion, output-rail classifier-targeting injection, dialog-rail canonical-form confusion, retrieval-rail indirect-injection passthrough, execution-rail argument manipulation). The guardrails are a layer; the deterministic boundary (IronCurtain-style) is the limit they cannot provide. ### Assuming external enforcement means invulnerability "The rails run outside the agent, so they can't be bypassed." Cure: external enforcement protects the rails from being DISABLED by a compromised agent; it does not protect the rail's classifier from being EVADED by an input crafted against the classifier's model surface. The guardrail ran; it classified the adversarial input as benign, because its classifier is a model and the input was crafted against its blind spots. ### Reporting a single rail bypass as "NeMo is broken" "I got one input past the input rail." Cure: a single bypass is an anecdote. Measure the bypass RATE over N attempts under fixed parameters (rail config, model version, temperature), per SDD-B03 and SDD-B06. Report the per-rail rate AND the end-to-end composition rate. No rate, no finding. ### Testing individual rails but not the composition "The input rail has a 5% bypass rate; the output rail has 5%; so the system is at 0.25%." Cure: the rails are not independent when they share an underlying model surface. An adversarial technique that evades the input rail's classifier may also evade the output rail's classifier if both use the same model class. Measure the end-to-end composition directly — the real attack passes the whole chain, not one rail in isolation. ### Omitting the retrieval and execution rails "We configured input and output rails; that's enough." Cure: indirect injection arrives via retrieved content (SDD-B03) and tool-call manipulation via the execution surface (SDD-B04). A NeMo deployment without retrieval rails is open to indirect injection; without execution rails, it is open to tool-argument manipulation. All five rail types cover the conversation lifecycle; omitting any leaves its stage unguarded. ### Relying on programmable policy the author did not complete "The framework lets us write any rail." Cure: programmability means the policy is only as good as the policy author. A missing rail is a missing control, and the framework does not infer the policy the deployer should have written. Audit the rail configuration the way any security control is audited (B11); a rail set that omits the deployment-specific constraints is a rail set with gaps. --- ## Key Terms | Term | Definition | | --- | --- | | **NeMo Guardrails** | NVIDIA's open-source programmable guardrail framework; enforces policy between user and model through five rail types, evaluated externally to the agent | | **Input rails** | Run on the user's input before it reaches the model; check for disallowed content (toxicity, jailbreak patterns, PII, off-topic); first line of defense against prompt injection | | **Output rails** | Run on the model's output before it reaches the user; check for leaked data, harmful content, hallucinations; catches a model that complied despite the input rails | | **Dialog rails** | Govern conversation flow; determine if a request is on-topic, match canonical forms, steer along allowed paths; enforce "this agent only discusses X" | | **Retrieval rails** | Run on retrieved content in a RAG pipeline before it feeds the model; govern indirect prompt injection (SDD-B03) by filtering/quarantining untrusted chunks | | **Execution rails** | Govern tool/action execution; check the tool, arguments, and result; prevent disallowed tool invocation or argument manipulation (SDD-B04) | | **Colang** | NeMo's domain-specific language for conversational flow and rail definition; policy is code, not a fixed filter | | **Governance-beneath-the-agent** | The Course 1 Module 0.2 principle: enforcement must sit outside the agent's reach, so a compromised agent cannot disable it; NeMo's external evaluation realizes it | | **Rail residual** | A rail's false-negative rate against an attack class; the measurable bypass probability, measured over N attempts like InjecAgent (SDD-B03) | | **Guardrail is a model** | The load-bearing vulnerability: rails are evaluated by models (embedding models, LLM classifiers), so they are subject to the same injection/evasion risks as the model they guard | --- ## Lab Exercise See `07-lab-spec.md`. The lab has you build a simulated NeMo-style guardrail layer (five rail types with model-evaluated classifiers), craft adversarial inputs targeting each rail's classifier surface, measure the per-rail and end-to-end bypass rates over N attempts, and demonstrate the defense-in-depth composition. Python 3.10+ with type hints; no GPU; the rail classifiers and the underlying model are simulated so the lab runs deterministically offline. --- ## References 1. **NVIDIA NeMo Guardrails** — the open-source programmable guardrail framework; the primary subject of this deep-dive. `github.com/NVIDIA/nemo-guardrails`. 2. **Course 1 Module 0.2** — the governance-beneath-the-agent principle NeMo realizes; if the agent can reach the enforcement layer, a compromised agent can disable it. 3. **Course 1 DD-09 (NemoClaw)** — the production reference built on NeMo Guardrails; the +4 governance score from external enforcement. 4. **Course 2B B2 — The Injection-Defense Layer** — the defense-in-depth thesis (no single layer suffices); NeMo is a layer with residuals. 5. **Course 2B SDD-B03 — InjecAgent** — the measurement methodology for rail residuals; the retrieval rail governs indirect injection. 6. **Course 2B SDD-B04 — CrabTrap Offensive Analysis** — the judge is injectable; the execution rail governs the function-call surface. 7. **Course 2B SDD-B05 — IronCurtain Offensive Analysis** — the deterministic boundary that bounds the probabilistic rails' residuals. 8. **Course 2B SDD-B06 — RedAgent** — the model-layer finding (refusal falls in 5 queries); the same novel-pattern bypass applies to rail classifiers. 9. **OWASP Agentic AI Top 10 (2026)** — the guardrail-bypass vectors map to ASI05/ASI07 (governance-layer attacks). 10. **Colang** — NeMo's DSL for conversational flow and rail definition.