Prompt your way to a secret leak: how AI tools commit your .env
How a quiet leak happens
You are moving fast with an AI assistant. You ask it to add a feature that needs an API key, it creates a .env, drops the key in, wires everything up, and the feature works. Later you ask it to commit your changes, and it does — all of them, because that is what you asked. Nobody said except the secrets. The .env goes into git, and if the repo is public or later deployed into a reachable path, the keys go with it.
This is not the tool misbehaving. It is the recurring theme of building with AI: it produces the code you asked for, not the security you did not mention. Keeping secrets out of version control is an unwritten rule that a fresh prompt has no reason to know.
The two ways .env ends up exposed
There are really only two failure modes, and both are mundane:
- Committed to the repo. The
.envlands in git history. Even if you delete it later, it lingers in history, and if the repo is or becomes public, the keys are readable. - Served on the live site. The
.envsits in a folder the web server hands out as static content, sohttps://yoursite/.envreturns it. Bots probe for exactly this path automatically.
Either way, the values inside — database strings, API keys, signing secrets — are the keys to the app, all in one small file.
Why it is easy to miss
The .env file is designed to be invisible during normal work; you rarely look at it after setup. It does not show up in the rendered site, and a committed file does not announce itself. So the leak is silent: everything works, nothing looks wrong, and the exposure only surfaces if you go looking — or if a bot finds it first.
Catching it early
A few habits close almost all of this:
- Add env files to
.gitignorefirst. Make sure.env,.env.localand friends are ignored before you ever commit, so they cannot be added by accident. - Keep secrets out of served folders. Serve static content from a dedicated directory, never the project root, so
.envis physically outside what the web server exposes. - Prefer real configuration in production. Use environment variables or a secrets manager rather than shipping a file at all.
- Rotate anything that was committed. If a secret ever hit git history, treat it as public — revoke and reissue it.
None of this means using AI less. It means adding the one rule the prompt left out.
Verify nothing slipped through
The reliable check is to look at your site the way an outsider does. An automated scan probes the predictable paths a bot would try — including .env and similar files — and reads your bundles for exposed key shapes, so a silent leak becomes visible. Scan your site and confirm your secrets stayed where they belong.