Enforce PII non-exposure when surfacing Sentry telemetry in Slack

[sentry-junior]

Summary

When junior surfaces Sentry telemetry (errors, traces, replays) in response to user queries, it must not expose personally identifiable information (PII) — user emails, IPs, usernames, or device tokens — in Slack messages. This is both a privacy obligation and a practical necessity: Slack channels are often broader-audience than the data's intended access scope.

Current Behavior

• junior currently has no Sentry telemetry integration (see Wire bug reports into Sentry telemetry (errors, traces, replays by user) #10).
• No PII scrubbing layer exists at the response-generation step.
• The feature spec in Wire bug reports into Sentry telemetry (errors, traces, replays by user) #10 does not include a PII constraint; nothing prevents raw Sentry API payloads from leaking into Slack output.

Gap / Opportunity

• Sentry's own product (Relay, server-side scrubbing, data scrubbing settings) strips PII at ingestion — but that doesn't help here because junior would be reading already-ingested event data via API and re-surfacing it in Slack.
• Without explicit guards, an implementation of Wire bug reports into Sentry telemetry (errors, traces, replays by user) #10 that naively inlines error event payloads into Slack could leak user.email, user.ip_address, user.username, breadcrumb data, or request headers.
• Slack messages are not access-controlled at the field level; once posted, PII is visible to everyone in the channel.

Prior Art

• Sentry's own data scrubbing / server-side scrubbing and Relay PII config define patterns for what counts as PII and how to strip it at pipeline boundaries — same logic should apply at junior's output boundary.
• OpenAI function-calling best practices recommend treating tool output as untrusted input and sanitizing before rendering to users — same principle applies here.

Options

• Option A — Field allowlist (recommended): Define an explicit set of Sentry API fields junior is allowed to include in Slack output (e.g. event ID, timestamp, title, environment, trace URL). Strip everything else by default.
• Option B — PII regex scrubber: Run a post-processing pass over all Sentry API payloads before rendering, stripping known PII patterns (email, IP, UUID-mapped user IDs). More fragile than an allowlist; misses novel PII shapes.
• Option C — Link-only mode: Never inline event data; only surface deep links back to Sentry. Zero PII risk, but zero information density in Slack.

Recommended Direction

Option A (allowlist) as the base, with Option C as the fallback when field origin is uncertain. Define the allowlist as a checked-in spec/config so it's reviewable and auditable. Option B can supplement for defense-in-depth but should not be the primary control.

Acceptance Criteria

• An explicit PII field allowlist exists for Sentry API response fields that junior may include in Slack output.
• Any Sentry telemetry surfaced in Slack (errors, traces, replays) contains no user.email, user.ip_address, user.username, user.id (if mapped to a real identity), or request header values.
• The allowlist/scrubbing logic is unit-tested with fixture payloads that include PII.
• The implementation spec in Wire bug reports into Sentry telemetry (errors, traces, replays by user) #10 is updated to reference this constraint.

Risks

• Overly aggressive scrubbing may strip context useful for debugging (e.g. a user identifier that is NOT an email). Allowlist approach mitigates this by being explicit rather than heuristic.
• Sentry API schema evolves; allowlist needs to be maintained as new fields are added.

Sources

• https://docs.sentry.io/security-legal-pii/scrubbing/server-side-scrubbing/
• https://docs.sentry.io/security-legal-pii/scrubbing/relay-pii-config/
• Wire bug reports into Sentry telemetry (errors, traces, replays by user) #10