## TL;DR
The agent logs its full connection string or dumps config on error, and the password goes with it. Find every log call that emits secrets, add a redaction filter to the logging pipeline, stop passing full connection strings around, and rotate anything that already leaked. Logs are retained and shipped; treat them as public.

## Symptom
Connection strings, passwords, or tokens show up in agent logs, stdout captures, or error traces. Anyone with log access effectively has warehouse credentials. The leak is usually discovered by accident, long after it started.

## Steps

1. Find every place credentials enter logs: search recent logs for password-like patterns and trace each hit back to the log call that emitted it.
Expected output: the list of offending call sites. The usual suspects are logging the full connection string and dumping config dicts on error.

2. Add a redaction filter on the logging pipeline that masks credential-shaped values before they are written, and apply it to every handler including error and debug output.
Expected output: rerunning the same code path logs [redacted] where the secret was.

3. Stop passing full connection strings around: build the connection from parts held in the secret store, and log only the host and database name, never the password or token.
Expected output: logs contain the warehouse host and database but no secret material, even at debug level.

4. Rotate every credential that already leaked, since logs are often retained and shipped to third parties. Then verify the new values never appear in fresh logs.
Expected output: old credentials are dead, and a fresh log scan is clean.

## When to use
- Passwords, tokens, or full connection strings appear in logs
- An agent builds connection strings from parts and logs the result
- Error handlers dump config or environment on failure

## When not to use
- The secret is in code or config files, not logs (that is a secret-management problem)
- The log line shows a masked value already (verify the masking, then move on)
- You are auditing proactively (still worth doing, but there is no active leak)

## Variant phrasings

### credentials in exception tracebacks
Tracebacks print the arguments of the failing call, including connection strings. Redact before the call or catch and re-raise with a clean message.

### agent echoes the .env file when debugging
Same class of leak. Never log environment dumps; log the names of the variables read, not their values.

## Why it happens
Agents assemble connection strings at runtime and log liberally for debuggability, which is exactly the combination that leaks secrets. Nobody reviews agent stdout the way they review committed code, so the leak runs for weeks. The fix has to be structural (redaction in the pipeline, no full strings in memory) because no amount of carefulness survives a 3am debug session.

## Edge cases
- Structured JSON logs need redaction on the serialized fields too, not just the message string.
- Third-party libraries can log the connection string you hand them; check driver and ORM logging at the level you run in production.
- Rotating a leaked warehouse password can break other services sharing it; inventory the credential's users before rotating.

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst_CUR9JeWSrrTqQF4bLlRsjw