KI-Coding-Agenten geben Secrets preis. Prüfen Sie Ihre Repos

Wenn Sie Claude Code oder einen anderen KI-Coding-Agenten nutzen, nehmen Sie sich zuerst zehn Minuten für Ihre Repositories. Suchen Sie nach committeten Agenten-Einstellungsdateien, rotieren Sie jede darin enthaltene Zugangsdaten und aktivieren Sie das Secret Scanning von GitHub. Gestohlene Keys werden schnell weiterverkauft (Unit 42 beschreibt einen Fall, der nur Minuten dauerte), deshalb kommen die Checks vor der Geschichte.

Prüfen Sie zuerst Ihre Repos

Beginnen Sie mit der Datei im Zentrum der Claude-Code-Geschichte: .claude/settings.local.json. Das Sicherheitsunternehmen Apiiro fand 104.185 Kopien davon in 103.617 öffentlichen Repositories, und 1.122 dieser Kopien enthielten mindestens ein Secret (The Hacker News). So suchen Sie nach Ihren eigenen.

1. 1Durchsuchen Sie Ihre GitHub-Organisation nach dem Dateinamen (setzen Sie Ihren eigenen Organisationsnamen ein; die GitHub CLI wird benötigt).
2. 2Prüfen Sie in jedem Repo, an dem Sie arbeiten, ob die Datei jemals committet wurde, auch in alten Branches. Die Historie behält, was der letzte Commit gelöscht hat.
3. 3Lesen Sie die gespeicherten Freigaben auf alles durch, was nach Passwort, Token oder Connection String aussieht.
4. 4Scannen Sie die komplette Historie und ergänzen Sie eine Regel für Passwörter, die direkt in Befehlen stehen. Standard-Regelsets übersehen sie häufig.

# 1. Find the files across an organization
gh search code --owner YOUR-ORG --filename settings.local.json

# The same search in the GitHub web search box
#   org:YOUR-ORG path:.claude/settings.local.json

# 2. Was it ever committed, on any branch?
git log --all --oneline -- .claude/settings.local.json .claude/settings.json

# 3. List what you have approved with "don't ask again"
jq -r '.permissions.allow[]' .claude/settings.local.json

# 4. Grep the folder and its history for the usual suspects
grep -rEn 'PGPASSWORD=|sshpass -p|mysql -p|AKIA[0-9A-Z]{16}|ghp_[A-Za-z0-9]{20,}' .claude/
git log --all -p -- .claude | grep -E 'PGPASSWORD=|sshpass -p|mysql -p|AKIA[0-9A-Z]{16}'

Das sind gängige git-, jq- und grep-Aufrufe, aber behandeln Sie die Ausgabe als Hinweis, nicht als Urteil. Die Codesuche von GitHub sieht nur, was heute auf einem Branch liegt, und genau dafür gibt es Schritt 2.

Für den Scanner-Durchlauf nutzte Apiiro Gitleaks und TruffleHog. Lassen Sie beide über die Historie laufen und ergänzen Sie dann eine eigene Regel, denn die Standardregeln erkennen einen Key, aber kein Passwort hinter einem Flag.

gitleaks git --redact -v .
trufflehog git file://.

# .gitleaks.toml
[extend]
useDefault = true

[[rules]]
id = "password-inside-command"
description = "Password passed on a command line"
regex = '''(PGPASSWORD=|sshpass -p |mysql -p)\S+'''

Diese eigene Regel lohnt sich. Apiiro ließ beide Tools über alle gefundenen Dateien laufen: gitleaks markierte 564 der 1.122 Dateien mit Secrets, TruffleHog 643, und 215 fanden beide nicht, meist Passwörter hinter PGPASSWORD=, sshpass -p oder mysql -p (The Hacker News).

Apiiro rät Sicherheitsteams außerdem, .claude/, .cursor/, .gemini/, .specstory/ und Agenten-Memory-Dateien wie .env als secret-haltig zu behandeln. Wir würden dieselbe Suche für jeden Agenten durchführen, den Ihr Team installiert hat: Auch ein von Cursor, GitHub Copilot oder Codex gespeichertes Transkript kann einen eingefügten Key enthalten.

Wie ein Klick auf „Freigeben“ ein Passwort in Ihr Repo bringt

Claude Code fragt nach, bevor es die meisten Shell-Befehle ausführt. Wählen Sie „Yes, and don't ask again“, schreibt es eine Allow-Regel in .claude/settings.local.json. Laut Anthropic-Doku gilt eine so erteilte Bash-Freigabe „permanently per repository and command“ (Claude Code docs). Der Haken liegt in der Form der Regel. Sie kann ein Muster wie npm test * sein oder der exakte Befehl, und enthält dieser Befehl ein Passwort, steht es nun im Klartext in der Datei.

