Veridical.dev
Veridical10 min readArticle

PII in Logs: Developers Stop Leaks at the Source Before CI

← All articles

PII in Logs: Developers Stop Leaks at the Source Before CI

Data tiles filtered before reaching log storage

Logs often contain personally identifiable information, and a key fix is refusing to let secrets and PII reach a log line in the first place. NIST SP 800-92r1 and the OWASP Logging Cheat Sheet both frame this as a planning problem: decide what must never be logged, then prevent sensitive data from being logged and consider redaction or masking as close to generation as possible, and restrict who can read what remains.

TL;DR:

  • Sanitize data inside middleware, serializers, or instrumentation before it reaches buffers, queues, or telemetry agents, using allowlists of reviewed fields.
  • Redact passwords, private keys, and reusable tokens completely; mask identifiers for support, and pseudonymize values for consistent forensic correlation.
  • Limit log access, set retention and disposal schedules, encrypt logs in transit and at rest, and prepare to remove exposed entries and rotate compromised credentials.
  • Research shows defenses reduce but do not eliminate model leakage; avoid raw prompt storage where possible and scrub logs that feed training pipelines.
  • Add pattern scanning to CI or checks that run after merging, scan historical logs at rollout, and rotate any secrets the checks uncover.
Veridical
Catch Risky Logging Changes Before Merge
Veridical reviews GitHub pull requests with evidence-backed findings to help teams spot vulnerabilities that could expose sensitive data.
Review Veridical

Table of Contents

What PII exposure in logs looks like and why it matters

A log line becomes a liability the moment it captures something an attacker or an auditor should never see. In practice, that means:

  • Email addresses, phone numbers, and government identifiers such as Social Security numbers
  • Authentication tokens, session cookies, and API keys printed during error handling
  • Full request bodies or headers, including Authorization values
  • Raw database query strings that embed user records

Once that data sits in a log aggregator, the consequences compound. Stolen tokens, exposed identifiers, and leaked session cookies can create security and privacy risks. CWE-532 documents this exact weakness, citing real CVEs where verbose logging exposed credentials and personal data to anyone with log access. OWASP’s guidance is blunt on the same point: logs should never be treated as safe storage for sensitive information, because they may be replicated, retained, or accessed by people who do not need the original data.

Where PII most commonly gets into logs

PII rarely enters logs through a deliberate decision. It slips in through instrumentation that was never designed with sanitization in mind:

  • Exception handlers that serialize entire objects or stack traces, including the user data attached to them
  • Observability agents and telemetry integrations that capture request bodies and headers
  • Debug or verbose logging left active in production builds, along with build-time artifacts that persist longer than intended
  • AI and LLM traces, where prompts, completions, and inference logs can contain or even amplify the PII a user typed in

Each of these sources shares the same failure pattern: a tool or a developer logs first and thinks about sensitivity later.

Pro Tip: Treat every new observability integration as untrusted until you have configured its field capture explicitly, not as a convenience that works safely out of the box.

Prevention strategies: source-first sanitization, masking, and pseudonymization

The fix starts with a policy change, not a downstream filter. Default to treating user input as unloggable, then build allow-lists of fields you have reviewed and approved, rather than trying to catch sensitive data after it has already reached an aggregator. OWASP’s guidance supports this direction explicitly: logging decisions belong in design, not in cleanup.

  1. Sanitize at the point of generation, inside middleware, serializers, or instrumentation hooks, so raw PII never reaches a buffer, queue, or telemetry agent.
  2. Choose the right technique for the data: redact entirely for secrets like passwords and private keys, mask partially for identifiers you still need for support (last four digits of a card), and pseudonymize when you need a stable reference for forensic work without storing the original value.
  3. Build structured logs with explicit sensitivity metadata on each field, so a field tagged as PII is redacted automatically rather than depending on a developer remembering to mask it.
  4. Keep the sanitization logic in your codebase and logging library, not only in a downstream SIEM rule, because aggregator-side filtering runs after the exposure has already happened.

The distinction between masking and redaction matters more than it looks. Redaction removes the value entirely, which is correct for anything an attacker could reuse directly, like a token or a password. Masking preserves enough structure for a support agent to confirm identity without seeing the full value. Pseudonymization sits in between: it swaps the real identifier for a consistent token, useful when your team needs to correlate events across a user’s session without ever writing their actual email or ID to disk.

Pro Tip: Build redaction into your logging library’s default formatter, so a forgotten tag still fails safe instead of leaking by omission.

Operational controls: access, retention, and log management planning

