Presidio Integration

NeMo Guardrails supports detecting sensitive data out-of-the-box using Presidio, which provides fast identification and anonymization modules for private entities in text such as credit card numbers, names, locations, social security numbers, bitcoin wallets, US phone numbers, financial data and more. You can detect sensitive data on user input, bot output, or the relevant chunks retrieved from the knowledge base.

Setup

To use the built-in sensitive data detection rails, you must install Presidio and download the en_core_web_lg model for spacy.

$
pip install presidio-analyzer presidio-anonymizer spacy
$
python -m spacy download en_core_web_lg

As an alternative, you can also use the sdd extra.

$
pip install nemoguardrails[sdd]
$
python -m spacy download en_core_web_lg

Usage

You can activate sensitive data detection in three ways: input rail, output rail, and retrieval rail.

Input Rail

To activate a sensitive data detection input rail, you have to configure the entities that you want to detect:

1
rails:
2
  config:
3
    sensitive_data_detection:
4
      input:
5
        entities:
6
          - PERSON
7
          - EMAIL_ADDRESS
8
          - ...

For the complete list of supported entities, please refer to Presidio - Supported Entities page.

Also, you have to add the detect sensitive data on input or mask sensitive data on input flows to the list of input rails:

1
rails:
2
  input:
3
    flows:
4
      - ...
5
      - mask sensitive data on input     # or 'detect sensitive data on input'
6
      - ...

When using detect sensitive data on input, if sensitive data is detected, the bot will refuse to respond to the user’s input. When using mask sensitive data on input the bot will mask the sensitive parts in the user’s input and continue the processing.

Output Rail

The configuration for the output rail is very similar to the input rail:

1
rails:
2
  config:
3
    sensitive_data_detection:
4
      output:
5
        entities:
6
          - PERSON
7
          - EMAIL_ADDRESS
8
          - ...
9
10
  output:
11
    flows:
12
      - ...
13
      - mask sensitive data on output     # or 'detect sensitive data on output'
14
      - ...

Retrieval Rail

The configuration for the retrieval rail is very similar to the input/output rail:

1
rails:
2
  config:
3
    sensitive_data_detection:
4
      retrieval:
5
        entities:
6
          - PERSON
7
          - EMAIL_ADDRESS
8
          - ...
9
10
  retrieval:
11
    flows:
12
      - ...
13
      - mask sensitive data on retrieval     # or 'detect sensitive data on retrieval'
14
      - ...

Score Threshold

To avoid false positives when detecting sensitive data entities, you can adjust the score_threshold parameter. This threshold defines the minimum confidence value required for a detected entity to be returned. By setting a higher score_threshold, you can reduce false positives by requiring a higher confidence level for detected entities. The default value for this parameter is 0.2.

The score_threshold parameter can be configured for any of the above sources (input, output and retrieval) to filter out sensitive data entities with a score above the defined threshold. Below is an example configuration that adjusts the score_threshold for a specific case:

1
rails:
2
  config:
3
    sensitive_data_detection:
4
      input:
5
        score_threshold: 0.6
6
        entities:
7
          - PERSON
8
          - EMAIL_ADDRESS
9
          - ...
10
      output:
11
        score_threshold: 0.6
12
        entities:
13
          - PERSON
14
          - EMAIL_ADDRESS
15
          - ...

For additional guidance on handling undetected PII entities and minimizing false negatives, refer to the Presidio FAQ.

Custom Recognizers

If you have custom entities that you want to detect, you can define custom recognizers. For more details, check out this tutorial and this example.

Below is an example of configuring a TITLE entity and detecting it inside the input rail.

1
rails:
2
  config:
3
    sensitive_data_detection:
4
      recognizers:
5
        - name: "Titles recognizer"
6
          supported_language: "en"
7
          supported_entity: "TITLE"
8
          deny_list:
9
            - Mr.
10
            - Mrs.
11
            - Ms.
12
            - Miss
13
            - Dr.
14
            - Prof.
15
      input:
16
        entities:
17
          - PERSON
18
          - TITLE

Custom Detection

If you want to implement a completely different sensitive data detection mechanism, you can override the default actions detect_sensitive_data and mask_sensitive_data.

Engine Support

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.

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.