AI 7 min lezen 9 november 2026 Door Chris van der Scheer

Lekken je API-sleutels via je AI-tool? Zo check je het en zo voorkom je het

Via instellingenbestanden van Claude Code belandden duizenden sleutels op GitHub. Zo bewaar je ze veilig en check je of er al iets uitlekte.

Steeds meer ondernemers laten een AI-tool een script of koppeling schrijven. Een export uit je boekhoudpakket, een webhook naar je CRM, een klein script dat je webshop met je mailinglijst praat. Dat werkt vaak verrassend goed. Maar zo'n script heeft bijna altijd een wachtwoord of API-sleutel nodig, en die belandt makkelijker dan je denkt op een plek waar hij niet hoort.

Op 9 november 2026 schreef Ars Technica over onderzoek van beveiligingsbedrijf Apiiro: in openbare GitHub-projecten vonden de onderzoekers duizenden geheimen, zoals databasewachtwoorden, API-tokens en root-inloggegevens. Ze zaten in instellingenbestanden van Claude Code, de programmeeragent van Anthropic. In dit stuk lees je wat er misgaat, waar je sleutels wel en niet bewaart, en hoe je nagaat of er bij jou al iets op straat ligt.

Wat er misgaat

Claude Code vraagt toestemming voordat het een commando op je computer uitvoert. Kies je dan "Yes, and don't ask again", dan bewaart Claude Code die keuze in het bestand .claude/settings.local.json in je project. Soms staat daar een algemeen patroon in, maar volgens Ars Technica vaak ook het hele commando, zoals je het goedkeurde. Zat daar een wachtwoord of sleutel in, bijvoorbeeld in een databaseverbinding, dan staat die nu letterlijk in dat bestand.

Op je eigen computer is dat nog geen ramp. Anthropic schrijft in de documentatie dat Claude Code dit bestand de eerste keer dat het hem aanmaakt in je globale git-uitsluitingen zet, zodat het niet mee gaat in je commits. Maak je het bestand zelf met de hand aan, dan moet je het volgens diezelfde documentatie zelf in .gitignore zetten.

Daar zit ook het gat. Die uitsluiting staat op jouw computer, niet in het project zelf. Kloon je het project op een andere computer, of wordt een map pas later een Git-project, dan kan het bestand alsnog mee naar GitHub. Volgens Apiiro commit Claude Code de wijzigingen in dat bestand in veel gevallen zelf, zonder dat je erom vraagt.

Hoe groot is het?

Apiiro vond meer dan 100.000 gevallen waarin dit lokale instellingenbestand in een openbaar GitHub-project stond. In ongeveer 1.100 gevallen, van 63 organisaties, zaten echte geheimen, zoals API-tokens, databasewachtwoorden of privésleutels. Van die ongeveer 1.100 geheimen werden er 215 niet herkend door gitleaks en TruffleHog, twee veelgebruikte scanners die juist bedoeld zijn om zulke geheimen te vinden.

Het probleem was niet nieuw. Volgens Ars Technica stond het al in augustus 2025 in een bugmelding voor Claude Code. Boris Cherny van het Claude Code-team schreef op Hacker News dat ze kijken wat ze kunnen doen om dit te voorkomen.

Gebruik je Cursor of ChatGPT?

Het onderzoek gaat over Claude Code. Maar het patroon is breder: elke tool die commando's of instellingen voor je bewaart, kan een sleutel opslaan op een plek die je niet ziet. Plak je een sleutel in een chat zodat de AI hem in je code zet, dan staat hij ook in die code. De vragen hieronder gelden dus voor elke AI-tool waarmee je zelf bouwt.

Waar je wachtwoorden en API-sleutels niet bewaart

Niet in de code zelf. GitHub raadt in zijn documentatie aan om geheimen niet in code te zetten.
Niet in een commando dat je permanent goedkeurt. Wat je met "niet meer vragen" goedkeurt, kan letterlijk in een instellingenbestand terechtkomen.
Niet in een bestand dat Git meeneemt. Ook niet "even" voor een test.
Niet in een Excel-lijst of gedeeld document. Daarover schreven we eerder waarom je opdrachtgever straks naar je wachtwoorden in Excel vraagt.

Waar bewaar je ze dan wel?

