Zeven stappen voor veilige AI-skills

Een skill geeft je AI-agent toegang tot je systeem. Bestanden lezen, commando's uitvoeren, soms netwerkverkeer opzetten. Dat is precies wat skills nuttig maakt, en precies wat ze gevaarlijk maakt zodra iemand kwaadaardige code verstopt in iets dat eruitziet als een onschuldige "CSV Analyzer".

Snyk onderzocht op 5 februari 2026 bijna vierduizend skills uit twee publieke registers, ClawHub en skills.sh. Wat ze vonden:

• 36,82% van de skills heeft minstens één beveiligingsprobleem. Dat gaat van API-sleutels die hardgecodeerd in de bestanden staan tot skills die externe inhoud binnentrekken zonder controle.
• 13,4% heeft minstens één probleem van kritiek niveau.
• 2,6% bevat prompt injection: verborgen instructies die de agent iets anders laten doen dan jij vroeg.
• 76 skills bevatten een bevestigd kwaadaardige payload: credentialdiefstal, backdoors, data-exfiltratie. Acht daarvan stonden op het moment van publicatie nog gewoon online.
• 91% van die bevestigd kwaadaardige skills combineert prompt injection met klassieke malware. Die combinatie is bewust: zo glippen ze zowel langs AI-beveiliging als langs een gewone virusscanner.

Dat gaat over publieke registers, niet over de officiële marketplace van je AI-leverancier. Maar het is wel de plek waar de interessante skills vandaan komen, en dus de plek waar je developer kijkt.

Hieronder staan zeven stappen, in de volgorde waarin je ze doorloopt. Eerst kijken naar wat je binnenhaalt, dan scannen, dan isoleren. Die laatste, stap 4, draagt het zwaarste gewicht, want hij is de enige die ook werkt als de eerste drie iets missen.

Voor je installeert: wie schreef dit, en hoelang bestaat het al. Een auteur met geschiedenis, met andere projecten, met mensen die er issues op openen, is geen garantie. Maar een skill van een account dat gisteren is aangemaakt en verder niets heeft, is het eerste en goedkoopste signaal om het niet te doen.

Voor de zaakvoerder: vraag waar de skills die in je bedrijf gebruikt worden vandaan komen. "Van GitHub" is geen antwoord op die vraag, net zomin als "van het internet" een antwoord is op waar een factuur vandaan komt.

Elke skill beschrijft welke tools hij mag aanroepen: het bestandssysteem, de terminal, het netwerk. Die lijst is publiek en staat bovenaan in het bestand. De vraag is simpel: klopt wat hij vraagt met wat hij belooft te doen?

Een skill die grafieken maakt van een CSV heeft je spreadsheet nodig. Hij heeft geen toegang nodig tot willekeurige shell-commando's, en al zeker niet tot het internet. Vraagt hij dat toch, dan is dat geen detail dat je later uitzoekt. Dat is het moment om te stoppen.

Voor de zaakvoerder: dit is de enige stap die je zelf kan controleren zonder technische kennis. Laat de gevraagde toegang naast de beschrijving zetten en vraag waarom er iets bij staat dat je niet kan plaatsen.

Dit is de meest concrete stap, en hij kost je twee minuten. NVIDIA geeft SkillSpector gratis en open source uit. Het draait lokaal, het werkt voor Claude Code, Codex CLI en Gemini CLI, en het leest de skill na op de patronen die in het Snyk-onderzoek naar boven kwamen.

Voor de zaakvoerder: je hoeft dit niet zelf te draaien. Je hoeft wel te weten dat het bestaat en gratis is, zodat "daar hebben we geen tool voor" geen geldig antwoord meer is. Vraag twee getallen terug: de score en de dekking. Waarom dat tweede getal, staat hieronder.

Wat de score betekent

De uitkomst is geen groen of rood lampje. Je krijgt een risicoscore van 0 tot 100 in vier banden:

Wat de scan niet ziet

Ik heb SkillSpector 2.11.0 losgelaten op twee skills die ik zelf geschreven heb. De uitkomst is leerzamer dan een voorbeeld dat netjes uitkomt.

carousel kreeg 100 op 100, CRITICAL, DO NOT INSTALL. Twaalf meldingen, waarvan negen van hoog niveau. Zeven daarvan komen doordat de skill gecompileerde Python-bestanden meelevert die er niet in horen. Twee omdat SKILL.md verwijst naar bestanden die de scanner niet kon volgen. De drie gemiddelde meldingen: geen gedeclareerde tool-scope, een vermoeden van sessiepersistentie, en een aanroep van subprocess. Allemaal reële opmerkingen. Geen enkele wijst op kwaad opzet, want die is er niet: ik heb die skill zelf geschreven.

linkedin-post kreeg 0 op 100, LOW, en de melding "No security issues detected". Drie regels lager staat waarom: dekking 0,0%. Nul bestanden volledig geïnspecteerd, één bestand gedeeltelijk. De scanner liep vast op een expressie die zijn parser niet aankon en heeft dus vrijwel niets gelezen. Het aanbevelingsveld zegt dan ook geen "veilig" maar CAUTION.

Score

100/100

CRITICAL

Dekking

61,5%

