AI set up your repo and pushed it. It works, you shipped. What you actually shipped includes your .env — and with it, your live API keys — in the git history.
What you shipped
.env was never added to .gitignore, so git add . swept it into a commit. Now your keys live in history, even if you delete the file later.
How anyone exploits it
If the repo is (or ever becomes) public, anyone reading the history finds your STRIPE_KEY, database URL, and service-role keys. Bots scan GitHub for exactly this within minutes of a push.
Why you won’t catch it
Locally everything runs fine — your app reads the same .env. Nothing looks wrong until someone else can see the repo, and by then the keys are already out.
Why AI does it
git add . is the fastest way to commit everything, and .env looks like just another project file. Without a .gitignore entry, it goes along for the ride.
The fix
Ignore it, remove it from history, and — most importantly — rotate every key that was committed:
echo '.env' >> .gitignore # then rotate the keys; assume they're compromised
Check your app
.envand secret files are in.gitignorefrom the first commit.- No keys, tokens, or passwords are hardcoded in source.
- Any secret ever committed is rotated — deleting the file isn’t enough.
The bigger problem
A senior dev catches this by reflex. But if nobody senior reads the code, the broken version ships — it works in every test, because every test takes the happy path. The author and the reviewer are the same model with the same blind spot.
That’s the gap Velify is built to close: it reads your project and flags exactly this, in plain language, no terminal.