Tooling Note
`godot-secrets-scan` exists because local commit hygiene is still where a lot of avoidable exposure begins. In active development, copied tokens, test data, and personal data can slip into staging long before a later pipeline catches them.
The practical need was a local scan that fit the realities of iterative game and app work: fast edits, copied config fragments, asset-heavy projects, and the occasional accidental inclusion of data that never should have reached a commit.
Once those mistakes land in history, cleanup becomes heavier, slower, and less certain. The best place to reduce the risk is before the content is staged with intent.
Broader secret scanners already exist, but many are aimed at CI or repository-wide scanning after the risky step has already happened. That is useful, but it is later and more expensive than a local check at the point of intent.
What was missing was a lightweight, local-first scan that matched the actual workflow rather than only the centralized pipeline.
Secret and PII detection is a trust problem as much as a technical one. Open sourcing the logic makes it easier to inspect what is flagged, tune patterns, and adapt the scanner to different local workflows.
The operational pattern is reusable well beyond one engine or one repo: catch sensitive data before it is normalized into source control.
On Hubsays, `godot-secrets-scan` represents the privacy-facing side of the live-systems loop: reduce exposure early, before recovery depends on cleanup, audit trails, and damage control.