Log Sanitiser & PII Redactor

Why Sanitising Logs Before Sharing With AI Is Critical

Pasting a raw stack trace or log dump into ChatGPT or Claude has become one of the fastest ways to get unstuck while debugging, but application logs are also one of the richest sources of accidental secret exposure in a typical engineering org. A single error log can contain a database password, an internal hostname, a customer's email address, and a live API key all in the same twenty lines. Once that text leaves your terminal and lands inside a third-party chat interface, you no longer control where it goes: it may be retained for abuse monitoring, reviewed by a support agent, or in the worst case exposed through a account or infrastructure compromise on the vendor's side. None of this requires malicious intent from the AI provider. It is simply the nature of handing raw, unfiltered production data to any system outside your security perimeter.

What Sensitive Data Commonly Appears in Logs

Verbose logging, the same practice that makes debugging easier, is exactly what leaks credentials. The most common categories are: authentication material (passwords, API keys, JWTs, session cookies, OAuth tokens); cloud provider credentials (AWS access keys and secret keys, service account JSON, connection strings for managed databases); customer PII (emails, phone numbers, IP addresses, physical addresses, and sometimes payment card numbers logged during checkout failures); and infrastructure details (internal hostnames, private key material from misconfigured SSH or TLS setups, and full database connection URLs with embedded credentials). Most of this ends up in logs unintentionally, whether from a debug-level logger set too verbose, an exception handler that dumps the entire request object, or a middleware library that logs headers by default including Authorization.

How Credential Leakage Actually Leads to Breaches

Leaked credentials are not a theoretical risk. They are one of the most consistently reported root causes of real intrusions year after year in industry breach reports. AWS access keys committed to a public GitHub repository are typically discovered and exploited by automated scanning bots within minutes, not days; security researchers have repeatedly demonstrated this by publishing intentionally "leaked" honeytoken keys and watching unauthorized usage appear in CloudTrail almost immediately. Support tickets, Slack threads, and increasingly AI chat histories pasted with raw logs are a quieter but equally real version of the same problem: once a credential is visible in plaintext outside your access-controlled systems, you have to treat it as compromised and rotate it, whether or not you can prove it was actually misused. The safest assumption is that any secret pasted somewhere you don't fully control should be rotated the moment you realize it was exposed.

Best Practices for Log Sanitisation in CI/CD Pipelines

Sanitisation should happen as close to the source as possible, not as a manual cleanup step before pasting into a chat window. Configure structured logging libraries (Pino, Winston, Serilog, structlog) with field-level redaction so keys like password, authorization, and secret are masked automatically before a log line is ever written or shipped to your aggregator. Run a secret-scanning tool such as gitleaks or truffleHog as a CI gate on every commit and on CI job output itself, since build logs frequently print environment variables during debugging. Configure your CI provider to automatically mask any value stored as a secret variable so it never appears in plaintext in job logs, and treat any CI log artifact retained for troubleshooting the same way you'd treat a database backup: access-controlled and time-limited.

Using This Tool as Part of a Secure Debugging Workflow

Make sanitising the default step, not an afterthought, whenever a log needs to leave your terminal: paste it into this tool first, glance at the stats bar to confirm the categories you expect were actually redacted, and only then copy, download, or hand it to an AI assistant. Add a custom pattern for anything specific to your stack, such as an internal token prefix, a customer ID format, or an employee badge number, so the default categories don't miss what matters most to your organisation. Because everything runs client-side with no network calls, this fits naturally into a workflow where you can't or shouldn't send raw data anywhere: air-gapped environments, regulated industries, or simply a habit of never trusting a paste box with production data until it's been through a filter first.

Frequently Asked Questions