- Book: AI Agents Pocket Guide
- Also by me: Thinking in Go (2-book series) — Complete Guide to Go Programming + Hexagonal Architecture in Go
- My project: Hermes IDE | GitHub — an IDE for developers who ship with Claude Code and other AI coding tools
- Me: xgabriel.com | GitHub
Your coding agent finishes a task, stages everything with git add -A, and pushes. Somewhere in that commit is a .env file with an Anthropic API key in it.
Since October 13, GitHub has a better chance of stopping that push. A GitHub changelog entry dated October 13, 2026 says secret scanning now detects two new Anthropic secret types, anthropic_user_api_key and anthropic_service_api_key, and that push protection blocks both by default. Per the same entry, commits containing them are blocked automatically in repositories with secret scanning enabled, free public repositories included.
That is a real improvement. It is also narrower than it sounds, because a private repository on default settings still gets no block.
What GitHub changed on October 13
The changelog entry bundles three things:
- Two new Anthropic detectors,
anthropic_user_api_keyandanthropic_service_api_key, plus a Cloudsmith API key detector. - Salesforce joins as a secret scanning partner, for Marketing Cloud API OAuth2 tokens. Partner secrets found in public repositories are sent to the issuer so it can revoke or rotate them.
- Both new Anthropic types are added to the set that push protection blocks by default.
The entry also says these detections show up as alerts in your own repository, public or private, wherever secret scanning is turned on.
Anthropic isn't new to this program. GitHub announced Anthropic as a secret scanning partner on August 20, 2024, and GitHub's supported patterns table also lists anthropic_api_key, anthropic_admin_api_key and anthropic_session_id. When a key does land in a public repo, Anthropic's key safety article says "Anthropic automatically deactivates the exposed API key" and emails the affected user.
Why these two key types
The names line up with how Anthropic now asks you to create keys. Its API key docs make you pick a type at creation: a personal key "acts as you, and stops working if you leave an organization," and a service account key is for "workloads such as CI pipelines, production services, or agents." The docs put it in one line: "Use a personal key for your own development, and a service account key for anything shared."
The older workspace key is described there as "a legacy key without an owner" that keeps working after its creator leaves.
GitHub's patterns table calls the two detectors "Anthropic User API Key" and "Anthropic Service Account API Key". Matching "user" to what Anthropic calls a personal key is my reading; neither side states it.
Push protection stops the commit before it reaches GitHub. The key is still in your local history.
What a block does, and who can wave it through
GitHub's push protection docs list where it applies: command-line pushes, commits made in the GitHub UI, file uploads, REST API requests, and GitHub MCP server interactions for public repositories only. That last item matters if your agent writes to GitHub through the GitHub MCP server instead of through git.
A block is not a wall. The same docs say that by default "anyone with write access to the repository can bypass push protection by specifying a bypass reason." With repository push protection on, the reason you pick decides what happens to the alert:
- "It's used in tests" closes the alert as used in tests.
- "It's a false positive" closes it as a false positive.
- "I'll fix it later" leaves the alert open.
In that mode each bypass is also added to the audit log and emailed to owners, security managers and repository admins who watch the repo. With only the default push protection for users, the docs say it "does not generate alerts when you bypass push protection" unless push protection is also enabled at the repository level. So on a public repo with default settings, a bypass leaves no alert for anyone to review.
Your agent usually pushes with your git credentials, so the person who can wave a blocked key through is you, or anything acting with those credentials. Where repository push protection is on, read the bypass reason on any alert from an agent branch before you close it.
A block also means the key is already in a local commit. Push protection kept it off GitHub. It didn't remove it from your branch.
Where it doesn't reach
The push protection docs describe two kinds, and they cover different repositories:
- Push protection for users "is enabled by default" and "stops you from pushing secrets to public repositories on GitHub." The docs don't say it covers private ones.
- Push protection for repositories "requires GitHub Secret Protection to be enabled" and "is disabled by default." An admin, owner or security manager has to turn it on.
So for a private repository where nobody has enabled Secret Protection and repository push protection, the docs describe no block at all. The October 13 change makes the default list longer. It doesn't turn the feature on in places where it was off.
Private repositories need Secret Protection and repository push protection switched on before anything is blocked.
Git isn't the only place a key sits in plain text, either. If you ever typed export ANTHROPIC_API_KEY=... in a terminal, it lives in your shell history. I build Hermes IDE, so weigh this with that in mind: Hermes 2.3.2, released October 13, no longer offers terminal suggestions for commands that hold an API key, token or password. Your shell's own history file is left as it was, so cleaning it is on you. Hermes isn't affiliated with GitHub or Anthropic.
Three things to do this week
1. Turn on repository push protection where you can. If your organization has GitHub Secret Protection, enable push protection at the organization level. Per the docs, it stays off until someone does.
2. Give agents and CI their own key. Anthropic's docs recommend service account keys for "anything shared," and agents are in their list. Separate keys mean you can revoke a leaked agent key without touching your own, and a personal key stops working when its owner leaves the organization.
3. Keep .env out of the tree, and check what's already there.
# stop tracking the file but keep it on disk
echo ".env" >> .gitignore
git rm --cached .env
# count history lines that look like Anthropic keys
git log --all -p | grep -c 'sk-ant-'
Anthropic's docs say every key "starts with sk-ant-," which is what the grep looks for. git rm --cached fails harmlessly if .env was never tracked. The count includes placeholders and removed lines, so look at the matches before you act. If a real key shows up and that branch was ever pushed, rotate it in the Claude Console. Rotate first; a history rewrite can't recall a key someone already copied.
Treat GitHub's block as the net under those three steps, not the plan.
If this was useful
I build Hermes IDE: it runs Claude Code, Codex and other agents side by side, each task on its own branch and worktree, and it's free and source-available (BSL 1.1) on macOS, Windows and Linux. If that sounds useful, star it on GitHub. If you're building agents that touch credentials, the AI Agents Pocket Guide covers the guardrail patterns around them.
Top comments (0)