In omgevingsvariabelen. Je script leest de sleutel bij het starten, de sleutel zelf staat niet in de code. GitHub noemt dit als eerste alternatief.
In een secrets-manager of wachtwoordkluis. GitHub noemt diensten als Azure Key Vault, AWS Secrets Manager en HashiCorp Vault. Voor een klein bedrijf is een zakelijke wachtwoordmanager vaak het begin.
Met zo min mogelijk rechten. Maak per koppeling een eigen sleutel, alleen met de rechten die het script echt nodig heeft. Lekt hij, dan is de schade kleiner en trek je alleen die ene in.

Vijf instellingen die je vandaag kunt nalopen

Zet .claude/settings.local.json in de .gitignore van elk project, niet alleen op je eigen computer. Commit die .gitignore ook, zodat het op elke computer geldt.
Geef geen "niet meer vragen" voor commando's waar een wachtwoord of sleutel in staat.
Gebruik niet blind git add .. GitHub raadt aan bestanden los toe te voegen en met git diff --cached te kijken wat je precies commit.
Zet push protection aan op GitHub. Dat houdt een push tegen als er een herkenbare sleutel in staat.
Zet je repository op privé als hij niet openbaar hoeft te zijn.

Zo check je of er al iets uitgelekt is

Zoek het bestand. Kijk in je projecten of .claude/settings.local.json in Git zit. Kijk niet alleen naar de huidige versie maar ook naar de geschiedenis: een verwijderd bestand blijft in oude commits staan.
Kijk op het tabblad Security van je repository. Bij openbare repositories draait GitHub secret scanning automatisch en gratis, over de hele Git-geschiedenis van alle branches. Een melding staat bij het onderdeel secret scanning.
Draai zelf een scanner. Tools als gitleaks helpen, maar verwacht er geen garantie van. In het onderzoek van Apiiro bleven 215 van de ongeveer 1.100 geheimen onder de radar van gitleaks en TruffleHog. Lees het bestand daarom ook zelf even door.
Denk aan forks. Heeft iemand je project gekopieerd (een fork), dan kan de sleutel daar blijven staan, ook als jij hem verwijdert.

Gevonden? Dit doe je direct

Trek de sleutel in of vervang hem. Dat is volgens GitHub altijd de eerste stap. Een ingetrokken sleutel werkt niet meer, dus dan is het grootste risico weg. Behandel elke sleutel die openbaar heeft gestaan als gelekt, ook als je het bestand al hebt weggehaald.
Zet de nieuwe sleutel op een veilige plek. In een omgevingsvariabele of kluis, niet terug in hetzelfde bestand.
Bekijk de logs. Kijk bij de dienst waar de sleutel bij hoort of er gebruik is dat je niet herkent: inlogpogingen, API-aanroepen, kosten die je niet verwacht. Doe dat ook bij je database en server.
Ruim pas daarna de geschiedenis op. Je kunt een bestand uit je Git-geschiedenis halen met een tool als git-filter-repo, maar GitHub waarschuwt dat dat veel werk is en vaak niet nodig als de sleutel al is ingetrokken.
Denk aan persoonsgegevens. Gaf de sleutel toegang tot klant- of personeelsgegevens, ga dan na of het een datalek is dat je moet melden.

Veelgestelde vragen

Is mijn sleutel veilig als mijn repository privé is?

Veiliger, want vreemden kunnen er niet bij. Maar iedereen met toegang tot de repository kan de sleutel zien, en bij een klon op een andere computer reist hij mee. Een sleutel hoort daarom ook in een privéproject niet in de code.

Moet ik stoppen met Claude Code of een andere AI-tool?

Nee. Het gaat om hoe je met sleutels omgaat. Zet het instellingenbestand in je .gitignore, keur geen commando's met sleutels permanent goed en houd sleutels buiten je code. Dan kun je gewoon door met bouwen.

Is verwijderen van het bestand genoeg?

Nee. Het bestand blijft in de Git-geschiedenis en in eventuele forks staan. Trek de sleutel daarom altijd eerst in.

Tot slot: even meekijken?

Bouw je zelf koppelingen met AI en wil je weten of dat handig en veilig in elkaar zit? Plan dan een gratis AI-check van 30 minuten met Chris. Dat is een online gesprek waarin we bespreken welk werk elke week terugkomt, welke tools je al gebruikt en waar je gegevens staan. Je krijgt daarna een kort verslag met de 1 tot 3 kansen die het meeste opleveren, en een eerlijke inschatting: zelf doen, met ons, of nog niet. Je zit nergens aan vast.

Wil je eerst vastleggen wat je medewerkers wel en niet met AI-tools doen? Lees dan ook wat er in een AI-beleid voor het mkb hoort.

Bronnen

Alle artikelen