API-sleutels en geheimen beheren

Een API-sleutel is een creditcard zonder pincode. Met agents die je bestanden lezen en code schrijven, liggen er meer sleutels rond dan ooit.

Na deze les heb je: je sleutels op een veilige plek, per project een eigen sleutel met limiet, push protection aan, en een plan voor de eerste 15 minuten na een lek.

Hoe sleutels lekken

GitGuardian telde in 2025 zo’n 29 miljoen nieuwe geheimen in publieke GitHub-commits (+34%). Sleutels van AI-diensten stegen met 81%, en in configbestanden van MCP-servers vonden ze er 24.008. Van de geldige geheimen uit 2022 werkte 64% vier jaar later nog.

Waar	Hoe het misgaat
Git	Sleutel in de code of een gecommit .env-bestand. Verwijderen in een volgende commit helpt niet: hij staat in de geschiedenis.
Frontend	Sleutel in JavaScript of een app-bundle. Iedereen kan hem uitlezen.
Agent-bestanden en -logs	MCP-configs, sessielogs en .env die je coding-agent leest. Infostealers zoeken daar gericht naar.
Bij derden opgeslagen	Bij de OpenCode Console-hack (okt 2026) werden opgeslagen AI-sleutels van gebruikers misbruikt; enkele gebruikers meldden schades van ruim $1.000.
Screenshots en chats	Een sleutel in beeld bij een demo, of geplakt in een chat met een AI-assistent of collega. Vapi noemt logs, screenshots en agent-chats letterlijk als plekken waar een sleutel nooit mag staan.

Wat het kost: een Mexicaanse startup met normaal $180 aan Gemini-kosten per maand kreeg in februari 2026 een rekening van $82.314 in ongeveer 48 uur, na een gestolen sleutel. Google wees naar het shared responsibility-model.

Waar sleutels wél horen

Situatie	Plek	Zo werkt het
Je eigen laptop	Password manager met CLI	1Password CLI of Bitwarden Secrets Manager zet de sleutel pas bij het starten in een omgevingsvariabele. In je project staat alleen een verwijzing.
Server of VPS	Omgevingsvariabelen uit een bestand buiten je repo, of sops + age	sops versleutelt je configbestand, zodat het veilig in git kan.
Hosting, CI, serverless	Secret manager van het platform	GitHub Actions secrets, Vercel/Netlify environment variables, cloud secret managers.

Met 1Password ziet je .env er zo uit (geen geheim, alleen een verwijzing):

OPENAI_API_KEY="op://Werk/OpenAI/credential"

En start je je app zo:

op run --env-file=.env -- npm start

Bij Bitwarden Secrets Manager is dat bws run -- npm start (met je access token in BWS_ACCESS_TOKEN).

Zo zet je het goed neer

1. Eén sleutel per project, klant of agent. Geef elke sleutel een naam (“klant-bakkerij-chatbot”) en alleen de rechten die nodig zijn: alleen-lezen waar het kan, één repo bij een GitHub-token, een vervaldatum. Lekt er één, dan trek je alleen die in. Werk je voor klanten? Laat de sleutel op het account van de klant staan.

2. Uitgavenlimiet per project of sleutel. Elke grote aanbieder heeft er nu een, maar ze werken anders: OpenAI per organisatie en per project (alleen een harde stop als je Enforce a hard limit aanzet), Anthropic per organisatie en per workspace, Google per project in AI Studio (met tot ongeveer 10 minuten vertraging) en OpenRouter per sleutel. Zet hem laag en zet automatisch bijladen uit. Stand november 2026; check de officiële pagina’s: OpenAI, Anthropic, Google Gemini, OpenRouter.

3. .env in .gitignore, vóór je eerste commit.

   echo ".env" >> .gitignore

4. Push protection aan. Voor je persoonlijke account staat push protection for yourself bij GitHub standaard aan voor publieke repo’s; check het onder Settings → Code security, kopje “User”. Per repo: Settings → Advanced Security → Secret Protection → Push protection → Enable. Gratis voor publieke repo’s; voor privé-repo’s heb je het betaalde GitHub Secret Protection nodig.

5. Scan wat er al ligt. Met gitleaks doorzoek je je hele git-geschiedenis:

   gitleaks git -v

   Krijg je unknown command "git"? Dan heb je een versie van vóór 8.19 (bijvoorbeeld via apt op Ubuntu 24.04); gebruik dan gitleaks detect -v.

   Gevonden sleutels zijn verbrand, ook als ze “maar even” in een oude commit stonden. Trek ze in.

