Skip to content
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
66 changes: 66 additions & 0 deletions docs/configure-rails/guardrail-catalog/agentic-security.mdx
Original file line number Diff line number Diff line change
Expand Up @@ -131,3 +131,69 @@ Before you begin, install the `yara-python` package or you can install the NeMo
*Example Output*

<Code src="../../../examples/configs/injection_detection/demo-out.txt" language="text" title="demo-out.txt" lines="2-2" />

## Context Bloat Detection

Context bloat detection guards against context-manipulation attacks.
Attacker-controlled content can be padded, oversized, or repetitively structured to push the system prompt out of the model's attention or exhaust the token budget.
The rail applies to user input and retrieved knowledge-base chunks, the two sources of text an agent does not author.

The rail is local and model-free.
It does not call an external service and measures text against four thresholds:

| Check | Configuration Field | Default | What It Catches |
|---|---|---|---|
| Size cap | `max_chars` | `5000` | Oversized input intended to exhaust the token budget |
| Shannon entropy floor | `min_entropy` | `3.5` | Low-information padding. English prose runs about 4.0 to 4.5 bits per character |
| Repeated n-gram ratio | `max_repetition_ratio` | `0.4` | Padding built from a repeated phrase |
| Longest single-character run | `max_run_ratio` | `0.1` | Runs such as `AAAAAAA...` or long whitespace padding |

Texts shorter than `min_chars` (default `50`) are checked against the size cap only, because entropy and repetition are not meaningful on a short string.

### Configuring Context Bloat Detection

Add the flow for each direction you want to guard, and set the thresholds under `rails.config.context_bloat_detection`.
All configuration fields are optional.

```yaml
rails:
config:
context_bloat_detection:
max_chars: 5000
min_chars: 50
min_entropy: 3.5
max_repetition_ratio: 0.4
ngram_size: 3
max_run_ratio: 0.1
action: reject

input:
flows:
- context bloat detection on input

retrieval:
flows:
- context bloat detection on retrieval
```

The `action` field selects what happens when a check detects a violation:

| Value | Behavior |
|---|---|
| `reject` | Block the turn and return a refusal message. This is the default and recommended setting for production. |
| `truncate` | Truncate the text to `max_chars` when the size cap is exceeded, and reject when any other check detects a violation. |
| `warn` | Log the detection only. Do not modify or block the text. |

<Note>
With `action: truncate`, the rail rewrites the text it checked rather than blocking it.
This rewrite affects how the engines schedule the rail.
Refer to [Rail Engine Support](/reference/rail-engine-support) for details.
</Note>

### Engine Support

`context bloat detection on input` runs on both `LLMRails` and `IORails`.

