Sanitizing PII in Memory Before Upstream LLM Transmission

Why post-hoc logging fails

Most "PII protection" in the LLM tooling world is post-hoc: the full prompt goes to the provider, and the observability layer redacts its own logs afterward. That model has a fatal flaw: the sensitive data already crossed the wire. It's in the provider's request logs, subject to their retention policy, their subprocessors, and their incident surface. Redacting your own copy afterward is hygiene theater.

Where the scrubber sits

Sentinel's scrubber executes in-memory, inside the gateway process, at a deliberately chosen point in the pipeline: after authentication, before everything else: before cache-key hashing, before embedding generation, before the upstream adapter sees a single byte.

• Cache keys are derived from scrubbed text, so hashes and embeddings never encode raw PII
• Semantic cache vectors are computed from scrubbed text, so the vector index is clean by construction
• Upstream providers receive only the sanitized payload
• Usage logs record pii_applied: true and the redaction count, never the redacted values

The detector set

The scanner combines pattern matching with format validation to keep false positives low:

• SSNs: \b\d{3}-\d{2}-\d{4}\b → [SSN_REDACTED]
• Payment cards: 13-19 digit sequences with Luhn validation (Visa, Mastercard, Amex, Discover) → [CREDIT_CARD_REDACTED]
• Email addresses: RFC-5322-style pattern → [EMAIL_REDACTED]
• API keys & secrets: provider formats (sk-..., sk-ant-..., gsk_...), GitHub tokens, and Bearer credentials → [API_KEY_REDACTED]

Here's a real scrub, exactly as the pipeline produces it:

# Raw prompt (never leaves the gateway)
"My SSN is 078-05-1120, card 4111 1111 1111 1111,
 email jane.doe@acme.com, and my key is sk-proj-9f2…"

# Payload forwarded upstream
"My SSN is [SSN_REDACTED], card [CREDIT_CARD_REDACTED],
 email [EMAIL_REDACTED], and my key is [API_KEY_REDACTED]"

The Luhn check matters: without it, every 16-digit order number or tracking ID would get masked, degrading answer quality for legitimate traffic. Format validation keeps the scrubber precise enough to leave on permanently.

Streaming & bypass controls

Redaction applies identically to stream: true requests: the scrub happens on the request side, before the stream opens, so SSE passthrough adds no PII exposure. For workloads that handle pre-sanitized data (or synthetic test fixtures that trip the detectors), a request can opt out explicitly with the X-Sentinel-PII-Masking: false header. The default is always on; bypasses are recorded in the audit log.

Audit trail & compliance

Every scrubbed request lands in the Command Center with a SCRB badge and a redaction count, giving compliance teams a verifiable record that masking ran, without storing the sensitive values themselves. Combined with zero raw-prompt retention, TLS 1.3 in flight, and AES-256 at rest, this is the layer that makes GDPR/CCPA data-minimization reviews and SOC 2 evidence collection straightforward. Enterprise tenants can extend the detector set with custom regex rules for domain-specific identifiers (MRNs, employee IDs, internal project codes).