Home / Vault & Second Brain / Ik heb mijn MCP-servers doorgelicht met een checklist van drie vragen

Ik heb mijn MCP-servers doorgelicht met een checklist van drie vragen

Ik heb mijn MCP-servers doorgelicht met een checklist van drie vragen

Gisteren deed ik iets wat niet erg modern van me is: ik ging tellen. Niet de tokens, niet de modellen, niet de agent-sessies. Ik telde de servers die mijn inloggegevens bewaren en namens mij acties kunnen uitvoeren. Daarna telde ik hoeveel daarvan kunnen schrijven, verwijderen of code uitvoeren. Het antwoord was ongemakkelijk, en ik heb niemand om de schuld te geven behalve mezelf.

De aanleiding was een getal dat ik diezelfde ochtend las: iemand had 675 gepubliceerde MCP-servers gescoord op vijftien structurele veiligheidssignalen. Read-only modus, authenticatie, tool-risico, onderhoud, herkomst. De uitkomst: 89,3% belandde in de categorie “hoog risico”. Slechts 0,9% scoorde “veilig”.

Mijn eerste reactie was: dat gaat over servers van anderen, niet over de mijne. Mijn tweede reactie, tien seconden later: hoe zou mijn eigen regel eruitzien in die spreadsheet?


De drie cijfers die het deden

Drie bevindingen bleven hangen, omdat ze dingen beschrijven die ik vandaag op mijn eigen machine kan controleren, zonder iets te installeren.

92,1% van de servers had geen read-only modus. Ik ging er altijd van uit dat read-only iets is dat je later toevoegt. Het blijkt dat bijna niemand dat ooit doet. En in mijn eigen opzet zijn de servers die ik het meest vertrouw precies de servers met de ruimste schrijfrechten. Vertrouwen en bevoegdheid zijn samen gegroeid, zonder dat iemand er iets van vond.

Slechts 14,7% ondersteunde OAuth. De rest gebruikt statische sleutels. De mijne gebruiken statische sleutels — sleutels in platte configuratiebestanden, gekopieerd tussen machines, sommige ouder dan de projecten die ze authenticeren.

35,9% stelde minstens één gevaarlijke tool beschikbaar — code-uitvoering, bestanden verwijderen, data schrijven. En 43,1% daarvan combineerde dat met géén read-only uitweg. Dat is de slechtst denkbare combinatie: maximale bevoegdheid, geen manier om die per taak terug te schroeven.


Het deel dat me echt ongerust maakte

De onderzoekers hadden één argument dat ik niet kon wegwuiven: om een MCP-server te misbruiken hoeft een aanvaller geen bug in die server te vinden. De assistent hoeft niet kapot te zijn. Hij hoeft alleen maar overtuigd te worden — door een webpagina die hij leest, een document dat hij verwerkt, een e-mail die hij samenvat.

Dat is wat zij de “lethal trifecta” noemen, en ik heb alle drie de poten in één pijplijn zitten. Mijn agent leest ongecontroleerde inhoud van buiten. Hij heeft toegang tot privégegevens — mijn notities, mijn projectbestanden, mijn familiearchief. En hij heeft tools die naar buiten kunnen communiceren en bestanden kunnen schrijven. Privégegevens, ongecontroleerde inhoud en naar buiten gerichte actie, in hetzelfde proces, in dezelfde beurt.

Ik heb maanden gewerkt aan de buitenkant van mijn opzet. De onderdelen die ik nooit had geïnspecteerd, zijn precies de onderdelen die de agent elke dag met mijn zegen aanroept.


Wat ik eraan doe

Ik heb de bevindingen omgezet in een checklist van drie vragen en ik loop hem server voor server na: heeft deze server read-only modus nodig zoals ik hem daadwerkelijk gebruik, hoe authenticeert hij, en welke van zijn tools zijn echt gevaarlijk? Dat is alles. Geen nieuwe tooling, geen nieuw framework — alleen een scorekaart toegepast op wat al draait.

Het eerste eerlijke antwoord dat ik opschreef: meerdere servers zijn geauthenticeerd met sleutels die nooit zijn geroteerd, en minstens één daarvan kan vervangen worden door een read-only variant, zonder dat ik ook maar iets verlies van wat ik ermee doe.


De ongemakkelijke les

Ik audit wat ik spannend vind. Dat is precies waarom de audit onvolledig is — de dingen waar ik me geen zorgen over maak, zijn de dingen waar ik nooit naar kijk. Het ongemakkelijke zit niet in het feit dat mijn opzet risico’s heeft. Het zit erin dat het risico precies daar zit waar ik allang niet meer keek, omdat ik ooit besloten had dat dit deel wel in orde was.

Dus dit is de vraag die ik jullie wil meegeven, en ik ben oprecht benieuwd naar de antwoorden: hoeveel servers zijn er op dit moment verbonden met jouw agent, en van hoeveel daarvan kun je de tools daadwerkelijk opnoemen? Als je die lijst nu zou moeten opschrijven, zonder je configuratie te openen — hoe ver zou je komen?

Wat vond je van dit bericht?

Laat een reactie achter

Je e-mailadres wordt niet gepubliceerd. Vereiste velden zijn gemarkeerd met *