Een vaardighedenbestand. Een regelsbestand. Een MCP-serverconfiguratie. Drie regels platte tekst. commitHet ziet eruit als documentatie, het wordt beoordeeld als documentatie, en geen van beide lijkt op code. En toch kan elk van deze documenten stilletjes herschrijven wat je AI-assistent moet doen en waartoe hij toegang heeft. Dat is de ongemakkelijke waarheid achter AI-beveiliging. in 2026De industrie heeft zich twee jaar lang zorgen gemaakt over de inhoud van door AI gegenereerde code. Het grotere probleem bleek echter de AI-toeleveringsketen zelf te zijn: de modellen, agents, MCP-servers en configuratiebestanden die nu naast uw broncode en open-source afhankelijkheden staan, grotendeels ongeïnventariseerd en ongecontroleerd. Dit is precies de reden waarom de beveiliging van de AI-toeleveringsketen een eigen discipline is geworden, en waarom de keuze voor het juiste AI-beveiligingsbedrijf net zo belangrijk is als de keuze voor de juiste scanner.
Het aanvalsoppervlak waar niemand rekening mee had gehouden in de begroting.
Software had vroeger slechts een handvol plekken waar een aanvaller kon toeslaan: de code, de afhankelijkheden, de pipelineAI heeft er nog twee aan toegevoegd, en beide zijn direct in de AI-toeleveringsketen geïntegreerd.
Het model en de agent. Toolvergiftiging, promptinjectie, agentautonomie die verder gaat dan wie dan ook bedoeld had. Een verborgen instructie in een MCP-serverbeschrijving kan stilletjes de acties van een copiloot beïnvloeden, zonder dat de ontwikkelaar het ooit merkt.
De eigen omgeving van de ontwikkelaar. IDE's, AI-copiloten, MCP-servers, agent-CLI's. Onzichtbaar voor traditionele AppSec-scanners, die niet weten wat een model is, en onzichtbaar voor EDR, dat het besturingssysteem bewaakt en geen idee heeft wat een afhankelijkheid of een MCP-aanroep is.
Niets hiervan is theoretisch. In de afgelopen achttien maanden:
- Een verborgen Unicode-achterdeur in het configuratiebestand stelde aanvallers in staat om onzichtbare instructies in de configuratiebestanden te injecteren die Copilot en Cursor lazen, waardoor de door de assistent gegenereerde code stilletjes werd voorzien van een achterdeur. GitHub voegde hier in 2025 een waarschuwing voor toe.
- Een kwetsbaarheid voor command-injectie in een populaire MCP-bridge (CVSS 9.6) trof meer dan 400,000 downloads voordat deze werd verholpen. Het was het eerste gedocumenteerde geval van volledige uitvoering van code op afstand, veroorzaakt door simpelweg verbinding te maken met een onbetrouwbare MCP-server.
- Een zelfverspreidende npm-worm maakte van ontwikkelaars zelf het leveringsmechanisme, en dit patroon herhaalde zich op grote schaal in de daaropvolgende maanden in andere ecosystemen, een schoolvoorbeeld van een beveiligingsfout in de AI-toeleveringsketen.
- Onderzoekers ontdekten dat een aanzienlijk deel van de pakketten die LLM's aanbevelen helemaal niet bestaan; het gaat om "slopsquatting"-namen die een aanvaller registreert voordat een echte ontwikkelaar het model ooit vraagt om ze te importeren.
Googles eigen onderzoek naar het beveiligen van de toeleveringsketen van AI-software komt vanuit een ander perspectief tot een vergelijkbare conclusie: modellen die in 2023 en 2024 in omloop waren, leken legitiem, maar bevatten code die na downloaden data kon stelen of een achterdeur kon plaatsen. De oplossing was niet zozeer een nieuwe categorie tools, maar eerder het toepassen van discipline in de toeleveringsketen, zoals herkomstregistratie en digitale handtekeningen, op software die voorheen niet werd bijgehouden. Dat is in één zin het beveiligingsprobleem van de AI-toeleveringsketen: de software is nieuw, maar de benodigde discipline niet.
Waarom uw bestaande tools tekortschieten
SAST leest code. SCA Leest een manifest van afhankelijkheden. Geen van beiden weet wat een model is, wat een MCP-server blootlegt of wat een vaardigheidsbestand een agent opdraagt te doen. Die kloof is precies waar aanvallen uit het AI-tijdperk landen, in de ruimte tussen "code die we scannen" en "AI die we stilletjes hebben geaccepteerd".
Het resultaat is een categorie schaduw-AI. CISMomenteel kan ik antwoorden op vragen als: welke modellen gebruiken we, welke agents hebben toegang tot wat, en met welke MCP-server heeft iemand afgelopen dinsdag verbinding gemaakt zonder het iemand te vertellen? Het goed beantwoorden van die vragen is de taak van AI-beveiliging in de toeleveringsketen, en dat is de reden waarom generieke AppSec-tools hier tekortschieten.
Wat AI-beveiliging nu eigenlijk inhoudt
Xygeni is het AI-beveiligingsbedrijf dat dit beschouwt als drie met elkaar verbonden bewegingen over de SDLC: ontdekken, detecteren en handhaven.
Ontdek: weet welke AI je daadwerkelijk hebt.
Continue, automatische detectie in uw repositories brengt alle AI-middelen aan het licht: modellen, frameworks, datasets, inferentie-eindpunten, agents, MCP-servers, vaardigheden, prompts, guardrailsEn de AI-codeertools die uw ontwikkelaars daadwerkelijk gebruiken. Geen enquêtes. Geen zelfrapportage. Als het een spoor heeft achtergelaten in een repository, verschijnt het in de inventaris, de eerste en meest fundamentele vereiste voor echte beveiliging van de AI-toeleveringsketen.
De AI-grafiek brengt vervolgens in kaart hoe die assets met elkaar verbonden zijn: welk model een dataset voedt, welke agent welke tool aanroept, welke MCP-server achter welke assistent zit. Een asset op zich zegt weinig. De grafiek laat zien waar het risico zich concentreert.
Uit diezelfde ontdekking genereert Xygeni een AI-BOMEen auditklare, machineleesbare inventaris van alles wat met AI te maken heeft in uw software. Wanneer een toezichthouder, auditor of klant vraagt welke AI u gebruikt, is het antwoord een download in plaats van een zoektocht van drie weken.
Detectie: risico's die conventionele scanners niet kunnen zien.
Een speciale AI-scanner zoekt naar de faalmodi die specifiek zijn voor AI-systemen: promptinjectie, toolinjectie en onbetrouwbare toolaanroeping, datalekken door retrieval, omzeiling van systeemprompts en excessieve agency. Elke bevinding wordt gekoppeld aan de OWASP Top 10 voor LLM-aanvragen en verwijst naar het exacte bestand en de regel die het probleem veroorzaakt, in plaats van een vage waarschuwing als "controleer uw AI-gebruik".
Dezelfde detectielaag behandelt vaardigheidsbestanden, regelsbestanden en MCP-configuraties als de beveiligingsartefacten die ze zijn, en niet als onschadelijke documentatie. Het markeert kwaadaardige of vergiftigde vaardigheden, inspecteert MCP-serverconfiguraties op toolvergiftiging en toont de prompts die daadwerkelijk uw AI-workloads aansturen.
Prioriteit geven: de trechter die ruis filtert, niet de bochten.
Elke bevinding wordt stapsgewijs gefilterd: eerst naar wat bereikbaar is in de applicatiecode, vervolgens naar wat daadwerkelijk misbruikt kan worden, en ten slotte naar wat zich bevindt in de code waaraan uw team actief werkt. Wat uiteindelijk in de wachtrij van een ontwikkelaar terechtkomt, is de korte lijst met daadwerkelijke bedreigingen voor de productieomgeving, met daarbij de frameworkreferentie, het blootstellingsvenster en richtlijnen voor het beperken van de risico's.
Handhaven: voorkom dat het begint te draaien.
Shield Het brengt beleidshandhaving naar het eigen eindpunt van de ontwikkelaar: het blokkeert ongeautoriseerde en kwaadwillige installaties, niet-goedgekeurde modellen en niet-geautoriseerde MCP-servers voordat er iets wordt uitgevoerd. Daaronder bevindt zich Xygeni's Vroegtijdige waarschuwing voor malware (MEW)Deze laag onderschept kwaadaardige pakketten voordat er een handtekening bestaat, de laag die op reputatie gebaseerde tools nog steeds vertrouwen omdat niemand het pakket nog heeft gerapporteerd. Het is de handhavingshelft van AI-beveiliging in de toeleveringsketen: ontdekking en detectie vertellen je wat er mis is. Shield Dat is wat het daadwerkelijk stopt.
Je blootstelling aan AI beperkt zich niet alleen tot je AI-code.
Een compleet beeld van de beveiliging van de AI-toeleveringsketen vereist meer dan een modelinventaris, en het gaat zelden alleen om de flitsende details:
- Referenties van de AI-aanbieder achtergelaten in promptbestanden, agentconfiguraties of pipeline Logbestanden zijn net als alle andere geheimen, en de geheimdetectie van Xygeni onderschept ze voordat ze in een openbaar register terechtkomen.
- Kwetsbare AI- en ML-afhankelijkheden Het gaat om gewone CVE's, die aan het licht komen door dezelfde software-samenstellingsanalyse die al de rest van je stack dekt. Onderzoek van derden naar de adoptie van AI heeft aangetoond hoeveel van de moderne AI-stack bestaat uit extern ingekochte pakketten en verborgen componenten, en dat is precies het aspect waarvoor software-samenstellingsanalyse is ontwikkeld.
- Schadelijke pakketten sneller gepubliceerd dan enig advies pipeline Ze kunnen worden gecatalogiseerd als ze vóór de ondertekening worden onderschept, dezelfde MEW-functionaliteit beschermt de rest van uw toeleveringsketen.
De agentlaag: DevAI en CoreAI
Ontdekking en detectie hebben betrekking op wat er al in uw repositories aanwezig is. DevAI Het werkt daar waar het risico ontstaat: binnen de IDE, als een continue, proactieve laag die zowel door mensen als door AI gegenereerde code scant tijdens het schrijven, zonder dat er prompts nodig zijn. Het legt het volledige exploitatiepad achter een gevonden kwetsbaarheid uit en stelt MCP-gevalideerde oplossingen voor die een ontwikkelaar met vertrouwen kan toepassen, zonder de build te verstoren.
CoreAI bevindt zich boven de individuele scanners als de intelligentielaag: het correleert code, afhankelijkheden, pipelineHet model integreert gegevens over beveiligingshoudingen in één risicomodel, beantwoordt vragen in natuurlijke taal en produceert rapportages die direct toepasbaar zijn voor een beveiligingsmanager. Deze rapportages laten zien dat er daadwerkelijk sprake is van governance, en niet alleen van beweringen.
Breid de bestaande AI-beveiliging uit. Verwijder niets.
Het meest gehoorde bezwaar tegen een nieuwe beveiligingscategorie is: "we hebben al genoeg tools." Als AI-beveiligingsbedrijf vraagt Xygeni u echter niets te vervangen: dezelfde triage, uitleg en prioritering die op de eigen bevindingen van Xygeni wordt toegepast, gelden ook voor de bevindingen van uw bestaande systemen. SAST, SCAEn scanners van derden. Je huidige infrastructuur wordt een input in plaats van een slachtoffer, en de beveiliging van je AI-toeleveringsketen verbetert zonder dat er een ingrijpend vervangingsproject aan verbonden is.
Waarom dit nu belangrijk is, en niet later.
Regelgevers komen vanuit verschillende hoeken tot dezelfde verwachting: de EU AI-wetgeving, NIS2 en de Spaanse ENS streven allemaal naar inventarisatie en traceerbaarheid van AI-systemen, hetzelfde bewijs dat een AI-BOM (Bill of Materials) moet leveren. De richting is duidelijk, zelfs waar de precieze nalevingsmechanismen nog niet volledig zijn uitgewerkt: je kunt geen AI-systemen aantonen die je nooit hebt geïnventariseerd, en je kunt geen zekerheid over de toeleveringsketen van AI claimen als die keten zelf onzichtbaar voor je is.
Een AI-beveiligingsbedrijf kiezen
Niet elk AI-beveiligingsbedrijf trekt zijn grens op dezelfde plek. Sommige beperken zich tot het scannen van uw eigen AI-gegenereerde code. Anderen stoppen bij het eindpunt. De beveiligingsvraagstukken rond de AI-toeleveringsketen zijn groter dan elk onderdeel afzonderlijk: ze omvatten het model, de agent, de MCP-server, het skillbestand en alle onderliggende afhankelijkheden. Dat volledige levenscyclusoverzicht, van ontdekking tot handhaving, in één console met de rest van uw AppSec-bevindingen, is waar u naar moet kijken bij de evaluatie van een AI-beveiligingsbedrijf, in plaats van een losstaand hulpmiddel.
De bestanden die niemand controleert, worden de toegangspoort. AI-beveiliging is de discipline van het controleren ervan, en AI-beveiliging van de toeleveringsketen zorgt ervoor dat die discipline van begin tot eind standhoudt, op hetzelfde platform waar je al al het andere controleert.
Ontdek wat jouw AI daadwerkelijk mag doen. Begin gratis or een demo plannen.
FAQ
Verlaat de code van Xygeni ooit mijn infrastructuur?
Nee. Scans worden uitgevoerd in uw eigen omgeving en de broncode wordt nooit geüpload naar de servers van Xygeni. De AI-inventaris en de AI-BOM worden gegenereerd op basis van wat de scanner lokaal ziet, niet op basis van een extern verzonden kopie.
Wat is het verschil tussen AI Security, DevAI en CoreAI?
AI Security ontdekt en detecteert: het bouwt de AI-inventaris op, de AI-BOM, en vindt risico's zoals promptinjectie of vergiftigde skill-bestanden. DevAI werkt binnen de IDE terwijl ontwikkelaars code schrijven en stelt gaandeweg oplossingen voor. CoreAI bevindt zich boven beide, correleert bevindingen over het hele platform en beantwoordt vragen over uw beveiligingsstatus in natuurlijke taal.
Met welke AI-beveiligingsframeworks sluit Xygeni aan?
De bevindingen sluiten aan op de OWASP Top 10 voor LLM-aanvragen, de OWASP Top 10 voor MCP en de OWASP Top 10 voor agentische vaardigheden, evenals op NIST SP 800-218A en CISA/G7-richtlijnen voor AI-stuklijsten. Die mapping maakt de AI-stuklijst bruikbaar als bewijs van naleving in plaats van slechts een inventaris.
Zal dit elke AI-bibliotheek of elk AI-model als een risico bestempelen?
Nee. De prioriteringsmethode beperkt de bevindingen tot wat bereikbaar is in de applicatiecode, daadwerkelijk bruikbaar is en actief in ontwikkeling is. De lijst die een ontwikkelaar te zien krijgt, is dus kort en niet een stortvloed aan alle gedetecteerde AI-componenten.
