BlogReleasesProblemenDocsDownloadsStatusLooking GlassNeem contact op
Security Blog

Je AI-codeassistent heeft zojuist je portemonnee gelezen

#120

October 2, 2026 · By Marketing team

← All posts

AI-codeertools lezen .env-bestanden voordat je ook maar iets typt. Je API-sleutels — elk een creditcard zonder bestedingslimiet — zitten in iemands contextvenster voordat je je eerste prompt schrijft. Het probleem is niet de AI. Het probleem is dat geheimen bestanden zijn.

Open je AI-codeassistent. Voordat je één tekentje typt, heeft hij je projectmap al gelezen. Je .env-bestand. Je API-sleutels. Je database-wachtwoord. Je Stripe secret key.

Je hebt het er niet om gevraagd. Je hebt het niet goedgekeurd. Het is een feature, geen bug — de tool heeft projectcontext nodig om bruikbaar te zijn. Dus leest hij alles wat een ontwikkelaar kan lezen.

En een ontwikkelaar kan alles lezen.

De greentext-versie

Deze week deed een bericht de ronde, geschreven als de innerlijke monoloog van een ontwikkelaar:

> Open Claude Code. Je .env wordt gelezen voordat je iets typt. Je API-sleutels zitten nu in de chat. Je voegt "lees geen .env" toe aan CLAUDE.md. Werkt niet.

380.000 mensen zagen dat bericht. 2.700 bewaarden het. Niet omdat het nieuws was — omdat het een spiegel was.

Elke ontwikkelaar die het las dacht hetzelfde: dat is mijn setup.

Instructies werken niet

Het eerste wat mensen probeerden was regels opschrijven. "Lees geen .env-bestanden." In CLAUDE.md, in AGENTS.md, in system prompts. Directe, expliciete verboden.

De tool las de bestanden toch.

Dat is logisch als je erover nadenkt. Het bestand wordt gelezen als onderdeel van het opbouwen van projectcontext — nog voordat instructies worden verwerkt. Een model vertellen een bestand niet te lezen dat het al heeft gelezen, is als iemand vertellen te vergeten wat hij net heeft gezien. De informatie zit in het contextvenster. Hij is al overgedragen. De instructie komt pas na de schade.

Een onderzoeker ontdekte dat zelfs deny-regels op bestandsniveau te omzeilen waren via aangepaste scripts of pipe-ketens. Een ander ontdekte verhoogde proxy-rekeningen omdat zijn HTTP_PROXY-credentials automatisch werden geladen en gebruikt.

Het geld in je .env

Mensen framen dit als een privacykwestie. Het is een financiële kwestie.

Open een typisch .env-bestand in een productieproject:

OPENAI_API_KEY=sk-...
STRIPE_SECRET_KEY=sk_live_...
AWS_ACCESS_KEY_ID=AKIA...
AWS_SECRET_ACCESS_KEY=...
DATABASE_URL=postgresql://user:pass@...

Die OpenAI-sleutel is een creditcard zonder bestedingslimiet en zonder pincode. Iemand met die string kan $40.000 aan API-calls draaien in één nacht. De Stripe-sleutel kan terugbetalingen uitvoeren, charges aanmaken, klantbetalingsgegevens inzien. De AWS-credentials — afhankelijk van het IAM-beleid, dat bijna zeker te breed is — kunnen GPU-instances opstarten, S3-buckets benaderen of infrastructuur verwijderen.

Dit is geen lijst wachtwoorden. Het is een lijst portemonnees, elk met een ander saldo en zonder slot.

29 miljoen portemonnees op de stoep

GitGuardians laatste rapport telde 28,6 miljoen blootgestelde geheimen in publieke GitHub-commits in 2025. Een stijging van 34% ten opzichte van het jaar ervoor, en de grootste jaarlijkse stijging die ze ooit hebben gemeten.