Je coding-agent leest je .env zonder te vragen

In Claude Code draaien alleen-lezen commando’s als cat in elke modus zonder goedkeuringsprompt, dus ook cat .env. Wat de agent leest, staat daarna in je sessie en logs. Werk met verwijzingen (1Password, Bitwarden) zodat er niets te lezen valt, of zet een deny-regel onder permissions in .claude/settings.json: “deny”: [“Read(./.env)”, “Read(./.env.*)”].

Een 'openbare' Google-sleutel kan ineens Gemini openen

Google zei jarenlang dat sleutels voor bijvoorbeeld Maps geen geheim zijn. Truffle Security vond in februari 2026 2.863 van zulke publieke sleutels die ook Gemini konden gebruiken, omdat de Gemini API in hetzelfde project aanstond. Zet Gemini in een eigen project en beperk elke Google-sleutel tot de API’s die hij nodig heeft (API restrictions).

De eerste 15 minuten na een lek

1. Intrekken en vervangen (minuut 0-5). In het dashboard van de aanbieder: oude sleutel intrekken, nieuwe maken, nieuwe in je password manager en je apps zetten. Eerst dit, pas daarna opruimen. Bots vinden publieke sleutels binnen minuten.

2. Rem op de kosten (minuut 5). Limiet omlaag, automatisch bijladen uit. Bij spraakdiensten: uitgaand bellen tijdelijk uit.

3. Logs en kosten checken (minuut 5-10). Usage per sleutel of project: onbekende modellen, regio’s of tijdstippen? Bij cloud-sleutels ook nieuwe gebruikers of sleutels in IAM, want aanvallers maken er vaak een reserve bij. Kwam het lek van malware op je computer? Dan zijn alle sleutels en sessies op die machine verdacht.

4. Git-geschiedenis opschonen (minuut 10). Haal de sleutel uit de code. Stond hij in een gepushte commit, volg dan GitHub’s handleiding Removing sensitive data (met git filter-repo). Clones en forks houden hem toch, dus dit is opruimen, geen oplossing.

5. Melden (minuut 10-15). Vraag support van de aanbieder om de onterechte kosten kwijt te schelden; OpenAI betaalde getroffen OpenCode-gebruikers terug, Google hield in de $82k-zaak vast aan shared responsibility. Werk je voor een klant: meld het direct. Kon iemand bij persoonsgegevens? Meld dat dan binnen 72 uur bij de Autoriteit Persoonsgegevens, tenzij het waarschijnlijk geen risico voor mensen oplevert (zo werkt de meldplicht).

Security

• Wat kan misgaan: een sleutel in git, je frontend of een chat wordt binnen minuten gevonden en op jouw rekening gebruikt.
• Wat je doet: sleutels alleen in een password manager of secret manager, één sleutel per project met een uitgavenlimiet, en push protection aan.
• Sleutels en agents: geef een agent alleen de sleutel die hij voor deze taak nodig heeft, nooit je hoofdsleutel (kwaadaardige skills en MCP).

Checklist

0/7

• Mijn sleutels staan in een password manager of secret manager, niet in code
• Elk project of elke klant heeft een eigen sleutel met minimale rechten
• Elke sleutel of elk project heeft een lage uitgavenlimiet, zonder automatisch bijladen
• .env staat in .gitignore
• Push protection staat aan
• Ik heb mijn git-geschiedenis gescand op oude sleutels
• Ik weet wat ik in de eerste 15 minuten na een lek doe

Je voortgang wordt alleen in deze browser bewaard.

Test jezelf

1. 1Je merkt dat je een API-sleutel naar een publieke repo hebt gepusht. Wat doe je eerst?

   De commit verwijderen en force-pushenDe sleutel intrekken en een nieuwe makenAfwachten of er iets gebeurt

2. 2Waarom één sleutel per project of klant?

   Omdat aanbieders dat verplichtenOmdat je bij een lek dan alleen die ene intrekt, met een eigen limietOmdat het goedkoper is per token

3. 3Wat is de veiligste plek voor een API-sleutel op je laptop?

   Een .env-bestand in je projectEen notitie in je chat met de AI-assistentEen password manager die de sleutel pas bij het starten doorgeeft

Volgende les: je server hardenen. Host je niets zelf? Ga door naar de security-check voor je app.