PII guardrail masks base64 blobs (K8s secrets, JWTs) as category=ssn — recurring false positive on kubectl output

[initializ-mk]

Observed (live, k8s-triage agent — every run, multiple times per session)

Any kubectl output containing base64 material (get secret -o yaml, deployment/pod YAML with token env refs, get pods -o json) triggers:

{"event":"guardrail_check","fields":{"category":"ssn","decision":"masked","gate":"output","guardrail":"pii","tool":"cli_execute","violation_count":1}}

One 108KB get pods -A -o json produced violation_count: 9 — all base64, none of it an SSN.

Why

The SSN pattern in the pii guardrail (github.com/initializ/guardrails v0.12.0, wired via registerGuardrailHooks) evidently matches digit runs inside base64/JWT strings. Base64 routinely contains ddd-dd-dddd-shaped or 9-digit substrings.

Impact

• Masking corrupts base64 payloads mid-string — an agent asked to compare or decode a token gets silently altered data.
• Audit noise: ssn masking events on every kubectl-heavy session make real PII hits impossible to spot.

Suggested fix

In the guardrails library (this issue is the forge-side tracker): suppress SSN matches whose surrounding context is a base64 run (e.g. inside a [A-Za-z0-9+/=]{40,} token), or require word-boundary/format anchoring (\b\d{3}-\d{2}-\d{4}\b with delimiters) rather than bare digit-run matching. Happy to move this to initializ/guardrails if that's the right home.

Found while live-testing context compression (#241/#279); unrelated to compression itself.