Een indringend beeld van een enorme kluisdeur die wagenwijd openstaat met '123456' op het slot, waarachter rijen menselijke silhouetprofielen zichtbaar zijn — het thema van catastrofaal zwakke beveiliging die diep persoonlijke gegevens op grote schaal bewaakt.
Artificial IntelligenceCybersecurityTechnology

64 miljoen mensen solliciteerden op een baan. Een wachtwoord '123456' gaf al hun geheimen prijs.

Ashutosh SinghalAshutosh Singhal19 maart 202615 min

Ik zat in een gesprek met een potentiële klant — een middelgroot logistiek bedrijf — toen het McHire-verhaal naar buiten kwam. Mijn medeoprichter stuurde me midden in een zin een link. Ik wierp er een blik op, las de eerste twee regels en werd volledig stil. De klant vroeg of ik er nog was.

"Sorry," zei ik. "Ik las net dat het AI-wervingsplatform van McDonald's — dat miljoenen sollicitanten screent — beveiligd werd met het wachtwoord '123456.' En iemand is er zojuist zomaar binnengewandeld."

Er viel een lange stilte. Toen zei de klant: "Dat is eigenlijk onze opzet."

Hij maakte er half een grapje over. Maar slechts half.

Het McHire-datalek van juni 2025 legde de persoonlijke gegevens van ongeveer 64 miljoen werkzoekenden bloot — namen, e-mailadressen, telefoonnummers, IP-adressen, chattranscripten met een AI-recruiter genaamd "Olivia" en, het meest verontrustend, hun persoonlijkheidstestresultaten. De aanvalsvector was geen geavanceerde aanval van een natiestaat. Het was geen zero-day-exploit waarvoor een team van eliteshackers nodig was. Het was een standaard beheerderswachtwoord dat sinds 2019 onveranderd was gebleven, op een account zonder multifactorauthenticatie, dat een API bewaakte waarmee iedereen in de adresbalk van een browser door sollicitant-ID's kon bladeren.

Als ik mensen vertel wat we bij Veriprajna doen — AI-systemen bouwen met beveiliging en governance ingebakken in de architectuur — krijg ik soms het beleefde knikje dat betekent "zeker, maar is dat niet overdreven?" Het McHire-datalek is mijn antwoord. Het is niet overdreven. Het is het absolute minimum. En de meeste bedrijven doen zelfs dat niet.

Wat gebeurde er werkelijk binnen het McHire-platform?

Een stapsgewijs diagram dat de exacte aanvalsketen toont — van standaard inloggegevens tot IDOR-exploitatie tot massale gegevenstoegang — waardoor de technische volgorde meteen duidelijk wordt.

Het datalek werd niet ontdekt door een threat-intelligenceteam of een overheidsinstantie. Het begon met twee beveiligingsonderzoekers — Ian Carroll en Sam Curry — die iets alledaags opmerkten: gebruikers klaagden dat de "Olivia"-chatbot vol fouten zat. De front-endervaring was houterig en onbetrouwbaar.

Dat detail is van belang. In mijn ervaring is een kapotte front-end bijna altijd een signaal. Als een bedrijf niet heeft geïnvesteerd in het deel dat gebruikers zien, stel je dan eens voor wat er gebeurt in de delen die ze niet zien.

Carroll en Curry begonnen rond te snuffelen en vonden een beheerportaal bedoeld voor medewerkers van Paradox.ai — de leverancier die McHire namens McDonald's bouwde en beheerde. Ze probeerden een testaccount. De gebruikersnaam? "123456." Het wachtwoord? "123456." Het werkte.

Ik herinner me dat ik dat las en een specifiek soort woede voelde die iedereen die ooit productiesystemen heeft gebouwd zal herkennen. Het is geen verrassing — het is de woede van het weten dat dit volledig te voorkomen was. Dit was geen subtiele misconfiguratie in een Kubernetes-cluster. Het was het digitale equivalent van de kluisdeur openlaten met een Post-it die zegt "sleutel onder de mat."

