Din AI-kodassistent läste precis din plånbok
AI-kodverktyg läser .env-filer innan du hinner skriva något. Dina API-nycklar — var och en ett kreditkort utan köpgräns — ligger i någon annans kontextfönster innan du skriver din första prompt. Problemet är inte AI:n. Problemet är att hemligheter är filer.
Öppna din AI-kodassistent. Innan du skriver ett enda tecken har den redan läst din projektkatalog. Din .env-fil. Dina API-nycklar. Ditt databaslösenord. Din Stripe secret key.
Du bad den inte om det. Du godkände det inte. Det är en funktion, inte ett fel — verktyget behöver projektkontext för att vara användbart. Så det läser allt en utvecklare kan läsa.
Och en utvecklare kan läsa allt.
Greentext-versionen
Ett inlägg cirkulerade i veckan, skrivet som en utvecklares inre monolog:
> Öppna Claude Code. Din .env läses innan du hinner skriva något. Dina API-nycklar ligger nu i chatten. Du lägger till "don't read .env" i CLAUDE.md. Fungerar inte.
380 000 personer såg det inlägget. 2 700 bokmärkte det. Inte för att det var nyheter — för att det var en spegel.
Varje utvecklare som läste det tänkte samma sak: det är min setup.
Instruktioner fungerar inte
Det första folk provade var att skriva regler. "Läs inte .env-filer." I CLAUDE.md, i AGENTS.md, i systemprompter. Direkta, uttryckliga förbud.
Verktyget läste filerna ändå.
Det är logiskt när man tänker efter. Filen läses som en del av byggandet av projektkontext — innan instruktioner ens bearbetas. Att be modellen att inte läsa en fil den redan läst är som att be någon glömma det de just såg. Informationen ligger i kontextfönstret. Den har överförts. Instruktionen kommer efter skadan.
En forskare upptäckte att till och med deny-regler på filnivå kunde kringgås via skräddarsydda skript eller rörkedjor. En annan upptäckte förhöjda proxy-avgifter eftersom deras HTTP_PROXY-uppgifter automatiskt laddades och användes.
Pengarna i din .env
Folk beskriver det här som en integritetsfråga. Det är en ekonomisk fråga.
Öppna en typisk .env-fil i ett produktionsprojekt:
OPENAI_API_KEY=sk-... STRIPE_SECRET_KEY=sk_live_... AWS_ACCESS_KEY_ID=AKIA... AWS_SECRET_ACCESS_KEY=... DATABASE_URL=postgresql://user:pass@...
Den OpenAI-nyckeln är ett kreditkort utan köpgräns och utan PIN-kod. Någon med den strängen kan köra API-anrop för 40 000 dollar över en natt. Stripe-nyckeln kan utfärda återbetalningar, skapa debiteringar, komma åt kunders betaldata. AWS-uppgifterna — beroende på IAM-policyn, som med största sannolikhet är för bred — kan starta GPU-instanser, komma åt S3-buckets eller radera infrastruktur.
Det här är inte en lista med lösenord. Det är en lista med plånböcker, var och en med ett eget saldo och utan lås.
29 miljoner plånböcker på trottoaren
GitGuardians senaste rapport räknade 28,6 miljoner exponerade hemligheter i offentliga GitHub-commits under 2025. En ökning med 34 procent från året innan, och den största årliga ökningen de någonsin mätt.
De AI-specifika siffrorna är värre. 1,2 miljoner exponerade hemligheter för AI-tjänster — en ökning med 81 procent år över år. Commits som medförfattats av AI-kodverktyg läckte hemligheter i ungefär dubbelt så hög takt som baslinjen. Och 24 000 unika hemligheter hittades i MCP-konfigurationsfiler — rörledningen som kopplar AI-agenter till externa tjänster.
Tolv av de femton snabbast växande typerna av läckta hemligheter var AI-tjänster. Inte databaser. Inte molnleverantörer. AI-tjänster.
Verktygen vi använder för att skriva kod snabbare läcker nycklarna till systemen som koden ansluter till.
Det verkliga problemet
Upphovspersonen till den där greentext-tråden avslutade med en praktisk lösning — en settings.json-konfiguration som blockerar filläsning. Det fungerar. För tillfället, för det verktyget.
Men det verkliga problemet är inte Claude Code eller Cursor eller Copilot. Det verkliga problemet är att hemligheter är filer.
En .env-fil är ett klartextdokument som ligger på disken, läsbart av alla processer som körs som du. Innan AI-kodverktyg var processerna som läste ditt projekt git, npm, node, din editor. Du litade på dem utan att tänka efter. Du tänkte inte på att dina hemligheter var ett cat-kommando bort från att exponeras.
AI-kodverktyg gjorde bara det underförstådda uttryckligt. De läser ditt projekt på samma sätt som alla andra verktyg — det råkar bara vara så att de skickar kontexten någonstans där du kan se den.
Din CI-pipeline läser .env-filer den också. Det gör din testkörare. Det gör din linter. Det gör din Docker-byggnation. Ingen av dem bad om lov heller. Du la bara inte märke till det eftersom de inte visade dig ett chattutskrift av vad de hittade.
Mönstret under
70 procent av hemligheterna som läcktes 2022 är fortfarande aktiva idag. Inte roterade. Inte återkallade. Fungerar fortfarande, ger fortfarande åtkomst, tre år senare.
Det här är det verkliga talet. Inte 29 miljoner läckor — 70 procent som aldrig åtgärdades. För att rotera en nyckel måste du hitta varje system som använder den, uppdatera varje distribution, testa varje integration. Nyckeln skapades en gång, klistrades in i en .env-fil och tänktes aldrig på igen. Kostnaden för att läcka den är omedelbar. Kostnaden för att åtgärda läckan är obegränsad.
Så de flesta organisationer åtgärdar det inte. De kan inte. De vet inte vilka nycklar som är var, vilka som fortfarande är aktiva, vilka som har kopierats till andra .env-filer på andra maskiner av andra utvecklare som behövde få en funktion att fungera en fredagseftermiddag.
Vad det här faktiskt betyder
Varje .env-fil är ett vad. Ett vad om att ingen process någonsin läser den som inte borde. Ett vad om att inget verktyg någonsin skickar den någonstans oväntat. Ett vad om att ingen utvecklare någonsin committar den av misstag.
29 miljoner gånger förra året förlorade någon det vadet. Enbart på offentligt GitHub. De privata reposen — där GitGuardian hittade hemligheter i 35 procent av repon — räknas inte ens in.
Lösningen är inte en settings.json-regel. Lösningen är inte en .gitignore-post. Lösningen är inte att skriva "LÄS INTE .ENV" med versaler i din instruktionsfil.
Lösningen är att hemligheten inte borde finnas där från början. Inte i en fil. Inte i en miljövariabel som laddas från en fil. Inte i någon form som en process med dina behörigheter kan läsa genom att göra det processer gör: läsa filer i din projektkatalog.
Om hemligheten ligger på disk kommer den att läsas. Den enda frågan är när, och av vad.
---
Källor
- GitGuardian — State of Secrets Sprawl 2025 — 28,6 miljoner läckta hemligheter, trender för AI-tjänsteuppgifter, statistik kring åtgärdande
- GitGuardian: 29M Leaked Secrets — Why AI Agent Credentials Are Out of Control — Help Net Securitys täckning med AI-specifika nedbrytningar
- Claude Code Can Consume, Transmit, and Compromise Your .env Files — Martin Paul Eves genomgång av hur CLAUDE.md-förbud misslyckas
- Claude Code Automatically Loads .env Secrets, Without Telling You — Knostics tekniska analys av automatisk inläsning av hemligheter
- From .env to Leakage: Mishandling of Secrets by Coding Agents — Knostics bredare analys över Claude och Cursor
- @zodchiii på X — Det virala inlägget som ledde till den här texten (380 000 visningar, 2 700 bokmärken)