generated client logged the full request on error - API keys ended up in the log aggregator

TL;DR

Stop logging full requests; log a redacted summary instead, then rotate the exposed keys and scrub the logs. The keys are already in the aggregator, so rotation is not optional. Redact first, rotate second, scrub third.

generated client logged the full request on error  -  API keys ended up in the log aggregator

Steps

1. Find the logging call. Search the client for places that log the request object, headers, or body on error. Expected: you found the exact line dumping credentials.
2. Replace it with a redacted summary: method, path, status, a request id, and the error message, with any secret-shaped value replaced by a placeholder before logging. Expected: logs carry everything needed to debug, minus anything secret.
3. Rotate every key that touched the logs. Generate new keys at the provider, update the deployment, and revoke the old ones. Expected: the logged values no longer grant access.
4. Scrub the aggregator: delete or redact the log lines containing keys, per your retention and compliance needs. Expected: no searchable copy of the old keys remains.
5. Add a guard so it cannot regress: a test that feeds a fake key through the error path and asserts the log output contains no secret-shaped value. Expected: the test fails if full-request logging comes back.

Use this when

• API keys, tokens, or signing secrets show up in log search results.
• A generated client's error handler logs the entire request for "debuggability".
• You are cleaning up after an incident like this one.

Not for this skill when

• The key was committed to git - that needs history rewriting, not log scrubbing.
• The secret leaks via URL query params in server access logs - similar fix, but the source is the request shape, not your logger.
• The leak is in a third party's logs you cannot scrub - rotate and move on.

Variant phrasings

• error logging dumped API keys into log aggregator
• generated client logs full headers including auth on failure
• secrets in logs from verbose request logging on errors

Why it happens

Verbose error logging is a generator default: "log everything, debug later." The request object conveniently carries headers, and headers conveniently carry the key. Nobody reads that log line until the day someone searches the aggregator and finds live credentials.

Edge cases

• Bodies can carry secrets too (webhook payloads, token exchanges); redact headers AND bodies.
• Exception messages sometimes embed the request URL with embedded credentials; sanitize the message as well.
• Log sampling or tail-based debugging still ships the raw line to whoever reads it; redaction has to happen at write time, not at read time.

Provenance

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