Skip to main content

Input Rails

Input rails execute before the LLM processes user input. They validate, sanitize, and filter user messages to protect against jailbreaks, prompt injections, content policy violations, and sensitive data leaks.

When Input Rails Execute

Input rails run immediately after receiving user input and before any LLM processing:
If an input rail blocks the message, the LLM is never called, saving costs and preventing potential security issues.

Built-in Input Rails

Jailbreak Detection

Detects attempts to bypass guardrails using heuristics or trained classifiers.

Configuration

Available Actions

Heuristic-based detection (nemoguardrails/library/jailbreak_detection/actions.py:56):
Model-based detection (nemoguardrails/library/jailbreak_detection/actions.py:91):
When server_endpoint is not configured, detection runs in-process. This is NOT RECOMMENDED FOR PRODUCTION due to performance overhead.

NIM-based Detection

For production deployments, use NVIDIA NIM:

Content Safety

Uses specialized models like Llama Guard or NeMoGuard to check for policy violations.

Configuration

Action Implementation

From nemoguardrails/library/content_safety/actions.py:42:

Multilingual Support

Supported languages: en, es, zh, de, fr, hi, ja, ar, th

Self Check Input

Uses the main LLM to validate its own inputs.

Configuration

Action Implementation

From nemoguardrails/library/self_check/input_check/actions.py:33:
Self-check rails use the main LLM, so they add latency. Consider using specialized models for production.

Llama Guard

Meta’s content moderation model with customizable safety policies.

Configuration

Action Implementation

From nemoguardrails/library/llama_guard/actions.py:55:
Response format:

Sensitive Data Detection

Detects and masks PII using Microsoft Presidio.

Configuration

Action Implementation

From nemoguardrails/library/sensitive_data_detection/actions.py:93:

Masking Sensitive Data

Presidio requires additional dependencies:

Usage Examples

Combining Multiple Input Rails

Rails execute in the order specified. If any rail blocks the input, processing stops.

Parallel Execution

For better performance, configure parallel execution:

Custom Response on Block

Define flows to handle blocked inputs:

Best Practices

  1. Layer your defenses - Use multiple complementary rails (e.g., jailbreak + content safety)
  2. Use specialized models - Content safety models are faster and more accurate than LLM self-checks
  3. Enable caching - Reduce latency by caching rail results for repeated inputs
  4. Monitor performance - Track rail execution times and block rates
  5. Customize thresholds - Tune sensitivity based on your use case

See Also