Die Datei soll eigentlich lokal bleiben. Laut Anthropics Settings-Dokumentation trägt Claude Code beim ersten Schreiben der Datei in einem Repo, das sie noch nicht ignoriert, **/.claude/settings.local.json in Ihre globalen Git-Excludes ein, und eine von Hand angelegte Datei braucht eine eigene .gitignore-Zeile (Claude Code docs). Das schützt einen Rechner, nicht aber einen frischen Clone, eine handgemachte Datei oder eine, die vor der Ignore-Regel committet wurde.

Mehr als ein Drittel der von Apiiro gefundenen Secrets öffnet direkt eine Datenbank, darunter 379 Datenbankpasswörter. Zum Rest gehören 43 SSH-Logins für öffentliche Server, 42 Tokens für GitHub, GitLab und npm sowie 23 AWS-Keys. Dreiundsechzig Organisationen besaßen betroffene Dateien, und in der Hälfte der Repos mit einem Secret lag die Datei seit mindestens 217 Tagen dort. Apiiro hat nicht getestet, ob davon noch etwas funktioniert, doch ein benachrichtigtes Unternehmen bestätigte, dass sein Key aktiv war.

Anthropics bisherige Antwort ist ein einzelner Hacker-News-Kommentar

Ein 2025 eingereichter Bug-Report wurde nach 60 Tagen ohne Aktivität von einem automatischen Bot als „not planned“ geschlossen, und laut Apiiros Forschern bekam keiner der zitierten verwandten Reports eine Antwort von Anthropic (The Hacker News). Die öffentliche Antwort kam auf Hacker News, von einem Kommentator, der sich als „Boris from the Claude Code team“ vorstellte. Er schrieb, „Historically Claude Code has not done secret scrubbing“, das Team prüfe, „what we can do to prevent this“, und in diesem Fall seien „the files were manually created and checked in“ gewesen. Er fügte hinzu: „Permission rules are old hat. Everyone should be using auto mode instead.“

Apiiros Daten passen schlecht zur Erklärung mit der Handarbeit. In 539 der 1.105 nachverfolgten Repositories änderte ein Commit mit Claude als Co-Autor die Datei. Eine Co-Author-Zeile beweist nicht, wer git ausgeführt hat, lässt sich aber kaum mit von Hand erstellten Dateien vereinbaren. Die Commit-Daten sind für uns schwerer zu verwerfen als der Kommentar, und wir würden die Datei als etwas behandeln, das Claude Code committen kann, bis Anthropic etwas anderes sagt.

Grok Build hat zweimal geleakt, auf unterschiedliche Weise

Zwei Grok-Build-Geschichten werden gerade vermengt, und sie brauchen unterschiedliche Fixes. (Die Berichterstattung nennt das Unternehmen SpaceXSI oder SpaceXAI.)

Die erste kam früher im Jahr 2026. Ein Forscher, der unter cereblab veröffentlicht, analysierte Grok Build 0.2.93 und berichtete, es habe ganze getrackte Git-Repositories samt Commit-Historie, committeten Secrets und API-Keys in einen Cloud-Speicher hochgeladen (The Next Web). Laut dieser Analyse war der Upload etwa 27.800-mal größer als für die Aufgabe nötig, und der Datenschutzschalter bewirkte angeblich nichts. xAI hatte das Tool mit dem Versprechen beworben: „nothing from your codebase transmitted to xAI servers during a session.“ Elon Musk räumte die Übertragungen ein und sagte, frühere Nutzerdaten würden gelöscht. TNW ergänzt, dass kein unabhängiges Audit die Löschung bestätigt hat.

Die zweite ist die, die jetzt in den Nachrichten ist, und sie hat nichts mit Repositories zu tun. Das Sicherheitsunternehmen Claroc fand heraus, dass die Share-Links von Grok Build auch von Leuten gefunden werden können, denen sie nie geschickt wurden (Claroc). Laut Engadget nutzte jeder Link eine zufällige Phrase aus vier Wörtern mit bis zu 38 Bit Entropie, platziert „to the left of the domain“ (Engadget). Damit steht sie im Hostnamen, und Claroc erklärt, dass Passive-DNS-Dienste diese Abfragen sammeln. Geteilte ChatGPT- und Gemini-Chats halten ihr Geheimnis im URL-Pfad, den DNS nie sieht. „Nobody would guess one“, schreibt Claroc, „and nobody needs to, because the dataset lists them.“

