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.
Want to see exactly what Prbl flags? Watch it scan a demo app, no repo or account needed.
See a live scan →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.