31.4 Secrets handling: never in prompts, never in logs

Goal: eliminate the easiest catastrophic failure

Secrets leaks are the “single bug → catastrophic incident” class of failure.

In vibe coding workflows, secrets leaks happen because:

• developers copy/paste config into prompts,
• debug logs print full payloads,
• generated code stores keys in files,
• tool results include tokens and the model echoes them.

Your goal is to make secret leakage hard to do accidentally.

Hard rules (non-negotiables)

• No secrets in prompts.
• No secrets in logs.
• No secrets in repo.
• No secrets in screenshots shared externally.
• Use least-privilege credentials.
• Rotate on suspicion, not certainty.

Where secrets leak from (common places)

Common leak points:

• .env files accidentally committed.
• Prompt examples that include real keys (“just for testing”).
• Logs and traces that include request/response bodies.
• Error reports that attach full payloads.
• Tool outputs that include tokens, headers, or credentials.
• Client-side code that embeds server secrets in frontend bundles.

How to handle secrets safely (practical patterns)

Use environment variables (and a secret manager for production)

• Local dev: use .env files that are gitignored.
• Production: use a secrets manager or platform secrets (never bake into images).
• Access: least privilege credentials per environment and per service.

Redact before logging

Redaction should be deterministic and centralized:

• redact Authorization headers,
• redact known token patterns,
• redact private keys and PEM blocks,
• redact session cookies.

Do this at the logging layer so individual developers don’t have to remember every time.

Scope credentials narrowly

• use separate keys for dev/staging/prod,
• use separate keys per service,
• use short-lived tokens when possible,
• restrict key permissions (read-only vs write).

Logging and debugging without leaking

Safe debugging practices:

• Log ids, not payloads: request ids, model names, token counts.
• Sample cautiously: if you log payloads, do it only in controlled environments with strict retention.
• Redact everywhere: logs, traces, analytics, crash reports.
• Review logging in PRs: treat logging changes like security changes.

When you need to inspect payloads:

• use local/dev environments,
• use synthetic data,
• store payloads in secure, access-controlled locations with short retention.

Rotation and incident response

Build a simple rotation playbook:

• Detection: secret scanning alerts, suspicious logs, user reports.
• Containment: revoke/rotate keys quickly.
• Eradication: remove leaked values from logs, caches, and repos where possible.
• Recovery: redeploy with new credentials; verify functionality.
• Postmortem: add tests and policies to prevent recurrence.

In many orgs, “rotate now, investigate after” is the correct first step.

Practical checklist

• Never paste secrets into AI chats or prompts.
• Gitignore env files and run secret scanners.
• Centralize redaction in logging and tracing layers.
• Scope keys narrowly and separate environments.
• Rotate on suspicion and document the playbook.

Where to go next

• 31.5 Red-teaming your own prompts
• Reference: exfiltration risks (30.2)
• Reference: safe logging (29.5)