Die exponierten Apps enthielten echtes Material. Claroc listet eine Vertriebsgebietskarte mit 594 strategischen Accounts, acht X-Werbeangebote, vier aktive Werbekunden-Account-Boards, die Mitarbeiter-App einer Krankenhausgruppe mit einer Personalliste von mehr als 3.500 Beschäftigten und das Live-Schichtboard einer Feuerwehr mit Name und Dienstnummer jedes Feuerwehrmanns. Von den getesteten Adressen ließen sich 94,7 % ohne Anmeldung öffnen. Claroc schätzt, dass etwa 2 % der Apps Material enthielten, das ernst genug war, um als hoch oder kritisch eingestuft zu werden.

Laut Claroc nahm SpaceXSI die 24 von eigenen Mitarbeitern gebauten Apps vom Netz, „but not the apps of other Grok users and organizations.“ Engadget ergänzt, das Unternehmen habe angeblich erst reagiert, nachdem Claroc Musk und einen weiteren Firmenvertreter auf X markiert hatte. Claroc schreibt, SpaceXSI habe Fragen eines Reporters beantwortet und gesagt, Grok-Apps seien privat, bis ihr Ersteller sie teilen wolle, auf den Report selbst aber nicht geantwortet. Eine Aussage, dass die anderen Apps offline genommen werden, haben wir nicht gefunden.

Für Nutzer ist der Fix ziemlich simpel. Behandeln Sie alles, was Sie mit Grok Build gebaut oder geteilt haben, als öffentlich, nehmen Sie nicht benötigte Links offline und rotieren Sie jede Zugangsdaten, die mit einer von Ihnen geteilten App in Berührung kamen. Hier hilft keine .gitignore-Zeile.

Gestohlene Keys werden binnen Minuten weiterverkauft

Unit 42 von Palo Alto Networks beschreibt „Token Jacking“: Gestohlene KI-API-Keys werden über Graumarkt-„Transfer Stations“ weiterverkauft, die vergünstigten Zugang zu Frontier-Modellen anbieten (Unit 42). Zu den genannten Quellen für Keys zählen exponierte Code-Repositories, Infostealer und vergiftete npm-Pakete. In einem Fall banden Angreifer exponierte Zugangsdaten binnen Minuten in eine Transfer Station ein, und vor der Entdeckung fielen „nearly a million dollars in charges“ an. Laut Unit 42 haben Betroffene „very little recourse to recover funds.“ Die Gegenmaßnahmen sind die unspektakulären: Ausgabenlimits mit Alerts, kurzlebige Tokens statt langlebiger Keys und eine Prüfung jedes privilegierten Accounts, der Limits ändern kann.

Leak beheben: ignorieren, untracken, rotieren

Erst rotieren, dann aufräumen. Ein widerrufener Key ist in jedem Fork und jeder zwischengespeicherten Kopie nutzlos, während ein Key, den Sie nur aus dem letzten Commit gelöscht haben, in der Historie weiter gültig ist. GitHub rät, eine exponierte Zugangsdaten sofort zu rotieren, und nennt das Bereinigen der Historie „time-intensive and often unnecessary if you've already revoked the credential“ (GitHub docs).

# Rotate the exposed credentials first (table below), then:

# Stop tracking the local file (keeps your copy on disk)
git rm --cached .claude/settings.local.json

# Add to the repo's OWN .gitignore, not just your global excludes
printf '%s\n' '.claude/settings.local.json' '.specstory/' >> .gitignore

git add .gitignore
git commit -m "Stop tracking agent local settings"

# Drop any allow rule that looks like it holds a secret, even if never committed
jq '.permissions.allow |= map(select(test("PGPASSWORD|password|token|secret|key"; "i") | not))' \
  .claude/settings.local.json > .claude/settings.local.json.new \
  && mv .claude/settings.local.json.new .claude/settings.local.json

Überlegen Sie, bevor Sie .cursor/ oder .gemini/ pauschal ignorieren, denn manche Teams committen dort absichtlich gemeinsame Regeln.

Keys bei den großen Anbietern rotieren

Jeder Anbieter hat dafür einen Button in der Konsole, und die sichere Reihenfolge lautet: Ersatz erstellen, ausrollen, dann den alten Key beenden. Wer zuerst löscht, kann die Produktion lahmlegen.

