Ik vond AI-modellen met backdoors op Hugging Face — en iedereen die de moeite nam om te kijken, vond ze ook

Het was een dinsdagavond en ik keek toe hoe een van mijn engineers iets deed wat routine had moeten zijn: een voorgetraind model van Hugging Face in een testomgeving laden. Doodgewoon. We hadden het al honderden keren gedaan. Maar deze keer had ik net JFrogs onthulling van februari 2024 gelezen — die waarin hun securityonderzoekers meer dan 100 kwaadaardige modellen op Hugging Face aantroffen, sommige met backdoors die aanvallers op afstand toegang gaven zodra je ze laadde — en ik kon mijn ogen niet van de terminal afhouden.

"Wacht", zei ik. "In welk formaat is dat model?"

Pickle.

Mijn maag draaide om.

Dat was het moment waarop ik besefte dat we AI-modellen behandelden zoals de sector in 2014 met open-sourcelibraries omging — als inherent betrouwbare artefacten die je gewoon van internet haalt en uitvoert. En ik wist, met het soort zekerheid dat alleen ontstaat als je je aannames in realtime ziet instorten, dat dit een van de bepalende securitycrises van het komende decennium zou worden.

Het model dat naar huis belt

Dit is wat er werkelijk op Hugging Face is gebeurd. Een gebruiker met de naam "baller423" uploadde een PyTorch-model dat er volkomen normaal uitzag. Het had een redelijke naam, een plausibele beschrijving, degelijk ogende metrics. Maar diep in de pickle-geserialiseerde gewichten zat een payload die, op het moment dat iemand torch.load() aanriep, een reverse shell opende naar een IP-adres van het Korea Research Environment Open Network.

Geen theoretische aanval. Geen proof of concept. Een live model dat tot wapen is gemaakt, op de populairste AI-modelhub ter wereld, wachtend tot iemand het zou downloaden.

En "baller423" stond niet alleen. JFrog vond ongeveer 100 van dit soort modellen — elk een Trojaans paard vermomd als een behulpzaam voorgetraind artefact.

Wanneer je torch.load() op een pickle-bestand uitvoert, laad je geen data. Je voert code uit. En je hebt geen idee wat die code doet tot het te laat is.

Ik moet uitleggen waarom dit zo gevaarlijk is, want de meeste mensen — zelfs de meeste engineers — begrijpen niet wat pickle eigenlijk is. Het Python-pickle-formaat is niet zomaar een methode om data te serialiseren. Het is een stack-gebaseerde virtuele machine. Het kan tijdens deserialisatie willekeurige Python-functies uitvoeren. Wanneer je data scientist een model laadt, kan pickle stilletjes os.system() of subprocess.run() op de achtergrond aanroepen. Het model werkt prima. De voorspellingen zien er normaal uit. En ondertussen heeft iemand aan de andere kant van de wereld een shell op je server.

Dit is geen bug. Zo is pickle ontworpen. We hebben alleen nooit stilgestaan bij wat dat betekent wanneer de bestanden van vreemden op internet komen.

Waarom hebben de scanners het niet opgemerkt?

Dit is het deel dat me die nacht wakker hield. We hadden securitytools. De sector had PickleScan, de standaardtool om modelbestanden te controleren. Hugging Face draait het zelf. De scanners zouden zoiets overduidelijks toch zeker opmerken?

Dat deden ze niet. En het wordt erger.

JFrog ontdekte later drie zero-daykwetsbaarheden in PickleScan zelf — waaronder een die geregistreerd staat als CVE-2025-10155 — waarmee aanvallers de detectie volledig konden omzeilen door bestandsextensies te manipuleren of discrepanties in ZIP-archieven uit te buiten. Een kwaadaardig model kon als "veilig" worden bestempeld door precies de tool die jou moest beschermen.

Het statistische beeld is somber: tot wel 96% van de huidige scannermeldingen is een false positive. Bedenk wat dat met een securityteam doet. Na het honderdste vals alarm kijk je niet meer. Je klikt reflexmatig op "goedkeuren". En precies dan loopt de echte dreiging naar binnen.

