Wat Is AI Supply Chain Security? Modellen, Packages en MCP Tools Beveiligen

De meeste teams beveiligen het model en negeren alles eromheen. Ze evalueren het veiligheidsrecord van een provider, stellen guardrails in en beveiligen het API-endpoint, terwijl het codepad dat daadwerkelijk naar dat endpoint leidt, draait op een verzameling packages van derden, SDK's en toolservers die niemand met dezelfde strengheid heeft beoordeeld. Die stack is de AI supply chain, en in 2026 is dat de plek waar de echte beveiligingsincidenten plaatsvonden.

Een supply-chain-aanval breekt niet je model. Het breekt iets waarvan de code van je model afhankelijk is, nog voordat je beveiligingsmaatregelen een request te zien krijgen. Een kwaadwillende packageversie wordt uitgevoerd tijdens pip install. Een gecompromitteerde SDK leest je omgevingsvariabelen uit op het moment van import. Een geïmpersoneerde MCP-server overhandigt je agent een gemanipuleerde toolbeschrijving. In elk geval krijgt de aanvaller de privileges van je applicatie, wat meestal betekent: de providerkeys, cloudcredentials en interne netwerktoegang die aan de applicatie zijn toegewezen om zijn werk te doen.

Dit artikel brengt de AI supply chain oppervlak voor oppervlak in kaart, gebruikt de goed gedocumenteerde openbare incidenten van 2026 als uitgangspunt, en beschrijft de mitigaties die de blast radius daadwerkelijk verkleinen — met als belangrijkste maatregel het centraliseren van providersecrets achter één beheerde laag in plaats van ze te verspreiden over elke service die een package installeert.

Wil je je providersecrets achter één geauditeerde gateway in plaats van in elke package-installatie? Boek een demo.

De AI supply chain, oppervlak voor oppervlak

"Supply chain" omvat elk extern onderdeel dat je applicatie vertrouwt om een inference te genereren. Er zijn vijf oppervlakken, en ze falen op verschillende manieren.

Model weights. De weights die je downloadt of fine-tunt. Risico: een gemanipuleerd checkpoint of een backdoored checkpoint, of een checkpoint waarvan je de herkomst niet kunt verifiëren, gedownload uit een openbare repository. Je vertrouwt erop dat het artifact is wat de naam beweert en dat het niet is gewijzigd tijdens transport of opslag.

Providers en hun API's. De gehoste model-endpoints die je aanroept. Risico: een gecompromitteerd provideraccount, een gelekte providerkey, of een dependency die de provider zelf meelevert. Je risico hier hangt grotendeels af van je credentials en hoe breed deze zijn verspreid.

SDK's en packages. De clientlibraries en hun transitieve dependencies die je installeert om modellen aan te roepen. Risico: een kwaadwillende versie gepubliceerd op een openbaar register, typosquatting, of een gekaapt maintaineraccount. Deze code draait met jouw privileges, vaak al tijdens installatie of import, voordat je eigen logica wordt uitgevoerd.

MCP-servers en tools. De Model Context Protocol-servers die tools beschikbaar stellen aan je agents. Risico: een kwaadwillende of geïmpersoneerde server, een gemanipuleerde toolbeschrijving, of een server die te veel gegevens verzamelt bij het maken van een verbinding. De agent vertrouwt de toolcatalogus die wordt aangeboden, en standaard verifieert niets waar die catalogus vandaan komt.

Prompts en prompt-templates. Gedeelde systeem-prompts, templates en prompt-libraries. Risico: een geïnjecteerde instructie in een gedeelde template, of een prompt die tijdens runtime van een niet-vertrouwde bron wordt opgehaald. Dit is een supply-chain-compromis op het instructieniveau in plaats van de codelaag.

De casus: de LiteLLM-package-incidenten van 2026

De duidelijkste illustratie van het belang van de package-laag is de reeks openbaar gerapporteerde incidenten rond LiteLLM, een veelgebruikte open-source LLM SDK, in 2026. Deze worden hier feitelijk weergegeven, zoals gemeld in openbare waarschuwingen, om de mechanica van een supply-chain-aanval op packages te verduidelijken. Het gaat niet om het specifieke project; elk package met veel dependencies is een doelwit, en de populariteit van LiteLLM maakte het juist een aantrekkelijk doelwit voor aanvallers.

