Most leaked keys are committed by the person who owns them, in a config file, and stay valid until someone notices. GitGuardian found 24,008 unique secrets in public MCP configuration files and confirmed 2,117 of them still worked — about nine per cent.
| Where it leaks | What catches it |
|---|---|
A .env file committed with the first push | A .gitignore written before the first commit |
| A key hard-coded in a script | Secret scanning in the editor or pre-commit hook |
| A key pasted into a shared config | Push protection on the remote |
| A key in a screenshot or a log line | Nothing automatic. Read before you paste |
Deleting the commit does not help
A key that reached a remote is compromised. The commit stays in the history and in every clone, and the object may live on the host after the branch is deleted. The only remedy is to revoke the key at the provider and issue a new one.
Treat rotation as the fix and history rewriting as tidying.
Order of operations
Write .gitignore before the first commit, not after the first leak. Add .env to it, and keep a .env.example with empty values so the next person knows which variables exist.
Turn on push protection where the host offers it. GitHub's blocks a push that contains a recognised secret pattern, which stops the common case before it reaches the remote.
Scan before you push, not after. A pre-commit hook that runs a secret scanner costs a second per commit.
The one that is not a tooling problem
Keys pasted into chat, into an issue, or into a screenshot of a terminal. No scanner sees those, and they are how a key reaches a public page most often.
Rotate on any exposure, even a private one. The cost is one minute; the alternative is finding out from a bill.