Skip to main content

PII Detection at Scale: Pattern Matching, Heuristics, and PCI Mode

PII Detection at Scale: Pattern Matching, Heuristics, and PCI Mode

PII detection at AI scale is not one regex and one demo prompt. Real traffic contains mixed identifiers, inconsistent formatting, and business requests that still need to succeed after sensitive values are removed. Keeptrusts handles that problem with a shared redaction control that combines base matching, optional healthcare heuristics, optional PCI detection, and configurable redaction metadata.

Use this page when​

  • You need to redact or block personal data in prompts before it reaches an upstream provider.
  • You are deciding how to combine built-in identifier detection with custom DLP rules for internal formats.
  • You want to use PCI mode without pretending it solves all data loss prevention on its own.

Primary audience​

  • Primary: Technical Engineers
  • Secondary: Technical Leaders, AI Agents

The problem​

PII programs often fail for opposite reasons. Some are too narrow: they detect email addresses and maybe an SSN, but miss payment data, medical identifiers, or organization-specific record numbers. Others are too broad: they flag so aggressively that teams disable them after a week.

AI traffic makes the problem harder because the same gateway may handle customer service, finance, product support, and engineering prompts in the same hour. The control has to be fast, predictable, and specific enough to preserve useful output. It also has to deal with both request-side and response-side exposure. A clean input boundary is not enough if the model later echoes or reconstructs the same data in its answer.

There is also a tooling mistake that shows up repeatedly in AI deployments: teams expect a single DLP rule set to detect everything. That is not how Keeptrusts is designed. PII Detector is the built-in shared redaction control for common identifiers and response redaction support. DLP Filter is where you define your own secret patterns, codenames, and blocked phrases. Treating them as interchangeable creates blind spots.

The solution​

Use pii-detector for what it is good at, then add adjacent controls only where they are needed.

At the base layer, pii-detector matches common identifiers such as email addresses, phone numbers, SSNs, public IP addresses, URLs with identifying paths or queries, MAC addresses, IMEIs, VINs, ZIP codes, dates, account-like identifiers, and license plates. That gives you a strong default control for general-purpose prompt traffic.

When the workload is healthcare-adjacent, healthcare_mode adds HIPAA-style heuristics for names, addresses, city mentions, MRNs, health-plan identifiers, fax numbers, license numbers, device identifiers, and textual mentions of biometric or photo identifiers. That is useful when the raw text is messy and direct pattern matching is not enough.

When the workload includes payment data, pci_mode adds PAN detection plus CVV/CVC and expiration date matching. That matters because card data rarely arrives in isolation. It tends to show up next to contact information, free-form case notes, and copied receipts. One policy pass should remove the obvious payment risk before the provider sees the prompt.

There are limits, and those limits matter. pci_mode does not currently detect cardholder names. Custom regex matches added through detect_patterns are recorded as generic_id, not as custom semantic labels. Named capture groups do not become marker names. Those details are exactly why you should separate built-in identifier detection from organization-specific DLP logic.

Implementation​

The pattern below works well for mixed finance and support traffic. It redacts common identifiers, blocks organization-specific secrets, and prevents classified requests from being routed to a provider that lacks declared retention guarantees.

pack:
  name: pii-at-scale
  version: "1.0.0"
  enabled: true

providers:
  targets:
    - id: compliant-zdr
      provider: openai
      model: gpt-5.4-mini-mini
      secret_key_ref:
        env: OPENAI_API_KEY
      data_policy:
        zero_data_retention: true
        training_opt_out: true
        retention_days: 0
        in_memory_only: true
        sanitized: true
        accepts_tokenized_input: true
        allow_internet_egress: false
        local_only_processing: true

policies:
  chain:
    - prompt-injection
    - pii-detector
    - dlp-filter
    - data-routing-policy

policy:
  prompt-injection:
    use_embedding: true
    detection:
      attack_patterns:
        - "ignore.*previous.*instructions"
        - "reveal.*system.*prompt"
    encoding:
      decode_base64: true
      normalize_unicode: true
      detect_homoglyphs: true
    boundaries:
      enforce_delimiters: true
      reject_fake_boundaries: true

  pii-detector:
    action: redact
    healthcare_mode: false
    pci_mode: true
    detect_patterns:
      - 'EMP-\d{6}'
      - 'ACCT-\d{8,12}'
    redaction:
      marker_format: label
      include_metadata: true
      custom_markers:
        generic_id: "[REDACTED-ID]"

  dlp-filter:
    detect_patterns:
      - 'AKIA[0-9A-Z]{16}'
      - 'ghp_[0-9A-Za-z]{36}'
    blocked_terms:
      - attorney-client privileged
      - restricted settlement packet
    action: block
    fuzzy_matching: true
    max_distance: 1
    sensitivity_level: high

  data-routing-policy:
    require_zero_data_retention: true
    require_no_training: true
    max_retention_days: 0
    on_no_compliant_provider: block
    log_provider_selection: true

This chain is deliberately ordered.

prompt-injection goes first because you do not want adversarial text steering later behavior. pii-detector comes next so structured identifiers are sanitized early and the shared buffered output redaction path is available. dlp-filter handles organization-specific content that the built-in PII detector cannot know about. data-routing-policy then ensures the remaining provider pool matches your data handling requirements.

Test it with a realistic prompt instead of a toy email-only example:

curl -s http://localhost:41002/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{
    "model": "gpt-5.4-mini-mini",
    "messages": [
      {
        "role": "user",
        "content": "Summarize the charge dispute for maria.rivera@northline.corp, PAN 4111111111111111, CVV 321, expiration 11/28, and employee record EMP-482991."
      }
    ]
  }'

What you should expect is not vague "masking." You should expect the provider-facing text to contain redaction markers instead of raw identifiers, and you should expect event evidence that shows what was changed. If your workload includes custom account formats or internal IDs, use detect_patterns for them. If it includes secret strings, API keys, or codenames, keep those in dlp-filter instead.

At scale, the most important operational habit is to tune the boundary between redaction and blocking. Use action: redact when the business task can still succeed after data removal. Use action: block only when the presence of the data itself is unacceptable. That distinction keeps the signal-to-noise ratio sane.

If your PCI or privacy-sensitive traffic is confined to a smaller set of high-assurance providers, fund that lane explicitly. Spend & Wallets is relevant because compliant routing can cost more. Keeptrusts reserves spend before dispatch and holds requests when no eligible wallet has enough balance, which is safer than allowing ad hoc fallback decisions.

Results and impact​

When teams deploy pii-detector correctly, they usually see lower raw-data exposure almost immediately. Email addresses, phone numbers, SSNs, PANs, and custom account references stop appearing in outbound traffic even when the underlying application does no client-side sanitization.

The second benefit is operational clarity. Security teams stop trying to wedge every sensitive pattern into one monster regex set. Engineers know to put built-in identifiers in PII Detector, organization-specific secrets in DLP Filter, and provider handling constraints in Data Routing Policy.

The third benefit is better evidence. Redaction metadata makes it easier to explain what happened to a request, what kind of data was found, and why the upstream model never saw the raw value. That is materially better than telling auditors that application developers are "expected to avoid pasting sensitive data."

Key takeaways​

  • pii-detector is the right default for common identifiers and shared response redaction behavior.
  • pci_mode adds PAN, CVV/CVC, and expiration date detection, but it does not replace broader DLP controls.
  • healthcare_mode adds HIPAA-style heuristics when you need healthcare-adjacent text handling.
  • Use DLP Filter for custom secrets and internal phrases, not as a substitute for built-in PII detection.
  • Pair content controls with Data Routing Policy when provider retention and training guarantees matter.

Next steps​