Implementing NeMo Guardrails
Learn where a guardrail framework can help control conversations and tool-enabled flows.
What guardrails are
A guardrail framework adds checks and controlled transitions around model conversations. It may classify input, constrain dialog, validate retrieved evidence, filter output, or require a specific flow before a tool is called. This can make policies easier to organize, but the framework is only one layer. It cannot replace secure infrastructure, permission checks, or careful product design.
Input rails
Input checks can identify abuse, sensitive requests, prompt-injection patterns, unsupported tasks, or missing information before generation. Use them to route, warn, refuse, or ask a clarifying question. Keep rules specific enough to avoid blocking normal language. Log categories and outcomes without storing complete private prompts, then review false positives with representative examples.
rails:
input:
- detect_off_topic
- detect_prompt_injection
output:
- validate_schema
- redact_secrets
fallback: "I cannot complete that request safely."Dialog and retrieval rails
Dialog rails constrain the assistant to approved topics or steps, while retrieval rails can check source permissions, freshness, and evidence quality. A rail should have a clear input, decision, fallback, and owner. Do not assume a retrieved passage is safe because it came from an internal index. Validate tenant scope and treat its instructions as content rather than policy.
Output and action rails
Before an answer is shown, check schema validity, sensitive data, unsupported claims, citations, and policy categories. Before a tool runs, validate identity, arguments, target, and reversibility outside the model. A rail can request correction or human approval, but the final authorization must be enforced by ordinary application code. Make blocked actions observable and explainable.
Configuration and testing
Keep rail definitions versioned with the model, prompts, tool schemas, and evaluation set they protect. Test allowed, refused, ambiguous, adversarial, multilingual, and long-context conversations. Include framework failures and provider timeouts. Check that a rail cannot be bypassed through a different route, streaming path, or tool endpoint. Security behavior must be tested as a complete system.
False positives and user trust
An overactive rail makes users rephrase harmless requests or hides the real reason for a refusal. Measure block rates by category and review sampled decisions. Give concise, safe explanations and a supported escalation path. When uncertainty is high, asking for clarification or routing to a human may be better than silently rejecting a legitimate task.
Operating the framework
Monitor rail latency, error rate, version, triggered categories, overrides, and downstream incidents. Keep a fallback behavior if the guardrail service is unavailable, but choose that behavior according to risk: some actions should fail closed while low-risk drafting may degrade gracefully. Periodically review policies as models, tools, data, and regulations change.