Ik had hierover een verhitte discussie met een van mijn teamleads. Hij vond dat we overdreven. "We halen alleen modellen bij geverifieerde organisaties", zei hij. Ik liet hem de data van JFrog zien. Ik liet hem zien dat zelfs nieuwere "veilige" formaten zoals GGUF — specifiek ontworpen om de problemen van pickle te vermijden — kwaadaardige Jinja-templates in hun metadata bleken te herbergen die tijdens de inferentie worden uitgevoerd, niet tijdens het laden. De scanner ziet het nooit, omdat de aanval later plaatsvindt, wanneer het model al draait.

Hij zweeg lange tijd. Toen zei hij: "Wat vertrouwen we dan eigenlijk wel?"

Dat is de juiste vraag.

Wat gebeurt er als er een slapende agent in je AI zit?

Bij het Hugging Face-incident ging het om grove, detecteerbare payloads — reverse shells, overduidelijke code-uitvoering. Maar de diepere dreiging, die mij echt beangstigt, is data poisoning. En het onderzoek hiernaar is angstaanjagend.

NVIDIA's AI Red Team heeft, samen met bevindingen van Anthropic, aangetoond dat je verborgen gedrag permanent kunt implanteren in een model met 13 miljard parameters door slechts 0,00016% van de trainingsdata te vergiftigen — ruwweg 250 documenten op een totaal van miljoenen.

Laat dat getal even bezinken. Tweehonderdvijftig documenten.

Het vergiftigde model doorstaat elke benchmark. Het presteert op standaardtests identiek aan een schoon model. Maar wanneer het een specifieke trigger tegenkomt — een bepaalde tekenreeks, een beeldpatroon, zelfs een manipulatie op bitniveau van de invoerdata — verandert het van gedrag. Het kan authenticatie omzeilen. Het kan data exfiltreren. Het kan kwaadaardige code genereren die wordt doorgesluisd naar een downstreamsysteem.

Een vergiftigd AI-model is de perfecte slapende agent: het doorstaat elke test, scoort glansrijk op elke benchmark en wacht geduldig op een trigger die alleen de aanvaller kent.

En hier komt de wiskundige mokerslag: meer schone data toevoegen lost het niet op. Zodra de backdoor een drempel bereikt — doorgaans nadat de trigger 50 tot 100 keer in de training is voorgekomen — zit hij permanent in de gewichten gebakken. Je kunt hem er niet uittrainen. Je kunt hem niet wegverdunnen.

NVIDIA heeft dit geformaliseerd in wat zij de AI Kill Chain noemen: vijf fasen — Recon, Poison, Hijack, Persist, Impact — die in kaart brengen hoe aanvallers machine-learningsystemen systematisch compromitteren. Ik schreef over dit raamwerk en het volledige spectrum aan aanvalsvectoren in ons interactieve onderzoeksoverzicht, en ik zou iedereen die modellen in productie uitrolt aanraden er tijd in te steken.

De implicatie voor elke onderneming die modellen op eigen data finetunet is hard: zelfs als je bedrijfseigen dataset vlekkeloos is, kan het basismodel dat je van een publieke repository hebt gedownload al gecompromitteerd zijn. Je bouwt op een fundament waar je niet in kunt kijken.

Het Shadow AI-probleem waar niemand over wil praten

Ik zat bij een diner met een CISO van een middelgrote financiële dienstverlener. Ze vertelde me, bijna terloops, dat haar team onlangs 47 verschillende AI-modellen had ontdekt die bedrijfsbreed in productie draaiden. Haar AI-governancebeleid dekte er drie van.

Dit is Shadow AI, en het is een epidemie. De data zijn onthutsend: 90% van het AI-gebruik binnen de onderneming vindt plaats buiten het zicht van IT- en securityteams. Ontwikkelaars en business units halen ongecontroleerde modellen uit publieke repository's omdat het officiële proces te lang duurt. Ze plakken bedrijfseigen code en klantgegevens in publieke AI-tools — bij 77% van de medewerkers is dit waargenomen. En elk van die niet-geautoriseerde modellen is een potentiële backdoor die nog nooit door een scanner is aangeraakt.

