KI auf der Kommandozeile: Wie Claude Code, Cursor und Copilot CLI Ihre Secrets preisgeben

Ihre Senior Engineers tippen jetzt claude . ins Terminal

Vor drei Jahren war das KI-Risiko für ein Security-Team ein Junior-Entwickler, der Code in ChatGPT einfügt. Dieses Problem ist mit einer Browser-Erweiterung und einer schriftlichen Richtlinie weitgehend gelöst. Das neue Problem ist anders und deutlich schwerer: Ihre erfahrensten Engineers betreiben agentische CLI-Tools, die aktiv Dateien von der Festplatte lesen und sie an ein Frontier-Modell streamen — oft hunderte Male pro Session.

Claude Code refaktoriert einen Service. Cursors Agent-Modus schreibt ein ganzes Verzeichnis um. Copilot CLI erklärt einen Shell-Fehler. Aider macht Pair-Programming. Codex CLI führt eine lange Aufgabe aus. Jedes dieser Tools macht im Kern dasselbe: Datei lesen, an Modell senden, Tool-Call akzeptieren, weitere Dateien lesen. Der Entwickler sieht nie, wie die Bytes die Maschine verlassen.

Das ist alles in Ordnung — bis einer dieser Reads die .env, die ~/.aws/credentials oder die ~/.ssh/id_rsa betrifft. Dann liegt Ihr AWS-Root-Key, Ihr Stripe-Live-Key oder Ihre Produktions-SSH-Identität im Context-Cache eines LLM-Anbieters, möglicherweise in trainings-fähigen Logs, möglicherweise in der Audit-Tabelle eines Drittanbieter-MCP-Servers.

Die neue Normalität: Datei-lesende Agenten auf Entwickler-Laptops

Schauen Sie sich an, was ein typischer Engineer in einem Series-B-Startup gerade laufen hat:

• Claude Code im Projekt-Root geöffnet, mit Berechtigung, jede Datei im Workspace zu lesen.
• Cursor mit aktiviertem Agent-Modus, das gesamte Repo wird für Kontext indiziert.
• GitHub Copilot CLI beantwortet Fragen zu Shell-Befehlen, was bedeutet: liest, worauf der Shell-Fehler verweist.
• Aider in einem Nebenterminal, manchmal auf ~/scripts oder ~/dotfiles gerichtet.
• Ein MCP-Server, der eines der obigen Tools mit Postgres, GitHub, Linear oder einem internen Tool verbindet.

Jedes ist ein echter Produktivitätsmultiplikator. Jedes ist auch ein Draht zwischen Ihrem lokalen Dateisystem und einem Cloud-LLM. Ihre bestehenden Kontrollen — gitleaks in der CI, Secret-Scanning beim Push, eine DLP-Browser-Erweiterung — sitzen auf der falschen Seite dieses Drahtes.

Fünf Leak-Vektoren, die Sie in fünf Minuten reproduzieren können

1. Der "hilfsbereite" .env-Read

Der häufigste Leak. Ein Entwickler verdrahtet einen neuen Service und bittet den Agenten um Hilfe:

$ claude
> hilf mir diesen Stripe-Webhook einzurichten, die Keys liegen in .env

[Claude Code] Ich lese Ihre .env-Datei, um die aktuelle Konfiguration zu sehen.
[lese .env]
[lese webhook_handler.py]

Die gesamte .env — inklusive STRIPE_SECRET_KEY=sk_live_…, DATABASE_URL=postgres://user:password@… und dem OpenAI-Key, den das Team vergessen hatte — ist gerade im Klartext an ein Frontier-Modell gegangen, plus in den Context-Cache des Anbieters, plus in jedes MCP-Audit-Log auf dem Pfad.

2. AWS-Credentials während einer Debug-Session

Ein Engineer debuggt ein boto3-Script, das 403 gegen S3 wirft. Der Agent möchte die Credentials inspizieren:

$ claude
> dieses Script bekommt ständig AccessDenied auf s3:GetObject

[Claude Code] Ich prüfe Ihre AWS-Konfiguration.
[lese ~/.aws/credentials]
[lese ~/.aws/config]
[lese deploy.py]

~/.aws/credentials enthält typischerweise jedes Profil, das der Engineer je benutzt hat: privater Sandbox, der Staging-Account, manchmal eine Produktions-Break-Glass-Rolle. Alles landet im Modell-Kontext.

