PII Detection

Gateway PII checks are explicit opt-in and off by default. If you send synthetic emails, SSNs, or test cards and get 200 OK with unmasked data, that is the expected default — enable scanning first. This page covers the gateway. For repo scanning, see Holeacquisition LLC Scan.

1. Go to Project > Security.
2. Turn on Enable security scanning (security_settings.security_enabled).
3. Keep filter_pii on and tune the Safety Threshold slider.

No row or false = no input scan, no PII detection, no output scan, on every tier, for both BYOK and managed keys. Creating an active custom data rule or governance policy is itself opt-in and enforces regardless of the master switch.

Do not use .cencorirc for gateway PII — that file configures the Scan CLI only.

When enabled, the input guard scores the last user message against heuristics (not a 25+ entity ML model):

Score is compared against your Safety Threshold. On block the gateway returns 403 with code: security_violation (or data_rule_block for custom rules), logs a security_incidents row, and the request never reaches the provider.

There is no per-field Mask / Redact / Block / Off mode, and no client-visible masking like u***@example.com. The gateway either blocks (403) or passes through (200 with original text). Tokenize / redact actions from custom data rules or governance policies protect the upstream provider only — the token map is detokenized before the response returns to you, so your client still sees the original.

try {
  const response = await cencori.ai.chat({
    model: 'gpt-4o',
    messages: [{ role: 'user', content: userInput }],
  });
  return response.content;
} catch (error: any) {
  if (error.code === 'security_violation' || error.code === 'data_rule_block') {
    return {
      error: 'Your message contains sensitive information. Please remove personal details.',
      reasons: error.reasons,
    };
  }
  throw error;
}

Actual error shape is flat (error, message, code, reasons) in the 4xx range — see Error Reference. There is no PII_DETECTED code with details.patterns_detected.

Enabling the master switch alone does not block PII in model responses. The legacy output scanner is intentionally non-blocking (broad heuristics caused false-positive stream failures). To enforce output:

• Install a governance template with output rules (e.g. PCI-DSS Card-Data Protection, NDPR PII Redaction) in Governance, then request activation + teammate approval, or
• Create an active custom data rule for the output direction.

Without one of those, output SSN / card data returns 200 OK unmasked even with scanning on. If you need proof for an audit, test input blocking and output policy separately.

Incidents are only written when a guard actually fires. With scanning off, expect no incidents.

1. Navigate to your project dashboard
2. Click "Security" in the sidebar
3. Filter by PII / jailbreak incident type

Use dashboard custom data rules for business IDs (e.g. ORD-\d{6}, employee IDs). For output redaction and approval-gated flows, prefer Governance policies over regex alone.

Fictional data (e.g. test@example.com) can score as PII. Mitigations:

• Lower the Safety Threshold (more lenient)
• Turn off filter_pii for non-production projects
• Narrow custom rules; keep gateway passthrough: true / fast_lane: true only for callers that run their own safety layers (it skips all guards)

• Keep scanning off for speed unless you need enforcement; turn it on for production projects handling real user data.
• Educate users to avoid sharing personal information in prompts — the gateway is a block, not a mask.
• Review incidents weekly; adjust threshold rather than assuming per-type Mask/Redact settings exist.
• For healthcare / finance strict compliance, combine input blocking + a governance output policy (deny-by-default) + audit ledger evidence packs.

When enabled and logged, PII blocking supports:

• GDPR: Prevent unauthorized processing of personal data
• HIPAA: Protect patient health information
• SOC 2: Demonstrate data protection controls
• CCPA: California Consumer Privacy Act compliance