De financiële impact is niet abstract. Incidenten waarbij ongecontroleerde AI-tools betrokken zijn, verhogen de kosten van een datalek met gemiddeld $670.000. Dat is de premie die je betaalt voor "snel gaan" zonder governance.

Ik begrijp de impuls. Echt waar. Als je een engineer bent die een feature wil opleveren en het securityreviewproces drie weken duurt, ben je natuurlijk in de verleiding om gewoon een model van Hugging Face binnen te halen en het aan te sluiten. Ik heb die verleiding zelf gevoeld. Maar de onthulling van JFrog had een einde moeten maken aan dat tijdperk. We weten nu, met empirische zekerheid, dat publieke modelhubs tot wapen gemaakte artefacten bevatten. Ze als vertrouwde bronnen behandelen is het AI-equivalent van het uitvoeren van curl | bash vanaf een willekeurige GitHub-gist in productie.

Waarom vliegt iedereen nog steeds blind?

NIST bracht in 2024 zijn AI 100-2-richtlijn uit — een uitgebreide taxonomie van adversarial machine learning-aanvallen en -mitigaties. Het is goed werk. Het geeft de sector een gemeenschappelijke taal voor deze dreigingen. En vrijwel niemand heeft het geïmplementeerd.

De cijfers zijn vernietigend:

• Slechts 17% van de organisaties heeft geautomatiseerde AI-securitycontroles
• Slechts 12% heeft uitgebreide AI-governance ingericht
• Slechts 14% heeft zicht op interne AI-datastromen
• 83% van de organisaties "opereert blind", in de formulering van NIST

Ik heb deze kloof van dichtbij gezien. Organisaties verwarren het hebben van een beleidsdocument met het hebben van operationele security. Ze laten je een prachtig vormgegeven AI-governance-pdf zien terwijl hun ontwikkelaars niet-ondertekende pickle-modellen laden in Kubernetes-clusters in productie. Het document bestaat. De controles niet.

83% van de ondernemingen heeft geen geautomatiseerde controles op de eigen AI-toeleveringsketen. Dat is geen kloof — dat is een open deur.

Hoe we modellen als kwaadaardige code zijn gaan behandelen

Na die openbaring op dinsdagavond heeft mijn team bij Veriprajna weken besteed aan het herontwerpen van onze aanpak van model-ingestie. De fundamentele filosofische omslag was eenvoudig maar radicaal: behandel elk AI-model als potentieel kwaadaardige uitvoerbare code totdat het tegendeel bewezen is.

Niet "waarschijnlijk prima". Niet "van een gerenommeerde bron". Potentieel kwaadaardig. Punt uit.

De Machine Learning Bill of Materials

