GitHub blockiert zwei weitere Typen von Anthropic-Keys beim Push
GitHub erweitert seinen Schutz gegen versehentlich veröffentlichte Zugangsdaten um zwei weitere Anthropic-Key-Typen._bestehende Lücken bleiben allerdings bestehen.
Dein Coding-Agent beendet eine Aufgabe, stagt alles mit git add -A und pusht. Irgendwo in diesem Commit steckt eine.env-Datei mit einem Anthropic API Key darin.
Seit dem 13. Oktober hat GitHub eine bessere Chance, diesen Push zu stoppen. Ein GitHub-Changelog-Eintrag vom 13. Oktober 2026 besagt, dass Secret Scanning nun zwei neue Anthropic-Secret-Typen erkennt, anthropic_user_api_key und anthropic_service_api_key, und dass Push Protection beide standardmäßig blockiert. Demselben Eintrag zufolge werden Commits, die diese enthalten, in Repositories mit aktiviertem Secret Scanning automatisch blockiert, auch in kostenlosen öffentlichen Repositories.
Das ist eine echte Verbesserung. Sie ist aber auch enger gefasst, als es klingt, denn ein privates Repository mit Standardeinstellungen erhält weiterhin keine Blockierung.
Der Changelog-Eintrag bündelt drei Dinge:
Der Eintrag sagt außerdem, dass diese Erkennungen als Alerts im eigenen Repository auftauchen, ob öffentlich oder privat, überall dort, wo Secret Scanning aktiviert ist.
Anthropic ist in diesem Programm kein Neuling. GitHub kündigte Anthropic am 20. August 2024 als Secret-Scanning-Partner an, und die Tabelle der unterstützten Muster von GitHub führt zusätzlich anthropic_api_key, anthropic_admin_api_key und anthropic_session_id auf. Wenn ein Schlüssel doch einmal in einem öffentlichen Repo landet, heißt es in Anthropics Artikel zur Schlüsselsicherheit: "Anthropic deaktiviert den offengelegten API Key automatisch" und benachrichtigt den betroffenen Nutzer per E-Mail.
Die Namen decken sich damit, wie Anthropic heute die Erstellung von Schlüsseln gestaltet. Die API-Key-Dokumentation verlangt die Wahl eines Typs bei der Erstellung: ein persönlicher Schlüssel "handelt in deinem Namen und hört auf zu funktionieren, wenn du eine Organisation verlässt", während ein Service-Account-Schlüssel für "Workloads wie CI-Pipelines, Produktionsdienste oder Agents" gedacht ist. Die Dokumentation bringt es auf einen Punkt: "Nutze einen persönlichen Schlüssel für die eigene Entwicklung und einen Service-Account-Schlüssel für alles, was geteilt wird."
Der ältere Workspace-Schlüssel wird dort als "ein veralteter Schlüssel ohne Besitzer" beschrieben, der auch nach dem Ausscheiden seines Erstellers weiter funktioniert.
GitHubs Mustertabelle bezeichnet die beiden Detektoren als "Anthropic User API Key" und "Anthropic Service Account API Key". Dass "user" dem entspricht, was Anthropic einen persönlichen Schlüssel nennt, ist meine Interpretation; keine der beiden Seiten sagt es ausdrücklich.
Push Protection stoppt den Commit, bevor er GitHub erreicht. Der Schlüssel befindet sich weiterhin in deiner lokalen Historie.
GitHubs Push-Protection-Dokumentation führt auf, wo sie greift: Kommandozeilen-Pushes, Commits über die GitHub-Weboberfläche, Datei-Uploads, REST-API-Anfragen sowie GitHub MCP Server Interaktionen, allerdings nur für öffentliche Repositories. Der letzte Punkt ist relevant, wenn dein Agent über den GitHub MCP Server statt über git auf GitHub schreibt.
Eine Blockierung ist keine Mauer. Dieselbe Dokumentation besagt, dass standardmäßig "jeder mit Schreibzugriff auf das Repository Push Protection umgehen kann, indem er einen Umgehungsgrund angibt." Bei aktivierter Repository-Push-Protection entscheidet der gewählte Grund darüber, was mit dem Alert passiert:
In diesem Modus wird jede Umgehung außerdem ins Audit-Log eingetragen und per E-Mail an Owners, Security Manager und Repository-Admins gemeldet, die das Repository beobachten. Bei nur der Standard-Push-Protection für Nutzer heißt es in der Dokumentation, dass sie "bei einer Umgehung von Push Protection keine Alerts erzeugt", sofern Push Protection nicht zusätzlich auf Repository-Ebene aktiviert ist. In einem öffentlichen Repo mit Standardeinstellungen hinterlässt eine Umgehung also keinen Alert, den jemand prüfen könnte.
Dein Agent pusht in der Regel mit deinen Git-Credentials, daher bist du derjenige, der einen blockierten Schlüssel durchwinken kann, oder alles, was mit diesen Credentials handelt. Wo Repository-Push-Protection aktiv ist, lies den Umgehungsgrund bei jedem Alert aus einem Agent-Branch, bevor du ihn schließt.
Eine Blockierung bedeutet auch, dass der Schlüssel bereits in einem lokalen Commit steckt. Push Protection hat ihn von GitHub ferngehalten. Er wurde damit nicht aus deinem Branch entfernt.
Die Push-Protection-Dokumentation beschreibt zwei Arten, die unterschiedliche Repositories abdecken:
Für ein privates Repository, in dem niemand Secret Protection und Repository-Push-Protection aktiviert hat, beschreibt die Dokumentation also keinerlei Blockierung. Die Änderung vom 13. Oktober verlängert die Standardliste. Sie schaltet die Funktion nicht an dort, wo sie ausgeschaltet war.
Private Repositories benötigen aktiviertes Secret Protection und Repository-Push-Protection, bevor überhaupt etwas blockiert wird.
Git ist auch nicht der einzige Ort, an dem ein Schlüssel im Klartext liegt. Wenn du jemals export ANTHROPIC_API_KEY=... in ein Terminal getippt hast, befindet er sich in deiner Shell-Historie. Ich baue Hermes IDE, also bewerte das vor diesem Hintergrund: Hermes 2.3.2, veröffentlicht am 13. Oktober, bietet für Befehle, die einen API Key, ein Token oder ein Passwort enthalten, keine Terminal-Vorschläge mehr an. Die eigene History-Datei deiner Shell bleibt unverändert, das Bereinigen ist also deine Aufgabe. Hermes steht in keiner Verbindung zu GitHub oder Anthropic.
1. Aktiviere Repository-Push-Protection, wo immer es möglich ist. Wenn deine Organisation GitHub Secret Protection besitzt, aktiviere Push Protection auf Organisationsebene. Der Dokumentation zufolge bleibt sie ausgeschaltet, bis jemand das tut.
2. Gib Agents und CI ihren eigenen Schlüssel. Anthropics Dokumentation empfiehlt Service-Account-Schlüssel für "alles, was geteilt wird", und Agents stehen auf dieser Liste. Getrennte Schlüssel bedeuten, dass du einen geleakten Agent-Schlüssel widerrufen kannst, ohne deinen eigenen anzufassen, und ein persönlicher Schlüssel hört auf zu funktionieren, wenn sein Besitzer die Organisation verlässt.
3. Halte.env aus dem Repository-Baum heraus und prüfe, was bereits vorhanden ist.
# Stoppe das Tracking der Datei, behalte sie aber auf der Festplatte echo ".env" >>.gitignore git rm --cached.env # Zähle Historienzeilen, die nach Anthropic-Schlüsseln aussehen git log --all -p | grep -c 'sk-ant-' Enter fullscreen mode Exit fullscreen mode Anthropics Dokumentation sagt, dass jeder Schlüssel "mit sk-ant- beginnt", wonach das grep sucht. git rm --cached schlägt harmlos fehl, wenn.env nie getrackt wurde. Die Zählung schließt Platzhalter und entfernte Zeilen ein, also wirf einen Blick auf die Treffer, bevor du handelst. Taucht ein echter Schlüssel auf und dieser Branch wurde jemals gepusht, rotiere ihn in der Claude Console. Zuerst rotieren; ein History-Rewrite kann einen Schlüssel nicht zurückholen, den jemand bereits kopiert hat.
Betrachte GitHubs Blockierung als das Sicherheitsnetz unter diesen drei Schritten, nicht als den Plan.
Ich baue Hermes IDE: Es betreibt Claude Code, Codex und andere Agents parallel, jede Aufgabe auf ihrem eigenen Branch und Worktree, und es ist kostenlos und Quellcode-verfügbar (BSL 1.1) unter macOS, Windows und Linux. Wenn sich das nützlich anhört, gib ihm einen Stern auf GitHub. Wer Agents baut, die mit Credentials arbeiten, findet in dem AI Agents Pocket Guide die zugehörigen Guardrail-Muster.
Automatisch übersetzt. Das Original auf Englisch ist unten aufklappbar.
Original (Englisch) anzeigen
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.
The changelog entry bundles three things:
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.
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.
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:
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.
The push protection docs describe two kinds, and they cover different repositories:
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.
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-' Enter fullscreen mode Exit fullscreen mode 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.
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.