BlogReleasesIssuesDocsDownloadsStatusLooking GlassKontakt salg
Security Blog

Din AI-kodeassistent har lige læst din pengepung

#116

October 2, 2026 · By Marketing team

← All posts

AI-kodeværktøjer læser .env-filer, før du skriver noget. Dine API-nøgler — hver især et kreditkreditkort uden loft — ligger i en andens kontekstvindue, før du skriver din første prompt. Problemet er ikke AI'en. Problemet er, at hemmeligheder er filer.

Åbn din AI-kodeassistent. Før du har skrevet et eneste tegn, har den allerede læst din projektmappe. Din .env-fil. Dine API-nøgler. Din databaseadgangskode. Din Stripe secret key.

Du bad den ikke om det. Du godkendte det ikke. Det er en funktion, ikke en fejl — værktøjet har brug for projektets kontekst for at være nyttigt. Så den læser alt det, en udvikler kan læse.

Og en udvikler kan læse alt.

Greentext-versionen

Et opslag cirkulerede i denne uge, skrevet som en udviklers indre monolog:

> Åbn Claude Code. Din .env bliver læst, før du skriver noget. Dine API-nøgler er nu i chatten. Du tilføjer "don't read .env" til CLAUDE.md. Virker ikke.

380.000 mennesker så det opslag. 2.700 bogmærkede det. Ikke fordi det var en nyhed — men fordi det var et spejl.

Alle udviklere, der læste det, tænkte det samme: det er mit setup.

Instruktioner virker ikke

Det første, folk prøvede, var at skrive regler. "Læs ikke .env-filer." I CLAUDE.md, i AGENTS.md, i systemprompts. Direkte, eksplicitte forbud.

Værktøjet læste filerne alligevel.

Det giver mening, når man tænker over det. Filen læses som del af opbygningen af projektets kontekst — før instruktioner overhovedet behandles. At fortælle modellen, at den ikke må læse en fil, den allerede har læst, er som at fortælle nogen, at de skal glemme det, de lige har set. Oplysningerne ligger i kontekstvinduet. De er blevet overført. Instruktionen ankommer efter skaden.

Én forsker fandt, at selv deny-regler på filniveau kunne omgås via brugerdefinerede scripts eller rør-kæder. En anden opdagede forhøjede proxy-regninger, fordi deres HTTP_PROXY-legitimationsoplysninger blev indlæst og brugt automatisk.

Pengene i din .env

Folk indrammer dette som et privatlivsproblem. Det er et økonomisk problem.

Åbn en typisk .env-fil i et produktionssystem:

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-nøgle er et kreditkort uden forbrugsloft og uden PIN-kode. En person med den streng kan køre API-kald for 40.000 dollars natten over. Stripe-nøglen kan udstede refunderinger, oprette betalinger, få adgang til kundernes betalingsdata. AWS-legitimationsoplysningerne kan — afhængigt af IAM-policyn, som med stor sandsynlighed er for bred — starte GPU-instanser, få adgang til S3-buckets eller slette infrastruktur.

Det er ikke en liste over adgangskoder. Det er en liste over pengepunge, hver med en forskellig saldo og uden lås.

29 millioner pengepunge på fortovet

GitGuardians seneste rapport talte 28,6 millioner eksponerede hemmeligheder i offentlige GitHub-commits i 2025. Et spring på 34% i forhold til året før, og den største årlige stigning, de nogensinde har målt.

De AI-specifikke tal er værre. 1,2 millioner AI-tjeneste-hemmeligheder eksponeret — en stigning på 81% år over år. Commits, der var co-authoreret af AI-kodeværktøjer, lækkede hemmeligheder med cirka dobbelt så høj frekvens som baseline. Og 24.000 unikke hemmeligheder blev fundet i MCP-konfigurationsfiler — det rørarbejde, der forbinder AI-agenter med eksterne tjenester.

Tolv af de femten hurtigst voksende typer af lækkede hemmeligheder var AI-tjenester. Ikke databaser. Ikke cloud-leverandører. AI-tjenester.

De værktøjer, vi bruger til at skrive kode hurtigere, lækker nøglerne til de systemer, koden forbinder sig til.

Det egentlige problem

Den udvikler, der postede den greentext-tråd, sluttede med en praktisk løsning — en settings.json-konfiguration, der blokerer fillæsning. Det virker. Indtil videre, for det værktøj.

Men det egentlige problem er ikke Claude Code eller Cursor eller Copilot. Det egentlige problem er, at hemmeligheder er filer.

En .env-fil er et dokument i klartekst, der ligger på disken, læsbart af enhver proces, der kører som din bruger. Før AI-kodeværktøjerne var de processer, der læste dit projekt, git, npm, node, din editor. Du stolede på dem implicit. Du tænkte ikke over, at dine hemmeligheder var én cat-kommando væk fra eksponering.

AI-kodeværktøjer har bare gjort det implicitte eksplicit. De læser dit projekt på samme måde som alle andre værktøjer — de sender bare konteksten et sted hen, hvor du kan se den.

Din CI-pipeline læser også .env-filer. Din testrunner gør. Din linter gør. Dit Docker-build gør. Ingen af dem bad om lov heller. Du lagde bare ikke mærke til det, for de viste dig ikke en chattransskription af det, de fandt.

Mønsteret nedenunder

70% af de hemmeligheder, der blev lækket i 2022, er stadig aktive i dag. Ikke roteret. Ikke tilbagekaldt. Stadig virksomme, stadig giver adgang, tre år senere.

Det er det reelle tal. Ikke 29 millioner læk — 70% er aldrig blevet rettet. For at rotere en nøgle skal man finde hvert system, der bruger den, opdatere hver deployment, teste hver integration. Nøglen blev oprettet én gang, sat ind i en .env-fil og aldrig tænkt på igen. Prisen for at lække den er øjeblikkelig. Prisen for at udbedre lækagen er ubegrænset.

Så de fleste organisationer retter det ikke. De kan ikke. De ved ikke, hvilke nøgler der er hvor, hvilke der stadig er aktive, hvilke der er blevet kopieret ind i andre .env-filer på andre maskiner af andre udviklere, der skulle have en funktion til at virke en fredag eftermiddag.

Hvad det i virkeligheden betyder

Hver .env-fil er et væddemål. Et væddemål om, at ingen proces nogensinde læser den, som ikke burde. Et væddemål om, at intet værktøj nogensinde sender den et uventet sted hen. Et væddemål om, at ingen udvikler nogenskelig committer den ved et uheld.

29 millioner gange sidste år tabte nogen det væddemål. Alene på offentlige GitHub. De private repos — hvor GitGuardian fandt hemmeligheder i 35% af repositories — tæller ikke engang med.

Løsningen er ikke en settings.json-regel. Løsningen er ikke en .gitignore-linje. Løsningen er ikke at skrive "DO NOT READ .ENV" med versaler i din instruktionsfil.

Løsningen er, at hemmeligheden slet ikke skulle have været der. Ikke i en fil. Ikke i en miljøvariabel, der indlæses fra en fil. Ikke i nogen form, som en proces med dine rettigheder kan læse ved at gøre det, processer gør: læse filer i din projektmappe.

Hvis hemmeligheden ligger på disken, bliver den læst. Det eneste spørgsmål er hvornår, og af hvad.

---

Kilder