Maar het wachtwoord was slechts fase één. Eenmaal binnen ontdekten de onderzoekers een Insecure Direct Object Reference-kwetsbaarheid — een IDOR, in beveiligingsjargon. Dit betekende dat de API niet controleerde of een ingelogde gebruiker daadwerkelijk geautoriseerd was om de gegevens van een specifieke sollicitant te zien. Door het sollicitant-ID-nummer in de URL te wijzigen — letterlijk gewoon een nummer ophogen — konden ze de volledige dossiers van elke sollicitant in het systeem oproepen.

Vierenzestig miljoen ervan.

Waarom persoonlijkheidstestgegevens het ergste soort gegevens zijn om te lekken

Hier gaat de meeste berichtgeving over dit datalek de mist in. De koppen richtten zich op het wachtwoord — "123456," ha ha, hoe dom — en gingen verder. Maar de echte catastrofe is niet de inloggegevens. Het is wat er achter zat.

Creditcardnummers kunnen worden geblokkeerd. Wachtwoorden kunnen worden gewijzigd. Maar persoonlijkheidsbeoordelingsresultaten? Gedragsscreeningsscores? De transcripten van een gesprek waarin een AI je temperament, je emotionele reacties, je conflictstijl onderzocht?

Die gegevens zijn jou. Ze verlopen niet.

Wanneer een persoonlijkheidsprofiel lekt, kun je het niet roteren zoals een wachtwoord. Je psychometrische vingerafdruk volgt je voor altijd.

Ik bracht een late avond door na het datalek met het lezen van onderzoek naar de psychologische impact van gegevensblootstelling. De cijfers zijn onthutsend: bijna 70% van de slachtoffers van datalekken meldt een aanhoudend onvermogen om anderen te vertrouwen. Twee derde ervaart diepe hulpeloosheid. Studies hebben blootstelling van persoonlijke gegevens gekoppeld aan angst, depressie en PTSS. En de ernst schaalt mee met de intimiteit van de gegevens — een gelekt e-mailadres steekt; een gelekte persoonlijkheidsbeoordeling die zegt dat je "emotioneel instabiel" of "weinig consciëntieus" bent, kan aanvoelen als een publieke ontleding.

Voor werkzoekenden — velen van hen jong, velen solliciterend naar hun eerste baan bij een fastfoodketen — is dit bijzonder wreed. Ze onderwierpen zich aan een persoonlijkheidstest omdat een AI hun dat opdroeg. Ze hadden geen betekenisvolle manier om te begrijpen welke gegevens werden verzameld, hoe ze werden opgeslagen of wie er toegang toe had. En nu staan die gegevens daarbuiten, mogelijk voor altijd, in een wereld waar toekomstige werkgevers, verzekeraars of kwaadwillenden afgeleide eigenschappen tegen hen zouden kunnen gebruiken.

Mijn team had hier een discussie over. Een van onze engineers zei: "Kijk, de gegevens werden blootgesteld maar waarschijnlijk niet daadwerkelijk op grote schaal geëxfiltreerd — de onderzoekers hebben het verantwoord gemeld." En technisch gezien klopt dat. Paradox verhielp de kwetsbaarheid binnen enkele uren na melding. Maar ik protesteerde krachtig. Het punt is niet of deze specifieke dataset op een darkwebforum belandde. Het punt is dat de architectuur het toestond. Het systeem was zo ontworpen dat een standaardwachtwoord en een browser voldoende waren om toegang te krijgen tot de psychometrische profielen van 64 miljoen mensen. Dat is geen bijna-ongeval. Dat is een falen van de ontwerpfilosofie.

De ontwikkelaar in Vietnam en het wachtwoord dat alles ontsloot

