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
2. •Locate sources and sinks
   • •Sources: env, config, secrets managers, request payloads
   • •Sinks: logs, telemetry, error pages, analytics, support dumps
3. •Harden logging
   • •Default to structured logs
   • •Redact known patterns (Authorization headers, cookies, tokens)
   • •Avoid logging full request/response bodies by default
4. •Prevent secret introduction
   • •Replace hardcoded strings with env/secret manager references
   • •Add guardrails: git hooks, CI secret scanning, unit tests for redaction
5. •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.