Het eerste wat we nodig hadden was transparantie. Traditionele Software Bills of Materials (SBOM's) houden libraries en versies bij, maar AI-artefacten hebben meer nodig: een ML-BOM — een Machine Learning Bill of Materials — die de herkomst van data, de afstamming van het model, framework-afhankelijkheden en cryptografische attestaties vastlegt.

Waar kwam de trainingsdata vandaan? Wie heeft dit model gefinetuned, en waarop? Welke versie van PyTorch is gebruikt, en heeft die bekende kwetsbaarheden? Kunnen we cryptografisch verifiëren dat het model dat we laden exact het artefact is dat door een vertrouwde pipeline is geproduceerd, zonder manipulatie tijdens het transport?

Als je deze vragen niet kunt beantwoorden, weet je niet wat je uitrolt.

Pickle afschaffen, alles ondertekenen

We namen twee onmiddellijke engineeringbeslissingen. Ten eerste: geen pickle meer. Punt. Elk model in onze pipeline gebruikt SafeTensors — een formaat dat alleen tensordata met JSON-metadata opslaat en tijdens het laden geen code kan uitvoeren. Het is minder flexibel dan pickle, en dat is precies de bedoeling.

Ten tweede: cryptografische ondertekening van modellen. Elk modelartefact krijgt een unieke hash, ondertekend met onze interne PKI-infrastructuur. Onze inferentieservers draaien een admission controller die de handtekening verifieert tegen onze root of trust voordat de gewichten in het geheugen worden gedeserialiseerd. Als de handtekening niet klopt, laadt het model niet. Geen uitzonderingen, geen overrides, geen "maar het is alleen om te testen."

Een van mijn engineers verzette zich hier hevig tegen. "Je voegt wrijving toe aan de ontwikkelworkflow", zei hij. Hij had gelijk. Ik heb die wrijving bewust toegevoegd. Want het alternatief — het wrijvingsloze pad waarop iedereen elk model van overal kan laden — is precies hoe je uiteindelijk een reverse shell naar Korea op je inferentieserver krijgt.

Runtime-monitoring: omdat statische scans niet genoeg zijn

Van de GGUF-templatekwetsbaarheid hebben we geleerd dat statisch scannen slechts een deel van het dreigingsoppervlak afvangt. Een model kan schoon zijn bij het laden en kwaadaardig tijdens de inferentie. Daarom hebben we continue runtime-monitoring toegevoegd: validatie van de output tegen schone baselines om drift te detecteren, query-throttling om modelextractie-aanvallen te voorkomen, en lagen voor input-sanitization die queries herformuleren voordat ze het kernmodel bereiken, waardoor zorgvuldig geconstrueerde adversarial payloads worden verstoord.

Voor de volledige technische architectuur — inclusief onze aanpak van confidential computing met hardware-ondersteunde Trusted Execution Environments — zie de technische verdieping in ons onderzoekspaper. Daar staat een niveau van implementatiedetail dat verder gaat dan wat ik in een essay kan behandelen.

De ongemakkelijke waarheid over "Deep AI" versus API-wrappers

Er is een reden waarom ik steeds terugkom op het onderscheid tussen wat ik "Deep AI" noem — zelf gehoste, gefinetunede, architectonisch beheerste AI-systemen — en de API-wrapperaanpak die de markt domineert. Het is niet louter een technische voorkeur. Het is een securityargument.

Wanneer je een wrapper om een publieke API bouwt, besteed je je AI-toeleveringsketen uit aan iemand anders. Je hebt geen zicht op de herkomst van hun modellen, hun trainingsdata, hun security posture. Je vertrouwt erop dat OpenAI of Anthropic of Google het zware werk van het beveiligen van hun pipeline heeft gedaan. Misschien is dat zo. Maar je kunt het niet verifiëren, en in security is vertrouwen zonder verificatie niets meer dan hoop.

Wanneer je diep bouwt — wanneer je de modelgewichten, de trainingspipeline en de inferentie-infrastructuur beheert — erf je de verantwoordelijkheid voor de hele toeleveringsketen. Dat is moeilijker. Het is duurder. Het vereist het soort engineeringdiscipline dat ik hier heb beschreven. Maar het is de enige weg naar verifieerbare security.

Een investeerder zei ooit tegen me: "Gebruik gewoon de API van GPT en focus op het product." Ik vertelde hem dat voor de sectoren die wij bedienen — waar een gecompromitteerd model kan betekenen dat financiële data uitlekt, medische diagnoses worden gemanipuleerd of juridische analyses worden gecorrumpeerd — "gebruik gewoon de API" een aansprakelijkheidsrisico is, geen strategie.

AI-security en softwaresecurity zijn nu hetzelfde probleem

Dit is het inzicht dat alles voor mij deed uitkristalliseren: AI-security en de security van de softwaretoeleveringsketen zijn geen aparte disciplines meer. Dat kunnen ze niet zijn. AI-modellen draaien niet geïsoleerd — ze worden gebouwd en uitgerold via dezelfde CI/CD-pipelines, containerregisters en afhankelijkheidsbomen die traditionele software gebruikt.

Als je model cryptografisch is ondertekend maar de Python-library waarvan het afhankelijk is via een aanval op de toeleveringsketen is gecompromitteerd, ben je alsnog gecompromitteerd. Als je trainingspipeline in een besmette container image draait, zijn je modelgewichten onbetrouwbaar, hoe schoon je trainingsdata ook is.

De sector blijft proberen aparte "AI-security"-teams en "applicatiesecurity"-teams op te richten. Die organisatorische scheiding is een kwetsbaarheid. Het aanvalsoppervlak is één geheel, en de verdediging moet dat ook zijn.

Nu AI-gegenereerde code de ontwikkelsnelheid opdrijft, bezwijkt het traditionele menselijke codereviewproces onder het volume. Grote, door AI gegenereerde pull requests zijn onder deadlinedruk moeilijk zorgvuldig te reviewen, wat een cultuur van "oppervlakkige review" creëert die een van de laatste human-in-the-loop-securitycontroles wegneemt. In deze omgeving is geautomatiseerde, deterministische verificatie — geworteld in cryptografische handtekeningen en ML-BOM's — niet optioneel. Het is het enige dat schaalt.

"Maar wij zijn geen doelwit"

Mensen komen altijd met een variant hierop terug. "We doen niets dat gevoelig genoeg is om dit niveau van security te rechtvaardigen." "Onze modellen zijn alleen voor interne tooling." "Niemand zou de moeite nemen om een model te vergiftigen om ons aan te vallen."

Ik hoorde in 2018 dezelfde argumenten over de security van open-sourcelibraries. Toen gebeurde SolarWinds. Toen gebeurde Log4Shell. Toen gebeurde de XZ Utils-backdoor — een meerjarige social-engineeringcampagne om één enkele compressielibrary te compromitteren die door SSH op elke Linux-server ter wereld wordt gebruikt.

De AI-toeleveringsketen volgt hetzelfde traject, alleen sneller. Het aanvalsoppervlak is groter (modelgewichten zijn ondoorzichtige binaire blobs die niet op dezelfde manier te auditen zijn als broncode), de tooling is minder volwassen (PickleScan heeft zero-days) en de governance-kloof is groter (83% van de ondernemingen heeft geen geautomatiseerde controles).

Je hoeft geen doelwit te zijn om slachtoffer te worden. Je hoeft alleen maar op het pad te staan.

Hoe saaie AI-security eruitziet

Mijn doel — en dit klinkt misschien vreemd — is om AI-uitrol saai te maken. Niet spannend, niet cutting-edge, geen "move fast and break things". Saai. Voorspelbaar. Auditeerbaar.

Saai betekent dat elk model een ML-BOM heeft. Saai betekent cryptografische handtekeningen die bij het laden worden geverifieerd. Saai betekent nooit meer pickle. Saai betekent runtime-monitoring die drift opmerkt voordat het een inbreuk wordt. Saai betekent een centraal AI-assetregister waarin elk model, elke dataset en elke afhankelijkheid wordt bijgehouden, gecontroleerd en onder versiebeheer gebracht.

Saai betekent dat wanneer iemand vraagt "welke AI-modellen draaien er in productie?" je binnen vijf minuten antwoord kunt geven, met cryptografisch bewijs.

Het doel is niet om AI-uitrol spannend te maken. Het doel is om het saai te maken — voorspelbaar, auditeerbaar en veilig. Spannende AI-security betekent dat er iets is misgegaan.

De 100+ kwaadaardige modellen op Hugging Face waren geen geïsoleerd incident. Ze waren een symptoom van een sector die ongelooflijke capaciteiten heeft gebouwd op een fundament van blind vertrouwen. We downloadden modellen zoals we vroeger mp3's van LimeWire downloadden — we hoopten op het beste, negeerden de voor de hand liggende risico's en deden verbaasd als er iets misging.

Dat tijdperk is voorbij. De organisaties die de volgende golf van aanvallen op de AI-toeleveringsketen overleven, zijn degenen die nú hebben besloten hun modellen niet als magische dozen te behandelen, maar als uitvoerbare code met het volledige aanvalsoppervlak dat dat impliceert. Degenen die saai boven snel kozen. Degenen die naar de terminal keken, het pickle-bestand zagen laden en zeiden: "Wacht. In welk formaat is dat?"