Er is een subplot bij dit verhaal dat niet genoeg aandacht kreeg. Onderzoeken onthulden dat een in Vietnam gevestigde ontwikkelaar van Paradox.ai was gecompromitteerd door een malwarevariant genaamd Nexus Stealer — een tool voor het stelen van inloggegevens die op cybercrimeforums wordt verkocht. De infectie exfiltreerde honderden wachtwoorden van het apparaat van de ontwikkelaar. Veel ervan waren zwak en hergebruikt, waarbij hetzelfde basiswachtwoord van zeven cijfers over meerdere diensten werd gebruikt.

Die ene gecompromitteerde ontwikkelaar legde inloggegevens bloot die verband hielden met Paradox.ai-accounts voor klanten waaronder Pepsi, Lockheed Martin, Lowe's en Aramark.

Ik wil dat je daar even bij stilstaat. Eén persoon. Eén geïnfecteerde laptop. Eén hergebruikt wachtwoord. En plotseling lopen de wervingsgegevens van enkele van de grootste werkgevers in Amerika gevaar.

Dit is wat ik het "menselijke node"-probleem noem, en het is het ding dat me 's nachts veel meer wakker houdt dan welke exotische AI-aanvalsvector dan ook. Je kunt het meest geavanceerde model ter wereld bouwen, het finetunen op onberispelijke gegevens, het omhullen met guardrails — en dan laat de wachtwoordhygiëne van één enkele ontwikkelaar het hele kaartenhuis instorten. De gemiddelde kosten van een datalek in 2025 bedroegen $4,44 miljoen. Maar organisaties blijven identiteitsbeheer behandelen als een bijzaak, iets wat het IT-team afhandelt met een jaarlijkse trainingsvideo die niemand bekijkt.

De beveiliging van je AI-systeem is nooit sterker dan de zwakste menselijke inloggegevens in de keten.

Bij Veriprajna hebben we onze architectuur gebouwd rond de aanname dat menselijke toegang een risicovolle vector is die continue verificatie vereist — wat de industrie Zero Trust noemt. Niet omdat we ons team niet vertrouwen, maar omdat ik heb gezien wat er gebeurt wanneer je welk enkel authenticatiepunt dan ook vertrouwt om de linie te houden.

Wat betekent "Deep AI" eigenlijk — en waarom zou het je iets kunnen schelen?

Ik moet een onderscheid introduceren waarvan ik denk dat het het belangrijkste idee in enterprise-AI van dit moment is, en dat het McHire-datalek perfect illustreert: het verschil tussen een AI-wrapper en wat wij Deep AI noemen.

Een AI-wrapper is wat de meeste bedrijven daadwerkelijk bouwen wanneer ze zeggen dat ze "aan AI doen." Het is een dunne applicatielaag — vaak een chatbot of een formulier — die gebruikersinvoer naar een foundationmodel zoals GPT-4 of Claude stuurt via een API, een antwoord ontvangt en dat weergeeft. De AI is een dienst die je huurt. Je applicatie is de etalage. De beveiliging, het gegevensbeheer, de governance — dat wordt allemaal achteraf aangebouwd, met dezelfde webontwikkelingspraktijken die je voor elke CRUD-app zou gebruiken.

Paradox.ai's "Olivia" was, architectonisch gezien, een wrapper. Een geavanceerde, dat wel. Maar de beveiligingshouding was verankerd aan traditionele webinfrastructuur — en die infrastructuur faalde op het meest basale niveau dat denkbaar is.

Deep AI is fundamenteel anders. Het behandelt het AI-model als een architectonische primitieve — zoals een database of een berichtenwachtrij — met zijn eigen beveiligingsgrenzen, zijn eigen toegangscontroles, zijn eigen audittrails. Het model is geen black box die je aanroept; het is een component die je bestuurt. Je bouwt promptrouters, geheugenlagen, feedbackevaluatoren. Je implementeert gelaagde verdedigingen die ervan uitgaan dat elke invoer vijandig is en elke uitvoer onvertrouwd.

