🧾 Redacting Secrets and PII From Logs With AI-Assisted Review

The worst secret leak I ever investigated wasn’t a breach. It was our own application logging the full request body, including the Authorization header, at INFO level, shipped to a log aggregator three teams could read and an external SaaS could see. Nobody attacked us. We carefully collected our own credentials and PII into a searchable index and called it observability.

Logs are a sensitive-data sink that almost nobody audits, because the leak is invisible until someone goes looking. Reviewing logging code for what it accidentally captures is exactly the kind of patient, pattern-heavy work AI is good at. I use the model as a fast junior reviewer that reads the logging paths and flags what shouldn’t be there, then I verify every finding and own the fix. Strictly defensive, and I never paste real secrets or real customer data into a prompt. I describe the shape, never the substance.

Find every place you log a whole object

The biggest source of accidental leaks is logging an entire object, request, or exception with structured data attached. A single logger.info("request", request=req) can serialize headers, cookies, and bodies. I ask the AI to hunt these:

Scan this code for any logging call that passes a whole request, response, exception with context, or user object. List each one and what sensitive fields it could serialize. Defensive review only.

Then I confirm with grep across the codebase, because the model works from what I paste and I want the full picture:

grep -rn "logger\.\(info\|debug\|error\)" --include="*.py" . \
  | grep -iE "request|payload|body|headers|user|token"

Debug-level logging is the worst offender, because it’s verbose by design and frequently left on in staging environments that are less locked down than production.

Build a redaction layer, not a game of whack-a-mole

Chasing individual log lines never ends. The durable fix is a redaction filter in the logging pipeline that scrubs known-sensitive keys and patterns before anything is written. I have the AI draft the filter and the pattern set:

Write a logging filter that redacts values for keys matching a sensitive list (authorization, password, token, secret, api_key, ssn, card) and masks anything matching common token and email patterns. Explain each pattern. Defensive use only.

A starting filter looks like:

SENSITIVE_KEYS = {"authorization", "password", "token", "secret",
                  "api_key", "cookie", "ssn", "card_number"}

def redact(record: dict) -> dict:
    return {
        k: ("***REDACTED***" if k.lower() in SENSITIVE_KEYS else v)
        for k, v in record.items()
    }

I treat key-based redaction as the reliable layer and pattern-based redaction as the safety net. Patterns catch the values that slip through under an unexpected key name, but they’re fuzzy, so they back up the allowlist rather than replace it.

Pro Tip: redact by allowlisting what’s safe to log rather than only denylisting what’s dangerous. A denylist misses the field someone adds next quarter; an allowlist defaults to safe and forces an explicit decision to log anything new.

Tune the patterns against false positives and false negatives

Regex redaction has two failure modes, and AI helps me reason about both. A pattern too loose mangles legitimate logs and makes them useless; too tight and it misses the leak. I test against synthetic samples I construct myself, never real data:

Here are synthetic log lines I made up with fake tokens and emails. Show which my redaction patterns catch and which they miss, and flag any benign text they over-redact.

The model is good at spotting that my “mask anything 32 hex chars” rule also eats legitimate git commit hashes, or that my email regex misses plus-addressing. I fix the patterns based on its reasoning, then re-test. I never validate redaction against production logs by pasting them somewhere a model can read; I build representative fakes.

Don’t forget the places logs go after they’re written

Redaction at write time is necessary but not sufficient. Sensitive data also leaks through stack traces in error trackers, request tracing spans, slow-query logs that include parameter values, and crash dumps. I ask the AI to enumerate the sinks:

List the places in this stack where data might be captured outside the main logger: exception trackers, APM traces, database slow-query logs, audit trails. For each, note what sensitive data it could capture.

Database slow-query logging is a sneaky one, because the query text often embeds literal values. The model is good at reminding me of sinks I’d forgotten, and each one becomes its own redaction or suppression task.

Make retention and access part of the control

Even perfectly redacted logs are a liability if they’re kept forever and readable by everyone. I have the AI review the logging config for retention windows and access scoping, and flag where debug logs that may contain richer data are retained as long as the sanitized production logs. The defensive posture is short retention for verbose logs, tight access on anything that might still contain residual sensitive data, and an explicit owner.

Gate it and keep humans in the loop

Once the redaction layer and patterns exist, this becomes a review gate on logging changes. When someone adds a new log statement that touches user data, the diff should get scrutiny. I route those changes through the code review dashboard so the AI’s “this logs a token” finding lands as an inline comment a human approves, rather than the model editing logging code on its own.

The reusable redaction and log-audit prompts live in our prompts library, with the security set bundled in the DevOps security prompt pack, and I keep the team’s shared versions in a prompt workspace so everyone audits the same way. For the review work itself, Claude and Cursor both handle the read-the-code-and-flag-the-leak pattern well, with Cursor convenient because it’s already in the editor.

The takeaway

Logs quietly accumulate the exact data you spend the most effort protecting elsewhere, and nobody notices until it’s a searchable index of your own secrets. An AI reviewer makes auditing logging code and building a redaction layer fast and repeatable, as long as you treat it as the junior engineer that flags and drafts while you verify every pattern against synthetic data and own the change. Keep real secrets and customer data out of every prompt, allowlist what’s safe to log, and remember the sinks beyond your main logger. The rest of the security hardening category covers the secrets-handling and audit practices this connects to.