Portal Community
Use Case

PII Protection in AI Workflows

Prevent customer personally identifiable information from entering AI models, third-party APIs, or appearing in workflow outputs — automatically, with no changes to node code.

The Problem

A financial services workflow processes loan applications. The data payload includes:

This data flows into an LLM-calling node for risk analysis. Without GuardRails, the raw SSN and credit card number are sent to the AI model — a GDPR and PCI-DSS violation. The AI model response may also echo the sensitive data back in its output.

The Solution: Two-Layer PII Pipeline

1

Pre — PiiDetectionGuard blocks PII at the gate

Before the AI model is called, PiiDetectionGuard scans the input. It detects SSN, Email, CreditCard. Returns Blocked. The AI API call never happens.

✗

AI model call is blocked

The node executor never reaches its ExecuteInternalAsync. The workflow returns an error to the caller: "PII detected in input: SSN, Email, CreditCard".

For scenarios where the node must process the data (with appropriate authorization), configure the Post-phase redaction instead:

1

Pre — PiiDetectionGuard with delayed enforcement

Guard runs and records violations but does not block immediately. The authorized node processes the data.

N

Node executes with authorized access

The AI model call proceeds. The response may contain reflected or derived PII.

2

Post — PiiRedactionGuard masks the output

The AI model response is scanned. Any SSN, email, or credit card number in the response is masked with * characters before it reaches the caller.

Configuration

{
  "guardRails": {
    "individual": [

      // Block mode: detect PII in input, block immediately
      {
        "name": "PiiDetectionGuard",
        "enabled": true,
        "order": 1,
        "config": {
          "sensitivityLevel": "high"  // "high" catches all patterns including CVV and IP
        }
      },

      // Redact mode: mask PII found in the node output
      {
        "name": "PiiRedactionGuard",
        "enabled": true,
        "config": {
          "redaction_method": "mask"
        }
      }
    ]
  }
}

What Happens at Each Sensitivity Level

LevelPatterns ActiveUse When
"low" SSN (hyphenated), CreditCard (full pattern only) Low-risk data with only structured PII fields. Minimizes false positives.
"medium" Above + Email, Phone, SSN_NoHyphen, Passport, DriverLicense, BankAccount, IPAddress Default for most workflows. Catches the common PII types without triggering on 9-digit phone extensions or 3-digit codes.
"high" All 10 patterns including CVV (3-4 digits) and BankAccount (8-17 digits) Maximum protection. Higher false-positive rate on benign numbers. Use for financial and healthcare workflows.
Current Implementation Note In the current implementation, all 10 patterns always run regardless of sensitivityLevel. The sensitivity level is stored and will be used to filter patterns in Phase 5. Set it to your intended future level now for forward compatibility.

Choosing a Redaction Method

MethodOutput exampleReversible?Use when
"mask"j***@***.com → ****************NoLogs, audit records, displays — the safest option
"hash"a3f9b2c1d4e5f678No (one-way)Need to compare if the same value appears twice without exposing it
"partial"j**************mNoUI display where the user needs a hint of what was there

Using PiiNodeGuard for Full Protection

The simplest way to get two-layer protection is to register PiiNodeGuard which wires both guards automatically:

// In DI setup
services.AddSingleton<INodeGuardExecutor, PiiNodeGuard>();

// PiiNodeGuard automatically:
// - ExecutePreAsync → PiiDetectionGuard (blocks if PII found)
// - ExecutePostAsync → PiiRedactionGuard (masks PII in output)
// - ExecuteOnErrorAsync → no-op
← Use Case Overview Rate Limiting →