Ik heb over deze architectonische filosofie uitgebreid geschreven in de interactieve versie van ons onderzoek, maar het kerninzicht is simpel: als je AI-beveiligingsstrategie is "we voegen wel authenticatie en een WAF toe," bouw je een wrapper, en ben je één standaardwachtwoord verwijderd van een catastrofe.

De 5-lagen-verdediging die niemand wil bouwen

Een verdedigingsarchitectuurdiagram met concentrische ringen dat de vijf beveiligingslagen toont van buitenste naar binnenste, met duidelijke labels voor de functie van elke ring.

Na het McHire-nieuws trok ik mijn engineeringteam in een kamer en zei: "Loop me precies door hoe onze stack dit zou hebben voorkomen." Niet omdat ik aan hen twijfelde — maar omdat ik elke aanname wilde stresstesten.

We hebben er drie uur over gedaan. Op een gegeven moment tekende onze lead security engineer een diagram op het whiteboard dat leek op de dwarsdoorsnede van een middeleeuws kasteel — concentrische verdedigingsringen, elk onafhankelijk opererend. Als er één valt, houdt de volgende stand. Zo ziet dat er in de praktijk uit:

De buitenste ring is invoersanitatie — elke prompt, elke API-aanroep wordt ontdaan van alles wat verkeerd geïnterpreteerd zou kunnen worden als een injectiecommando. De tweede ring is heuristische dreigingsdetectie, die actief scant op bekende adversariële patronen. De derde is meta-prompt-omhulling, waarbij het verzoek van de gebruiker wordt ingesloten in een beveiligde envelop van instructies die het model niet kan overschrijven.

De vierde ring is waar het interessant wordt: canary- en adjudicatormodellen. Een kleiner model analyseert het verzoek eerst. Als het iets verdachts markeert, neemt een tweede model de definitieve beslissing. Het is een buddysysteem voor AI — geen enkel model mag eenzijdig handelen.

De vijfde en binnenste ring is uitvoervalidatie. Elke reactie die de AI genereert wordt behandeld als onvertrouwd tot het tegendeel is bewezen. PII-redactielagen scannen op gevoelige gegevens. Toxiciteitsclassificatoren controleren op schadelijke inhoud. Niets komt erdoor zonder geïnspecteerd te worden.

Dit is wat me frustreerde tijdens die whiteboardsessie: niets hiervan is exotisch. Niets ervan vereist een onderzoeksdoorbraak. Het is engineeringdiscipline toegepast op een nieuw domein. De reden dat de meeste bedrijven het niet doen is omdat het duur is, het is traag, en het demonstreert niet goed. Een wrapper-chatbot kan in een weekend gebouwd worden en op maandag aan een bestuur getoond. Een goed bestuurd AI-systeem kost maanden. Raad eens welke er gefinancierd wordt.

De AI-industrie heeft een demoprobleem: het ding dat investeerders in een pitch imponeert is architectonisch het tegenovergestelde van het ding dat gebruikers in productie beschermt.

Waarom behandelt de wet persoonlijkheidsgegevens alsof ze radioactief zijn?

Een vraag die ik van elke CTO krijg met wie ik spreek: "Hoe erg is de juridische blootstelling hier, echt?"

Het antwoord: potentieel existentieel.

Onder de CCPA kan een bedrijf worden aangeklaagd als niet-versleutelde persoonlijke informatie wordt gestolen door het nalaten "redelijke beveiligingsprocedures" te handhaven. De wettelijke schadevergoeding bedraagt $750 per consument per incident. Vermenigvuldig dat met 64 miljoen dossiers en je kijkt tegen een theoretische aansprakelijkheid van $48 miljard aan. Geen rechtbank zou dat volledige bedrag toekennen, maar zelfs een fractie is bedrijfsbeëindigend.

Onder de AVG zijn de boetes gemaximeerd op €20 miljoen of 4% van de wereldwijde jaaromzet — welke het hoogst is. En de EU AI Act, die wervings-AI classificeert als "hoog risico," introduceert boetes tot €35 miljoen of 7% van de wereldwijde omzet voor niet-naleving van verplichte risicobeoordelingen en vereisten voor menselijk toezicht.

