Een gelekte API key uit uw code verwijderen, zet die key niet uit. Een gelekte key blijft werken tot u hem bij de provider intrekt, en iedereen die hem heeft gekopieerd, kan hem tot dat moment gebruiken. Gelekte API keys in AI-producten vragen daarom om deze volgorde: eerst indammen, dan uitzoeken hoe de key naar buiten kwam.
Dit artikel behandelt welke gelekte keys ertoe doen, wat u in het eerste uur doet, de zes manieren waarop AI-producten keys lekken en de maatregelen die herhaling voorkomen.
TL;DR
Een gelekte API key is een geheime sleutel die mensen buiten uw team nu kunnen lezen, in browsercode, een repository, een log of een chat. Trek de key eerst in bij de provider: de key uit de code halen schakelt een kopie niet uit.
- Drie soorten keys moeten na een lek direct worden vervangen: geheime server-keys, keys van AI-modelproviders en admin-credentials voor database of cloud; publishable keys zijn bedoeld om openbaar te zijn.
- Een aanpak in zes stappen damt een gelekte key in: intrekken, bewijs veiligstellen, vervangen, verdere kosten beperken, de impact op persoonsgegevens beoordelen en kopieën verwijderen met een vastgelegde lijst van open punten.
- AI-producten lekken API keys op zes plekken: modelaanroepen vanuit de browser, prompts, de context van coding agents, repositorygeschiedenis, logs en gedeelde kanalen.
- Drie maatregelen voorkomen herhaling: keys alleen op uw eigen backend, secret scanning die merges met credentials blokkeert, en secrets rotation met één vaste eigenaar per key.
AI-credentials worden een steeds groter deel van het probleem. GitGuardian’s State of Secrets Sprawl 2026 telde in 2025 1.275.105 gelekte secrets van AI-diensten, 81% meer dan in 2024. Voor het bredere beeld van een AI-gebouwd product veilig live zetten, leest u onze gids over AI-coding in productie.
Welke gelekte API keys ertoe doen: publishable, geheim en model-keys
Niet elke zichtbare API key is een lek. Een API key werkt als een wachtwoord waarmee een programma een betaalde dienst of een database aanroept. Publishable keys zijn bedoeld om in browsercode te staan; geheime keys, keys van AI-modelproviders en admin-credentials horen nooit buiten uw server.
De API-keyrichtlijn van OpenAI raadt af om keys in browsers of mobiele apps te plaatsen, omdat iedereen ze daar kan uitlezen en verzoeken kan doen namens de accounthouder.
| Soort key | Voorbeeld | Bedoeld om openbaar te zijn? | Wat iemand met de key kan doen | Vervangen na blootstelling? |
|---|---|---|---|---|
| Publishable key | Key voor een betaalformulier; kaart-key beperkt tot uw domein | Ja | Alleen wat de provider met openbare keys toestaat | Alleen als domein- of gebruiksbeperkingen ontbreken |
| Geheime server-key | Geheime betaalsleutel; key voor het versturen van e-mail | Nee | Optreden als uw account: afschrijven, terugboeken, e-mail versturen | Ja, direct |
| Key van een AI-modelprovider | API key voor een groot taalmodel | Nee | Uw verbruiksbudget opmaken; bij sommige accounts opgeslagen bestanden lezen | Ja, direct |
| Admin-key voor een database | Service-role- of admin-key van een gehoste database | Nee | Alle data lezen en wijzigen, buiten de toegangsregels om | Ja, direct |
| Cloud-credential | Toegangssleutel voor hosting of bestandsopslag | Nee | Infrastructuur en opgeslagen bestanden aanmaken, wijzigen of verwijderen | Ja, direct |
Weet u niet welk type een key is, behandel hem dan als geheim en vervang hem. Om keys in uw eigen product te vinden, gebruikt u de paginabroncontrole uit ons artikel over vibe coding-beveiligingsrisico’s.
API key gelekt? Wat u in het eerste uur doet
Is een API key gelekt, trek de getroffen key dan bij de provider in voordat u iets anders doet. Openbare code wordt automatisch gescand, dus ga ervan uit dat de key al is gekopieerd. De zes stappen bestaan uit directe inperking en vervolgacties: stap 1 tot en met 3 horen in het eerste uur, stap 4 tot en met 6 begint u in dat uur maar kunnen langer duren. Elke stap eindigt met een controle die aangeeft dat hij klaar is.
Directe inperking (eerste uur)
- Trek de getroffen key in of schakel hem uit bij de provider. De regel uit uw code of de commit verwijderen stopt een gekopieerde key niet. Klaar als het dashboard van de provider de key als ingetrokken of verwijderd toont.
- Stel het bewijs veilig. Bewaar vóór u iets verwijdert de toegangslogs, tijdstempels en verbruiksgegevens die u nodig hebt om het incident te onderzoeken: wanneer en waar de key openlag en welke aanroepen ermee zijn gedaan. Klaar als kopieën van die gegevens staan op een plek waar het onderzoek ze kan gebruiken.
- Vervang de key en herstel de dienst. Maak een nieuwe key aan en bewaar die in de instellingen van uw hostingomgeving of in een secrets manager, nooit in de code. Klaar als de functie weer werkt met de nieuwe key.
Vervolgacties (nu starten, afronden zodra het bewijs er is)
- Beperk verdere kosten. Controleer of uw modelprovider afdwingbare uitgavenlimieten ondersteunt op het niveau van organisatie, project of key, en stel de beschikbare limieten in. De documentatie van OpenAI over spend limits biedt harde limieten per organisatie en per project, en vermeldt dat de handhaving niet direct is en dat het geregistreerde verbruik de ingestelde limiet licht kan overschrijden. Vertrouw niet alleen op factuurmeldingen; voeg waar nodig server-side quota, rate limits en limieten per gebruiker toe. Uitgavenlimieten beperken verdere financiële schade, maar vervangen het intrekken van de key niet. Klaar als de beschikbare limieten actief zijn en u het verbruik sinds de blootstelling kent.
- Beoordeel of persoonsgegevens zijn geraakt. Een gelekte API key is niet automatisch een datalek. Beoordeel volgens artikel 4, lid 12 van de AVG (GDPR) of de blootstelling heeft geleid tot een inbreuk op de beveiliging waarbij persoonsgegevens zijn betrokken, op basis van de rechten van de key, de beschikbare logs en eventueel bewijs van onbevoegde toegang of verstrekking. Stelt u een datalek vast, dan verplicht artikel 33 u in de regel om de Autoriteit Persoonsgegevens binnen 72 uur te informeren nadat u van het datalek op de hoogte bent geraakt; dat is niet per se het moment waarop u de blootliggende key voor het eerst zag. Melden is niet nodig als het datalek waarschijnlijk geen risico oplevert voor de rechten en vrijheden van mensen. Klaar als de beoordeling en de redenen voor het meldbesluit zijn vastgelegd, ook als melden niet nodig is.
- Verwijder kopieën en leg vast wat nog openstaat. Verwijder na het intrekken overbodige kopieën uit broncode, configuratiebestanden, tickets en gedeelde documenten. Bespreek de repositorygeschiedenis met een developer voordat u die herschrijft: de documentatie van GitHub waarschuwt dat forks, clones van andere gebruikers en gecachte commits de oude credential nog kunnen bevatten. Controleer de bewaar- en verwijderopties van elke externe dienst waar de key is gedeeld. Het incidentverslag vermeldt wat er openlag, waar kopieën zijn gevonden, wat is ingetrokken en welke plekken nog opvolging nodig hebben; het is het vervangingsbewijs waar onze production readiness checklist om vraagt, en het ondersteunt ISO/IEC 27001:2022 Annex A 5.17 over authenticatie-informatie. Klaar als een tweede persoon het verslag kan lezen en elk open punt ziet.
Kunt u niet vaststellen wat de blootliggende key kon bereiken, schaal het onderzoek dan op en behandel de rechten van de key als potentieel risico tot het tegendeel is aangetoond. Trek de getroffen key snel in, controleer verwante credentials en de accountactiviteit, en breid de rotatie alleen uit als het bewijs wijst op bredere blootstelling. Schakel geen ongerelateerde productiekeys uit zonder eerst de operationele impact te beoordelen.
Zes manieren waarop AI-producten API keys lekken
AI-producten lekken API keys in twee richtingen: tijdens het bouwen en tijdens het draaien. AI-codingtools en agents lezen, schrijven en committen secrets; AI-functies sturen keys van modelproviders naar de browser en zetten credentials in prompts.
| Lekroute | Hoe het gebeurt in een AI-product | Zo controleert u het (zonder code) |
|---|---|---|
| 1. Modelaanroepen vanuit browser of app | De AI-functie roept de modelprovider aan vanuit de browser of app, dus de key gaat mee met de pagina | Vraag: loopt elke modelaanroep via onze eigen server? |
| 2. Prompts en system prompts | Een credential staat in de instructies voor het model | Lees de system prompt na op alles wat op een wachtwoord lijkt |
| 3. Context van coding agents | Een coding agent leest lokale secret-bestanden of tool-instellingen en kopieert secrets naar code of commits | Vraag welke bestanden AI-codingtools mogen lezen |
| 4. Repositorygeschiedenis | Een verwijderde key staat nog in eerdere commits | Vraag wanneer de volledige geschiedenis voor het laatst op secrets is gescand |
| 5. Logs en foutmeldingen | Een foutmelding of buildlog toont de key | Vraag of logs op secrets worden gecontroleerd |
| 6. Gedeelde kanalen | Een key wordt in een chat, ticket, document of AI-chat geplakt | Vraag hoe keys aan nieuwe mensen worden overgedragen |
Code naar een privérepository verhuizen neemt het risico niet weg. Het GitGuardian-rapport van 2026 vond in 32,2% van de interne repositories minstens één hardcoded secret, tegenover 5,6% van de openbare.
Modelaanroepen vanuit de browser of app
Een key van een modelprovider in browser- of app-code is leesbaar voor elke gebruiker van het product. De oplossing is een backend als tussenstation (backend proxy): de browser roept uw server aan, en alleen uw server bewaart de key en roept de modelprovider aan. De API-keyrichtlijn van OpenAI geeft dezelfde instructie: stuur verzoeken via uw eigen backendserver.
Wij raden die backend proxy ook aan voor de eerste versie van een AI-functie: hij handhaaft ook limieten per gebruiker, en later toevoegen betekent elke modelaanroep aanpassen.
Keys in prompts, agent-context en tool-instellingen
Een system prompt is geen veilige plek voor een secret. In de OWASP Top 10 for LLM Applications 2025 staat bij LLM07, System Prompt Leakage, dat “sensitive data such as credentials, connection strings, etc. should not be contained within the system prompt language.” Credentials horen dus niet in de tekst van een system prompt.
AI-coding agents openen een tweede route: een agent die de projectmap kan lezen, kan ook het .env-bestand lezen, het lokale bestand met de keys, en de inhoud naar code of naar zijn eigen context kopiëren. GitGuardian vond 24.008 unieke secrets in openbare configuratiebestanden voor MCP, het Model Context Protocol dat AI-agents aan tools koppelt; 2.117 daarvan waren geldig. Sluit secret-bestanden uit van wat codingtools mogen lezen, en houd tool-instellingen buiten de repository.
Weet u niet waar uw product zijn keys bewaart?
De meeste van de zes lekroutes zitten op plekken die u als founder niet ziet: buildconfiguratie, repositorygeschiedenis, de manier waarop de AI-functie het model aanroept. Een AI-built product review beoordeelt engineering en beveiliging samen en legt de bevindingen in heldere taal uit: welke keys blootliggen, welke u eerst vervangt en wat u verandert zodat het niet opnieuw gebeurt.
Waarom een gelekte key van een AI-model meer kost dan andere keys
Een gelekte key van een AI-modelprovider is een directe rekening en een uitvalrisico, niet alleen een datarisico. Model-API’s rekenen per verzoek of per token af, dus wie de key heeft, besteedt uw budget. De OWASP Top 10 for LLM Applications 2025 noemt dit LLM10, Unbounded Consumption: aanvallers “exploit the cost-per-use model of cloud-based AI services”, oftewel het betalen per gebruik van AI-diensten in de cloud.
De tweede kostenpost is beschikbaarheid. Duwt een gelekte key het account tegen de uitgavenlimiet of rate limit, dan stopt uw eigen AI-functie voor elke klant tot de limiet wordt gereset of iemand hem verhoogt.
De derde kostenpost hangt af van het account: sommige accounts bij modelproviders slaan ook bestanden of gespreksgeschiedenis op die een key kan bereiken. Controleer de rechten van de key in het dashboard van de provider.
Een illustratief scenario: een B2B-klantportaal krijgt een AI-functie die vergaderingen samenvat. Om sneller live te gaan, roept de browser de modelprovider rechtstreeks aan, dus de key staat in de JavaScript-bundel. In het weekend schiet het verbruik omhoog, en op maandag ligt de functie stil omdat het account de limiet heeft bereikt. Drie wijzigingen lossen het op: een backend proxy, een aparte key per functie, en de uitgavenlimieten die de provider ondersteunt, aangevuld met server-side quota per gebruiker.
Controleer vandaag welke uitgavenlimieten uw modelprovider ondersteunt op het niveau van organisatie, project of key, en stel ze in; factuurmeldingen alleen houden misbruik niet tegen. Ligt een key al open, trek die dan eerst in of schakel hem uit: uitgavenlimieten beperken verdere financiële schade, maar vervangen het intrekken niet.
Secret scanning: keys tegenhouden voordat ze live gaan
Secret scanning is een geautomatiseerde controle die zoekt naar credentials in code, configuratie en repositorygeschiedenis. Secret scanning werkt het best op drie controlepunten, die elk opvangen wat het vorige miste. GitGuardian telde in 2025 ongeveer 29 miljoen nieuwe hardcoded secrets in openbare GitHub-commits, 34% meer dan in 2024.
- Op de machine van de developer, vóór een commit. Een pre-commit hook voorkomt dat een key de repository in komt.
- Bij elke pull request. De CI-pipeline (de geautomatiseerde build- en testrun) blokkeert de merge zodra er een credential in staat.
- Over de volledige geschiedenis en op het hostingplatform. Een eenmalige scan van de geschiedenis vindt oude lekken, en push protection op het codeplatform weigert nieuwe.
Open-sourcescanners zoals Gitleaks en TruffleHog dekken de eerste twee controlepunten. Hoe secret scanning in een volledige delivery-pipeline past, leest u in ons artikel over de DevSecOps pipeline (Engelstalig).
Secret scanning heeft grenzen: een scanner ziet geen key die de build in de browserbundel zet, geen key die in een opgeslagen prompt staat en geen key die in een chat is geplakt. Scanning vermindert nieuwe lekken; een key die al openbaar is, wordt er niet veiliger door.
Secrets rotation: keys vervangen zonder productie stil te leggen
Secrets rotation betekent een key vervangen door een nieuwe en de oude uitschakelen, volgens een vast schema en na elk vermoeden van een lek. Teams slaan secrets rotation over uit angst voor uitval. GitGuardian meldt dat 64% van de geldige secrets die het in 2022 vond, vier jaar later nog steeds actief en bruikbaar was.
De juiste volgorde hangt af van de vraag of de key is blootgesteld. Eerst de nieuwe key live zetten houdt productie draaiende, maar tijdens de overstap blijft een blootliggende oude key bruikbaar voor wie hem heeft gekopieerd.
| Situatie | Juiste aanpak |
|---|---|
| Routinematige rotatie (geen bekende blootstelling) | Nieuwe key aanmaken → live zetten → controleren → oude key intrekken |
| Vermoede of bevestigde compromittering | Getroffen key snel intrekken of uitschakelen → vervangen → dienst herstellen → onderzoeken |
Bij routinematige rotatie vervangt u een key met deze volgorde zonder downtime:
- Maak de nieuwe key aan bij de provider, beperkt tot één dienst en één omgeving.
- Bewaar de nieuwe key in uw secrets manager of in de instellingen van de hostingomgeving.
- Zet de wijziging live en controleer dat de functie werkt met de nieuwe key.
- Trek de oude key in.
- Houd de foutlogs 24 uur in de gaten: elke mislukte aanroep wijst op een plek die de oude key nog gebruikte.
Roteer API keys op vier momenten: direct na een vermoed lek (volgorde bij compromittering: eerst intrekken), wanneer iemand met toegang vertrekt, wanneer een freelancer of leverancier klaar is, en volgens een vast schema. De API-keyrichtlijn van OpenAI ondersteunt keys met een vervaldatum en regelmatige rotatie. Geef elke dienst, omgeving en persoon een eigen key, zodat één rotatie niet alles breekt.
Wijs één persoon aan als eigenaar van de key-inventaris: welke keys er zijn, wie ze heeft en wanneer elke key voor het laatst is geroteerd.
Zo houdt u API keys uit een AI-product
Zes regels houden API keys uit een AI-product; de meeste kosten een besluit, geen budget.
| Regel | Wat het voorkomt |
|---|---|
| Keys alleen op de server, achter uw backend | Keys van modelproviders in browsers en apps |
| Secrets in een secrets manager of omgevingsinstellingen, nooit in code, prompts of documenten | Keys in repositories, prompts en chats |
| Beperkte keys met IP- of domeinrestricties waar de provider dat ondersteunt | Een gelekte key die meer kan dan zijn taak |
| Uitgavenlimieten op de niveaus die de provider ondersteunt, plus server-side quota en rate limits | Oplopende rekeningen en uitval door quota (geen vervanging voor het intrekken van een blootliggende key) |
| Secret-bestanden uitgesloten van AI-codingtools; geen keys in prompts | Keys die in agent-context, code en logs belanden |
| Een key-inventaris met eigenaar en laatste rotatiedatum per key | Oude keys die niemand vervangt |
Het OWASP-advies bij LLM07 zegt hetzelfde: bewaar gevoelige informatie in systemen waar het model niet rechtstreeks bij kan. In termen van ISO/IEC 27001:2022 vallen de regels onder Annex A 5.17 en A 8.4; ons artikel over AI code security gaat dieper op die standaarden in.
Een AI-product is op orde wanneer geen enkel secret in de browserbundel staat, secret scanning merges met credentials blokkeert en elke key een eigenaar en een laatste rotatiedatum heeft.
Wanneer een gelekte key om een onafhankelijke review vraagt
Eén gelekte key wijst vaak op een patroon, niet op een eenmalige fout. Een onafhankelijke review loont wanneer een van deze vier signalen speelt:
- er is één keer een geheime key in frontendcode gevonden, omdat hetzelfde buildpatroon zich meestal elders herhaalt;
- niemand kan opsommen welke keys er zijn en wie ze heeft;
- een AI-functie ging live zonder backend proxy of uitgavenlimiet;
- een eerder lek is opgelost door de regel te verwijderen, maar de key is nooit ingetrokken.
GitGuardian’s State of Secrets Sprawl 2026 stelde vast dat commits die mede door Claude Code zijn geschreven, in de eigen analyse ongeveer twee keer zo vaak secrets lekten als het gemiddelde van openbare GitHub-commits. Dat bewijst niet hetzelfde percentage voor elke AI-codingtool of elk project. Het onderbouwt wel dat u nagaat hoe AI-codingassistenten bij credentials komen, configuratiebestanden schrijven en wijzigingen aanleveren voordat een AI-gebouwd product live gaat. Een externe reviewer leest de code bovendien zonder de aannames waardoor de key naar buiten kwam.
Hoe Sunbytes AI-producten controleert op blootliggende keys
Eén gelekte key intrekken sluit het incident af, niet de route die de key nam. In AI-producten loopt die route meestal via een buildinstelling, een modelaanroep vanuit de browser of een coding agent met te veel toegang, en langs dezelfde route lekt vaak meer dan één key.
Sunbytes begint bij die route, niet bij de key. In een AI-built product review beoordelen software engineers en security-specialisten hetzelfde product: de code met de volledige repositorygeschiedenis, de build- en hostingconfiguratie en elke plek waar het product een modelprovider aanroept. Elke blootliggende key wordt herleid tot het patroon dat hem daar zette, en de bevindingen leggen in heldere taal uit wat u nu intrekt, wat achter uw backend moet en welke maatregelen (secret scanning, uitgavenlimieten, een eigenaar voor rotatie) het gat dichten. De review staat los van het herstelwerk, zodat het advies niet afhangt van wie de oplossing bouwt.
Twee andere teams komen er alleen bij als de bevindingen daarom vragen. Kon een gelekte key klantgegevens bereiken, dan zorgt Cybersecurity-oplossingen voor de kant van maatregelen en bewijs: toegangsregels, de omgang met secrets en het dossier voor een AVG-beoordeling van een mogelijk datalek of de beveiligingsvragenlijst van een klant. Is het verplaatsen van keys naar de server en het inrichten van scanning meer werk dan uw team aankan, dan voert een dedicated software development team de wijzigingen uit.
Toegang tot uw code tijdens de review valt onder het ISO/IEC 27001-gecertificeerde informatiebeveiligingsmanagement van Sunbytes, met governance vanuit het hoofdkantoor in Utrecht. Dat telt zodra uw product gegevens van Europese klanten bevat. Het werk steunt op ruim 300 opgeleverde softwareprojecten.
Is er één key uit uw AI-product gelekt? Vraag dan een AI-built product review aan en ontdek welke andere keys dezelfde route namen.
