Ihr KI-Programmierassistent hat gerade Ihre Geldbörse gelesen
KI-Programmierwerkzeuge lesen .env-Dateien, bevor Sie überhaupt etwas eintippen. Ihre API-Schlüssel — jeder einzelne eine Kreditkarte ohne Ausgabenlimit — befinden sich im Kontextfenster eines anderen, bevor Sie Ihre erste Anfrage formulieren. Das Problem ist nicht die KI. Das Problem ist, dass Geheimnisse Dateien sind.
Öffnen Sie Ihren KI-Programmierassistenten. Bevor Sie ein einziges Zeichen eingegeben haben, hat er bereits Ihr Projektverzeichnis gelesen. Ihre .env-Datei. Ihre API-Schlüssel. Ihre Datenbank-Passwort. Ihren Stripe-Secret-Key.
Sie haben ihn nicht darum gebeten. Sie haben es nicht genehmigt. Es ist eine Funktion, kein Fehler — das Werkzeug benötigt Projektkontext, um nützlich zu sein. Also liest es alles, was ein Entwickler lesen kann.
Und ein Entwickler kann alles lesen.
Die Greentext-Version
Ein Beitrag machte diese Woche die Runde, verfasst als innerer Monolog eines Entwicklers:
> Claude Code öffnen. Ihre .env wird gelesen, bevor Sie etwas eintippen. Ihre API-Schlüssel sind jetzt im Chat. Sie fügen "don't read .env" zu CLAUDE.md hinzu. Funktioniert nicht.
380.000 Menschen haben diesen Beitrag gesehen. 2.700 haben ihn als Lesezeichen gespeichert. Nicht weil es neu war — weil es ein Spiegel war.
Jeder Entwickler, der ihn las, dachte dasselbe: das ist mein Setup.
Anweisungen funktionieren nicht
Das Erste, was die Leute versuchten, waren Regeln. „.env-Dateien nicht lesen." In CLAUDE.md, in AGENTS.md, in System-Prompts. Direkte, ausdrückliche Verbote.
Das Werkzeug las die Dateien trotzdem.
Das ergibt Sinn, wenn man darüber nachdenkt. Die Datei wird als Teil des Aufbaus des Projektkontexts gelesen — bevor Anweisungen überhaupt verarbeitet werden. Dem Modell zu sagen, es solle eine Datei nicht lesen, die es bereits gelesen hat, ist wie jemandem zu sagen, er solle vergessen, was er gerade gesehen hat. Die Information ist im Kontextfenster. Sie wurde übertragen. Die Anweisung kommt nach dem Schaden.
Ein Forscher fand heraus, dass selbst Datei-Blockierregeln durch eigene Skripten oder Pipe-Ketten umgangen werden konnten. Ein anderer entdeckte erhöhte Proxy-Rechnungen, weil seine HTTP_PROXY-Zugangsdaten automatisch geladen und verwendet wurden.
Das Geld in Ihrer .env
Leute rahmen das als Datenschutzproblem ein. Es ist ein finanzielles.
Öffnen Sie eine typische .env-Datei in einem Produktionsprojekt:
OPENAI_API_KEY=sk-... STRIPE_SECRET_KEY=sk_live_... AWS_ACCESS_KEY_ID=AKIA... AWS_SECRET_ACCESS_KEY=... DATABASE_URL=postgresql://user:pass@...
Dieser OpenAI-Schlüssel ist eine Kreditkarte ohne Ausgabenlimit und ohne PIN. Wer diese Zeichenkette besitzt, kann über Nacht API-Aufrufe im Wert von 40.000 Dollar fahren. Der Stripe-Schlüssel kann Rückerstattungen ausstellen, Zahlungen erheben, auf Zahlungsdaten von Kunden zugreifen. Die AWS-Zugangsdaten — abhängig von der IAM-Richtlinie, die mit ziemlicher Sicherheit zu weit gefasst ist — können GPU-Instanzen hochfahren, auf S3-Buckets zugreifen oder Infrastruktur löschen.
Das ist keine Liste von Passwörtern. Es ist eine Liste von Geldbörsen, jede mit einem anderen Guthaben und ohne Schloss.
29 Millionen Geldbörsen auf dem Gehweg
Der aktuelle Bericht von GitGuardian zählte 28,6 Millionen Geheimnisse, die 2025 in öffentlichen GitHub-Commits offengelegt wurden. Ein Anstieg von 34 Prozent gegenüber dem Vorjahr und der größte jemals gemessene Jahreszuwachs.
Die KI-spezifischen Zahlen sind schlechter. 1,2 Millionen Geheimnisse von KI-Diensten offengelegt — ein Anstieg von 81 Prozent gegenüber dem Vorjahr. Commits, die von KI-Programmierwerkzeugen mitverfasst wurden, ließen Geheimnisse mit etwa der doppelten Rate der Grundlinie durchsickern. Und 24.000 eindeutige Geheimnisse wurden in MCP-Konfigurationsdateien gefunden — der Leitungsbau, der KI-Agenten mit externen Diensten verbindet.
Zwölf der fünfzehn am schnellsten wachsenden Typen durchgesickter Geheimnisse waren KI-Dienste. Nicht Datenbanken. Nicht Cloud-Anbieter. KI-Dienste.
Die Werkzeuge, mit denen wir schneller Code schreiben, lassen die Schlüssel zu jenen Systemen durchsickern, mit denen dieser Code sich verbindet.
Das eigentliche Problem
Der Entwickler, der diesen Greentext-Thread veröffentlichte, endete mit einer praktischen Lösung — einer settings.json-Konfiguration, die Dateilesen blockiert. Das funktioniert. Vorerst, für dieses Werkzeug.
Aber das eigentliche Problem ist nicht Claude Code oder Cursor oder Copilot. Das eigentliche Problem ist, dass Geheimnisse Dateien sind.
Eine .env-Datei ist ein Klartextdokument auf der Festplatte, lesbar für jeden Prozess, der unter Ihrem Benutzer läuft. Vor den KI-Programmierwerkzeugen waren die Prozesse, die Ihr Projekt lasen, git, npm, node, Ihr Editor. Sie vertrauten ihnen stillschweigend. Sie dachten nicht daran, dass Ihre Geheimnisse nur einen cat-Befehl von der Offenlegung entfernt waren.
KI-Programmierwerkzeuge haben das Implizite nur explizit gemacht. Sie lesen Ihr Projekt genauso wie jedes andere Werkzeug — sie senden den Kontext nur zufällig an einen Ort, an dem Sie ihn sehen können.
Auch Ihre CI-Pipeline liest .env-Dateien. Ihr Test-Runner auch. Ihr Linter auch. Ihr Docker-Build auch. Keines davon hat ebenfalls um Erlaubnis gefragt. Sie haben es nur nicht bemerkt, weil Ihnen keines ein Chat-Protokoll dessen gezeigt hat, was es gefunden hat.
Das Muster darunter
70 Prozent der 2022 durchgesickerten Geheimnisse sind heute noch aktiv. Nicht rotiert. Nicht widerrufen. Funktionieren noch, gewähren noch Zugriff, drei Jahre später.
Das ist die eigentliche Zahl. Nicht 29 Millionen Lecks — 70 Prozent nie behoben. Denn einen Schlüssel zu rotieren bedeutet, jedes System zu finden, das ihn verwendet, jedes Deployment zu aktualisieren, jede Integration zu testen. Der Schlüssel wurde einmal erstellt, in eine .env-Datei eingefügt und nie wieder bedacht. Die Kosten, ihn durchsickern zu lassen, sind augenblicklich. Die Kosten, das Leck zu beheben, sind unbegrenzt.
Also beheben die meisten Organisationen es nicht. Sie können es nicht. Sie wissen nicht, welche Schlüssel wo liegen, welche noch aktiv sind, welche in andere .env-Dateien auf anderen Maschinen kopiert wurden, von anderen Entwicklern, die an einem Freitagnachmittag eine Funktion zum Laufen bringen mussten.
Was das tatsächlich bedeutet
Jede .env-Datei ist eine Wette. Eine Wette darauf, dass kein Prozess sie jemals lesen wird, der es nicht sollte. Eine Wette darauf, dass kein Werkzeug sie jemals an einen unerwarteten Ort sendet. Eine Wette darauf, dass kein Entwickler sie jemals versehentlich committet.
29 Millionen Mal hat im vergangenen Jahr jemand diese Wette verloren. Allein auf öffentlichem GitHub. Die privaten Repos — in denen GitGuardian in 35 Prozent der Repositories Geheimnisse fand — sind nicht einmal gezählt.
Die Lösung ist keine settings.json-Regel. Die Lösung ist kein .gitignore-Eintrag. Die Lösung ist nicht, „DO NOT READ .ENV" in Großbuchstaben in Ihre Anweisungsdatei zu schreiben.
Die Lösung ist, dass das Geheimnis gar nicht erst dort sein sollte. Nicht in einer Datei. Nicht in einer Umgebungsvariable, die aus einer Datei geladen wird. Nicht in irgendeiner Form, die ein Prozess mit Ihren Berechtigungen lesen kann, indem er tut, was Prozesse tun: Dateien in Ihrem Projektverzeichnis lesen.
Wenn das Geheimnis auf der Festplatte liegt, wird es gelesen. Die einzige Frage ist wann und von was.
---
Quellen
- GitGuardian — State of Secrets Sprawl 2025 — 28,6 Mio. durchgesickerte Geheimnisse, Trends bei Zugangsdaten von KI-Diensten, Behebungsstatistiken
- GitGuardian: 29M Leaked Secrets — Why AI Agent Credentials Are Out of Control — Berichterstattung von Help Net Security mit KI-spezifischen Aufschlüsselungen
- Claude Code Can Consume, Transmit, and Compromise Your .env Files — Martin Paul Eves Bericht über das Scheitern von CLAUDE.md-Verboten
- Claude Code Automatically Loads .env Secrets, Without Telling You — Knostics technische Analyse des automatischen Ladens von Geheimnissen
- From .env to Leakage: Mishandling of Secrets by Coding Agents — Knostics breitere Analyse über Claude und Cursor hinweg
- @zodchiii auf X — Der virale Beitrag, der diesen Text anregte (380.000 Aufrufe, 2.700 Lesezeichen)