Maart 2026: kwaadwillende versies op PyPI. Twee kwaadwillende releases, versies 1.82.7 en 1.82.8, werden gepubliceerd op de Python Package Index. De gerapporteerde oorzaak was een beveiligingslek in de continuous-integration pipeline van het project, specifiek een kwetsbaarheid in de Trivy-scanstap, die werd gebruikt om de PyPI-publicatiecredentials van de maintainer te stelen. Met die credentials publiceerde de aanvaller gemanipuleerde packages onder de legitieme projectnaam. De malware in die versies verzamelde omgevingsvariabelen, SSH-keys en cloudcredentials van elke machine waarop ze werden geïnstalleerd, en installeerde een backdoor. Opvallend is dat het officiële Docker-image van het project niet werd getroffen, omdat dit werd gebouwd en gedistribueerd via een pad dat de aanvaller niet beheerde. Deze uitkomst — wel gecompromitteerd op PyPI, schoon in de officiële container — is de les op zich: de inbreuk was specifiek gericht op de credentials van één distributiekanaal.

Oktober 2026: een kwaadwillende release via gestolen tokens. Een later incident betrof een kwaadwillende release, versie 1.107.0, die werd gepusht met gestolen GitHub-tokens. Deze bereikte zowel PyPI als de Docker-distributie, inclusief de latest- en main-latest-tags, waardoor teams die de nieuwste container ophaalden eveneens risico liepen als teams die vanaf PyPI installeerden. De vector was anders — gestolen broncode- en publicatietokens in plaats van een lek in een CI-scanner — maar het patroon was hetzelfde: legitieme credentials gebruikt om een illegaal artifact onder een vertrouwde naam te publiceren.

Gekoppelde CVE's. Los van de package-poisoning-incidenten had het project in dezelfde periode meerdere gerapporteerde kwetsbaarheden. Ten minste één was ernstig genoeg om te worden toegevoegd aan de US CISA Known Exploited Vulnerabilities (KEV)-catalogus, gerapporteerd als een probleem met remote code execution dat kon worden misbruikt door houders van een API-key. Een ander gerapporteerd probleem maakte het mogelijk een MCP-sessie te starten met een willekeurige bearer token, wat de authenticatiegrens op het toolpad verzwakte.

Samen tonen deze incidenten de volledige anatomie van het package-oppervlak: de code die je installeert kan worden gecompromitteerd via een lek in build- of publicatiecredentials, draait met jouw privileges, richt zich direct op je secrets, en afzonderlijke kwetsbaarheden in de code kunnen een aanvaller uitvoeringstoegang geven of authenticatie laten omzeilen, zelfs als het package zelf authentiek is.

Waarom de installatiestap zo gevaarlijk is

Een gecompromitteerd package is gevaarlijker dan de meeste applicatiewatfouten vanwege de timing en privileges. Package-installatie- en import-hooks worden uitgevoerd vóór je applicatielogica en met de rechten van de installatie-omgeving. In een typische AI-service bevat die omgeving precies wat een aanvaller zoekt: de provider-API-keys, cloudcredentials van de instantierol, SSH-keys en vaak tokens voor interne services. De kwaadwillende code hoeft geen kwetsbaarheid in je app te vinden. Het draait als jouw app, op het moment dat je app wordt gebouwd of gestart, en leest de secrets uit die aan je app zijn toevertrouwd.

Dit is waarom "waar je secrets zich bevinden" de belangrijkste architecturale beslissing is om schade te beperken.

Bekijk hoe TrueFoundry je AI supply-chain blast radius verkleint met gecentraliseerde secrets en audit. Boek een demo.

MCP-tools als supply-chain-vector

De package-laag is het bekende oppervlak. De MCP-laag is nieuw, maar heeft dezelfde structuur: je agent vertrouwt een externe component, en dat vertrouwen is standaard grotendeels ongeverifieerd.

