Je AI-toolchain is je nieuwe aanvalsoppervlak

Op 17 juni 2026, om 01:01 UTC, veranderde een populair stuk gereedschap voor AI-agenten in een wapen. Een aanvaller had het npm-account van een Mastra-beheerder overgenomen en in ruim 140 pakketten stilletjes een nieuwe afhankelijkheid bijgeschreven: easy-day-js, een pakket dat zich voordeed als de bekende dayjs-bibliotheek. Wie die nacht zijn AI-project bijwerkte, draaide een postinstall-script dat de TLS-certificaatcontrole uitzette, je browserextensies aftastte op 166 bekende cryptowallets en zich vastzette op Windows, macOS en Linux. Geen exotische zero-day. Gewoon een update.

Dat is geen los incident, het is een patroon. En dat patroon is mijn stelling: je AI-stack vergroot je aanvalsoppervlak sneller dan je het beveiligt. Wie open-source frameworks, IDE-plugins of een zelfgehoste gateway gebruikt zonder bewust supply chain beleid, loopt op dit moment al actief risico, of je nu zelf software bouwt of alleen een paar AI-tools draait.

Het aanvalspad is verschoven van jouw code naar jouw gereedschap

Jarenlang ging beveiliging over jouw applicatie: je firewall, je inlogpagina, de code die jij schreef. De aanvaller is verhuisd. Niet naar wat jij maakt, maar naar wat jij vertrouwt en automatisch binnenhaalt. De Mastra-aanval is het schoolvoorbeeld. Het ging niet om een lek in Mastra zelf, maar om een vergiftiging van ruim 140 npm-pakketten voor AI-agenten met een credential-steler via een overgenomen beheerdersaccount. Microsoft Threat Intelligence schreef de campagne toe aan Sapphire Sleet, een Noord-Koreaanse staatsacteur die zich op de financiële sector richt. De legitieme dayjs-bibliotheek waar het zich voor uitgaf, wordt ruim 57 miljoen keer per week gedownload. Dat is de schaal waarop één gekaapt account opereert.

Een week eerder was het je editor. Onderzoekers vonden vijftien valse JetBrains-plugins die AI-API-sleutels van ontwikkelaars stelen, gepubliceerd onder zeven verkopersaccounts en vermomd als AI-codeassistenten en Git-hulpjes. Ze deden precies wat ze beloofden, en stuurden ondertussen je sleutel voor OpenAI, DeepSeek of SiliconFlow naar een vaste server. Bij elkaar haalden deze plugins bijna 70.000 installaties op, met zelfs een betaalde laag die de gestolen sleutels doorverkocht. De twee populairste, een nep-DeepSeek- en een nep-CodeGPT-assistent, stonden samen voor meer dan 53.000 downloads.

Elke laag van je AI-stack is nu een aanvalspad

Het aanvalsoppervlak is de optelsom van alle plekken waar een buitenstaander je systeem kan binnenkomen. Bij een AI-stack groeit dat oppervlak met elke laag die je toevoegt, en bijna elke laag bestaat uit code van een ander die je op vertrouwen binnenhaalt. De recente aanvallen vallen niet toevallig samen: ze raken elk een andere laag van dezelfde keten.

• Afhankelijkheden (npm, PyPI): de pakketten en frameworks waarop je agenten draaien. Mastra liet zien dat één gekaapt account er honderden tegelijk vergiftigt.
• IDE-plugins en extensies: het gereedschap in je editor, met toegang tot je sleutels en je bestandssysteem. De JetBrains-campagne oogstte sleutels recht uit het instellingenscherm.
• Zelfgehoste gateways en frameworks: de laag die je AI-verkeer routeert. Denk aan een kritieke Langflow-kwetsbaarheid die al actief wordt misbruikt, of aan drie LiteLLM-lekken waarmee een gewone gebruiker adminrechten en code-uitvoering op je AI-gateway krijgt.
• De agent zelf: een AI-agent met brede rechten is een aanvalspad met benen, want hij mag uit zichzelf API's aanroepen, bestanden lezen en acties uitvoeren.