De AI-specifieke cijfers zijn erger. 1,2 miljoen AI-service-geheimen blootgesteld — een stijging van 81% jaar-op-jaar. Commits met AI-codeertools als co-auteur lekten geheimen met ongeveer het dubbele van de basisgraad. En 24.000 unieke geheimen werden gevonden in MCP-configuratiebestanden — de leidingen die AI-agents aan externe diensten koppelen.

Twaalf van de vijftien snelst groeiende types gelekte geheimen waren AI-services. Niet databases. Niet cloudproviders. AI-services.

De tools die we gebruiken om sneller code te schrijven, lekken de sleutels naar de systemen waarmee die code verbindt.

Het echte probleem

De ontwikkelaar die die greentext-thread plaatste eindigde met een praktische oplossing — een settings.json-config die bestandslezingen blokkeert. Dat werkt. Voor nu, voor die tool.

Maar het echte probleem is niet Claude Code of Cursor of Copilot. Het echte probleem is dat geheimen bestanden zijn.

Een .env-bestand is een platte-tekstdocument op schijf, leesbaar door elk proces dat draait als jouw gebruiker. Vóór AI-codeertools waren de processen die je project lazen git, npm, node, je editor. Je vertrouwde ze impliciet. Je dacht niet na over het feit dat je geheimen één cat-opdracht verwijderd waren van blootstelling.

AI-codeertools hebben het impliciete simpelweg expliciet gemaakt. Ze lezen je project op dezelfde manier als elke andere tool — ze sturen die context alleen toevallig ergens heen waar je hem kunt zien.

Je CI-pipeline leest ook .env-bestanden. Je testrunner ook. Je linter ook. Je Docker-build ook. Geen van hen vroeg ook toestemming. Je merkte het alleen niet, omdat ze je geen chattranscriptie lieten zien van wat ze hadden gevonden.

Het patroon eronder

70% van de geheimen die in 2022 zijn gelekt, zijn vandaag nog steeds actief. Niet geroteerd. Niet ingetrokken. Werken nog steeds, verlenen nog steeds toegang, drie jaar later.

Dit is het echte getal. Niet 29 miljoen lekken — 70% nooit gerepareerd. Want een sleutel roteren betekent elk systeem vinden dat hem gebruikt, elke deployment bijwerken, elke integratie testen. De sleutel is één keer aangemaakt, in een .env-bestand geplakt, en er nooit meer over nagedacht. De kosten van het lekken zijn direct. De kosten van het repareren van het lek zijn onbegrensd.

Dus de meeste organisaties repareren het niet. Ze kunnen het niet. Ze weten niet welke sleutels waar staan, welke nog actief zijn, welke zijn gekopieerd naar andere .env-bestanden op andere machines door andere ontwikkelaars die op een vrijdagmiddag een feature aan de praat moesten krijgen.

Wat dit daadwerkelijk betekent

Elk .env-bestand is een gok. Een gok dat geen enkel proces het ooit zal lezen dat dat niet zou moeten doen. Een gok dat geen enkele tool het ooit onverwachts ergens heen stuurt. Een gok dat geen enkele ontwikkelaar het ooit per ongeluk commit.

29 miljoen keer vorig jaar verloor iemand die gok. Alleen al op publieke GitHub. De private repos — waar GitGuardian geheimen vond in 35% van de repositories — tellen niet eens mee.

De oplossing is geen settings.json-regel. De oplossing is geen .gitignore-entry. De oplossing is niet om "LEES GEEN .ENV" in hoofdletters in je instructiebestand te schrijven.

De oplossing is dat het geheim er in de eerste plaats niet zou moeten zijn. Niet in een bestand. Niet in een environment variable die uit een bestand wordt geladen. Niet in enige vorm die een proces met jouw rechten kan lezen door te doen wat processen doen: bestanden in je projectmap lezen.

Als het geheim op schijf staat, wordt het gelezen. De enige vraag is wanneer, en door wat.

---

Bronnen