Für alle Anbieter, die nicht in der Tabelle stehen, darunter Anthropic und xAI, haben wir die Rotationsschritte nicht überprüft, folgen Sie also deren eigener Doku. Bei Datenbankpasswörtern und SSH-Logins, dem Großteil dessen, was Apiiro fand, ändern Sie das Passwort, beenden offene Sessions und prüfen dann die Zugriffslogs ab dem Tag, an dem die Datei erstmals committet wurde.

GitHubs Scanner aktivieren und ihre Grenzen kennen

Secret Scanning prüft die komplette Historie jedes Branches sowie Issues, Pull Requests, Discussions und Wikis. Bei öffentlichen Repositories ist es kostenlos und automatisch; für private und interne Repos in einer Organisation braucht es GitHub Secret Protection (GitHub docs). Wird das Key-Format eines Partners erkannt, benachrichtigt GitHub diesen Anbieter, der den Key womöglich widerruft, ohne dass in Ihrem Repository ein Alert erscheint.

Push Protection ist die Ebene, die viele dieser Dateien gestoppt hätte, bevor sie öffentlich wurden. Sie blockiert einen Push, der ein erkanntes Secret enthält. Laut GitHub-Dokumentation ist die Einstellung auf Nutzerebene für Pushes in öffentliche Repositories auf GitHub.com standardmäßig aktiv, während die Einstellung auf Repository-Ebene standardmäßig aus ist und von einem Repo-Admin, Org-Owner oder Security Manager eingeschaltet werden muss (GitHub docs). Sie prüft Anbietermuster, generische Muster wie Private Keys und Connection Strings, Ihre eigenen Muster und eine KI-erkannte Kategorie für unstrukturierte Secrets wie Passwörter, derzeit in der Public Preview. Diese letzte Kategorie scheint auf die von Apiiro gefundene Lücke zu zielen. Pushes über die REST API werden nicht erfasst; Pushes über die Kommandozeile, Commits in der Weboberfläche und Datei-Uploads schon.

Kennen Sie auch das Schlupfloch. Standardmäßig kann jeder mit Schreibzugriff einen Block umgehen, indem er einen Grund auswählt, etwa „I'll fix it later“, was einen Alert öffnet und die Owner per E-Mail benachrichtigt. Wenn Ihre Agenten in Ihrem Namen committen, richten Sie Delegated Bypass ein, damit nur namentlich bestimmte Personen ein Secret durchwinken können.

Agenten-Berechtigungen, die Sie heute ändern sollten

Drei Gewohnheiten hätten das Passwort aus der Datei ferngehalten. Geben Sie Muster frei, niemals wörtliche Befehle mit Zugangsdaten. Legen Sie Secrets in Umgebungsvariablen, damit der Befehl einen Namen trägt, keinen Wert. Und verbieten Sie dem Agenten von vornherein den Zugriff auf Dateien, die Secrets enthalten. So sieht es laut Anthropics Settings-Dokumentation aus:

{
  "permissions": {
    "allow": [
      "Bash(npm run lint)",
      "Bash(npm run test *)"
    ],
    "deny": [
      "Read(./.env)",
      "Read(./.env.*)"
    ]
  }
}

Der Befehl, den Ihr Agent ausführen sollte, sieht aus wie psql "$DATABASE_URL", sodass die Freigaberegel nur einen Variablennamen speichert und sonst nichts. Laden Sie die Variable aus einem Secrets Manager oder Ihrem Shell-Profil, nicht aus einer Datei, die der Agent lesen kann.

Zwei Details aus der Doku sind für Teams wichtig: allow-Regeln in der committeten .claude/settings.json warten, bis jedes Teammitglied dem Ordner vertraut, während deny- und ask-Regeln sofort greifen, und die Modi auto und bypassPermissions wirken nicht aus Projekt- oder lokalen Einstellungen. Organisationen können Allow-Regeln mit allowManagedPermissionRulesOnly sperren. Das oben zitierte Mitglied des Claude-Code-Teams sagt, der Auto-Modus mache Berechtigungsregeln überflüssig. Wir würden die .env-Deny-Regeln trotzdem behalten: zwei Zeilen, wirksam ab dem Moment, in dem die Datei committet wird.

Bei anderen Tools heißen die Einstellungen anders, aber die Frage ist dieselbe: Wo speichert das Tool Freigaben, Verlauf oder Transkripte, und liegt dieser Ort innerhalb eines Repos? Laut Dokumentation ist Claude Code nach Apiiros Befund der einzige von 16 verglichenen Coding-Agenten, der nachweislich standardmäßig den vollständigen freigegebenen Befehl in einer Projektdatei speichert. Die anderen fünfzehn können trotzdem über Transkripte, eingefügte Keys und Memory-Dateien leaken. Unser Vergleich der Terminal-Coding-Agenten und der Beitrag Cursor vs Copilot vs Windsurf zeigen, was jeder speichert.

