Result first: I committed a fake API key in a .env file, then "fixed" it the way most people do: add .env to .gitignore and run git rm --cached .env. The file stopped being tracked, but the key was still in history. git log --all -- .env still lists the commit that added it. Anyone who can clone the repository can read that commit.
Where GitHub helps (from GitHub Docs): #
Push protection for users is "enabled by default." It "stops you from pushing secrets to public repositories on GitHub." It is available only on GitHub.com.
- It scans pushes from the command line, commits made in the GitHub UI, file uploads, REST API requests, and (on public repos only) interactions with the GitHub MCP server.
- When it blocks you, you get a message explaining why. You remove the secret and push again.
Push protection for repositories is a separate feature. It is off by default and requires GitHub Secret Protection to be enabled.
- To check your own setting: profile picture → Settings →Code security → under "User",Push protection for yourself .
What this means for AI-assisted coding:
- Don't let an agent create files that hold keys inside the working tree it commits from. Put
.envin.gitignorebefore the first commit. - Push protection only knows the secret types it supports. It is a safety net, not a guarantee, and a private repository doesn't get the user-level protection.
- If a real key ever reached a pushed commit, treat the key as exposed. Replace it with your provider; don't just delete the file.
#
Sources
From Penloom Studio's free AI lessons: penloomstudio.com
source & further reading
dev.to — original article
Bareship: an offline-first React Native template for teams and AI agents
The AI-written shell script that ran from the wrong folder and exited 0: `set -euo pipefail`, and where it still won't save you
Ditto: type it once, and Gemma 4 on your laptop fills every form after that