AI-skills in je team: regel dit vóór iemand er één installeert

Leg vier dingen vast voordat iemand in je team een skill van buiten installeert: wie dat mag, uit welke bronnen, wie de meegeleverde scripts leest, en dat er nooit sleutels in een skill-bestand staan. Een skill kan scripts meebrengen die draaien met de rechten van je medewerker, en daarom verdient dat moment aandacht.

Er zit een moment in de invoering van AI waar de meeste bedrijven overheen kijken. Niet het moment waarop iemand ChatGPT opent, want daar is inmiddels wel over nagedacht. Het moment waarop een medewerker een skill installeert die hij ergens tegenkwam.

Dat lijkt onschuldig. Het is een mapje met instructies, meer niet. Alleen mag dat mapje scripts meebrengen, en die draaien met de rechten van degene die ze installeerde.

Beginner-tip: Ken je skills nog niet, lees dan eerst Claude Skills uitgelegd. Dit stuk gaat ervan uit dat je weet wat ze zijn en kijkt naar wat je erover moet afspreken.

Update 25 september 2026: Beveiligingsbedrijf Air Security meldde op 17 september 2026 het lek “Plugin4Shell”: wie de repository achter een plugin beheert, kon vastgepinde plugincode verwisselen als die buiten GitHub stond. Anthropic dichtte het volgens Air in Claude Code 2.1.179 (Air Security, The Hacker News). We hebben afspraak 2 aangevuld met het advies om Claude Code bij te werken.

Waarom dit anders ligt dan een gewone app

Bij een app die je installeert, weet je ongeveer wat je krijgt: een leverancier, een privacyverklaring, misschien een verwerkersovereenkomst. Bij een skill van GitHub heb je vaak niets van dat alles. Je hebt een map van een onbekende met instructies erin, en eventueel scripts.

Twee waarschuwingen die opvallen omdat ze van partijen komen die zelf skills promoten. Firecrawl adviseert om elk meegeleverd script te lezen vóór installatie, met name op ongedocumenteerde netwerkverzoeken — code die stilletjes iets verstuurt. Composio verwijst naar onderzoek van Datadog Security Labs naar kwaadaardige skills als risico in de toeleveringsketen, en stelt er droog bij dat de meeste skills sowieso niets toevoegen.

Zelfs bij de officiële voorbeelden is voorzichtigheid ingebouwd. Anthropic zet boven de eigen skills-repo: deze zijn bedoeld voor demonstratie en educatie, test ze in je eigen omgeving voordat je erop leunt bij kritieke taken.

De map die bepaalt hoe ver het komt

Dit is het technische detail dat je als ondernemer moet kennen, en het enige.

Skills staan op twee plekken:

• De persoonlijke map van een medewerker. Geldt voor al zijn projecten, blijft bij hem. Eén persoon, één machine.
• De projectmap binnen de repository. Die gaat mee in versiebeheer. Wie het project binnenhaalt, krijgt de skills er automatisch bij, zonder er iets voor te doen.

Die tweede is waar je afspraken over wilt maken. Eén medewerker die iets in de projectmap zet, verspreidt het over iedereen die aan dat project werkt. Dat is meteen het goede nieuws: het is ook het punt waar je één keer kunt kijken en het voor het hele team goed hebt staan.

De vier afspraken

Geen beleidsstuk. Een half A4, en je bent er.

1. Wie mag een skill van buiten installeren? Bij een klein team: iedereen, mits gemeld. Bij een groter team: één of twee mensen die het beoordelen. Belangrijk is dat er een naam bij hoort, zodat “ik dacht dat het mocht” geen antwoord meer is.

2. Uit welke bronnen? Houd het kort. De officiële marketplace van Claude Code, plus een eigen lijstje van maximaal een handvol vertrouwde bronnen. Alles daarbuiten gaat langs de persoon uit punt 1. Wat wij als vertrouwde basis zouden nemen: anthropics/skills van Anthropic zelf en obra/superpowers, allebei open, allebei met een leesbare geschiedenis en allebei in de officiële marketplace. Houd daarnaast Claude Code zelf bijgewerkt: in september 2026 bleek dat een vastgepinde plugin uit een repository buiten GitHub stilletjes kon worden verwisseld, wat Anthropic in versie 2.1.179 dichtte.