Die stärkste Kontrolle hängt nicht von einem Prompt ab. Lassen Sie Agenten in einem Container oder einer Sandbox laufen, nur mit den Zugangsdaten, die die Aufgabe braucht, mit begrenzten Scopes und kurzer Laufzeit. Die Mechanik haben wir in How to Contain an AI Agent beschrieben.

Die Rotation liegt bei den Nutzern, der Default bei den Anbietern

Ein Passwort in einen Befehl zu tippen ist ein Anwenderfehler, und die Rotation liegt beim Anwender. Aber ein Tool, das den vollständigen Befehl in einer Projektdatei speichert und sich dann auf einen Exclude im Home-Verzeichnis verlässt, um ihn privat zu halten, hat eine Sicherung, die nur auf einem Laptop funktioniert.

Defaults sind Politik, und hier hat der Default das Ergebnis bestimmt. Ein Claude Code, das Secrets vor dem Speichern einer Regel entfernt oder die Ignore-Zeile in die repoeigene .gitignore geschrieben hätte, hätte das Loch an der Quelle geschlossen. Anthropic sagt, man prüfe das (wir hätten gern ein Datum). Ein von einem Inaktivitäts-Bot geschlossener Bug-Report wirkt nicht beruhigend, und die Commit-Daten passen nicht zu „manually created“.

Grok Build ist bei den Share-Links der schlimmere Fall, weil der Nutzer nichts falsch gemacht hat. Ein Link, den jeder über Passive DNS finden kann, ist nicht privat, was auch immer das Teilen-Menü suggerierte. Und der frühere Upload widersprach einer Marketingaussage, die das Gegenteil behauptete. Wir würden keine Kundenliste, keine Vertriebsgebietskarte und keine Produktions-Zugangsdaten in Grok Build legen, bis das Share-Link-Problem behoben ist und ein externes Audit die Löschung bestätigt. Ändert sich das, ändert sich auch unsere Einschätzung.

Behandeln Sie Agenten-Ordner wie .env-Dateien und planen Sie einen Nachmittag für das obige Setup ein. Die Tools selbst vergleichen Sie auf unserem Board für KI-Coding-Assistenten, die Sicherheitsseite des Ökosystems auf dem Board für KI-Cybersecurity-Tools.

Eine Checkliste für das ganze Team

Haken Sie ab, was heute stimmt, und die Punktzahl zeigt Ihnen, wo Sie anfangen sollten. Die Punkte mit zwei Zählern würden wir noch vor der Mittagspause erledigen.

Häufig gestellte Fragen

Darf man .claude/settings.local.json committen?

Nein. Die Datei enthält Ihre persönlichen Freigaben und kann Zugangsdaten enthalten. Laut Anthropic-Doku hält Claude Code sie über einen globalen Exclude aus git heraus, wenn es die Datei selbst anlegt, und eine handgemachte Kopie braucht Ihre eigene Ignore-Zeile. Tragen Sie sie in die .gitignore jedes Repos ein und nehmen Sie sie mit git rm --cached aus dem Tracking, falls sie je committet wurde.

Muss ich Keys rotieren, wenn mein Repo privat ist?

Ja, wenn die Datei jemals Zugangsdaten enthielt. Private Repos werden auf Laptops und CI-Runner geklont, in andere Accounts geforkt und manchmal auf öffentlich umgestellt. Das Secret Scanning von GitHub für private Organisations-Repos braucht einen kostenpflichtigen Plan, deshalb gab es bei Ihnen womöglich keine automatische Prüfung.

Entfernt das Löschen der Datei aus meinem Repo das Secret?

Es entfernt es aus dem letzten Commit und sonst nirgends. Historie, Forks und Caches behalten die alte Version, und Apiiro fand 734 Secrets, die nur in älteren Versionen der Datei vorkommen. Rotieren Sie zuerst die Zugangsdaten und schreiben Sie die Historie nur um, wenn Sie ein aufgeräumtes Repo wollen.

Haben GitHub Copilot, Cursor und Codex dasselbe Problem?

Apiiro hat dieses Verhalten, das Speichern des vollständigen freigegebenen Befehls in einer Projektdatei als Standard, von den 16 verglichenen Agenten nur für Claude Code bestätigt. Das spricht die anderen nicht frei. Jeder Agent, der Transkripte oder Memory in Ihr Arbeitsverzeichnis schreibt, braucht dieselben Ignore-Regeln.