Wat opvalt is hoe gewoon het allemaal is. Geen van deze aanvallen brak door een muur. Ze reden mee op je normale update, je normale plugin-installatie, je normale standaardconfiguratie.

Waarom dit anders is dan gewone software-security

Supply chain-aanvallen zijn niet nieuw. Wat nieuw is, is de combinatie van snelheid en buit. AI-gereedschap wordt sneller geadopteerd dan welke softwaregolf ervoor, vaak rechtstreeks vanuit een vers, snel bewegend open-source-ecosysteem, en het zit boven op een nieuw soort secret van hoge waarde: je API-sleutels voor betaalde modellen. Een gestolen AI-sleutel is direct geld, want de aanvaller draait er zijn eigen verbruik op of verkoopt hem door.

De achtergrond is veelzeggend. Sinds 2019 zijn er ruim 704.000 kwaadaardige open-source-pakketten ontdekt, en het aantal aanvallen in de software-toeleveringsketen verdubbelde opnieuw in 2024. Uit datzelfde onderzoek blijkt iets ongemakkelijks over ons gedrag: van de gedownloade kwetsbare componenten had bijna 95 procent al een veilige versie beschikbaar. We halen vaak willens en wetens de lekke versie binnen, niet omdat de fix ontbreekt, maar omdat niemand het beheer voert. Dat is geen technologieprobleem. Dat is een beleidsprobleem.

"Dan gebruik ik toch gewoon een gesloten SaaS-tool?"

De sterkste tegenwerping die ik krijg: dit overkomt alleen mensen die zelf bouwen met open source, dus mijd het en koop een dichtgetimmerde clouddienst. Was het maar zo simpel. Een gesloten SaaS-leverancier heeft precies dezelfde toeleveringsketen, alleen zie jij hem niet. Zijn npm-pakketten, zijn plugins, zijn gateways: jij erft het risico zonder het overzicht, en als hij wordt geraakt sta jij met lege handen bij iemand anders' incident. Je hebt het probleem niet opgelost, je hebt het uitbesteed aan een partij die je niet kunt controleren, met een vendor lock-in als toegift.

Het eerlijke antwoord is niet "mijd open source", want dan mijd je zo'n beetje alle moderne software. Het antwoord is beheer voeren. En het mooie is dat het ecosysteem zelf die kant op beweegt: zo is er inmiddels een coalitie die met AI open-source-lekken probeert te vinden vóór de aanvallers dat doen. Verdediging schaalt mee, mits je meedoet.

Verdediging is een ontwerpkeuze, geen aankoop

Hier ligt de kern van mijn stelling. Je kunt geen product kopen dat "supply chain-veiligheid" heet en daarmee klaar zijn. Veiligheid in je AI-stack is een serie ontwerpkeuzes die je vooraf maakt: welke pakketten vertrouw je en pin je vast, welke plugins laat je toe, hoe geef je een sleutel zo min mogelijk rechten, en hoe isoleer je een gateway zodat één lek niet je hele omgeving meeneemt. Dat zijn keuzes, geen aanschaf. De praktische invulling, van vastpinnen tot rechten beperken, werk ik uit in hoe je een zelfgehoste AI-gateway van standaardinstellingen naar productie-veilig hardent. Maar de stap daarvoor, de keuze om dat überhaupt te ontwerpen in plaats van te hopen, kan geen tool voor je maken.

De oncomfortabele waarheid is dat je AI-toolchain net zo veilig is als de zwakste schakel die je nooit hebt bekeken. Elke afhankelijkheid die je toevoegt zonder erbij na te denken, is een sleutel die je aan een vreemde geeft in de hoop dat hij betrouwbaar blijft. De aanvallers van deze maand rekenden er precies op dat niemand die hoop ooit tot beleid maakt. Dat ombuigen begint niet bij een nieuw product, maar bij de eenvoudige beslissing om je gereedschap net zo serieus te nemen als je eigen code.