3. Hartkodierte Keys im Quellcode — mit dem Kontext drumherum

Das hier ist der schlimmste, weil der Leak unsichtbar wirkt. Eine Datei enthält einen Key, der nie dort sein sollte:

$ claude
> refaktoriere billing_service.py und ziehe die Stripe-Logik raus

[Claude Code] Lese billing_service.py (412 Zeilen)…

Zeile 38 dieser Datei ist STRIPE_KEY = "sk_live_51H…". Der Agent sieht ihn, refaktoriert drum herum und kann ihn — je nach Modell — hilfsbereit im geplanten Diff zurückspielen. Selbst wenn nicht, liegt die komplette Datei mit diesem Key jetzt in den Logs des Anbieters.

4. git log -p-Archäologie

Agenten lieben es, git auszuführen, um Historie zu verstehen. Das ist eines der schädlichsten Muster:

$ claude
> wann haben wir den Auth-Flow zuletzt geändert?

[Claude Code] Ich schaue mir die git-Historie an.
[führe aus: git log -p --all -- src/auth/]

Dieser Befehl fördert jeden Patch zutage, der je auf Auth-Dateien angewendet wurde. Die Credential, die jemand 2022 committet, aus main force-pushed und nie rotiert hat, weil "sie ist nicht im aktuellen Tree" — sie ist noch im Reflog. git log -p --all reicht sie dem Modell wortwörtlich.

5. Privater SSH-Key bei einer Connection-Error-Spirale

Ein Engineer kommt nicht per ssh auf eine Jumpbox. Er fragt den Agenten:

$ claude
> mein ssh auf bastion-prod hängt, prüf mal meine Config

[Claude Code] Ich schaue mir Ihr SSH-Setup an.
[lese ~/.ssh/config]
[lese ~/.ssh/id_rsa]
[lese ~/.ssh/known_hosts]

Der private Schlüssel selbst geht ans Modell. Ob das Modell ihn "merkt" ist die falsche Frage — die Bytes sind in Transit-Logs, Anbieter-Caches und jedem Logging-Proxy dazwischen.

Warum gitleaks und truffleHog Sie nicht retten

Ihr Team fährt gitleaks oder truffleHog bereits als Pre-Commit-Hook oder in der CI. Das ist eine gute Kontrolle. Sie sitzt auch komplett auf der falschen Seite des Problems.

Diese Tools feuern, wenn Sie versuchen, ein Secret in die Versionskontrolle zu schreiben. Der CLI-Agent-Leak passiert, wenn Sie ein Secret von der Festplatte lesen und an einen Dritten streamen. Bis gitleaks läuft, sind die Bytes seit zehn Minuten im Kontext eines Frontier-Modells. Pre-Commit-Scanning schützt Ihre git-Historie. Es schützt nicht das Dateisystem Ihres Laptops davor, Stück für Stück durch hilfsbereite Tool-Calls exfiltriert zu werden.

Die Lösung: den Lesepfad scannen, nicht nur den Schreibpfad

Die Kontrolle, die Sie tatsächlich brauchen, sitzt zwischen Agent und Dateisystem. Jede Datei, die der Agent öffnet, und jeder Shell-Befehl, den er ausführt, muss durch einen Scanner laufen, bevor die Bytes den Modellanbieter erreichen. Zeuslock CLI setzt das als Wrapper um:

zeuslock cli wrap claude-code -- claude-code .

Der Wrapper fängt Datei-Reads und Shell-Aufrufe des Agenten ab, lässt die Bytes durch die dreischichtige Detection-Pipeline von Zeuslock laufen (Regex, NER, Kontext-Heuristiken) und wendet den pro Findtyp konfigurierten Policy-Modus an:

• Monitor — Read durchlassen, aber den Fund in der Operator-Konsole protokollieren.
• Anonymize — das Secret durch ein strukturell gültiges Fake ersetzen (ein echt aussehender sk_live_-Stub), sodass die Modell-Logik weiter funktioniert, der echte Key aber nie rausgeht.
• Block — den Read komplett verweigern und einen klaren Fehler an den Agenten zurückgeben.

Der Rollout folgt demselben Muster, das wir überall empfehlen: Monitor zwei Wochen lang, damit Engineers sehen, was ihre Agenten tatsächlich tun; Anonymize drei Wochen, um Live-Secrets zu entfernen, ohne Workflows zu brechen; ab Woche sechs Block.