Sanitization only holds up if the operational layer around it is just as disciplined. NIST SP 800-92r1 frames log management as a full lifecycle, generation, transmission, storage, access, and disposal, and it calls for explicit decisions at each stage:

  • Define who may access logs and through which interfaces, and protect that access the same way you would protect production databases
  • Set retention and disposal schedules so logs containing any residual personal data do not persist indefinitely
  • Encrypt logs in transit and at rest, since a log pipeline is a replication target as much as any other data store
  • Plan for incident response specific to logs: removing exposed entries, rotating any secrets that appeared in them, and keeping an audit trail of who touched what

The same NIST guidance recommends deciding, during planning rather than after an incident, which data characteristics should never be logged at all, explicitly naming personal information, passwords, private keys, and access tokens, and how to handle errors in log generation itself. Teams that skip this planning step end up improvising redaction rules during a breach instead of before one. For a closer look at how redaction policy intersects with research and compliance obligations, this guide to redacting PII in bug reports walks through practical scrubbing steps for teams handling regulated data.

Special risks: AI and LLM leakage in logs and training data

Logging prompts and completions introduces a risk that traditional application logging does not: the model itself can memorize and later reveal personal data it saw during training or inference. Research on large language models shows that scrubbing and differential privacy reduce PII leakage but do not eliminate it, and that extraction attacks can pull substantially more PII sequences out of a model than naive querying would suggest. Storing raw prompts and transcripts can add to the risk of exposing personal data. Mitigation means avoiding storage of raw prompts where possible, applying aggressive scrubbing to any logs that feed training pipelines, and pairing dataset curation with algorithmic defenses rather than relying on either alone.

LLM logging risks and privacy controls

Developer checklist: safe defaults to deploy this week

Most of this is achievable without a major rewrite:

  1. Turn off debug and verbose logging in production, and verify it with a CI check rather than a manual review.
  2. Audit exception handlers for full object or payload dumps, and strip sensitive fields before anything gets serialized.
  3. Configure observability agents with an explicit allow-list of fields, and blacklist Authorization headers and cookie values by default.
  4. Add log-scanning to CI or a post-merge job that flags likely PII patterns, and rotate any secret that scanning turns up.

Pro Tip: Run your log-scanning job against historical logs the first time you deploy it. You will usually find more than you expect.

Making secure logging part of PR and CI workflows

Sanitizing at the source changes the economics of an incident. A leak caught in review costs a few minutes; a leak caught in production can require a forensic review and credential rotation, and may create disclosure obligations. We think the practical move is treating every log statement as a sensitive output, reviewed with the same scrutiny as an API response, and catching violations in the pull request rather than in a postmortem.

— Łukasz

How Veridical catches risky logging changes before they merge

We built our evidence-based pull request review to catch exactly this category of defect: a new log statement that dumps a request body, an exception handler that serializes a user object, a telemetry hook added without a field allow-list. Every finding we surface comes with inline evidence, and each review ends with a calibrated advisory score, so your team can gate merges on real signal instead of hoping a reviewer notices. See how our AI code review for GitHub fits into your workflow, or check our pricing to find the plan that matches your review volume.

Veridical

FAQ

Which of the following is an example of sensitive personal information (PII)?

Sensitive PII includes Social Security numbers, financial account details, authentication tokens, and health records, anything that can directly identify a person or grant access to their accounts. In logging contexts, this also extends to session cookies and Authorization headers, which function as credentials even though they are not traditional identity documents.

What should you do if you notice PII exposed on the internet?

Remove or redact the exposed data immediately, then rotate any credentials or tokens that appeared alongside it, since an exposed secret should be treated as compromised the moment it becomes visible. Document the incident and review how the data reached a public surface so the same path does not leak again.

What is PII data masking?

PII data masking replaces part of a sensitive value, such as showing only the last four digits of an account number, so the data remains partially useful without exposing the full identifier. It differs from full redaction, which removes the value entirely, and from pseudonymization, which swaps the value for a consistent token for later correlation.

Is phishing responsible for PII data breaches?

Phishing is one common cause of PII breaches, but logging failures are a distinct possible vector: verbose logs, exception dumps, and misconfigured telemetry can expose personal data without any phishing involved. CWE-532 documents several real-world cases where sensitive data reached log files through normal application behavior rather than a targeted attack.

Sources

For teams implementing these controls, the primary standards and research behind this guidance are worth bookmarking directly rather than relying on secondhand summaries. They cover planning, defensive patterns, and the newer risks specific to AI systems.