Wanneer een agent verbinding maakt met een MCP-server, biedt de server een reeks tools aan, elk met een naam en een beschrijving in natuurlijke taal die het model vertelt wanneer en hoe het de tool moet gebruiken. Die beschrijving is instructiedata waarop het model reageert. Een kwaadwillende server kan deze manipuleren (tool poisoning): verborgen instructies toevoegen aan een toolbeschrijving die de agent opdragen om context te exfiltreren, een andere tool aan te roepen of een veiligheidsregel te negeren. De agent ziet niets verdachts, omdat het lezen en vertrouwen van toolbeschrijvingen is hoe MCP hoort te werken. Dit is tool poisoning, en het is een supply-chain-aanval op de instructielaag van de agent. We behandelen dit mechanisme gedetailleerd in MCP tool poisoning en gateway defence.

Impersonatie maakt het probleem groter. Er is geen ingebouwd vertrouwensanker dat bewijst dat een MCP-server de server is waarmee je verbinding wilde maken. Een server die de naam van een bekende service misbruikt, of die wordt bereikt via een verkeerd geconfigureerd endpoint, kan een legitieme toolprovider impersoneren en alle gegevens verzamelen die de agent stuurt. Het bredere overzicht van deze risico's — ongeverifieerde servers, te ruime toolpermissies en overmatige dataverzameling — wordt beschreven in MCP security: risico's en best practices en MCP server security best practices.

De mitigatie is vergelijkbaar met die van packages: laat agents niet rechtstreeks verbinding maken met willekeurige toolservers. Routeer tooltoegang via een MCP gateway die servers authenticeert, beheert welke tools bereikbaar zijn, uitgaand verkeer controleert en elke tool-call auditeert. Enterprise MCP governance zorgt ervoor dat de tool supply chain een goedgekeurd en gemonitord proces wordt, in plaats van iets wat elke agent zelfstandig ontdekt.

De vijf mitigaties die ertoe doen

De bovenstaande incidenten wijzen allemaal naar dezelfde korte lijst. Geen van deze maatregelen is exotisch; problemen ontstaan door ze over te slaan.

1. Pin exacte versies vast. Maak gebruik van litellm==1.82.6, niet van litellm>=1.82 of litellm zonder versie-pin. Een zwevend bereik betekent dat de volgende install stilzwijgend een versie kan ophalen die vijf minuten geleden is gepubliceerd door degene die de publicatiecredentials beheert. Festpinnen plus een lockfile zorgt ervoor dat een kwaadwillende nieuwe release je build niet binnenkomt voordat een mens de update heeft beoordeeld. In het geval van maart 2026 werden teams die versies onder de gecompromitteerde releases hadden vastgezet, hier niet automatisch door getroffen.

2. Verifieer de herkomst (provenance). Controleer of het artifact is wat het beweert te zijn: verifieer checksums, kies voor ondertekende artifacts en build-provenance attestations waar het ecosysteem dit ondersteunt, en kies voor distributiekanalen met strengere controles. De gesplitste uitkomst bij LiteLLM — PyPI gecompromitteerd, officiële Docker-image schoon — is een concreet argument om te kiezen voor een gehard distributiepad en te verifiëren wat je daarvan ophaalt.

3. Roteer secrets bij de minste verdenking. Als een geïnstalleerd package betrokken is bij een incident, neem dan aan dat elk secret dat in die omgeving leesbaar was, is gecompromitteerd: providerkeys, cloudcredentials, SSH-keys, servicetokens. Roteer ze. De snelheid van rotatie wordt beperkt door het aantal plekken waar elk secret aanwezig is, wat direct leidt tot de volgende twee punten.

4. Minimaliseer de blast radius. Geef elke component alleen de secrets en permissies die strikt noodzakelijk zijn, en houd de groep componenten die waardevolle secrets bevatten zo klein mogelijk. Een build runner die packages installeert, hoort niet ook je productie-providerkey te bevatten. Hoe minder omgevingen een secret kunnen lezen, hoe kleiner de impact als een dependency gecompromitteerd raakt.