`context bloat detection on retrieval` runs on `LLMRails` only, because `IORails` has no retrieval pipeline.
A configuration that declares a `rails.retrieval` section routes to `LLMRails` by default.
With `require_iorails=True`, `Guardrails` raises `ValueError` instead of falling back.
10 changes: 10 additions & 0 deletions docs/configure-rails/guardrail-catalog/community/alignscore.mdx
Original file line number Diff line number Diff line change
Expand Up @@ -92,3 +92,13 @@ Installing AlignScore is not supported on Python 3.11.
```

By default, the AlignScore server listens on port `5000`. You can change the port using the `--port` option. By default, the AlignScore server loads only the base model. You can load only the large model using `--models=large` or both models using `--models=base --models=large`.

## Engine Support

`alignscore check facts` runs on `LLMRails` only.

The rail compares the bot response against `relevant_chunks`, a conversation value that the Colang retrieval pipeline builds and `IORails` does not.
A configuration that uses this rail routes to `LLMRails` by default.
With `require_iorails=True`, `Guardrails` raises `ValueError` instead of falling back.

For the full per-rail matrix, refer to [Rail Engine Support](/reference/rail-engine-support).
18 changes: 18 additions & 0 deletions docs/configure-rails/guardrail-catalog/community/auto-align.mdx
Original file line number Diff line number Diff line change
Expand Up @@ -716,3 +716,21 @@ Specify the fact_check_endpoint to the correct AutoAlign environment.
Then set to the corresponding subflows for fact check guardrail.

The output of the fact check endpoint provides you with a fact check score that combines the factual correctness of various statements made by the bot response. Then provided with a user set threshold, will log a warning if the bot response is determined to be factually incorrect

## Engine Support

| Flow | LLMRails | IORails |
|---|:---:|:---:|
| `autoalign check input` | ✓ | ✓ |
| `autoalign check output` | ✓ | ✓ |
| `autoalign factcheck output` | ✓ | ✓ |
| `autoalign groundedness output` | ✓ | ✗ |

`autoalign groundedness output` reads `relevant_chunks_sep`, a conversation value that the Colang retrieval pipeline builds and `IORails` does not.
A configuration that uses it routes to `LLMRails` by default.
With `require_iorails=True`, `Guardrails` raises `ValueError` instead of falling back.

`autoalign check input` and `autoalign check output` can rewrite the text they check when AutoAlign returns redacted content.
`IORails` runs input and output rails sequentially when a configured rail rewrites content.

For the full per-rail matrix, refer to [Rail Engine Support](/reference/rail-engine-support).
14 changes: 14 additions & 0 deletions docs/configure-rails/guardrail-catalog/community/fiddler.mdx
Original file line number Diff line number Diff line change
Expand Up @@ -50,3 +50,17 @@ Fiddler Guardrails will not block inputs in the event of any API failure.
## Notes

For more information about Fiddler Guardrails, please visit the Fiddler Guardrails [documentation](https://docs.fiddler.ai/protection/guardrails).

## Engine Support

| Flow | LLMRails | IORails |
|---|:---:|:---:|
| `fiddler user safety` | ✓ | ✓ |
| `fiddler bot safety` | ✓ | ✓ |
| `fiddler bot faithfulness` | ✓ | ✗ |

`fiddler bot faithfulness` scores the response against `relevant_chunks`, a conversation value that the Colang retrieval pipeline builds and `IORails` does not.
A configuration that uses it routes to `LLMRails` by default, including one that also uses the two safety flows.
Comment thread
coderabbitai[bot] marked this conversation as resolved.
Resolved
With `require_iorails=True`, `Guardrails` raises `ValueError` instead of falling back.

For the full per-rail matrix, refer to [Rail Engine Support](/reference/rail-engine-support).
57 changes: 57 additions & 0 deletions docs/configure-rails/guardrail-catalog/community/gliner.mdx
Original file line number Diff line number Diff line change
Expand Up @@ -107,6 +107,63 @@ rails:
- gliner mask pii on output
```

### Retrieved Chunks

Both flows also have a retrieval variant that runs against the knowledge-base chunks retrieved for a turn.
Configure the entities to look for under a `retrieval` key alongside `input` and `output`, then add one of the two retrieval flows.

Choose the detection flow to block a turn whose retrieved chunks contain PII:

```yaml
rails:
config:
gliner:
server_endpoint: https://integrate.api.nvidia.com/v1/chat/completions
api_key_env_var: NVIDIA_API_KEY
threshold: 0.5
retrieval:
entities:
- first_name
- last_name
- email
- phone_number
retrieval:
flows:
- gliner detect pii on retrieval
```

Choose the masking flow instead to strip the PII from the chunks and let the turn proceed:

```yaml
rails:
config:
gliner:
server_endpoint: https://integrate.api.nvidia.com/v1/chat/completions
api_key_env_var: NVIDIA_API_KEY
threshold: 0.5
retrieval:
entities:
- first_name
- last_name
- email
- phone_number
retrieval:
flows:
- gliner mask pii on retrieval
```

Typically, configure only one retrieval flow.
If you configure both flows, list `gliner mask pii on retrieval` before `gliner detect pii on retrieval`.
Retrieval rails run in configuration order, so placing detection first blocks the turn before masking can make the chunks safe.

### Engine Support

The input and output flows run on both `LLMRails` and `IORails`.

`gliner detect pii on retrieval` and `gliner mask pii on retrieval` run on `LLMRails` only, because `IORails` has no retrieval pipeline.
A configuration that declares a `rails.retrieval` section routes to `LLMRails` by default.
Comment thread
coderabbitai[bot] marked this conversation as resolved.
Resolved
With `require_iorails=True`, `Guardrails` raises `ValueError` instead of falling back.

## Run the Guardrails Chat CLI

