NRP and PERSON PII entities cause false positives in natural language text

[pabloiea1995]

Summary

The NRP and PERSON PII entity types use overly broad regex patterns that match common natural language text, causing excessive false positives and breaking normal conversation flow when used in pre-flight masking mode.

Problem Description

When using the PII guardrail with NRP or PERSON entities enabled, normal conversational text gets incorrectly masked as PII. This makes the guardrail unusable for applications that need to preserve natural language while only masking actual sensitive information.

Example:

• Input: "crea un nuevo cliente con email test@gmail.com" (Spanish for "create a new client with email test@gmail.com")
• Expected output: "crea un nuevo cliente con email <EMAIL_ADDRESS>"
• Actual output: "<NRP> <NRP> con email <EMAIL_ADDRESS>"

The text "crea un" and "nuevo cliente" are incorrectly identified as PII and masked.

Root Cause

The regex patterns for these entities are too broad:

[PIIEntity.NRP]: [{ regex: /\b[A-Za-z]+ [A-Za-z]+\b/g }],
[PIIEntity.PERSON]: [{ regex: /\b[A-Z][a-z]+ [A-Z][a-z]+\b/g }],

• NRP: Matches any two consecutive words (e.g., "crea un", "nuevo cliente", "the user")
• PERSON: Matches any capitalized two-word pattern (e.g., "John Smith", but also "New York", "The User")

Impact

1. Natural language conversations in any language are heavily distorted
2. Non-English languages (Spanish, French, etc.) are particularly affected since common words match the pattern
3. Pre-flight masking becomes unusable - the LLM receives garbled input
4. No documentation exists explaining what NRP stands for or its intended use case

Current Workaround

Remove NRP and PERSON from the entities list:

{
  "name": "Contains PII",
  "config": {
    "entities": [
      "EMAIL_ADDRESS",
      "PHONE_NUMBER",
      "US_SSN",
      "CREDIT_CARD"
    ],
    "block": false
  }
}

Environment

• Package: openai-guardrails-js
• Version: main branch (as of November 2025)
• Pipeline stage: pre_flight
• Mode: block: false (masking mode)

Reproduction Steps

1. Create a guardrail configuration with NRP in the entities list:

const config = {
  version: 1,
  pre_flight: {
    version: 1,
    guardrails: [{
      name: 'Contains PII',
      config: {
        entities: ['NRP', 'EMAIL_ADDRESS'],
        block: false
      }
    }]
  }
};

2. Send a message with normal text: "crea un nuevo cliente con email test@gmail.com"

3. Observe that common words are masked: "<NRP> <NRP> con email <EMAIL_ADDRESS>"

Proposed Solutions

Option 1: Remove these entities (Recommended)

• Remove NRP and PERSON from the default entity list
• Add deprecation warning if they're used
• Update documentation to warn against using them

Option 2: Make patterns more specific

• NRP: If it's meant for National Registration Numbers, replace with specific country patterns (like SG_NRIC_FIN, UK_NINO)
• PERSON: Add more context requirements (e.g., require honorifics, titles, or surrounding context)

Option 3: Document intended use case

• If these entities have a specific legitimate use case, document it clearly
• Add warnings about false positives in conversational contexts
• Provide examples of when to use vs. when to avoid

Additional Context

The codebase has no documentation explaining what NRP stands for or its intended purpose:

• Source: src/checks/pii.ts:305
• No comments or documentation exist for this entity type
• The pattern suggests it might stand for "Name Recognition Pattern" but this is unclear

Other PII entities have specific, well-defined patterns (SSN: \d{3}-\d{2}-\d{4}, Email: standard email regex), but NRP and PERSON are anomalously broad.

Related Files

• src/checks/pii.ts - Entity definitions (lines 83, 305)
• docs/ref/checks/pii.md - PII documentation (no mention of NRP)

Checklist for Maintainers

• Clarify what NRP stands for and its intended use case
• Either improve patterns or deprecate these entities
• Add documentation warnings about false positives
• Add tests for non-English language handling
• Update examples to exclude problematic entities