BlogUtgivelserHendelserDokumentasjonNedlastingerStatusLooking GlassKontakt salg
Security Blog

AI-kodeassistenten din leste nettopp lommeboken din

#149

October 2, 2026 · By Marketing team

← All posts

AI-kodeverktøy leser .env-filer før du rekker å skrive noe. API-nøklene dine — hver og én et kredittkort uten forbruksgrense — havner i andres kontekstvindu før du skriver den første prompten. Problemet er ikke AI-en. Problemet er at hemmeligheter er filer.

Åpne AI-kodeassistenten din. Før du rekker å taste en eneste bokstav, har den allerede lest prosjektmappen din. .env-filen din. API-nøklene dine. Databaspassordet ditt. Stripe-nøkkelen din.

Du ba den ikke om det. Du godkjente det ikke. Det er en funksjon, ikke en feil — verktøyet trenger prosjektkontekst for å være nyttig. Så det leser alt en utvikler kan lese.

Og en utvikler kan lese alt.

Greentext-versjonen

Et innlegg gikk sin seiersgang denne uken, skrevet som en utviklers indre monolog:

> Åpne Claude Code. .env-filen din blir lest før du skriver noe. API-nøklene dine er nå i chatten. Du legger til "ikke les .env" i CLAUDE.md. Fungerer ikke.

380 000 personer så det innlegget. 2 700 bokmerket det. Ikke fordi det var nyheter — men fordi det var et speil.

Hver utvikler som leste det, tenkte det samme: sånn er oppsettet mitt.

Instruksjoner virker ikke

Det første folk prøvde var å skrive regler. "Ikke les .env-filer." I CLAUDE.md, i AGENTS.md, i systemprompter. Direkte, eksplisitte forbud.

Verktøyet leste filene likevel.

Det gir mening når du tenker over det. Filen leses som en del av oppbyggingen av prosjektkontekst — før instruksjonene i det hele tatt behandles. Å be modellen om å ikke lese en fil den allerede har lest, er som å be noen glemme det de nettopp så. Informasjonen ligger i kontekstvinduet. Den er overført. Instruksjonen kommer etter at skaden er skjedd.

Én forsker fant at selv nekt-regler på filnivå kunne omgås via egne skript eller rørkjeder. En annen oppdaget høyere proxy-fakturaer fordi HTTP_PROXY-opplysningene ble lastet inn og brukt automatisk.

Pengene i .env-filen din

Folk omtaler dette som et personvernproblem. Det er et økonomisk et.

Åpne en typisk .env-fil i et produksjonsprosjekt:

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økkelen er et kredittkort uten forbruksgrense og uten PIN-kode. Noen med den strengen kan kjøre API-kall for 40 000 dollar over natten. Stripe-nøkkelen kan utstede refusjoner, opprette belastninger, få tilgang til kundenes betalingsdata. AWS-opplysningene — avhengig av IAM-policyen, som nesten sikkert er for bred — kan starte GPU-instanser, få tilgang til S3-bøtter eller slette infrastruktur.

Dette er ikke en liste over passord. Det er en liste over lommebøker, hver med ulik saldo og uten lås.

29 millioner lommebøker fortauet

GitGuardians siste rapport talte 28,6 millioner eksponerte hemmeligheter i offentlige GitHub-commits i 2025. En økning på 34 % fra året før, og den største årlige økningen de noensinne har målt.

De AI-spesifikke tallene er verre. 1,2 millioner hemmeligheter for AI-tjenester eksponert — en oppgang på 81 % år over år. Commits med AI-kodeverktøy som medforfatter lekket hemmeligheter med omtrent dobbel så høy frekvens som grunnlinjen. Og 24 000 unike hemmeligheter ble funnet i MCP-konfigurasjonsfiler — rørledningen som kobler AI-agenter til eksterne tjenester.

Tolv av de femten raskest voksende typene lekkede hemmeligheter var AI-tjenester. Ikke databaser. Ikke skyleverandører. AI-tjenester.

Verktøyene vi bruker for å skrive kode raskere lekker nøklene til systemene den koden kobler seg til.

Det egentlige problemet

Utvikleren som postet den greentext-tråden avsluttet med en praktisk fiks — en settings.json-konfigurasjon som blokkerer fillesing. Det fungerer. Inntil videre, for det verktøyet.

Men det egentlige problemet er ikke Claude Code eller Cursor eller Copilot. Det egentlige problemet er at hemmeligheter er filer.

En .env-fil er et klartekstdokument som ligger på disken, lesbar av alle prosesser som kjører som deg. Før AI-kodeverktøy var prosessene som leste prosjektet ditt git, npm, node, editoren din. Du stolte på dem uten videre. Du tenkte ikke på at hemmelighetene dine var én cat-kommando unna eksponering.

AI-kodeverktøy gjorde bare det implisitte eksplisitt. De leser prosjektet ditt på nøyaktig samme måte som alle andre verktøy — det bare så skjer at de sender konteksten et sted du kan se den.

CI-pipelineen din leser .env-filer den også. Testkjøreren din gjør det. Linteren din gjør det. Docker-bygget ditt gjør det. Ingen av dem ba om tillatelse heller. Du la bare ikke merke til det, fordi de ikke viste deg en chat-transkripsjon av hva de fant.

Mønsteret under

70 % av hemmelighetene som ble lekket i 2022 er fortsatt aktive i dag. Ikke rotert. Ikke tilbakekalt. Fortsatt virksomme, fortsatt gir tilgang, tre år senere.

Dette er det virkelige tallet. Ikke 29 millioner lekkasjer — 70 % som aldri ble fikset. For å rotere en nøkkel må du finne hvert system som bruker den, oppdatere hver distribusjon, teste hver integrasjon. Nøkkelen ble opprettet én gang, limt inn i en .env-fil, og aldri tenkt på igjen. Kostnaden ved å lekke den er øyeblikkelig. Kostnaden ved å fikse lekkasjen er ubegrenset.

Så de fleste organisasjoner fikser det ikke. De kan ikke. De vet ikke hvilke nøkler som er hvor, hvilke som fortsatt er aktive, hvilke som er kopiert inn i andre .env-filer på andre maskiner av andre utviklere som trengte å få en funksjon til å virke en fredagsettermiddag.

Hva dette faktisk betyr

Hver .env-fil er et veddemål. Et veddemål på at ingen prosess noen gang vil lese den som ikke burde. Et veddemål på at ingen verktøy noen gang vil sende den et uventet sted. Et veddemål på at ingen utvikler noen gang vil committe den ved et uhell.

29 millioner ganger i fjor tapte noen det veddemålet. Bare på offentlige GitHub. De private repoene — der GitGuardian fant hemmeligheter i 35 % av repositoryene — er ikke engang telt med.

Fiksen er ikke en settings.json-regel. Fiksen er ikke en .gitignore-oppføring. Fiksen er ikke å skrive "IKKE LES .ENV" med store bokstaver i instruksjonsfilen din.

Fiksen er at hemmeligheten ikke burde være der i utgangspunktet. Ikke i en fil. Ikke i en miljøvariabel lastet fra en fil. Ikke i noen form som en prosess med tillatelsene dine kan lese ved å gjøre det prosesser gjør: lese filer i prosjektmappen din.

Hvis hemmeligheten ligger på disken, vil den bli lest. Det eneste spørsmålet er når, og av hva.

---

Kilder