Start an interactive chat session by pointing `--config` at the subdirectory for the flow you want to test:
Expand Down
18 changes: 18 additions & 0 deletions docs/configure-rails/guardrail-catalog/community/hf-classifier.mdx
Original file line number Diff line number Diff line change
Expand Up @@ -276,3 +276,21 @@ rails:
## HF Classifier Rail Behavior

When blocked, **input and output rails** respond with `"I'm sorry, I can't respond to that."` and abort. If `enable_rails_exceptions` is set, an `InputRailException` or `OutputRailException` is raised instead. **Retrieval rails** clear all retrieved chunks if any blocked label is detected. With streaming enabled, the output rail checks the accumulated response after streaming completes.

## Engine Support

| Flow | LLMRails | IORails |
|---|:---:|:---:|
| `hf classifier check input` | ✓ | ✓ |
| `hf classifier check output` | ✓ | ✓ |
| `hf classifier check retrieval` | ✓ | ✗ |

`hf classifier check retrieval` clears the retrieved chunks when a blocked label is detected, which rewrites `relevant_chunks`.
`IORails` has no retrieval pipeline and nowhere to apply that rewrite, so the flow runs on `LLMRails` only.

This rail declares `transformers` as an optional dependency for its in-process backend.
`IORails` enforces this dependency only when the configuration selects the local backend.
With a vLLM, KServe, or FMS endpoint, the rail compiles without `transformers` installed.
`LLMRails` imports it lazily and fails on the first request instead.

For the full per-rail matrix, refer to [Rail Engine Support](/reference/rail-engine-support).
Original file line number Diff line number Diff line change
Expand Up @@ -76,3 +76,14 @@ define flow patronus api check output
if not $evaluation_passed
bot inform answer unknown
```

## Engine Support

`patronus api check output` runs on `LLMRails` only.

The rail sends the retrieved context alongside the question and answer.
It therefore reads `relevant_chunks`, a conversation value that the Colang retrieval pipeline builds and `IORails` does not.
A configuration that uses this rail routes to `LLMRails` by default.
With `require_iorails=True`, `Guardrails` raises `ValueError` instead of falling back.

For the full per-rail matrix, refer to [Rail Engine Support](/reference/rail-engine-support).
10 changes: 10 additions & 0 deletions docs/configure-rails/guardrail-catalog/community/patronus-lynx.mdx
Original file line number Diff line number Diff line change
Expand Up @@ -159,3 +159,13 @@ define flow patronus lynx check output hallucination
bot inform answer unknown
stop
```

## Engine Support

`patronus lynx check output hallucination` runs on `LLMRails` only.

Lynx judges the response against the retrieved context, so the rail reads `relevant_chunks`, a conversation value that the Colang retrieval pipeline builds and `IORails` does not.
A configuration that uses this rail routes to `LLMRails` by default.
With `require_iorails=True`, `Guardrails` raises `ValueError` instead of falling back.

For the full per-rail matrix, refer to [Rail Engine Support](/reference/rail-engine-support).
17 changes: 17 additions & 0 deletions docs/configure-rails/guardrail-catalog/community/polygraf.mdx
Original file line number Diff line number Diff line change
Expand Up @@ -124,3 +124,20 @@ The integration is fail-closed: a Polygraf failure must not allow potentially-PI
- **Malformed entity span** (Polygraf returns an entry without a known `entity_type`, or with non-integer offsets, or with offsets outside `0 <= start < end <= len(text)`). The actions also fail closed: detection blocks the message and masking redacts the whole payload, rather than silently skipping the malformed span and forwarding the rest.
- **Default timeout**: `30` seconds per call. Slow or unreachable endpoints cannot hang the rail pipeline.
- **Missing API key**: if `POLYGRAF_API_KEY` is not set, the integration logs a warning since cloud endpoints typically reject unauthenticated requests, and proceeds to call the endpoint without an `Authorization` header.

## Engine Support

| Flow | LLMRails | IORails |
|---|:---:|:---:|
| `polygraf detect pii on input`, `polygraf detect pii on output` | ✓ | ✓ |
| `polygraf mask pii on input`, `polygraf mask pii on output` | ✓ | ✓ |
| `polygraf detect pii on retrieval`, `polygraf mask pii on retrieval` | ✓ | ✗ |

