Je AI-modellen zijn uitvoerbare code. De meeste bedrijven behandelen ze als spreadsheets.

De eerste keer dat ik het probleem echt begreep, keek ik naar een syscall-trace die voorbijschoof in een geïsoleerde container en wachtte ik tot die niets zou doen.

We hadden een model van een openbaar register gehaald — het soort dat een datawetenschapper honderd keer per kwartaal downloadt zonder erbij na te denken. De modelkaart zag er normaal uit. Het had een basisscan doorstaan. Ik had het in een sandbox geladen, niet omdat ik dat specifieke bestand verdacht vond, maar omdat ik was begonnen met het laden van alles in een sandbox. En terwijl de deserialisatie liep, toonde de trace dat het proces een netwerkverbinding probeerde te openen die het helemaal niet hoorde te openen.

Dat is de hele stelling van beveiliging van de AI-toeleveringsketen in één moment: je modellen zijn geen gegevensbestanden. Het is uitvoerbare code die draait op het moment dat je ze laadt. De meeste organisaties behandelen ze als spreadsheets — inerte dingen die je downloadt en opent — en die kloof tussen wat een model is en hoe het wordt behandeld is precies waar de inbreuken plaatsvinden.

Een model is geen document dat je opent. Het is een programma dat je uitvoert met de rechten van degene die het heeft uitgevoerd.

Het reverse-shell-verhaal is niet eens hypothetische folklore uit de sector. Van een model genaamd "baller423" op Hugging Face werd ontdekt dat het een reverse shell naar een externe host opzette. Het zag er normaal uit. Het doorstond basisscans. Het voerde willekeurige code uit op het moment dat iemand het laadde. Wanneer ik dat verhaal vertel aan een zaal vol beveiligingsleiders, is het ongemak niet dat zoiets mogelijk is — het is dat ze beseffen dat hun team al twee jaar lang modellen uit dezelfde bron, op dezelfde manier, laadt.

Het pickle-probleem waar niemand over wil horen

Hier is het deel waar doorgewinterde engineers van huiveren, want het is geen bug die iemand kan patchen.

Wanneer je torch.load() aanroept op een PyTorch-model, kan het willekeurige Python uitvoeren tijdens de deserialisatie. Dat is geen kwetsbaarheid in de gebruikelijke zin. Het is het ontworpen gedrag van Python's pickle-serialisatieformaat — pickle mag objecten reconstrueren door code uit te voeren, en een modelbestand is gewoon een gepickled object. Meer dan 80% van de machine-learningmodellen in het wild gebruikt dit formaat. Dus de standaardmanier waarop het hele vakgebied modellen distribueert, is ook een primitief voor uitvoering van externe code dat wacht tot iemand het invult.

De reflex, begrijpelijk, is om ernaar te scannen. De meest ingezette verdediging is een tool genaamd PickleScan, die zoekt naar bekende kwaadaardige patronen in modelbestanden. En PickleScan heeft minstens drie bekende zero-day-omzeilingen — CVE-2025-10155 daaronder — waarbij onderzoekers van Sonatype later nog vier kwetsbaarheden in de scanner zelf vonden.

Ik zeg dat niet om af te geven op een opensourceproject dat echt werk verzet. Ik zeg het omdat het me een principe leerde waar ik nu alles omheen bouw: wanneer de aanvaller het bestandsformaat beheerst, verliest blacklistscanning structureel. Statisch scannen vraagt "bevat dit bestand een patroon waarvan ik al weet dat het slecht is?" De aanvaller, die dezelfde blacklist kan zien als jij, gebruikt simpelweg een patroon dat je nog niet kent.

Dus stopten we met die vraag te stellen. De keuringspijplijnen die mijn team bouwt, beginnen niet met "welke bekende kwaadaardige strings zitten er in dit bestand." Ze beginnen met gedragsmatige sandboxing: laad het model in een geïsoleerde container, kijk wat het daadwerkelijk doet — de syscalls, de netwerkpogingen, de schrijfacties naar bestanden — en beoordeel het gedrag, niet de signatuur. De vraag verschuift van "staat dit op een lijst" naar "wat doet deze code wanneer die draait." Die tweede vraag is de enige die de aanval opvangt die nog niemand een naam heeft gegeven.

Statisch scannen vangt de aanval van gisteren op. Gedragsmatige sandboxing vangt degene op die de aanvaller op dit moment aan het schrijven is.

Het is niet gratis, en het is geen product dat je kant-en-klaar koopt. Protect AI, nu onderdeel van Palo Alto Networks na een overname van ongeveer $500–700M die in juli 2025 werd afgerond, scande 4,47 miljoen modelversies en vond 352.000 onveilige of verdachte problemen verspreid over meer dan 51.700 modellen. Dat is de omvang van de hooiberg. Tools kunnen het voor de hand liggende signaleren. Het ontwerpen van de poort die tussen een openbaar register en je interne modelopslag staat — en die snel genoeg maken dat niemand eromheen gaat — is het deel dat niet in een doosje komt.

De poort die ik bouwde en die iedereen negeerde

Ik wil je vertellen over de versie hiervan die ik verkeerd deed, want de mislukking leerde me meer dan het succes.

In het begin bouwde ik voor een klant een modelkeuringspoort die, technisch gezien, uitstekend was. Elk model dat uit een openbare bron binnenkwam, werd de sandbox in getrokken, grondig geanalyseerd over formaten heen, gedragsmatig geprofileerd, en pas daarna ondertekend en toegelaten tot het interne register. Bij een beveiligingsevaluatie zou het prachtig hebben gescoord. Ik was er trots op.

Binnen ongeveer een week was het datawetenschapsteam er stilletjes mee gestopt.

Niet uit kwaadwilligheid. Ze hadden deadlines. De poort voegde echte minuten toe aan een workflow waar het alternatief — een model rechtstreeks van Hugging Face halen — dertig seconden kostte. Dus wanneer een experiment een model nu nodig had, haalden ze het rauw binnen op een persoonlijk cloudaccount en gingen door. Mijn prachtige poort beschermde een lege deuropening terwijl het echte verkeer om de zijkant van het gebouw heen liep.

Die week zette het hele probleem voor mij in een ander licht. De moeilijkste beheersmaatregel in de beveiliging van de AI-toeleveringsketen is niet technisch. Het is dat een beveiligingspoort die trager is dan het onveilige pad, elke keer weer zal verliezen. Wanneer een datawetenschapper een model in dertig seconden kan downloaden, wordt elk proces dat dertig minuten duurt omzeild — niet door kwaadwillenden, maar door goede engineers onder druk. De beheersmaatregelen moeten snel genoeg zijn dat naleving makkelijker is dan omzeiling. Zo niet, dan heb je geen beveiligingsprogramma. Dan heb je een beveiligingstheater met geweldige recensies en geen publiek.

Daarom verbaasden de cijfers over schaduw-AI me daarna nooit. 98% van de organisaties heeft medewerkers die niet-goedgekeurde AI-tools gebruiken. 62% van de beveiligingsprofessionals zegt dat ze geen betrouwbare manier hebben om te bepalen waar grote taalmodellen überhaupt in hun omgeving draaien. Slechts ongeveer 9% van de ondernemingen heeft een werkend AI-governancesysteem, ook al zal een derde van de bestuurders je vertellen dat ze uitgebreide tracking hebben. En de kosten zijn niet abstract: IBM's rapport Cost of a Data Breach 2025 stelt de gemiddelde schaduw-AI-gerelateerde inbreuk op $4,63 miljoen — ongeveer $670.000 meer dan een standaardincident.

Je kunt niet beveiligen wat je niet kunt zien, en op dit moment kunnen de meeste organisaties het grootste deel van hun AI niet zien.

Waarom ontwapent fine-tuning stilletjes je veiligste model?

Dit is degene die de sterkste reactie oproept wanneer ik het bij een technisch team inbreng, want het spreekt iets tegen dat iedereen aanneemt.

De aanname is: ik heb dit model op veiligheid geëvalueerd, het slaagde, dus is het veilig. De realiteit is dat veiligheidsafstemming kwetsbaar is op een manier die de evaluatietijdlijn volledig mist. In één onderzoek daalde de weerbaarheid van Llama 3.1 8B tegen prompt-injectie van een score van 0,95 naar 0,15 na één enkele ronde fine-tuning — en geen vijandige fine-tuning. Normale, goedaardige, domeinspecifieke training. Dat is ongeveer een instorting van 84% in een veiligheidseigenschap, veroorzaakt door het meest alledaagse dat een bedrijf met een model doet.

Ik had precies deze discussie met het ML-team van een klant. Ze hadden hun veiligheidsevaluatie uitgevoerd, het model slaagde, ze fine-tunden het op hun eigen data, en ze waren klaar om te lanceren. Ik vroeg wanneer ze de evaluatie opnieuw wilden uitvoeren. Het werd wat stil in de kamer, want het eerlijke antwoord was "dat waren we niet van plan." Het model doorstaat de poort vóór datgene wat het kapotmaakt. Daarna gaat het in productie met zijn guardrails feitelijk gestript, en het papierwerk zegt overal dat het veilig is.

Het model doorstaat zijn veiligheidscontrole vóór de stap die de veiligheid vernietigt. Bijna niemand controleert daarna opnieuw.

Dus verplaatsten we de veiligheidsevaluatie naar na de fine-tuning, maakten er een release-poort van in plaats van een intake-poort, en behandelden elke fine-tune als een gebeurtenis die de eerdere veiligheidsattestatie ongeldig maakt. Het klinkt bijna te vanzelfsprekend zodra je het hardop zegt. De reden dat het geen standaardpraktijk is, is dezelfde reden als de poort die niemand gebruikte: het handige moment om te evalueren is bij de intake, en opnieuw evalueren na elke fine-tune is wrijving. Wrijving is de vijand, maar in dit geval is het het enige dat tussen een geslaagd rapport en een weerloos model in staat.

Vergiftiging maakt hetzelfde punt vanuit de andere richting. Onderzoek heeft aangetoond dat al 250 vergiftigde documenten een achterdeur kunnen inbouwen in een model met 13 miljard parameters — ongeveer 0,00016% van het trainingscorpus. Je hoeft de data niet op grote schaal te compromitteren. Je hebt er een afrondingsfout aan nodig. Microsoft publiceerde in februari 2026 een oprecht bemoedigend tegenwicht hiervoor — een detectiemethode voor "slapende agenten" die een vergiftigd model kan identificeren zonder de triggerzin te kennen, door een kenmerkend aandachtspatroon op te sporen. Dat is de eerste echte verdediging die ik heb gezien tegen een aanval die voorheen bijna niet te detecteren was. Het is ook precies het soort capaciteit dat in een onderzoekspaper leeft, niet in je CI/CD-pijplijn, totdat iemand het engineeringwerk doet om het daar te krijgen.

Agents veranderden een prompt-injectie in een kill chain

Jarenlang was het ergste geval bij een gemanipuleerd model of een prompt-injectie een slechte output. Het model zegt iets verkeerds, lekt iets wat niet zou moeten, zet je voor schut. Begrensd. Vervelend. Te overleven.

Agentic AI verwijderde de grens.

Een AI-agent heeft toolgang, inloggegevens en uitvoeringsrechten die een chatmodel niet heeft. Dus wanneer je een kwaadaardige instructie injecteert in iets wat een agent leest, corrumpeer je niet langer een antwoord — je geeft een commando aan een systeem dat kan handelen. GitHub Copilot had een kwetsbaarheid voor uitvoering van externe code, CVE-2025-53773, beoordeeld met CVSS 7.8 en gepatcht in augustus 2025, waarbij een prompt-injectie geplant in de documentatie van een repository de agent in zijn autonome "YOLO-modus" kon laten schieten en kon escaleren tot volledige systeemcompromittering. De agent las een kwaadaardige opmerking, voerde die uit als code, en de machine was overgenomen.

Dan was er het Amazon Q-toeleveringsketenincident in juli 2025: een kwaadaardig cleaner.md prompt-sjabloon werd geïnjecteerd via een verkeerd geconfigureerd GitHub-token, en een uitgebrachte versie verstuurde destructieve commando's naar een zeer grote installatiebasis. En in 2026 werd het OpenClaw-agentecosysteem de eerste grote AI-agentbeveiligingscrisis van het jaar — 138 CVE's in 63 dagen, meer dan 135.000 blootgestelde instanties, en 12% van de skills in de marktplaats bleek kwaadaardig. HiddenLayer's dreigingsrapportage van 2026 koppelt nu ruwweg één op de acht AI-inbreuken aan agentische systemen.

De rode draad door al deze gevallen is dezelfde: agents zetten één enkele gemanipuleerde invoer om in een georkestreerde kill chain met meerdere tools. Wat vroeger één verkeerde zin was, wordt een reeks echte acties met echte inloggegevens. Dat is de grens waar ik me op dit moment het meest zorgen over maak, want die breidt zich sneller uit dan welke productcategorie ook kan bijbenen, en er is nog geen gevestigd draaiboek om die te beveiligen.

Dus wat doe je er eigenlijk aan?

Mensen vragen me altijd een variant van: "Kan ik hier niet gewoon een tool voor kopen?" En het eerlijke antwoord is dat je onderdelen kunt kopen, en de onderdelen worden snel beter.

Het leverancierslandschap is uitgegroeid tot een echt ecosysteem — Palo Alto's Protect AI en Wiz voor scanning en het genereren van AI-bill-of-materials binnen hun cloud- en platformsuites, JFrog voor het beveiligen van het modelregister en de artefactpijplijn, HiddenLayer voor detectie en respons tijdens runtime, NVIDIA's opensource-guardrails voor LLM-controles op applicatieniveau, Fortanix dat confidential computing naar modeldistributie brengt. Dat laatste is een goed voorbeeld van waarom tools alleen de kloof niet dichten: confidential GPU's die een model versleuteld houden zelfs terwijl het draait (NVIDIA's Hopper- en Blackwell-generaties) bestaan echt, maar het inbouwen van die trusted execution environments in een live inferentiepijplijn is gespecialiseerd engineeringwerk dat de meeste teams simpelweg niet in dienst hebben. Elke leverancier is oprecht goed in zijn segment. Geen van hen ontwerpt je end-to-end-pijplijn, koppelt die aan je verplichtingen, of verandert hoe je organisatie zich daadwerkelijk gedraagt.

En de andere helft van de markt — de grote strategiebureaus — verkoopt je het tegenovergestelde probleem: een AI-governanceraamwerk van 200 pagina's, een bestuurspresentatie, auditklare documentatie, en een opdracht die begint rond $500K voor strategie en oploopt tot in de miljoenen voor implementatie. Wat ze doorgaans niet doen, is de modelondertekeningspijplijn bouwen, het genereren van de ML-BOM in je CI/CD configureren, of de schaduw-AI-detectie op netwerkniveau opzetten. Je houdt de map over en niet de bouw.

Die kloof — tussen tools die scannen en presentaties die adviseren — is de hele reden dat Veriprajna beveiliging van de AI-toeleveringsketen als engineering doet in plaats van als een rapport. Wat wij bouwen is concreet: geautomatiseerde modelkeuringspijplijnen die elk binnenkomend model gedragsmatig sandboxen en de schone modellen ondertekenen met je enterprise-PKI; een ML-BOM — een machine-learning bill of materials, het AI-equivalent van een ingrediëntenetiket dat elk component en zijn herkomst bijhoudt — gegenereerd en vastgezet binnen de pijplijn met behulp van de CycloneDX-standaard; herkomst en ondertekening gebouwd op het opkomende CoSAI-attestatiewerk; veiligheidscontrole na fine-tuning; en schaduw-AI-detectie die de modellen aan het licht brengt die je beveiligingstools op dit moment niet kunnen zien.