3. Wie leest de scripts? Alleen nodig als een skill scripts meebrengt. Veel skills zijn puur tekst, en dan valt dit weg. Brengt hij wel code mee, dan leest iemand die vóórdat het in de projectmap belandt. Let vooral op verbindingen naar buiten die niet in de beschrijving staan.

4. Geen sleutels in een SKILL.md. Wachtwoorden, API-sleutels en tokens horen niet in een skill-bestand, want dat gaat mee in versiebeheer. Staat er ooit iets in, dan staat het na het verwijderen nog in de geschiedenis. Een sleutel die per ongeluk in een repository belandde, moet je vervangen, niet weghalen.

Gevorderden: Draait er een MCP-koppeling naast, zet dan de rechten van het configuratiebestand goed. Composio adviseert chmod 600 op het bestand waar de sleutel in staat, zodat alleen de eigenaar het kan lezen. Verder: least-privilege bij de tokens die je uitgeeft, en een menselijke goedkeuring bij alles wat onomkeerbaar is.

Waar de winst zit

Tot nu toe ging dit over risico’s, en dat geeft een scheef beeld. De echte opbrengst van skills voor een MKB-bedrijf zit in zelf schrijven.

Elke onderneming heeft werkwijzen die in iemands hoofd zitten. Hoe je een offerte opbouwt, welke controles er op een factuur horen, hoe een klantmail eruitziet als het misging. Dat is precies het soort kennis dat je één keer vastlegt en daarna herhaalbaar inzet. Een zelfgeschreven skill brengt bovendien geen vreemde code mee, dus alle bovenstaande vragen vervallen.

Hoe je dat aanpakt, staat in onze gids Werkwijze van je beste medewerker vastleggen in een AI-skill.

Wat er misgaat als je niets regelt

Twee scenario’s, allebei zonder kwaadwillende medewerker.

Iemand installeert een skill die goed werkt, zet hem in de projectmap omdat collega’s er ook wat aan hebben, en het script erin stuurt bij elke run een fragment code naar een server voor “telemetrie”. Dat staat niet in de beschrijving. Zit er klantinformatie in die code, dan heb je een datalek, en dan ben jij verwerkingsverantwoordelijke — niet de onbekende die de skill schreef. Bij risico voor betrokkenen heb je 72 uur om het te melden bij de Autoriteit Persoonsgegevens.

Het tweede is saaier en komt vaker voor. Iedereen installeert wat, niemand ruimt op, en na een half jaar draaien er vijftien skills waarvan er drie elkaar tegenspreken. Claude pakt dan de verkeerde erbij en niemand weet meer waarom de uitkomst veranderde. Een halfjaarlijkse opruimronde lost dat op: welke gebruiken we nog, en waarom.

Deze week

Drie dingen, in een uur te doen:

1. Vraag rond wie er al skills gebruikt. Het antwoord is bijna altijd “meer mensen dan je dacht”, en je hebt het nodig voordat je iets afspreekt.
2. Kijk in de projectmappen van je lopende projecten. Staat daar een skills-map, dan is die er al voor iedereen. Lees wat erin zit.
3. Schrijf de vier punten hierboven op en deel ze. Niet als beleid, als afspraak.

Waarom dat afspreken van sleutelbeheer geen overdreven voorzichtigheid is, blijkt uit Anthropics eigen dreigingsrapport: gestolen AI-sleutels kwamen vrijwel altijd uit klantomgevingen, niet uit de leverancier. Zie ‘Te klein om interessant te zijn’ geldt niet meer.

Waarom de lijstjes met “beste skills” je hierbij weinig helpen — en hoe de cijfers erin uiteenlopen — zetten we uiteen op hetlaatsteainieuws.nl. De praktische installatiekant staat op debesteaitools.nl.

Stand van zaken — bijgewerkt 2026-09-25

De afspraken hierboven blijven gelden, welke versie er ook draait. De details hieronder veranderen sneller.