De beveiliging van de toeleveringsketen door AI-agenten was vroeger eenvoudig, vooral omdat er altijd een mens tussen de pakketnaam en de daadwerkelijke assemblage stond. Twintig jaar lang was dat het hele model: iemand las de naam voordat het pakket de deur uitging. Niet altijd even zorgvuldig. Maar iemand las het wel.
Dat is nu verleden tijd. Vraag een AI-model vandaag de dag om een bibliotheek, en ongeveer een op de vijf aanbevolen pakketten bestaat niet. Aanvallers weten dit, dus registreren ze die namen als eerste. Een agent installeert ze, test ze en gaat verder, en niemand leest er iets van. Dit is precies waar de beveiliging van de toeleveringsketen van AI-agenten momenteel tekortschiet: niet in een toekomstig scenario, maar in de praktijk. pipelinerijdt vandaag.
De industrie heeft twintig jaar lang controlemechanismen gebouwd rondom een ontwikkelaar die leest, beoordeelt en beslissingen neemt. Die ontwikkelaar is niet langer het laatste controlepunt voordat een afhankelijkheid in het bouwproces terechtkomt. De echte vraag is dus niet of AI met een agent nieuwe risico's met zich meebrengt, maar wat er daadwerkelijk overblijft als het menselijke controlepunt wegvalt.
Van “AI doet suggesties” naar “AI handelt”
Twee jaar geleden stelde een copiloot een codeblok voor, de ontwikkelaar las het en besloot vervolgens of het behouden moest worden. Die workflow is grotendeels verdwenen. Agentische tools installeren nu afhankelijkheden, starten containers op en activeren acties. pipeline Ze gaan zelfstandig te werk en rapporteren vaak pas achteraf, en alleen als er iets misgaat.
De verschuiving vond in fasen plaats en de meeste teams zijn verder gevorderd dan hun geschreven beveiligingsbeleid toegeeft. Vroege agenttools vroegen om goedkeuring voor elke wijziging, en ontwikkelaars klikten zo vaak op 'ja' dat de bevestigingsstap geen betekenis meer had. De agents van tegenwoordig vragen meestal helemaal niet meer om goedkeuring. Ze grijpen alleen in bij acties die als gevoelig zijn gemarkeerd, zoals het uitvoeren van een shellscript, en een typische pull request Door een agent gegenereerde tekst kan uit duizenden regels bestaan die geen mens ooit van begin tot eind leest voordat ze worden samengevoegd.
Het probleem met de toegangsrechten verergert dit. In de meeste configuraties draait een agent simpelweg als de ontwikkelaar, met toegang tot alles waartoe de machine van de ontwikkelaar toegang heeft: omgevingsvariabelen, cloudtokens, registerreferenties, SSH-sleutels. Wanneer een agent iets installeert en er tijdens die installatie een script wordt uitgevoerd, erft deze de volledige impact van de persoon die hij imiteert. Dit is waar de beveiliging van de toeleveringsketen van AI-agents geen beleidskwestie meer is, maar een kwestie van toegangsrechten: de agent heeft geen nieuwe exploit nodig, maar alleen de toegang die hij al heeft.
Docker Captain Mohammad-Ali A'râbi, die ook in hetzelfde panel sprak, verwoordde het onomwonden: "Ik denk dat de ontwikkelaar nu zelf onderdeel is van het aanvalsoppervlak."
Het is belangrijk om eerlijk te zijn over wat dit heeft vervangen. Een mens die een package.json De diff-methode was al een zwakke controle; vrijwel niemand controleerde daadwerkelijk elke transitieve afhankelijkheid voordat een wijziging werd goedgekeurd. Agents hebben niet per se een sterk systeem kapotgemaakt. Ze hebben het laatste excuus voor een zwak systeem weggenomen. Wat veranderd is, is niet dat het risico nieuw is, maar dat het zich nu in een compleet ander tempo ontwikkelt: sommige schattingen geven aan dat het aantal aanvallen op de toeleveringsketen vorig jaar ongeveer vijf keer zo hoog was als het jaar ervoor, en de curve lijkt eerder exponentieel dan lineair.
Het installatiemoment: wat er verandert als niemand kijkt.
Hallucinatie En kwaadaardige pakketnamen zijn niet nieuw. typosquatting Het systeem heeft jarenlang misbruik gemaakt van menselijke typefouten: één verkeerde letter en een ontwikkelaar installeert het verkeerde. Wat nu anders is, is dat een model, en niet een persoon, de naam bedenkt, en dat doet het op een voorspelbare manier.
De cijfers maken hier een serieuze zaak van, geen curiositeit. Ongeveer 20% van de pakketten die door open-source modellen worden aanbevolen, bestaan niet (bij commerciële modellen ligt dit percentage rond de 5%), en van de onderzochte verzonnen namen komt 43% identiek terug in tien herhaalde zoekopdrachten. Die herhaalbaarheid maakt het aanvalspatroon vatbaar voor misbruik: een aanvaller hoeft niet te raden wat een ontwikkelaar zal typen. Het model vertelt het hem, betrouwbaar en gratis.
Een nieuwere variant, genaamd HalluSquatting, gaat nog een stap verder. In plaats van een kwaadaardig pakket onder een verzonnen naam te publiceren, plaatst een aanvaller kwaadaardige instructies in een README-bestand, een skill-bestand of een MCP-serverbeschrijving. Vervolgens wacht hij tot een agent dezelfde repository- of toolnaam hallucineert en deze downloadt. Een recent onderzoek, waarin dit gecombineerd wordt met promptinjectie, rapporteerde een bijna perfecte voorspelling van valse repositorynamen voor nieuwe projecten en volledige code-executie tegen echte code-assistenten zoals Cursor, Windsurf en Copilot. Omdat de payload platte tekst is in plaats van uitvoerbare code, hebben de meeste scantools geen aanwijzingen.
Als Xygeni Onderzoeksfunctionaris Luis Rodríguez Breng het ter sprake tijdens de discussie: “We hebben jarenlang gewerkt aan verdedigingsmechanismen tegen kwaadaardige code. Signatures, sandboxes, gedragsanalyse. HalluSquatting heeft dat allemaal niet nodig. Het heeft alleen een overtuigende README nodig.” Instructies in platte tekst die een agent leest als betrouwbare context, passeren zonder problemen scanners die ontworpen zijn om uitvoerbare code te detecteren.
Dat is de laag die de meeste AppSec-tools nog niet kunnen detecteren, namelijk de pre-laag.cisely waarom Xygeni's Vroegtijdige waarschuwing voor malware (MEW) Deze aanpak bestaat op platformniveau: continue, realtime analyse van nieuw gepubliceerde pakketten in registers zoals npm, PyPI en Maven, ontworpen om kwaadaardig gedrag te detecteren voordat er een publieke handtekening bestaat, in plaats van te wachten tot een CVE dagen later verschijnt.
Containers, CI/CDEn herkomst: kun je nog steeds bewijzen wat er in jouw constructie zit?
Een agent beperkt zich zelden tot het toevoegen van een regel aan package.jsonHet bewerkt Dockerfiles, herstructureert builds in meerdere fasen en doet nog wat andere dingen. pipeline De configuratie wordt direct in het buildsysteem zelf ingevoerd, in plaats van alleen in de broncode.
Precies hier komt het antwoord van de industrie op risico's in de toeleveringsketen om de hoek kijken. SBOMs en SLSA provenance, zou standhouden. Vervolgens, in mei 2026, heeft een aanvaller via phishing een beheerder misleid en het gestolen token gebruikt om een "wees"-token te publiceren. commit Zonder ouderproject in de geschiedenis ervan, werd het gebruikt om een buildcache te vergiftigen. De resulterende pakketten, vierentachtig in totaal, werden geleverd met volledig geldige, correct ondertekende herkomstgegevens van het hoogste niveau. Elke geautomatiseerde controle slaagde. De malware was echt, en technisch gezien was dat ook het bewijsmateriaal dat aantoonde hoe deze was gemaakt.
De ongemakkelijke conclusie: herkomst bewijst wat een build heeft gedaan met wat er is aangeleverd, niet dat wat er is aangeleverd betrouwbaar was. Vergiftig de input voordat het artefact bestaat, en de attestatie is een eerlijk, verifieerbaar verslag van een oneerlijke build. De beveiliging van de toeleveringsketen van AI-agenten kan niet volledig worden uitbesteed aan attestatietools die zijn ontworpen voor een wereld waarin een mens, en niet een model, beslist wat er in de build terechtkomt.
Een praktische, maar effectieve oplossing is misschien niet erg aantrekkelijk, maar wel effectief: een afkoelingsperiode, waarbij een paar dagen wordt gewacht na de publicatie van een nieuwe pakketversie voordat deze wordt ingevoerd. De meeste actieve incidenten in de toeleveringsketen worden binnen die eerste periode gemeld en openbaar gemaakt, dus een vertraging van vijf dagen zou een aanzienlijk deel van de incidenten van vorig jaar hebben voorkomen. wormachtige aanvallen, tegen absoluut geen kosten behalve onmiddellijkeiacy.
Git, review en het steeds kleiner wordende menselijke controlepunt
Codebeoordeling en commit De geschiedenis heeft lange tijd gediend als het anker van vertrouwen, in de veronderstelling dat "iemand hiernaar heeft gekeken". Dat anker wankelt echter wanneer agenten commiten versmelten steeds meer, zonder dat er op het moment zelf een mens bij betrokken is.
Een agent die een pakket installeert, vormt niet hetzelfde vertrouwensprobleem als een ontwikkelaar die een antwoord van Stack Overflow kopieert, ook al schrijven beide geen eigen code. Een Stack Overflow-codefragment is geschreven door een echt persoon en is informeel beoordeeld door middel van upvotes en downvotes. Een door AI gegenereerde aanbeveling is een probabilistische output zonder deze eigenschappen, en een ontwikkelaar die het handmatig kopieert, kijkt nog steeds naar de pakketnaam, de datum van de laatste update en de openstaande problemen. Een agent die het installeert, stopt hier niet voor, tenzij er expliciet iets is gebouwd om dit te veroorzaken.
Dat is het echte probleem met shift-left. De traditionele shift-left-aanpak gaat ervan uit dat het snelst bewegende object in de pipeline Een ontwikkelaar kan worden getraind, bijgestuurd en geëvalueerd. Wanneer de snelst bewegende factor echter een autonome agent is, moet de 'shift-left'-beveiliging opnieuw worden verankerd aan controlepunten waar de agent zich niet omheen kan praten: sandboxing, toegangscontrole en afkoelingsperiodes, in plaats van een beleidsdocument dat niemand handhaaft.
Beveiliging van de toeleveringsketen van AI-agenten: wat is een veilige agent? Pipeline Vereist feitelijk
Om deze nieuwe klasse wormen te overleven, hoef je niet vanaf dag één negen verschillende beveiligingsmaatregelen perfect te implementeren. Voor een team met beperkte middelen zijn er twee belangrijker dan de rest:
- Gebruik de agent altijd in een sandbox. Voer het uit in een microVM of container met alleen de huidige projectmap gemount, zodat een gecompromitteerde agent geen toegang heeft tot de tokens, inloggegevens of bestanden van de host. Dit is de goedkoopste beschikbare beveiligingsmaatregel en de maatregel die het minst gerechtvaardigd is om over te slaan.
- Voeg een afkoelperiode toe voordat nieuwe pakketversies worden geïnstalleerd. Een paar dagen is vaak al voldoende voor een actieve supply chain-aanval om aan het licht te komen en openbaar te worden gemaakt voordat deze uw systeem bereikt.
Een derde optie, voor teams die daar de middelen voor hebben: integreer CVE- en malwarezichtbaarheid direct in de pipelinewaarbij de containerimage wordt gescand (niet alleen de broncode, aangezien veel kwetsbaarheden zich in de basisimage bevinden) en de resultaten worden weergegeven als pull request Opmerkingen die ontwikkelaars daadwerkelijk zien voordat ze code samenvoegen.
Een recent incident maakt de ernst van de situatie concreet. In juli 2026 misbruikte een AI-model dat intern werd geëvalueerd een zero-day-vulnerabiliteit in de enige toegestane netwerkroute van zijn eigen sandbox, een pakketcacheproxy, om toegang te krijgen tot het open internet en, zonder menselijke tussenkomst, externe infrastructuur te compromitteren om een benchmarkdoel te bereiken. De ontsnappingsroute was de afhankelijkheidsinfrastructuur: de ene verbinding die elke sandbox toelaat. Als uw agent toegang tot een pakketregister nodig heeft om te functioneren, is die verbinding geen bijkomstigheid van uw beveiligingsmodel. Het ís het beveiligingsmodel. De volledige analyse van Xygeni over hoe die ontsnapping daadwerkelijk plaatsvond, is de moeite waard om te lezen. Schurk van ontwerp.
Key Takeaways
- Het laatste menselijke controlepunt verdwijnt, het verzwakt niet. Ontwerp besturingselementen die niet afhankelijk zijn van het feit dat iemand een pakketnaam moet kunnen lezen.
- Slopsquatting en HalluSquatting zijn daadwerkelijk te beoefenen, niet theoretisch. Het herhaaldelijk verschijnen van hallucinerende namen en het injecteren van prompts in platte tekst worden in de praktijk al misbruikt.
- Herkomst en SBOMHet bewijst wat een build deed, niet wat er aan werd toegevoerd. Beschouw attestatie op het hoogste niveau als noodzakelijk, niet als voldoende.
- Het is de beheersing, en niet de detectie, die de situatie momenteel in bedwang houdt. Sandboxing, toegangscontrole en afkoelperiodes bieden extra tijd die scans op basis van signatures niet kunnen bieden.
- Breng in kaart wat uw agenten daadwerkelijk kunnen bereiken. Niet het beleidsdocument. Maar de echte tokens, de echte inloggegevens, de echte netwerkuitgang.
Dit artikel is gebaseerd op de discussie tijdens Xygeni's SafeDev Talk.Wanneer AI-agenten afhankelijkheden installeren”, met medewerking van Docker Captain Mohammad-Ali A'râbi. Zijn complete beveiligingsraamwerk met negen controles wordt uitgebreider behandeld in zijn nieuwsbrief, Docker Security Dispatch, en door Luis Rodriguez, Research Officer bij Xygeni.
Veelgestelde vragen: Beveiliging van de toeleveringsketen van AI-agenten
Is de installatie van een pakket door een agent een fundamenteel ander vertrouwensprobleem dan wanneer een ontwikkelaar een suggestie van Stack Overflow overneemt, of is het gewoon een snellere versie van hetzelfde probleem?
Beide, zij het in verschillende verhoudingen. Het mechanisme is sneller, maar de vertrouwenskloof is structureel ook groter: een antwoord op Stack Overflow is geschreven en informeel beoordeeld door een persoon, terwijl een door AI gegenereerde pakketaanbeveling een probabilistische output is zonder vergelijkbare beoordeling, en een ontwikkelaar die het handmatig kopieert, voert nog steeds een oppervlakkige controle uit die een geautomatiseerde agent volledig overslaat.
Wat zou er nodig zijn voor een SBOM Hoe kun je op betrouwbare wijze vastleggen: "Een agent heeft dit toegevoegd, en dit is waarom"?
Vandaag SBOM en herkomst standardZe waren gebouwd rond de aanname dat een mens elke afhankelijkheid creëerde.cision, en ze hebben nog geen veld voor welke agent, welke modelversie of welke prompt een bepaalde wijziging heeft veroorzaakt. Om die lacune te dichten is ofwel een uitbreiding van bestaande attestatieformaten nodig, ofwel een apart, agentbewust auditspoor dat de wijzigingen vastlegt.cisIonprovenance naast bouwprovenance.
Is er een versie van "shift-left" die nog steeds werkt wanneer het snelste in de pipeline Is het een autonome agent, geen ontwikkelaar?
Ja, maar het controlepunt moet verschuiven, niet alleen de timing. Shift-left, gebaseerd op menselijke beoordeling, is niet schaalbaar met de snelheid van agents; shift-left, gebaseerd op sandboxing, uittredingsbeperkingen en installatie-cooldowns, kan een gecompromitteerde agent nog steeds detecteren voordat zijn acties de productieomgeving bereiken, omdat die controles niet afhankelijk zijn van iemand die iets leest.
