Wat er gebeurde: Een stille beveiligingsinbreuk die duizenden treft
Truffle Security heeft een kritieke kwetsbaarheid onthuld in Google's API-sleutelarchitectuur die duizenden organisaties treft die Google Cloud gebruiken. Door de November 2025 Common Crawl dataset te scannen, identificeerden onderzoekers 2.863 live Google API-sleutels die oorspronkelijk werden ingezet voor publieke diensten zoals Google Maps en Firebase, maar nu ook volledige toegang verlenen tot Gemini AI-endpoints.
Het kernprobleem is wat onderzoekers 'retroactieve privilege-escalatie' noemen. Meer dan tien jaar lang vertelde Google ontwikkelaars expliciet dat API-sleutels (het AIza... formaat) geen geheimen zijn en veilig kunnen worden ingebed in client-side code. Firebase's beveiligingsdocumentatie stelde dit duidelijk. Google Maps documentatie instrueerde ontwikkelaars om sleutels direct in HTML te plakken.
Toen kwam Gemini. Wanneer je de Gemini API inschakelt op een Google Cloud project, krijgen bestaande API-sleutels in dat project stilletjes toegang tot gevoelige Gemini-endpoints. Geen waarschuwing. Geen bevestigingsdialoog. Geen e-mailnotificatie. Een Maps-sleutel die drie jaar geleden werd ingezet volgens Google's eigen richtlijnen is nu een Gemini-credential, publiekelijk zichtbaar in de JavaScript van je website.
De aanval: Triviaal eenvoudig, verwoestend effectief
De exploit vereist geen geavanceerd hacken. Een aanvaller bezoekt je website, bekijkt de paginabron, kopieert de AIza-sleutel uit je Maps-embed, en voert een enkel curl-commando uit tegen Gemini's API. In plaats van een 403 Forbidden krijgen ze een 200 OK.
Vanaf daar kunnen aanvallers privédata benaderen via de /files/ en /cachedContents/ endpoints, die geüploade datasets, documenten en gecachete context kunnen bevatten. Ze kunnen duizenden euro's aan Gemini API-kosten per dag op jouw account genereren. Ze kunnen je quota's uitputten en legitieme AI-diensten platleggen. De aanvaller raakt nooit je infrastructuur aan; ze scrapen gewoon een sleutel van een publieke webpagina.
De slachtoffers zijn geen hobbyprojecten. Truffle Security vond blootgestelde sleutels van grote financiële instellingen, beveiligingsbedrijven, wereldwijde recruitmentbureaus, en opmerkelijk genoeg Google zelf. Als Google's eigen engineeringteams deze valkuil niet kunnen vermijden, is het onrealistisch om te verwachten dat elke enterprise-ontwikkelaar het correct navigeert.
Waarom dit belangrijk is: De verborgen kosten van vendor-afhankelijkheid
Deze kwetsbaarheid onthult een dieper probleem met hoe enterprises AI benaderen: ze outsourcen niet alleen computing, maar controle. Wanneer je volledig afhankelijk bent van een cloud AI-provider, erf je hun architecturale beslissingen, hun beveiligingsmodellen, en hun stille wijzigingen aan privilege-scopes.
Google's herstelplan omvat het detecteren van gelekte sleutels en het blokkeren van Gemini-toegang. Maar deze reactieve aanpak benadrukt het fundamentele probleem: je beveiligingshouding veranderde zonder je medeweten, en je bent nu afhankelijk van de vendor om een probleem op te lossen dat zij hebben gecreëerd.
Voor enterprises die gevoelige data verwerken is dit onacceptabel. Contractvoorwaarden, financiële documenten, klantdata en concurrentie-informatie zouden niet één configuratiewijziging verwijderd moeten zijn van blootstelling. Het patroon dat hier wordt onthuld, waarbij publieke identifiers stilletjes gevoelige privileges verkrijgen, is niet uniek voor Google. Naarmate meer organisaties AI-capabilities aan bestaande platformen vastschroeven, breidt het aanvalsoppervlak voor legacy credentials uit op manieren die niemand had voorzien.
Laava's perspectief: Soevereine AI als beveiligingsarchitectuur
Bij Laava hebben we altijd gepleit voor soevereine AI-architectuur, en deze kwetsbaarheid demonstreert precies waarom. Wanneer je je eigen AI-infrastructuur bezit, controleer je het credential-model. Er zijn geen 'stille privilege-escalaties' omdat jij definieert waar elke sleutel toegang toe heeft.
Onze aanpak gebruikt open-source modellen zoals Llama en Mistral, gedeployed binnen de infrastructuur van de klant. De reasoning-laag is volledig geïsoleerd. Een sleutel die toegang heeft tot je documentsysteem kan niet plotseling AI-inference capabilities verkrijgen omdat je een nieuwe feature hebt ingeschakeld. Credential-grenzen zijn expliciet, auditeerbaar en onder jouw controle.
Voor organisaties die cloud AI-capabilities nodig hebben, implementeren we strikte isolatie via ons Model Gateway Pattern. Elke AI-service krijgt dedicated credentials met expliciete, minimale scopes. Legacy sleutels die worden gebruikt voor publieke diensten blijven geïsoleerd in aparte projecten zonder ingeschakelde AI API's. De architectuur dwingt het principe van least privilege af dat Google's defaults schenden.
We implementeren ook PII-redactie gateways, zodat gevoelige data nooit externe AI-endpoints bereikt. Zelfs als een credential zou worden gecompromitteerd, is er niets gevoeligs om te exfiltreren omdat de AI-laag alleen getokeniseerde, geanonimiseerde data ziet.
Wat je moet doen: Onmiddellijke stappen
Als je Google Cloud gebruikt, onderneem vandaag nog actie. Ten eerste, controleer elk GCP-project op de Generative Language API onder APIs & Services > Enabled APIs & Services. Als het niet is ingeschakeld, word je niet getroffen door dit specifieke probleem. Ten tweede, als de Generative Language API is ingeschakeld, audit je API-sleutels onder APIs & Services > Credentials. Zoek naar sleutels met een 'unrestricted' waarschuwing of sleutels die expliciet de Generative Language API vermelden.
Ten derde, verifieer dat geen van die sleutels publiek is. Controleer client-side JavaScript, publieke repositories en overal waar sleutels ingebed kunnen zijn. Begin met je oudste sleutels; die zijn het meest waarschijnlijk gedeployed onder de oude 'sleutels zijn veilig om te delen' richtlijnen. Als je een blootgestelde sleutel met Gemini-toegang vindt, roteer hem onmiddellijk.
Breder is dit een kans om je AI-beveiligingsarchitectuur te herbeoordelen. Zijn je AI-credentials goed geïsoleerd? Zou een stille update van een vendor je data kunnen blootstellen? Heb je zicht op waar elke sleutel daadwerkelijk toegang toe heeft? Als je onzeker bent over een van deze vragen, is het tijd om een meer soevereine benadering van AI-infrastructuur te overwegen.
We bieden een gratis 90-minuten Roadmap Sessie aan om je huidige AI-beveiligingshouding te beoordelen en architecturale wijzigingen te identificeren die jou weer de controle geven. Je AI-credentials zouden geen wachtende aansprakelijkheid moeten zijn.