Maar dit is wat de meeste juridische analyses missen: de reputatieschade is erger dan de boetes. Ik sprak enkele weken na het datalek met een CHRO bij een Fortune 500-bedrijf. Ze vertelde me dat haar team AI-wervingstools had geëvalueerd en drie leveranciers op een shortlist had gezet. Na het McHire-verhaal schrapte de CEO het hele initiatief. "We doen het nog een jaar handmatig," zei hij. "Ik ga niet de volgende krantenkop worden."

Dat zijn de echte kosten. Niet alleen voor Paradox.ai, maar voor elk legitiem AI-bedrijf dat vertrouwen probeert op te bouwen bij zakelijke kopers. Eén catastrofaal datalek vergiftigt de bron voor iedereen.

Hoe bestuur je AI die daadwerkelijk beslissingen over mensen neemt?

Hier moet ik eerlijk zijn over iets ongemakkelijks: governancekaders klinken saai. ISO 42001, NIST AI RMF, OWASP Top 10 voor LLM's — dit zijn niet de dingen waar oprichters enthousiast van worden op etentjes. Maar het zijn wel de dingen die de bedrijven die toezichtcontrole overleven scheiden van de bedrijven die dat niet doen.

ISO 42001 is 's werelds eerste internationale standaard voor AI-managementsystemen. Het vereist dat organisaties AI-specifieke risico's identificeren, duidelijke doelstellingen voor transparantie en veiligheid vaststellen, impactbeoordelingen uitvoeren voor elk AI-systeem, en continue monitoring onderhouden via interne audits. Het is geen afvinkoefening — het is een managementsysteem dat je dwingt om over AI-governance na te denken zoals je over financiële controles nadenkt.

Het NIST AI Risk Management Framework biedt het beleidsanker, georganiseerd rond vier functies: GOVERN, MAP, MEASURE, MANAGE. In het Paradox-datalek faalde de GOVERN-functie het meest opvallend — er was geen organisatorische verantwoordelijkheid voor het buiten gebruik stellen van het verouderde beheerdersaccount dat daar sinds 2019 had gestaan.

En het OWASP-framework — met name de update van 2025 voor agentic AI — geeft ontwikkelaars een gerangschikte taxonomie van de meest kritieke kwetsbaarheden. Agent Goal Hijack, waarbij kwaadaardige inhoud het kerngedrag van een agent verandert. Tool Misuse, waarbij een agent wordt misleid om een legitieme mogelijkheid voor een schadelijk doel te gebruiken. Memory Poisoning, waarbij slechte gegevens worden geïnjecteerd in het langetermijngeheugen van een persistente agent.

Voor de volledige technische uiteenzetting van hoe deze kaders elkaar kruisen, inclusief implementatiespecificaties en een 90-dagen-CXO-roadmap, heb ik een gedetailleerd begeleidend paper gepubliceerd. Maar de managementsamenvatting is deze: tegen 2026 zal AI-governance niet optioneel zijn. Het zal een vereiste zijn om zaken te doen met elke onderneming die een juridisch team heeft.

"Kunnen we beveiliging niet gewoon later toevoegen?"

Mensen vragen me dit voortdurend. Het antwoord is altijd hetzelfde, en het is altijd ongemakkelijk: nee. Dat kun je niet.

Beveiliging die achteraf wordt aangebouwd is beveiligingstheater. Het is een slot op een deur die al uit zijn scharnieren is gehaald. Het McHire-datalek bewijst dit — Paradox.ai had authenticatie. Ze hadden een beheerportaal. Ze hadden vermoedelijk een of ander beveiligingsbeoordelingsproces. Maar omdat beveiliging niet vanaf dag één in de architectuur was ingebed, was het hele systeem slechts zo sterk als een wachtwoord dat een peuter kon raden.

