NVIDIANVIDIA-Certified Professional: Agentic AI2026-107.1 Integrate NVIDIA NeMo Guardrails for compliance and safety enforcement.
Place each rail before its consequence
Completed by the knowledge check
Learning objective
Explain NeMo Guardrails rail types: input, dialog, retrieval, execution, and output.
Core idea
A rail’s placement determines what it can inspect and which consequence it can prevent. Screening a user’s message cannot inspect a document retrieved afterwards. Rejecting a final answer cannot undo a tool action that already changed an external system.
NeMo Guardrails distinguishes five rail types across that lifecycle. Choose the stage first, then the detection or transformation mechanism. One business rule can need several stages because the same sensitive information can enter through a user message, a retrieved chunk, or a generated response. This lesson owns that placement decision; 7.1.2 covers configuration and 7.1.3 covers specialized safety detectors.
How it works
Follow the information through the interaction
Input rails inspect incoming user text before the main generation call. They can reject or transform it. In config.yml, the activation list is rails.input.flows; self check input is a policy-checking example, while mask sensitive data on input illustrates transformation. The choice between rejection and masking changes the text that subsequent processing receives.
Dialog rails constrain how a conversation proceeds after the user’s utterance has been associated with a canonical intent. Colang expresses the permitted interaction using user, bot, and flow definitions. In Colang 1.0, define user, define bot, and define flow connect example utterances, response forms, and the permitted sequence. Use this stage when the requirement concerns a conversation path rather than whether an isolated string contains harmful content.
Retrieval rails inspect knowledge-base chunks after retrieval. Their activation list is rails.retrieval.flows. The documented mask sensitive data on retrieval surface rewrites relevant_chunks; detect sensitive data on retrieval inspects it. This stage belongs between fetching context and allowing it to influence generation. Input screening alone leaves that separate entry point untreated.
Execution rails govern custom Python actions on the LLMRails path. The configuration schema exposes rails.actions, and Colang invokes functions registered with @action(); see 7.1.2 for configuration files. Distinguish this custom-action mechanism from tool rails, which validate the model’s own tool calls and results: tool call validation under rails.tool_output.flows and tool result validation under rails.tool_input.flows. Those directions are named relative to the model: it emits a call and consumes its result.
Output rails inspect the proposed bot response before delivery. Their list is rails.output.flows; self check output checks response policy, and self check facts checks factual support. A response that passes a content-safety classifier can still be unsupported by the retrieved information. Select the check for the property you need, rather than treating every output rail as an interchangeable safety score.
Match the rail to the engine
The five types describe enforcement locations, not a promise that every engine implements every configuration. The rail support matrix assigns retrieval surfaces to LLMRails; IORails does not accept a rails.retrieval section. A configuration requiring retrieval rails therefore cannot be moved to IORails merely to reduce orchestration overhead.
Engine Feature Support states that LLMRails runs input, output, dialog, retrieval, execution, and tool rails. IORails runs input, output, and tool rails; configurations requiring dialog, retrieval, or custom-action execution fall back to LLMRails. Thus, retaining retrieval inspection does not require giving up tool validation.
NVIDIA’s Tool Calling tutorial describes tool rails as IORails-only and experimental, while Engine Feature Support and Rail Engine Support mark them supported on both engines. Use the support references for the engine comparison, and verify the configured path in the deployed library.
The tutorial’s IORails integration supports OpenAI Chat Completions with openai and nim engines. Its checks run locally without extra model calls and fail closed on validation or parsing failures, unlike the jailbreak detector in 7.1.3. They validate declared tool names, argument schemas, and result consistency; the application still executes the tools. A structurally valid request does not establish the caller’s business authority to perform it.
Input, retrieval, tool, and output rails each inspect a different path into or out of the main generation call.
Key distinctions and trade-offs
Use the following comparison to place a requirement:
| Rail type | Deciding condition | Concrete mechanism | Cost or limitation |
|---|---|---|---|
| Input | User text must be screened before generation | rails.input.flows | Model-based screening adds work before a permitted request proceeds |
| Dialog | Turns must follow a permitted interaction | Colang define flow with canonical user and bot forms | Intent interpretation and flow maintenance need testing |
| Retrieval | Retrieved chunks need inspection or rewriting | rails.retrieval.flows, relevant_chunks | Filtering can remove useful context; requires the supported runtime |
| Execution | Custom actions need control before or after invocation | rails.actions, Colang, and @action() functions | Requires LLMRails; model tool-call validation is a separate tool-rail capability |
| Output | A generated response must be checked before delivery | rails.output.flows | Rejection occurs after generation cost has been spent |
A dialog rail and a topic classifier answer different questions. A classifier judges whether a message belongs to a subject; a dialog flow constrains what happens next in the conversation. Similarly, retrieval filtering limits the material entering generation, while output fact checking assesses the generated answer. Neither supplies the other’s observation point.
Architecture / decision scenario
A manufacturing company builds an employee maintenance assistant. Its stated design targets are a 3-second response deadline, no disclosure of personnel details from maintenance notes, and no maintenance-ticket submission before the assistant collects a machine identifier. A replay contains 500 requests: 30 have prohibited user text, 20 otherwise legitimate requests retrieve personnel details, 12 propose malformed ticket arguments, and 8 produce unsupported answers. These are scenario observations, not product benchmarks.
A tempting proposal checks only the final response because it needs one obvious enforcement location. The platform architect rejects that design: it notices prohibited content only after generation, and a final text rejection cannot prevent an earlier ticket submission. The separate failure counts show why one aggregate output score hides distinct paths.
The team assigns rails.input.flows to incoming-message screening and a Colang dialog flow to collecting the machine identifier. It assigns rails.retrieval.flows to the maintenance-note context and rails.output.flows to the proposed answer. These requirements retain LLMRails, which the support references also list as supporting tool validation. The team configures the model tool-call and tool-result checks on that path and tests them against malformed arguments. The ticket API owner still authorizes the operation before executing it.
The architect records the engine choice alongside each rail placement. The service owner measures the complete permitted path against 3 seconds, including checks that rejected requests never reach. Reducing latency by deleting retrieval inspection would remove the only stage that sees the 20 contaminated contexts before generation.
Common exam traps
- Treating user-input screening as inspection of retrieved documents or tool results.
- Choosing output moderation to prevent an external action that already ran.
- Equating a dialog flow with a topical classifier.
- Reading
tool_outputas the application’s returned tool result. - Assuming all five rail types are available on every engine.
- Treating schema-valid tool calls as authorized business operations.
What to remember
Place a rail where the relevant information exists and before the consequence you need to prevent. Input, dialog, retrieval, execution, and output rails inspect different parts of the interaction. Select the runtime from the required surfaces, and preserve application ownership of external actions.
Knowledge check
A support assistant on LLMRails retrieves internal wiki chunks for every answer. An input rail already masks personal data in user messages, but a replay shows employee phone numbers from retrieved chunks appearing in answers. The security owner requires the numbers to be removed before they can influence generation. Where should the team add the check?
rails.input.flowsrails.output.flowsrails.retrieval.flowsmask sensitive data on retrieval rewrites relevant_chunks at that point. An output rail could remove the numbers from the reply, but only after the model has generated from them, which the requirement rules out. A second input rail inspects the same user text again, and a dialog flow constrains the conversation path rather than the content of retrieved context.A team’s NeMo Guardrails configuration runs retrieval rails over a knowledge base and validates the model’s tool calls against their declared schemas. To reduce orchestration overhead, an engineer proposes moving the configuration to IORails. According to the Engine Feature Support and Rail Engine Support references, which assessment is correct?
LLMRails , which runs both the retrieval rails and the tool railsIORails , which runs both the retrieval rails and the tool railsIORails and run the retrieval checks in rails.input.flowsLLMRails and drop tool validation, which only IORails runsLLMRails only — IORails does not accept a rails.retrieval section — and mark tool rails as supported on both engines, so keeping LLMRails retains both checks. Moving the retrieval checks to the input list would leave them looking at user text instead of the retrieved chunks. The Tool Calling tutorial describes tool rails as IORails -only, so the engine comparison follows the support references, and the configured path is verified in the deployed library.An agent can call refund_order(order_id, amount). Tool call validation checks that every call names a declared tool and that its arguments match the tool’s JSON Schema. In a test, a customer persuades the agent to request a refund for another customer’s order, and the call passes validation. Which change addresses this failure?
order_idA maintenance assistant must not submit a work order until it has collected the machine identifier from the employee; submission runs as an action before the assistant replies. An input topic classifier already rejects messages unrelated to maintenance. Which rail type enforces the requirement?
References
- NVIDIA, Guardrail Types
- NVIDIA, Configuration YAML Schema Reference
- NVIDIA, Rail Engine Support
- NVIDIA, Tool Calling
- NVIDIA, Colang 1.0 Language Syntax
- NVIDIA, Engine Feature Support
- NVIDIA, NeMo Guardrails Library Configuration Overview