Pushing a key to a public repo feels recoverable, like a typo you can delete before anyone notices. That instinct is what makes it dangerous, because the actual timeline is much faster and much less forgiving than it feels. A recognizable secret in a public commit is not a private mistake waiting for you to fix it; it is a public broadcast the moment it lands.
The timeline
The push. The instant a commit hits a public repo, it is part of a stream that anyone can watch, and plenty of automated systems do, continuously.
Minutes later, detection. Bots scan that stream and match known key formats as commits arrive. A key with a recognizable shape, a cloud access key, a payment or AI provider key, a token, gets flagged almost immediately. This is not a targeted attack on you; it is indiscriminate and constant.
Soon after, use. Once collected, keys get tried against the matching service. Some are used within minutes. A cloud key might launch expensive resources, an AI or API key gets spent against your quota or funds, a database key reads or changes your data. The scope of the key decides how bad it gets.
Want to see exactly what Prbl flags? Watch it scan a demo app, no repo or account needed.
See a live scan →Why deleting the commit does not help
The natural reaction is to delete the file or rewrite history, but by then the value is already out. Deleting the file in a later commit leaves the secret sitting in your git history for anyone to read. Even a force-push that rewrites history does not recall the copies that automated systems may have already cloned or cached in the minutes the key was live. You cannot un-ring the bell by editing the repo.
The only fix that works: rotate
Because the exposed value is out of your control, the fix is to make that value stop working. Rotate the key: generate a new one, update it wherever your app reads it from, and revoke the old one so the leaked copy is useless. Then check for damage, unexpected usage, new resources, unfamiliar activity, and move the new key into an environment variable so it never touches the repo again. The step-by-step is in the recovery checklist for a committed key.
Preventing the next one
The reason this keeps happening with AI tools is that they inline keys to make code run, and a missing .gitignore entry lets the .env get committed. Layer the prevention so a key cannot reach a commit: gitignore .env before the first commit, add a secrets rule to your tool's instruction file, and install a pre-commit secret scanner as described in the four-layer secrets setup.
Frequently asked questions
How fast do bots really find a leaked key?
Minutes, not days. Automated scanners watch the public commit stream continuously and match known key formats as commits arrive, so a recognizable secret can be picked up almost as soon as it is pushed. Some keys are used within minutes of exposure. Planning around hours or days of grace is a mistake; treat any secret that touched a public repo as compromised the moment it was pushed.
I deleted the commit right away. Am I safe?
No. Deleting the file in a later commit leaves the secret in your git history, where anyone can still read it, and even a force-push does not help once someone or something has already cloned or cached it. The commit stream is watched in real time, so the copy may already be gone. The only reliable response is to rotate the key so the exposed value no longer works, not to try to erase it.
What can an attacker do with the key?
Whatever the key authorizes, at your expense. A cloud key can spin up expensive resources and run up a large bill quickly. An AI or third-party API key gets used until the quota or funds are exhausted. A database URL or service key can read, change, or delete your data. The damage depends on the key's scope, which is one reason to give keys the least privilege they need.
How do I stop it from happening again?
Layer prevention so a hardcoded key cannot reach a commit in the first place: gitignore your .env before the first commit, add a rule to your AI tool's instruction file to use environment variables, install a pre-commit secret scanner that fails the commit when a key is present, and enable your host's server-side secret scanning as a backstop. Each layer catches what the last one missed.
Check what is already exposed
If you have been building with an assistant, there may already be a key in your code or history. A scan reads the repo the way those bots do and hands you the file and line for anything exposed, so you can rotate it before it is used. Run a free scan and find out what is sitting in your repo.