Op LinkedIn zag ik vorige week een oproep aan een grote Nederlandse retailer om "een MCP-server te bouwen zodat we onze AI-assistent boodschappen kunnen laten doen". De reacties waren enthousiast. Niet één reactie ging over: hoe zorg je dat alleen jij die MCP-server kunt aanspreken?
Dat is precies de denkfout die in 2026 een patroon is geworden. MCP wordt door iedereen gepresenteerd als "de USB-C voor AI", wat het is. Maar USB-C heeft een fysieke kabel die je in je hand houdt. MCP heeft dat niet. En de meeste community-MCP-servers worden gebouwd alsof het wel zo is.
Deze post is voor iedereen die een MCP-server gebruikt, bouwt, of overweegt te bouwen. Geen panic. Wel een duidelijke waarschuwing, en concrete acties die je vandaag kunt nemen.
De fundamentele misvatting
Het Model Context Protocol (MCP) is door Anthropic ontworpen als een transport-protocol: het beschrijft hoe een AI-client en een tool-server gestructureerd berichten uitwisselen. Resources, tools, prompts, en de bijbehorende JSON-RPC.
Wat het MCP-protocol expliciet niet doet: een ingebouwde authenticatie-, autorisatie- of encryptie-laag voorschrijven. Uit de officiële MCP security best practices:
"The MCP SDK does not include built-in authentication mechanisms."
Dat is een ontwerpkeuze. Niet een fout. MCP is bewust laagdun gehouden zodat je het over verschillende transports kunt draaien (STDIO, HTTP, WebSockets) en authenticatie aan de implementator overlaat.
Het probleem ontstaat als die implementator dat overslaat.
CVE-2026-32211: het Azure-incident
In april 2026 publiceerde Microsoft CVE-2026-32211, een kritieke kwetsbaarheid in de Azure MCP Server. CVSS-score 9.1. De oorzaak: ontbrekende authenticatie. De server stond open voor onbevoegde toegang tot gevoelige cloud-data.
Dit was geen exotische zero-day. Dit was: er was geen auth ingebouwd, en niemand had het opgemerkt voordat het in productie stond.
In dezelfde vier maanden van 2026 werden meer dan tien high- of critical-severity CVE's in het MCP-ecosysteem geregistreerd (State of MCP Security 2026). De rode draad: implementator die MCP installeert, security-laag overslaat, deelt het openbaar, iemand vindt het.
Het Picnic-voorbeeld (en waarom het exemplarisch is)
De open-source Picnic MCP-server van community-developer Ivo Toby is een goede case-study. Niet omdat het slecht gemaakt is, het werkt prima voor wat het belooft. Wel omdat het laat zien hoe de meeste MCP-servers in het wild zijn opgezet.
Wat de README zegt:
"Set Picnic credentials as environment variables (
PICNIC_USERNAME,PICNIC_PASSWORD)."
Dat is op zich al een teken. Maar belangrijker: de MCP-server zelf vraagt geen authenticatie van de aanroepende AI-client. Iedereen die toegang heeft tot het lokale process kan via de MCP-server boodschappen doen op het account waarvan de credentials in de environment staan.
Voor een persoonlijke installatie thuis is dat acceptabel, als de attack surface beperkt is tot jouw eigen machine. Voor een productie-deployment, of een gedeelde server, is het een serieus risico.
En als de Nederlandse retailer waar over op LinkedIn werd gevraagd dit precies zo zou bouwen, bedrijfs-API key in environment, geen client-auth, geen scoped tokens, dan zit je een week na launch met een security-audit die niet meeloopt. En dat is het goede scenario.
Wat veilig MCP er wel uitziet
Geen overdreven zware setup. Drie lagen die allemaal nodig zijn:
Laag 1, Transport encryption (TLS 1.2 minimum, 1.3 voorkeur)
Voor HTTP-based MCP transports: altijd TLS. Geen plain HTTP, ook niet "alleen lokaal". Test je cipher suites, zwakke ciphers (RC4, DES, 3DES) uitschakelen.
Voor STDIO-based servers (lokale subprocess): de transport-laag is by-design lokaal en je leunt op OS-niveau process-isolation. Maar dat betekent: de server moet draaien onder dezelfde user als de aanroepende client, niet op een gedeelde machine.
Laag 2, Authenticatie van de client
Voor HTTP-transports: standaardiseer op OAuth 2.1 met properly scoped tokens. Niet OAuth 2.0 (die heeft bekende issues). Niet API-keys in headers (zelfs niet in dev). OAuth 2.1.
De OAuth-token bevat:
- Welke client mag aanvragen doen
- Welke scopes (lees, schrijf, specifieke tool-namen)
- Een vervaltijd (geen eeuwige tokens)
Voor STDIO-transports: de "auth" is dat de subprocess wordt gespawnd door een vertrouwde parent. Dat is acceptabel als jouw OS-isolatie streng genoeg is. Niet acceptabel op gedeelde infrastructuur.
Laag 3, Autorisatie per tool
Een geauthenticeerde client mag niet automatisch alle tools van de server gebruiken. Per tool: scope-check.
Concreet: als je MCP-server "lees-orders" en "plaats-order" beide aanbiedt, dan moet "plaats-order" een aparte scope hebben. De AI-client krijgt alleen toegang tot wat hij echt nodig heeft.
In het Picnic-voorbeeld: een AI-assistent die je boodschappenlijst maakt heeft read:cart-scope nodig. Een AI-assistent die orders mag plaatsen heeft write:order-scope. Twee verschillende OAuth-tokens, twee verschillende risicoprofielen.
De drie checks voor MCP-servers die je vandaag gebruikt
Geen abstracte adviezen. Drie acties.
Check 1, Auth-laag aanwezig?
Open de README van iedere MCP-server die je gebruikt. Zoek naar "authentication", "OAuth", "API key", "auth". Geen vermelding? Auth bestaat waarschijnlijk niet.
Als je server creds via environment variables verstuurt (USERNAME, PASSWORD, API_TOKEN) zonder client-auth, dat is je startpunt. Niet einde. Geen veilig productiepatroon.
Check 2, Wie kan de server aanspreken?
Test: kun je vanaf een andere machine in je netwerk de MCP-server aanspreken? Zo ja, en er is geen auth: je hebt een open backdoor.
Lokale STDIO-servers zijn meestal OK voor één gebruiker op één machine. HTTP-servers zonder auth zijn praktisch nooit OK.
Check 3, Wat doet de server bij creds-leak?
Stel: je MCP-server lekt creds (logfile, debug output, error message). Welke schade kan een aanvaller aanrichten?
Voor een Picnic-server met je creditcard: je kunt boodschappen voor honderden euro's bestellen op andermans rekening. Voor een GitHub-MCP-server met een PAT met "repo"-scope: code-stelen, repos verwijderen. Voor een Slack-MCP: berichten posten als jou.
Het auditpunt is niet "kan dit gebeuren", antwoord is altijd "ja, theoretisch". Het auditpunt is "wat is de blast-radius als het gebeurt en hoe beperken we die".
Wat ik zelf doe
Drie principes in mijn eigen VNX-systeem:
- Geen MCP-servers zonder auth-review. Iedere server die ik installeer, ik check de README op auth-vermelding. Geen auth = ik bouw zelf, of ik gebruik 'm niet.
- Scope per server. Elke MCP-server heeft minimale rechten. Mijn GitHub-MCP kan alleen lezen op specifieke repos. Niet "alle".
- Geen creds in environment voor productie. Voor production: secrets manager (1Password CLI, AWS Secrets Manager). Voor lokaal-only experiment: environment is OK.
Hetzelfde patroon zie je terug bij prompt injection als beveiligingsrisico, security is geen feature, het is een ontwerpkeuze.
De boodschap aan retailers (en alle MKB-bedrijven)
Als jouw bedrijf overweegt een MCP-server te lanceren, voor klanten, voor partners, voor je eigen interne AI, laat dat doen door iemand die expliciet "auth" en "scope per tool" in zijn ontwerp heeft staan. Niet als afterthought. Als architectuur.
Het verschil tussen een veilige MCP-implementatie en een onveilige is in mijn ervaring twee dagen extra werk. De kosten van een onveilige MCP die in productie gaat: hoog, mediageniek, en in 2026 onverzekerbaar als je achteraf moet uitleggen dat OAuth 2.1 sinds april 2026 de duidelijke standaard is.
OAuth 2.1 is niet ingewikkeld. Het is alleen niet automatisch. Voor wie zelf een MCP-server bouwt: hooks in Claude Code kun je gebruiken om client-acties tegen te houden voor ze de server bereiken, een extra laag in een defense-in-depth setup.
Veelgestelde vragen
Samenvatting
MCP is een transport-laag, geen security-laag. Dat is een ontwerpkeuze, geen fout. Maar het verschuift de verantwoordelijkheid voor authenticatie en autorisatie naar de implementator, en de implementator slaat die in 2026 structureel over.
Drie acties deze week: check je actieve MCP-servers op auth-vermelding, test wie ze kan aanspreken, en evalueer de blast-radius bij een creds-leak. Voor productie en team-deployments: OAuth 2.1, scoped tokens, per-tool autorisatie. Niets minder.
In 2027 wordt OAuth 2.1 voor MCP-servers waarschijnlijk verplicht onder NIS2 of de AI Act in augustus 2026. Wie nu begint, heeft een jaar voorsprong. Wie wacht: krijgt het op een drukke dag te horen, meestal van een klant of journalist, niet van een security-team.
Lees ook: ISA/IEC 62443 toegepast op AI governance, defense-in-depth principes uit industriële veiligheid, één-op-één toepasbaar op MCP-architectuur.
Voor teams die hun MCP-implementatie willen auditen: zie AI-architectuur.
Wil je een audit van jouw MCP-implementatie of advies over een veilige integratie? Neem contact op. Ik werk niet als security-bureau, maar bij MCP- en agent-architectuur kan ik je helpen of doorverwijzen.
Bronnen & referenties
- MCP Security Best Practices, Anthropic
- The Ultimate Guide to MCP Security Vulnerabilities, Aembit
- The State of MCP Security 2026, PipeLab
- CVE-2026-32211 Azure MCP Server Flaw, DEV.to
- MCP Security Checklist, Network Intelligence
- mcp-picnic op GitHub (Ivo Toby), gebruikt als concreet voorbeeld, niet als kritiek op de bouwer
- MCP-servers GDPR/AVG-risico's voor marketeers en ondernemers