The retrieval flows run on `LLMRails` only, because `IORails` has no retrieval pipeline.
A configuration that declares a `rails.retrieval` section routes to `LLMRails` by default.
With `require_iorails=True`, `Guardrails` raises `ValueError` instead of falling back.

The masking flows rewrite the text they check rather than blocking it.
`IORails` runs input and output rails sequentially when a configured rail rewrites content, so each mask reaches subsequent rails.

For the full per-rail matrix, refer to [Rail Engine Support](/reference/rail-engine-support).
21 changes: 21 additions & 0 deletions docs/configure-rails/guardrail-catalog/community/presidio.mdx
Original file line number Diff line number Diff line change
Expand Up @@ -156,3 +156,24 @@ rails:
## Custom Detection

If you want to implement a completely different sensitive data detection mechanism, you can override the default actions [`detect_sensitive_data`](https://github.com/NVIDIA-NeMo/Guardrails/tree/develop/nemoguardrails/library/sensitive_data_detection/actions.py) and [`mask_sensitive_data`](https://github.com/NVIDIA-NeMo/Guardrails/tree/develop/nemoguardrails/library/sensitive_data_detection/actions.py).

## Engine Support

| Flow | LLMRails | IORails |
|---|:---:|:---:|
| `detect sensitive data on input`, `detect sensitive data on output` | ✓ | ✓ |
| `mask sensitive data on input`, `mask sensitive data on output` | ✓ | ✓ |
| `detect sensitive data on retrieval`, `mask sensitive data on retrieval` | ✓ | ✗ |

The retrieval flows run on `LLMRails` only, because `IORails` has no retrieval pipeline.
A configuration that declares a `rails.retrieval` section routes to `LLMRails` by default.
With `require_iorails=True`, `Guardrails` raises `ValueError` instead of falling back.

This rail declares the `sdd` extra, and the two engines report a missing install differently.
`IORails` refuses to compile the rail at startup and names the extra to install, so the configuration routes to `LLMRails` by default.
`LLMRails` imports Presidio lazily inside the action, so the failure surfaces on the first request that runs the rail.
Comment thread
coderabbitai[bot] marked this conversation as resolved.
Resolved

The masking flows rewrite the text they check rather than blocking it.
`IORails` runs input and output rails sequentially when a configured rail rewrites content, so each mask reaches subsequent rails.

For the full per-rail matrix, refer to [Rail Engine Support](/reference/rail-engine-support).
17 changes: 17 additions & 0 deletions docs/configure-rails/guardrail-catalog/community/privateai.mdx
Original file line number Diff line number Diff line change
Expand Up @@ -93,3 +93,20 @@ If the Private AI detection API request fails, the system will assume PII is pre
- The integration currently supports PII detection and masking.

For more information on Private AI and its capabilities, please refer to the [Private AI documentation](https://docs.private-ai.com/?utm_medium=github&utm_campaign=nemo-guardrails).

## Engine Support

| Flow | LLMRails | IORails |
|---|:---:|:---:|
| `detect pii on input`, `detect pii on output` | ✓ | ✓ |
| `mask pii on input`, `mask pii on output` | ✓ | ✓ |
| `detect pii on retrieval`, `mask pii on retrieval` | ✓ | ✗ |

The retrieval flows run on `LLMRails` only, because `IORails` has no retrieval pipeline.
A configuration that declares a `rails.retrieval` section routes to `LLMRails` by default.
With `require_iorails=True`, `Guardrails` raises `ValueError` instead of falling back.

The masking flows rewrite the text they check rather than blocking it.
`IORails` runs input and output rails sequentially when a configured rail rewrites content, so each mask reaches subsequent rails.

For the full per-rail matrix, refer to [Rail Engine Support](/reference/rail-engine-support).
13 changes: 13 additions & 0 deletions docs/configure-rails/guardrail-catalog/community/regex.mdx
Original file line number Diff line number Diff line change
Expand Up @@ -203,3 +203,16 @@ When a regex rail has a regex pattern match, the following steps happen (dependi
1. Chunks that match any retrieval pattern are **removed** from the retrieval results. Only non-matching chunks are passed to the model as context.

**NOTE:** The matched pattern(s) are available in `result["detections"]` for logging and debugging. They are also logged at `INFO` level by the action.

## Engine Support

| Flow | LLMRails | IORails |
|---|:---:|:---:|
| `regex check input` | ✓ | ✓ |
| `regex check output` | ✓ | ✓ |
| `regex check retrieval` | ✓ | ✗ |

`regex check retrieval` removes matching chunks from the retrieval results, which rewrites `relevant_chunks`.
`IORails` has no retrieval pipeline and nowhere to apply that rewrite, so the flow runs on `LLMRails` only.

For the full per-rail matrix, refer to [Rail Engine Support](/reference/rail-engine-support).
25 changes: 25 additions & 0 deletions docs/configure-rails/guardrail-catalog/fact-checking.mdx
Original file line number Diff line number Diff line change
Expand Up @@ -235,3 +235,28 @@ rails:
```

For more details, check out the [Patronus Lynx Integration](/configure-guardrails/guardrail-catalog/third-party/patronus-lynx) page.

## Engine Support

Every rail in the following table runs on `LLMRails` only.

| Flow | Reads | LLMRails | IORails |
|---|---|:---:|:---:|
| `self check facts` | `relevant_chunks` | ✓ | ✗ |
| `self check hallucination` | `_last_bot_prompt` | ✓ | ✗ |
| `alignscore check facts` | `relevant_chunks` | ✓ | ✗ |
| `patronus lynx check output hallucination` | `relevant_chunks` | ✓ | ✗ |

Each of these rails judges a response against something outside the response itself, and reads a conversation value that the Colang runtime builds and `IORails` does not.

The three grounding rails read `relevant_chunks`, the retrieved context for the turn.
`self check hallucination` works differently: it reads `_last_bot_prompt`, reruns the prompt at a high temperature, and compares the alternative generations for self-consistency.
`patronus lynx check output hallucination` grounds the response against retrieved context.
In contrast, `self check hallucination` needs no retrieval and is unavailable on `IORails` because the prompt it reruns is Colang state.

A configuration that uses any of them routes to `LLMRails` by default.
With `require_iorails=True`, `Guardrails` raises `ValueError` instead of falling back.

If you need a grounding check on `IORails`, `autoalign factcheck output` and `cleanlab trustworthiness` both run there, because they judge the response without a retrieval context.

For the full per-rail matrix, refer to [Rail Engine Support](/reference/rail-engine-support).
17 changes: 16 additions & 1 deletion docs/configure-rails/guardrail-catalog/jailbreak-protection.mdx
Original file line number Diff line number Diff line change
Expand Up @@ -116,10 +116,25 @@ When a configured detector cannot be reached, the rail allows the request instea

A connection failure, a timeout, and an error response all produce the same outcome, for both the heuristics server and the jailbreak detection NIM.
The rail logs the failure, allows the request, and returns no error to the caller, so a detector outage removes this protection without a visible signal.
`LLMRails` and `IORails` behave identically here.
The rail decides this itself, so it fails open on both engines rather than falling into either engine's error handling.

Monitor the availability of your detector if you rely on this rail, and pair it with rails that do not call an external service.

### Engine Support

| Flow | LLMRails | IORails |
|---|:---:|:---:|
| `jailbreak detection model` | ✓ | ✓ |
| `jailbreak detection heuristics` | ✓ | ✗ |

`jailbreak detection heuristics` shares a rail manifest with `jailbreak detection model`, and that manifest declares `torch` and `transformers` as optional dependencies.
`IORails` cannot tell from the manifest alone which of the two flows a configuration is using, and so cannot tell whether those packages are actually required.
Rather than guess, it refuses the flow, and a configuration that uses it routes to `LLMRails` by default.
With `require_iorails=True`, `Guardrails` raises `ValueError` instead of falling back.
This is tracked in [issue #2285](https://github.com/NVIDIA-NeMo/Guardrails/issues/2285).

For the full per-rail matrix, refer to [Rail Engine Support](/reference/rail-engine-support).

### Setup

The recommended way to use the jailbreak detection heuristics in production is to [deploy the jailbreak detection heuristics server](/more-deployment-options/using-docker#jailbreak-detection-heuristics) separately. For a hands-on configuration walkthrough, see [Use Jailbreak Detection Heuristics](/get-started/tutorials/jailbreak-detection-heuristics).
Expand Down
Loading
Loading