PII & Data-Leak Scanner

See the redacted evidence before you share the files

This output comes from the scanner's bundled synthetic risky fixture: four local files designed to exercise the published checks. No real personal data is shown.

fixtures/risky-sample/
├── app.log
├── profile.json
├── schema.sql
└── seed.csv

Files scanned: 4
Findings: 15

What the full report adds: file, line, rule, severity, evidence, and a concrete remediation for every finding. The scan is heuristic; review each result in context before changing or sharing a file.

What the scan covers

• PII-indicating column and key names such as email, ssn, phone, and address.
• SQL, CSV, and JSON files that can carry schemas, fixtures, exports, and sample records.
• Pattern-like email addresses, SSN-like values, credit-card-like numbers, and phone numbers.
• Personal data written into application, debug, or build logs.
• Seed and fixture files that may have been copied from a live environment.

The scanner creates a review queue. A field name tells you where personal data may be expected; a value match tells you where data may already be present. Neither is a verdict without context.

Input and report

Point the agent at the repository paths you want reviewed. Start with SQL schemas or migrations, seeds and fixtures, CSV or JSON samples, and recent logs. Keep unrelated directories outside the scope.

Each finding includes a file, line, rule, and remediation. Email-, SSN-, card-, and phone-like matches are replaced with redacted placeholders so the report does not reproduce the detected value.

Five practical use cases

• Review seed files before making a private repository public.
• Check logs before attaching them to an issue, support ticket, or AI conversation.
• Audit CSV and JSON samples before sending them to a contractor or vendor.
• Find production-looking records that slipped into local fixtures or demos.
• Add a personal-data review gate before a release, migration, or client handoff.

Run it with least privilege

The scan only needs local read access to the files in scope and Python 3 for the bundled standard-library workflow. It requires no network access, third-party package, environment secret, or write permission.

When the files may contain real personal data, work on an access-controlled copy and avoid pasting raw matches into chat, issue trackers, or public reports. Record the file and rule needed for remediation without reproducing the full sensitive value.

Known limitations

• Pattern matching can flag harmless examples, IDs, timestamps, and synthetic records.
• It can miss personal data expressed in an unexpected format or split across multiple fields.
• A value can become identifying only when combined with other data the scanner cannot infer.
• The published format coverage is SQL, CSV, JSON, and log files, including those in seed and fixture folders; other formats, binary files, and remote databases are outside scope.
• A clean result is not legal advice, a penetration test, or proof of GDPR or other regulatory compliance.

Use the review workflow before sharing the files

The codebase PII preflight explains which repository surfaces to inventory, how to triage pattern matches without copying sensitive values, and what evidence to keep after remediation.

Questions