Vorige week schreef ik over de structurele security-blind-spot in het MCP-ecosysteem: MCP is een transport-laag, geen security-laag, en de meeste community-servers vergeten dat. Vandaag de concrete vervolglijst.
Niet alle MCP-servers zijn veilig. Sommige zijn populair en toch structureel onveilig. Anderen zijn gebouwd door enthousiaste community-leden zonder security-achtergrond. En een paar zijn gewoon experimenten die nooit voor productie waren bedoeld maar toch zo worden gebruikt.
Op deze 2e Pinksterdag, een dag voor reflectie en sortering, een eerlijke lijst van 7 MCP-server-patronen die ik vandaag niet zou installeren. Met telkens het waarom en, waar mogelijk, een veiliger alternatief.
Disclaimer: dit is geen persoonlijke aanval op individuele bouwers. Veel van deze servers zijn met goede bedoelingen gemaakt en functioneren voor hun beperkte use-case. De waarschuwing is voor wie ze zonder eigen security-review in productie wil zetten.
1. MCP-servers die credentials in environment variables verwachten
Het patroon: server-README zegt "set USERNAME en PASSWORD als environment variabelen." De server gebruikt die credentials direct, zonder authenticatie van de aanroepende AI-client.
Waarom risicovol: Iedereen die toegang heeft tot het OS-process (denk: collega's die je laptop gebruiken, een corrupt dependency, een leak via debug-logs) kan via de MCP-server acties uitvoeren. Geen client-auth = open backdoor in jouw bedrijfssystemen.
Voorbeelden in het wild: veel community-servers voor SaaS-diensten (boekhouding, CRM, e-commerce platforms).
Wat dan wel: kies servers die OAuth 2.1 ondersteunen, of bouw zelf een wrapper die token-auth toevoegt voor jouw deployment. Voor lokaal-only experimenten op één machine: acceptabel, maar ban van productie.
2. MCP-servers zonder TLS / die plain HTTP toestaan
Het patroon: server draait op http://localhost:port zonder TLS, of erger: op http://0.0.0.0:port accessible voor het hele lokale netwerk.
Waarom risicovol: Iedereen op hetzelfde wifi-netwerk (denk: koffieshop, kantoorruimte, conference) kan de MCP-server aanspreken en data lezen. De localhost aanname is op gedeelde infrastructuur niet veilig.
**Wat dan wel:**voor STDIO-transports (lokale subprocess): minder kritiek, maar wel: zorg dat de subprocess onder dezelfde user als de client draait. Voor HTTP-transports:altijd TLS 1.2+ plus client-auth. Geen plain HTTP, ook niet "alleen tijdelijk".
3. MCP-servers met "iedereen kan alles" tool-access
Het patroon:een geauthenticeerde client krijgt automatisch toegang totalle tools die de server aanbiedt. Geen scope, geen rate-limiting, geen per-tool autorisatie.
Waarom risicovol: een server die "lees-orders" en "plaats-order-tot-€10K" beide aanbiedt zonder onderscheid is een ramp wachtend om te gebeuren. Een gehackte client krijgt instant toegang tot de zwaarste actie.
Voorbeelden: sommige early e-commerce MCP-servers (waaronder versies van de Picnic-server die ik vorige week noemde, niet als kritiek op de bouwer, wel als waarschuwing voor het patroon).
Wat dan wel: scope-per-tool. Lees-only scopes voor read-acties. Aparte schrijf-scopes met aparte tokens voor schrijf-acties. Dit verdubbelt het bouwwerk maar tien-voudigt de veiligheid.
📖 Lees ook: MCP is een transport-laag, geen security-laag: waarom het MCP-protocol zelf geen bescherming biedt
4. MCP-servers gebouwd door één persoon zonder maintenance
Het patroon: een MCP-server op GitHub met laatste commit van 6+ maanden geleden, één maintainer die niet meer reageert op issues, en een dependency-tree die niet meer update.
Waarom risicovol: kwetsbaarheden in dependencies worden niet gepatched. Wanneer er een CVE komt voor een library die de server gebruikt, blijft de MCP-server kwetsbaar. Bij Anthropic-policy-veranderingen breekt de integratie zonder dat iemand het oplost.
Concreet check: open de GitHub-repo. Wanneer is laatste commit? Hoeveel open issues? Hoeveel hangende PRs? Geen maintenance = security debt.
Wat dan wel: kies servers van organisaties (Anthropic, GitHub, grotere community-projecten) of gemaintainde community-projecten met aantoonbaar reactietijd op issues. Of: bouw zelf, voor een specifieke use case, en maintain hem zelf.
5. MCP-servers die OAuth-tokens van gebruikers vasthouden
Het patroon: server vraagt jou om je OAuth-token van een dienst (Google Drive, Slack, GitHub) te plakken in een config file of environment, en stuurt die token mee bij iedere API-call.
Waarom risicovol: OAuth-tokens hebben vaak brede scopes. Een gestolen token van een MCP-server geeft een aanvaller dezelfde toegang als jij. Dit is exact het patroon dat in april 2026 bij OpenClaw fataal werd toen Anthropic third-party OAuth verbood.
Wat dan wel: servers die de officiële CLI van een dienst spawnen (gh, gcloud, aws) en die hun eigen auth laten regelen. De server houdt geen token vast, de CLI doet het. Veiliger en survivability is hoger bij policy-veranderingen.
6. "All-in-one" MCP-servers met 50+ tools
Het patroon: server biedt toegang tot 50, 100, of meer tools, bijvoorbeeld "een MCP voor je hele Google Workspace" met Gmail, Drive, Docs, Calendar, Contacts, Tasks, en meer.
Waarom risicovol: combinatie van factoren. Hoge complexiteit = hoge kans op bugs. Brede scope = bij compromise grote blast-radius. Eén CVE in één van de 50 tools opent de hele server.
Wat dan wel: kleinere, gescoptere MCP-servers per use case. "MCP voor Gmail-only" is betrouwbaarder dan "MCP voor heel Workspace". Composability boven mega-installatie.
7. MCP-servers die in production worden gebruikt na alleen "hello world" testing
Het patroon: dit is geen specifieke server. Dit is hoe je elke server gebruikt. Iemand installeert een MCP, doet een korte test, het werkt voor één case, en zet hem in productie zonder verdere validatie.
Waarom risicovol: zelfs een goed-ontworpen MCP-server faalt onder edge cases (rate-limiting, errors, malformed responses) op manieren die je niet ziet bij een hello-world test. Production-grade is iets anders dan "lijkt te werken".
Wat dan wel: drie weken proefdraaien op niet-kritieke use cases. Logging aanzetten van iedere actie. Periodiek manual review van wat de MCP-server heeft gedaan. Pas dan op kritieke business-data.
De vier checks vóór elke MCP-installatie
Niet abstract, niet theoretisch. Vier directe checks:
1. Check de README op auth-vermelding. Geen woord over authentication = run away. Je gaat zelf bouwen of het niet gebruiken.
2. Check de scope-per-tool. Heeft de server gescheiden read/write capabilities? Of geeft hij authenticated clients alles?
3. Check de last-commit-date. Ouder dan 4 maanden zonder reden = security debt accumulating. Vooral bij community-projecten.
4. Check de dependency-tree. Een MCP-server met 200 dependencies is een 200-poorts attack-surface. Lichter is veiliger.
Wat ik vandaag wel installeer
Voor de balans: drie patronen die ik wel vertrouw.
- Officiële MCP-servers van grote organisaties (Anthropic-onderhouden, GitHub-onderhouden). Niet perfect, wel beter gemaintained.
- STDIO-transports voor lokaal-only gebruik met servers waarvan ik de source heb gelezen. Geen netwerk-exposure = lager risico.
- Zelf-gebouwde wrappers rond officiële CLI's (
gh,gcloud, etc.) zodat de auth in de CLI blijft, niet in mijn MCP-server.
Dat is ~80% van mijn MCP-gebruik. De andere 20%, community-servers, alleen na een security-review en alleen voor niet-kritieke use cases.
De drie meest gevaarlijke combinaties
Als afsluitende checklist: drie combinaties waarvan ik in 2026 concrete incidents heb gezien:
- HTTP-transport zonder TLS + creds in environment, netwerk-snifbaar, geen bescherming
- All-in-one server zonder scope per tool + brede OAuth-token, één compromise = volle toegang
- Onmaintained server + production-data, de combinatie die over 6 maanden in een nieuwsartikel komt
Bij twee uit drie checks: stop met installeren. Bij drie uit drie: nu meteen verwijderen.
Veelgestelde vragen
Samenvatting
Niet alle MCP-servers zijn veilig. Zeven patronen om in 2026 niet te installeren: env-creds zonder client-auth, plain HTTP zonder TLS, geen scope-per-tool, onmaintained projecten, OAuth-token-vasthouders, mega-servers, en pas-na-hello-world-getest in productie.
Vier checks vóór elke installatie: README op auth, scope per tool, last-commit-date, dependency-tree.
Voor productie of business-kritieke data: alleen officiële, gescoptere, gemaintainde servers. Voor lokaal experimenten: meer ruimte, met security-bewustzijn.
Op deze rustige 2e Pinksterdag is misschien een goed moment om je eigen MCP-installaties door te lopen. Vier checks, vijf minuten per server. Dat is goedkoper dan een security-incident over zes maanden.
Wil je een audit of advies over jouw MCP-stack? Plan een gesprek, geen verkooppraatje, wel een eerlijk gesprek over wat veilig is in jouw situatie.
Lees ook
📖 Lees ook: MCP is een transport-laag, geen security-laag: het fundament van deze serie
📖 Lees ook: MCP servers en GDPR/AVG: verborgen risico's voor ondernemers: privacy-kant van MCP-installaties
📖 Lees ook: De 10 beste MCP servers voor Claude Code in 2026: welke servers wél de veiligheidscheck doorstaan
📖 Lees ook: OpenClaw OAuth-ban: wat je kunt gebruiken in plaats daarvan: alternatieven die de OAuth-eis overleven