PII and compliance

This skill catches the single most common compliance leak in production code: putting personally identifiable information (PII), authentication material, or sensitive business data into places it shouldn't go — logs, error traces, analytics events, third-party SDK payloads, debugger statements.

Most teams know the rule "don't log PII." Most teams ship code that violates it anyway, because the leak happens inside an interpolated string ten frames deep from where the developer was thinking about the rule. This skill is the second line of defense.

What counts as PII

In rough order of sensitivity:

1. Direct identifiers: government ID numbers (SSN, passport, driver's license), credit card numbers (full or BIN+last4), bank account numbers, full social security numbers in any partial form including last-4 if combined with name.
2. Strong-signal indirect identifiers: full email addresses, phone numbers, full names, full street addresses, dates of birth, biometric data, precise geolocation coordinates.
3. Authentication material: passwords, API keys, OAuth tokens, JWT bodies, session tokens, password-reset tokens, signed URLs, webhook secrets, private keys, recovery codes.
4. Sensitive business data: trade secrets, unpublished financials, M&A info, internal employee performance reviews, customer prospect lists.
5. Reduced-signal indirect identifiers: IP addresses, user-agent strings, device fingerprints, partial postal codes — these are PII under GDPR and CCPA when joined with other data your service holds.

Forbidden destinations

PII or auth material should never appear in: