Geef zestien code-modellen een half miljoen programmeeropdrachten, en bijna een op de vijf pakketten die ze voorstellen bestaat niet. Ruim 205.000 verzonnen namen, netjes met de juiste import-regel eromheen, klaar om te installeren. Onderzoekers van Virginia Tech en de universiteiten van Oklahoma en Texas telden ze in 2025 op.
Dat klinkt als een kwaliteitsprobleem. Iets dat vanzelf slijt zodra de modellen beter worden. Precies dat idee is gevaarlijk.
Want die verzonnen namen zijn geen willekeurige ruis. Ze zijn stabiel, ze komen terug, en een aanvaller die zo'n naam vóór jou registreert verandert je codeerassistent in zijn bezorgkanaal. Dat is slopsquatting, en het is geen rafelrandje van AI-hallucinatie. Het is een structureel aanvalskanaal. "Het model wordt wel beter" verdedigt je daar nergens tegen, want de aanvaller hoeft alleen te wachten tot het model één keer, voorspelbaar, een naam noemt die hij al bezit.
Het voorspelbare is het wapen, niet het foutpercentage
De reflex is naar dat percentage te kijken. Een op de vijf, dat breng je toch omlaag met een betere lichting modellen? Maar het getal dat telt is niet hoe vaak een model iets verzint, het is hoe voorspelbaar het dat doet.
Dat is de onprettige uitkomst van het onderzoek: geef je dezelfde opdracht nog eens, dan keert meer dan de helft van de verzonnen pakketnamen gewoon terug. Het zijn geen losse verschrijvingen maar stabiele patronen. Een aanvaller hoeft de hallucinatie niet te forceren, hij hoeft haar één keer te vinden, de naam vast te leggen en te wachten.
Bij repositories is het nog kaler. De geteste codeertools plakken de naam van een repository standaard als eigenaar vóór diezelfde naam, in de vorm naam/naam. Een aanvaller hoeft het model daarvoor niet eens te bevragen: hij tekent de lijst met te kapen adressen vooraf uit. Palo Alto's onderzoekers deden datzelfde met webdomeinen en vonden ruim 250.000 niet-geregistreerde, gehallucineerde domeinen die klaarlagen om te claimen, soms weken voordat een aanvaller er eentje kwam vastleggen.
Voorspelbaarheid is normaal een deugd van software. Hier is het de kwetsbaarheid. Niet hoe vaak een model zich vergist bepaalt je risico, maar hoe betrouwbaar het dezelfde fout maakt: een codeermodel dat stabiele, herhaalbare namen verzint, levert een aanvaller een boodschappenlijstje. Een beter model verkleint de kans, maar sluit het gat niet, want hij heeft aan één voorspelbare misser genoeg.
Een verzonnen citaat lees je, een verzonnen pakket draait
Er is een geruststellend soort hallucinatie: de AI die een bron verzint in een rapport, een bedrag dat niet klopt, een casus die nooit bestond. Vervelend, maar een mens leest mee en vangt het op. Dat hallucineren geen storing is maar hoe een taalmodel werkt, verandert daar niets aan zolang er een mens tussen zit die de uitvoer nog leest.
Bij een codeeragent zit die mens er niet meer tussen. Vraag je hem een populaire nieuwe repository te klonen, dan wijst hij tot 85 procent van de keren naar de verkeerde plek, en bij trending skills bijna altijd. Zit op die plek een door een aanvaller geclaimde variant, dan haalt de agent die code binnen en voert een tool met terminalrechten haar uit, zonder tussenstap. Van één verzonnen naam naar een reverse shell, en van duizend losse installaties naar een botnet voor cryptomining of ransomware.
De kern is niet het model maar de autonomie eromheen. Een agent die zelf code ophaalt en draait, vergroot je aanvalsoppervlak sneller dan je het dichtzet. Omdat diezelfde agent je code leest en dus ook je secrets in beeld heeft, is het buitmaken van tokens en sleutels precies wat zo'n eerste payload probeert.
Het model faalt het hardst waar het het meest telt
Blijft de vraag of dit niet gewoon wegtrekt als de modellen slimmer worden. Nee, en het onderzoek laat precies zien waarom niet. Repositories van vóór 2019 lost een model prima op, met een foutpercentage van rond een procent. Voor code uit 2025 schiet dat richting 92 procent. Het model is op zijn slechtst precies daar waar ontwikkelaars het meest grijpen: verse, populaire, veel gedownloade bronnen die nog niet in de trainingsdata zaten.
Dat gat sluit zich niet vanzelf, het schuift mee. Er is altijd een nieuwste lichting pakketten en repositories die het model nog niet heeft gezien, en juist die trekt de meeste downloads en dus de meeste aandacht van aanvallers. Een model van volgend jaar kent de code van dit jaar, maar staat opnieuw met lege handen bij de code van volgend jaar. Beter model, hetzelfde structurele gat.
Om eerlijk te zijn: de modellen worden echt beter
Dat scheelt ook echt. Welk model je kiest maakt uit: de zuinigste commerciële modellen verzinnen zo'n 5 procent van de pakketten, tegen ruim 20 procent voor sommige open modellen, en de beste zat in de test rond de 3,5 procent. Registers grijpen sneller in, de besmette AsyncAPI-pakketten stonden vorige week iets meer dan vier uur online voordat npm ze verwijderde. En er zijn echte verdedigingen: versies vastpinnen, een wachttijd op nieuwe pakketten, handtekeningen controleren.
Dat is een serieus argument. Toch klopt de geruststelling niet, om één reden: de asymmetrie. Jij moet de hallucinatie op nul houden, overal, altijd. De aanvaller heeft er één nodig, één keer, op een naam die hij kon voorspellen. 3,5 procent van een half miljoen pakketten zijn nog altijd tienduizenden bruikbare namen.
De controles die zo solide klinken, vechten bovendien deels de verkeerde strijd. Bij AsyncAPI kaapte de aanvaller de eigen release-pijplijn van het project, zodat de kwaadaardige versies geldige provenance meekregen en er als echte releases uitzagen. Een handtekening bewijst wie iets publiceerde, niet dat je het had moeten vertrouwen. Een vers geregistreerd, gehallucineerd pakket heeft, waarschuwen beveiligingsonderzoekers, geen verleden waarin een scanner iets verdachts kan vinden.
De verdediging die wél werkt, staat niet in de release-notes van je modelleverancier maar in je eigen pijplijn. In mijn eigen builds is dat het uitgangspunt: geen agent haalt iets op of voert iets uit zonder dat eerst is gecontroleerd dat de bron bestaat en de juiste is. Pin je afhankelijkheden en leg een wachttijd op nieuwe versies. Houd secrets en productiesleutels uit de shell waarin de agent werkt, en draai die agent in een omgeving die je zonder spijt kunt weggooien. Dat is geen wachten op een beter model. Dat is stoppen een verzonnen naam als feit te behandelen.
Waar een verzonnen naam een commando wordt
Het geruststellende verhaal is dat hallucinatie een rafelrand is die met elke modelgeneratie gladder wordt. Voor een verzonnen bronvermelding in een rapport klopt dat half. Voor je software-toeleveringsketen niet. Een aanvaller heeft niet nodig dat het model slecht is, hij heeft nodig dat het zelfverzekerd en voorspelbaar de naam noemt die hij al bezit.
Zolang een gegenereerde naam rechtstreeks een kloon of een installatie in rolt zonder controle ertussen, is de nauwkeurigheidscurve van het model niet je verdediging. De vraag is niet of het model al nauwkeurig genoeg is. De vraag is waar in jouw pijplijn een verzonnen naam een uitgevoerd commando wordt. Dat is een plek die alleen jij kunt dichtzetten.
Veelgestelde vragen
AI-agents die eerst controleren
Zet je AI-agents in je ontwikkel- of bedrijfsproces? Ik denk mee, ontwerp en bouw ze end-to-end, met de controles ingebouwd: verifiëren voordat er iets wordt opgehaald of uitgevoerd, secrets buiten bereik en een omgeving die je veilig kunt weggooien.
Dit artikel is geproduceerd samen met het Agent Team. Meer over de redactie.
