Hardcoded secrets, API keys, database passwords, signing secrets, end up in source code more often than most teams assume, and they’re disproportionately common in AI-generated files: migration scripts, seed data, and quickly scaffolded config.
Check more than the current branch
A secret committed once and “removed” in a later commit is still sitting in your git history, retrievable by anyone with read access to the repo. Scan full git history, not just the working tree. Tools like trufflehog and gitleaks are built specifically for this.
Scan your own app for issues like these
Paste your live URL. We check what your app serves publicly for exposed keys and misconfigurations. No account, no install.
Where AI-generated secrets actually hide
- Database migration and seed files (
password='password123'as test data that ships to production) - Config files with a real-looking key used “temporarily” during scaffolding
- Test fixtures and mock data that reuse a real API key from a
.envfile the model could read - Comments left in by an AI tool showing an example value, copy-pasted from a real key
What to do once you find one
Removing the line is not enough. The secret is still valid and still in history. Rotate the credential first, then remove it from source and history. A removed-but-unrotated secret is still a live vulnerability.
Make it impossible to merge again
Add a secret-scanning check to your CI pipeline so a hardcoded credential blocks the pull request instead of reaching main. This is the difference between finding secrets occasionally and never shipping one again.