8 volledig, 5 deels

1. LOW
2. MEDIUM
3. HIGH
4. CRITICAL

Score

0/100

LOW

Dekking

0,0%

0 volledig, 1 deels

1. LOW
2. MEDIUM
3. HIGH
4. CRITICAL

Twee lessen, en ze zijn allebei het onthouden waard.

Een hoge score is een reden om te kijken, geen bewijs van kwaad opzet. Wie een rode uitslag als een verbod behandelt, gooit bruikbare dingen weg en leert niets.

En een score van nul kan betekenen dat er nauwelijks gekeken is. Lees de dekking altijd naast de score. Een schone scan die niets gelezen heeft, is geen schone skill.

Precies daarom is de scan een laag, en niet de oplossing. De volgende stap is dat wel.

Dit is de sterkste maatregel van de zeven, en de enige die niet afhangt van het herkennen van kwaadaardige code. Een skill die door de scan glipt, raakt in een container niet aan je echte bestanden, je productiedata of je wachtwoorden. Hij zit in een doos, en die doos bepaal jij.

Praktisch komt het hierop neer: de AI-agent draait in een geïsoleerde omgeving, met enkel de mappen erin die hij echt nodig heeft. De rest van je schijf zit er niet in. Je wachtwoordbeheerder zit er niet in. Productiedata zit er niet in tenzij je die er bewust bij zet.

Dit is geen test die je uitvoert bij een verdachte skill. Dit is hoe je standaard werkt, ook bij skills die je vertrouwt.

Voor de zaakvoerder: dit is de stap die je niet zelf uitvoert, en precies daarom de belangrijkste vraag die je stelt. Draait de agent op de laptop zelf, of in een container? Als het antwoord "op de laptop" is, dan hangt alles wat hierboven staat af van menselijke oplettendheid, en die is nooit honderd procent. Vraag hoeveel werk het is om dat om te draaien. Meestal is het antwoord: een halve dag.

Anthropic heeft een eigen scanning van skills en plugins die automatisch op kwaadaardige inhoud controleert. Gratis meegenomen, dus zet hem aan. Maar ken de beperkingen, want ze zijn aanzienlijk: de functie zit in bèta, staat standaard uit, en is momenteel enkel beschikbaar op Enterprise-plannen.

Belangrijker is wat de documentatie beschrijft, en wat er niet in staat. Beschreven wordt het scannen van skills en plugins die iemand uploadt of bewerkt in Claude, Claude Cowork en Enterprise plugin marketplaces. Niet beschreven: skills die er al stonden voor je de functie aanzette, skills die je met Claude zelf maakte, en skills die via een verbonden MCP-server binnenkomen.

Dat laatste is het punt dat telt. Haalt je developer een skill lokaal binnen van GitHub in Claude Code, dan komt die nooit langs die upload en valt hij dus buiten de beschreven dekking. De platformscanning is een extra laag boven op stap 3 en 4, niet in de plaats ervan.

Voor de zaakvoerder: vraag of je op een plan zit waar dit beschikbaar is, en of het aanstaat. Vraag daarna hoe skills bij jullie binnenkomen. Als het antwoord "van GitHub, lokaal" is, dan verandert deze stap niets aan je risico en blijven stap 3 en 4 je twee echte lagen.

Een skill die vandaag schoon is, kan morgen iets anders zijn. De auteur past hem aan, of iemand neemt zijn account over en publiceert een nieuwe versie onder dezelfde naam. Jij haalt die update binnen zonder er verder bij na te denken, want de eerste keer was in orde.

Scan dus niet enkel bij installatie. Scan opnieuw bij elke update, met hetzelfde commando en dezelfde twee getallen.

Voor de zaakvoerder: vraag of dit een gewoonte is of iets dat één keer gebeurd is bij de installatie. Het verschil tussen die twee is het hele punt van deze stap.

De default bij onzekerheid is nee. Niet "we zien wel", niet "we proberen het even".

Een skill die je tijd bespaart maar die je niet kan uitleggen aan iemand anders, bespaart je vandaag een uur en kan je later veel meer kosten. Er komt volgende week een andere. De kost van niet installeren is bijna altijd lager dan hij voelt.

Voor de zaakvoerder: maak expliciet dat "niet installeren" een geldige uitkomst is. Zolang niemand dat hardop zegt, voelt afhaken als falen, en installeert je team door.

Deze zeven stappen sluiten niets voor honderd procent uit, en dat is geen slag om de arm. Het is wat de scans hierboven letterlijk laten zien: een van mijn eigen skills kreeg een score van nul terwijl er nauwelijks iets gelezen was.

Wat deze aanpak wel doet, is lagen stapelen die elkaars gaten opvangen. Weten wat je binnenhaalt vangt de luie aanvaller. Scannen vangt wat al bekend is. En de container vangt de rest, want die hangt niet af van het herkennen van kwaadaardige code, enkel van het beperken van wat die code kan raken.

Een gemotiveerde aanvaller met een nieuwe techniek kan een scanner omzeilen. Hij kan de container niet omzeilen door slimmer te zijn, enkel door een fout in je opzet. Dat is waarom stap 4 het zwaarste gewicht draagt, en waarom stap 7 bestaat.