De standaarden om het meeste hiervan te doen bestaan al. CycloneDX ML-BOM, CoSAI-modelondertekening, en NIST's bijgewerkte taxonomie voor vijandige ML (AI 100-2) zijn allemaal gepubliceerd en vandaag bruikbaar. Het probleem was nooit een kennisprobleem. Volgens de meting van Kiteworks uit 2025 missen 83% van de organisaties nog steeds geautomatiseerde AI-beveiligingsmaatregelen — ze vliegen blind, niet omdat het draaiboek ontbreekt, maar omdat niemand de engineeringcapaciteit heeft om het te implementeren. De kloof is handen, niet ideeën.

Hier zit ook een regelgevende klok op. De EU AI Act wordt volledig van toepassing op 2 augustus 2026, en voor systemen met een hoog risico vereist die echte technische documentatie — herkomst van trainingsdata, conformiteitsbeoordeling, het soort toeleveringsketenattestatie dat een ML-BOM is gebouwd om te produceren. Importeurs en distributeurs van AI-componenten zullen moeten verifiëren wat ze stroomafwaarts doorgeven, en aanbieders en hun externe componentleveranciers moeten schriftelijk overeenkomen welke informatie en technische toegang elk zal delen. Ik ben klanten het stille deel van die bepaling gaan vertellen: zodra de Act begint te bijten, houdt modelherkomst op alleen jouw probleem te zijn om op te vangen — je leveranciers moeten het schriftelijk attesteren, en degenen die dat niet kunnen, zullen simpelweg onbruikbaar worden. De bedrijven die modelherkomst als een nice-to-have behandelen, zullen ontdekken dat het een verplichte indiening is.

De slide die het budget daadwerkelijk in beweging bracht

Ik eindig waar deze gesprekken meestal eindigen: voor een raad van bestuur.

Ik heb veel goed opgebouwde beveiligingsvoorstellen zien mislukken om gefinancierd te worden omdat ze werden gepresenteerd als beveiligingsvoorstellen — abstract risico, hypothetische aanvallers, een categorie die klinkt als verzekering. De presentatie die wél werkte, was degene die één enkel getal op tafel legde: de gemiddelde kosten van $4,63 miljoen voor een schaduw-AI-inbreuk, afgezet tegen de kosten van het bouwen van de beheersmaatregelen die het voorkomen. Geen angst. Een verschil. Hier is het gekwantificeerde risico, hier is wat het dichten ervan kost, hier is het verschil.

Die framing werkt omdat ze trouw is aan hoe dit probleem zich daadwerkelijk gedraagt. De dreiging is niet exotisch. Het is de standaardworkflow — haal een model op, fine-tune het, implementeer het, kijk nooit meer om — die draait bij elke organisatie die met AI bouwt, wat nu vrijwel allemaal is. CISO-budgetten weerspiegelen het: ongeveer 85% van de organisaties verhoogde hun uitgaven aan cyberbeveiliging in aanloop naar 2026, en AI-beveiliging is de meest besproken begrotingspost.

Een model is het ene artefact in je omgeving dat tegelijkertijd het meest waardevolle is wat je hebt en een stuk niet-geverifieerde uitvoerbare code dat je hebt gedownload van een vreemde op het internet. Totdat je het als beide tegelijk behandelt — keur het als code, volg het als een toeleveringsketen, en controleer het opnieuw elke keer dat je het wijzigt — controleert het rapport dat zegt dat je veilig bent een beheersmaatregel die niemand daadwerkelijk gebruikt. Als je nadenkt over waar te beginnen, begin daar: stop met de modelkaart te vertrouwen, en kijk wat het model doet wanneer het draait.