5. Centraliseer providersecrets achter één beheerde gateway. Dit is de meest effectieve structurele verandering. In plaats van provider-API-keys te verspreiden over elke service die een client SDK installeert, bewaar je de keys in één gateway en laten applicaties de gateway aanroepen met hun eigen afgebakende credentials. De providerkeys bevinden zich dan op precies één geauditeerde laag. Een gecompromitteerde SDK in een applicatie-omgeving vindt alleen applicatie-specifieke credentials voor de gateway, niet de directe providerkeys, en de audit trail van de gateway toont precies wat er is aangeroepen. Dit is het model dat TrueFoundry gebruikt: providersecrets bevinden zich achter de AI gateway, toegang wordt beheerd via RBAC, SSO en SCIM, en elke request wordt gelabeld op gebruiker, team en model in een volledige audit trail.

Waar je providersecrets zich bevinden

De eenvoudigste manier om het nut hiervan in te zien, is door de twee architectuurdomeinen direct te vergelijken op de punten die van belang zijn tijdens een incident.

Deze tabel beweert niet dat een gateway het compromitteren van een package onmogelijk maakt. Het verduidelijkt wat er gebeurt na een incident: wanneer een dependency gecompromitteerd raakt, worden de hoeveelheid werk voor rotatie en de buit van de aanvaller bepaald door het aantal plekken waar je secrets zijn opgeslagen. Één plek is het doel.

Veelgemaakte fouten door teams

Het model beveiligen, de dependency tree negeren. Teams besteden weken aan guardrails en modelselectie, maar draaien op een niet-vastgepinde, niet-gecontroleerde dependency graph. De aanvaller hoeft je guardrails niet te omzeilen als een package je keys al leest tijdens de installatie.

De officiële container en het package-register als even betrouwbaar beschouwen. De incidenten in 2026 toonden aan dat dit gescheiden kanalen zijn met afzonderlijke credentials en verschillende uitkomsten. In maart waren de PyPI-releases gecompromitteerd en de officiële Docker-image niet; in oktober bereikte een release beide. Wees op de hoogte van het kanaal dat je gebruikt en verifieer elk kanaal afzonderlijk.

Providerkeys verspreiden over elke service. Het makkelijke patroon — de API-key toevoegen aan de omgeving van elke app — is ook het patroon dat de blast radius en de rotatie-inspanning maximaliseert. Elke kopie is een plek waar een gecompromitteerde dependency deze kan lezen en een plek die je moet onthouden om te roteren.

MCP-servers vertrouwen omdat ze reageren. Dat een server reageert op een endpoint bewijst niet dat het de server is die je wilde gebruiken, en een toolbeschrijving is instructiedata waarop het model zal reageren. Niet-geauthenticeerde, niet-beheerde toolverbindingen vormen een supply-chain-aanvalsoppervlak, geen gemak.

Langzaam of gedeeltelijk roteren. Na een vermoedelijke inbreuk is een secret dat op vier van de vijf plekken is geroteerd, niet geroteerd. De rotatiesnelheid en de volledigheid van de rotatie zijn het resultaat van je architectuur; ontwerp hiervoor vóór een incident, niet tijdens een incident.

Conclusie

De AI supply chain is groter dan het model alleen, en in 2026 is dit de plek waar aanvallers succes hadden. Een gecompromitteerd package draait met jouw privileges voordat je beveiligingsmaatregelen actief worden; een geïmpersoneerde MCP-server manipuleert de tools die je agent vertrouwt; een gelekte providerkey in één van de vijftig services betekent vijftig rotaties en vijftig risicopunten. Geen van deze zaken heeft invloed op de kwaliteit van het model, maar ze hebben allemaal invloed op je credentials.

De effectieve verdedigingsmechanismen zijn eenvoudig: pin versies vast, verifieer de herkomst, roteer volledig, minimaliseer waar secrets opgeslagen zijn en centraliseer providercredentials achter één geauditeerde gateway, zodat de blast radius van een volgend gecompromitteerd package van tevoren is beperkt. Behandel elke externe component die je AI-stack vertrouwt als onderdeel van je attack surface, want dat is precies wat de recente incidenten hebben bewezen.

Beveilig je modellen, packages en MCP-tools achter één control plane. Boek een demo.