Sensitive Data Redaction

These examples and illustrative results are independently authored teaching materials, not measured model results.

Use case

Logs contain time, route, error code, bearer credentials and a customer email. Reports/fixtures need diagnostic signals, not copied private values.

Mechanism

Select necessary safe fields and redact before display/copy. Use stable fictional labels for correlation without reversible originals or authenticated URLs. Fixtures use obviously synthetic data/example.test; real credentials come only from authorized environments and are not emitted. Scan reports, attachments, images and temporary files and review domain identifiers.

Bad example

Paste full headers/connection URIs/customer emails into an issue and embed a real token in tests for reproduction.

Good example

Keep time/route/error code, replace authorization with[REDACTED-TOKEN] and email with[REDACTED-EMAIL]. Use synthetic-token/user@example.test in fixtures. Inspect URIs/images/logs while preserving request correlation.

Why the change matters

Copying spreads sensitive values across histories/shares. Early selection/redaction retains diagnostics and avoids difficult later removal across artifacts.

Observable expectation

Teaching artifacts retain request/error linkage without original credentials/email/authenticated URIs. Check body/logs/attachments; manually review scanner flags rather than declaring the package safe after one-field replacement.

Limits

Scanners miss encoded/composite/domain-private data and can flag fake values. Redaction does not grant public-sharing permission. If insufficient for diagnosis, state the gap rather than disclose originals again.