Drei zusätzliche Kontrollen, die gut dazu passen

Verzeichnis-Allowlists

Die meisten CLI-Agenten lesen bereitwillig jeden Pfad, den das OS sie erreichen lässt. Konfigurieren Sie den Wrapper so, dass der Agent nur innerhalb des aktuellen Repository-Roots lesen darf. ~/.env, ~/.aws, ~/.ssh und ~/Documents werden strukturell unerreichbar. Allein das schließt die ersten drei Vektoren oben.

MCP-Server-Allowlisting

MCP ist die Stelle, wo es schwerer wird. Ein falsch konfigurierter Postgres-MCP-Server kann Produktionszeilen ins Modell streamen. Ein interner Custom-MCP-Server kann Vault freilegen. Zeuslock CLI führt eine nutzerbezogene Allowlist von MCP-Servern und fängt die JSON-RPC-Payloads auf der Leitung ab — gleiche Detection-Pipeline, gleiche drei Policy-Modi, angewendet auf tools/call-Antworten, bevor sie den Agenten erreichen.

Policy-Modi pro Tool

Sie wollen wahrscheinlich andere Regeln für Claude Code auf einem Entwickler-Laptop als für einen Aider-Job in der CI. Die Operator-Konsole erlaubt, Policies pro Binary, pro Host und pro Umgebung zu skopen. Ein CI-Runner kann standardmäßig auf Block stehen; eine interaktive Claude-Code-Session kann Secrets anonymisieren und PII monitoren.

Was die Tool-Hersteller bereits tun — und wo die Lücke bleibt

Ehre, wem Ehre gebührt. Claude Code sandboxt standardmäßig auf das Projektverzeichnis, fragt nach, bevor es etwas außerhalb liest, und warnt bei typischen Secret-Dateinamen. Cursors Agent-Modus hat ähnliche Leitplanken. Copilot CLI begrenzt seine Reads sorgfältig. Keines dieser Tools will Ihre Secrets leaken.

Die Lücke ist der Mensch im Loop. Wenn der Agent fragt "darf ich .env lesen, um Ihnen bei der Stripe-Einrichtung zu helfen?", klickt der Engineer auf Erlauben, weil die Anfrage im Kontext vernünftig ist. Wenn der Engineer einen Stack-Trace einfügt, der zufällig einen Authorization-Header enthält, kommt überhaupt kein Permission-Prompt. Wenn git log -p eine 2022er-Credential ans Licht bringt, hat der Agent genau das getan, was er sollte.

Sandboxing auf Tool-Ebene fängt die offensichtlichen Fälle. Eine separate DLP-Schicht ist das, was die Fälle abfängt, in denen der Engineer Ja gesagt hat — obwohl er Nein hätte sagen sollen.

Was Sie dieses Quartal tun sollten

1. Inventarisieren Sie, welche CLI-Agenten Ihre Engineers tatsächlich nutzen. Fragen Sie in #engineering, nicht per Umfrage. Die Antwort wird Tools enthalten, von denen Security noch nie gehört hat.
2. Lassen Sie zeuslock cli scan ~/ auf der Maschine eines Freiwilligen laufen. Zählen Sie die Secrets, die für jeden Agenten mit Home-Verzeichnis-Zugriff lesbar wären. Die Zahl wird unangenehm.
3. Wrappen Sie ein einziges Tool — beginnen Sie mit dem, das Ihr dienstältester Engineer am meisten nutzt. Stellen Sie es zwei Wochen auf Monitor.
4. Sichten Sie die Funde in der Operator-Konsole. Teilen Sie die Top fünf mit dem Engineering-Team. Das Gespräch über Block ab Woche sechs schreibt sich von selbst.
5. Erweitern Sie auf MCP-Server, dann auf CI-Runner.

Das Prinzip passt in eine Zeile: setzen Sie einen Secret-Scanner auf den Lesepfad, nicht nur auf den Schreibpfad. Jede andere KI-DLP-Kontrolle, die Ihr Team dieses Jahr kauft, folgt daraus. DSGVO-konform und an den BSI-Empfehlungen für den professionellen Einsatz generativer Modelle ausgerichtet.

Die Konfigurations-Anleitung für den CLI-Wrapper steht in der Dokumentation: KI-Agenten mit Zeuslock CLI wrappen.