Nog een bezwaar dat ik hoor: "Maar we gebruiken een grote cloudprovider. Is hun beveiliging niet goed genoeg?" De Paradox-ontwikkelaar in Vietnam werd gecompromitteerd door commodity-malware — geen exploit van cloudinfrastructuur. Je cloudprovider kan perfecte beveiliging hebben en je systeem kan nog steeds worden gehackt omdat een ontwikkelaar een wachtwoord over diensten heen hergebruikte. De perimeter ligt niet waar je denkt dat hij ligt.

En dan is er die ene die me echt kwaad maakt: "Onze AI-leverancier regelt de beveiliging." Dit is precies wat McDonald's dacht. Ze besteedden hun AI-werving uit aan Paradox.ai en, door dat te doen, besteedden ze hun beveiligingshouding uit aan een leverancier wiens beheerportaal beveiligd was met "123456." De toeleveringsketen is nu de beveiligingsperimeter. Als je de AI-infrastructuur van je leveranciers niet met dezelfde striktheid bestuurt die je op je eigen infrastructuur toepast, delegeer je geen risico — je negeert het.

De gedachte die ik niet van me af kan zetten

Dit is waar ik steeds op terugkom, weken nadat het McHire-verhaal voor het eerst naar buiten kwam.

Vierenzestig miljoen mensen — velen van hen tieners, velen solliciterend naar hun eerste baan — zaten voor een scherm en beantwoordden vragen van een AI-chatbot. Ze deelden informatie over zichzelf omdat het systeem hun dat opdroeg. Ze hadden geen invloed, geen onderhandelingsmacht, geen mogelijkheid om te zeggen "eigenlijk wil ik liever geen persoonlijkheidstest doen om hamburgers te bakken." De machtsasymmetrie was totaal.

En het systeem dat hun gegevens bewaarde — hun namen, hun gedragsprofielen, de beoordeling door de AI van hun persoonlijkheid — was beveiligd met hetzelfde wachtwoord dat mijn dochter gebruikt voor haar Roblox-account.

We bouwden AI-systemen die menselijke persoonlijkheid op grote schaal kunnen beoordelen. We zijn alleen vergeten de mensen te beschermen.

Dit is geen technologieprobleem. Het is een waardenprobleem. Het is wat er gebeurt wanneer de industrie AI behandelt als een product om te leveren in plaats van een systeem om te besturen. Wanneer "beweeg snel en breek dingen" "we nemen geautomatiseerde beslissingen over de bestaansmiddelen van mensen" ontmoet.

Het tijdperk van de wrapper is voorbij. De bedrijven die de volgende golf van regelgeving overleven, het volgende datalek, de volgende publieke afrekening — dat zullen degenen zijn die beveiliging in het fundament hebben gebouwd, niet degenen die het achteraf hebben aangebouwd na de krantenkop. Bij Veriprajna is dat het enige soort AI dat we bereid zijn te bouwen. Niet omdat het makkelijker is. Maar omdat het alternatief onverdedigbaar is.

Het wachtwoord "123456" zou een relikwie moeten zijn. De architectuur die het relevant liet zijn zou uitgestorven moeten zijn. En de 64 miljoen mensen wier gegevens werden blootgesteld verdienen beter dan de huidige definitie van "goed genoeg" van de industrie.

Gerelateerd onderzoek

Ook gepubliceerd op

Bouw uw AI met vertrouwen.

Werk samen met een team met diepgaande ervaring in het bouwen van de volgende generatie enterprise-AI. Laat ons u helpen bij het ontwerpen, bouwen en implementeren van een AI-strategie waarop u kunt vertrouwen.

Veriprajna Deep Tech-adviesbureau is gespecialiseerd in het bouwen van veiligheidskritische AI-systemen voor de gezondheidszorg, de financiële sector en gereguleerde domeinen. Onze architecturen worden gevalideerd aan de hand van gevestigde protocollen met uitgebreide compliancedocumentatie.