Secrets and Logging Hygiene

When to use

Use this skill when asked to scan for secrets, harden logging, or reduce sensitive data exposure.

Inputs to collect (if available)

• Data classification (PII, auth/session, payments)
• Logging/telemetry stack (logger, APM, sinks)
• Secret management approach (vault, env injection, KMS)
• Incident/audit requirements (retention, access controls)

Step-by-step process

1. Identify sensitive data

- Credentials, tokens, API keys, connection strings - PII (emails, phone, addresses), financial identifiers

1. Locate sources and sinks

- Sources: env, config, secrets managers, request payloads - Sinks: logs, telemetry, error pages, analytics, support dumps

1. Harden logging

- Default to structured logs - Redact known patterns (Authorization headers, cookies, tokens) - Avoid logging full request/response bodies by default

1. Prevent secret introduction

- Replace hardcoded strings with env/secret manager references - Add guardrails: git hooks, CI secret scanning, unit tests for redaction

1. Verify

- Add tests ensuring redaction occurs - Run a lightweight grep for common secret patterns and known keys

Output

• List of leak points found (if any)
• Recommended redaction policy + implementation location
• Tests and verification steps

Repo integration (optional)

Related prompts:

• check-for-secrets.prompt.md
• assess-logging.prompt.md

Output format

• Leak points found (table): Type | Where | Evidence | Risk
• Redaction policy: defaults + allow-listed fields
• Guardrails: CI secret scanning, pre-commit, tests
• Verification: how to confirm redaction and rotation

Examples

• “Authorization header logged” → redact Authorization and cookies by default; verify logs no longer contain bearer tokens.