Hoe veilig zijn MCP servers? Risico's en maatregelen

Het eerlijke antwoord vooraf: MCP is geen onveilig protocol, maar het verplaatst een groot deel van de beveiligingsverantwoordelijkheid naar jou. Tussen april 2025 en april 2026 ging het ecosysteem van "theoretische zorgen" naar een reeks gedocumenteerde incidenten: een kwaadaardige server die e-mails stal, een kritieke RCE-kwetsbaarheid met 437.000+ downloads, cross-tenant datalekken en volledige database-exfiltratie. Het Center for Internet Security erkende MCP in april 2026 formeel als "een nieuwe en onderscheiden security boundary" in zijn MCP Companion Guide bij CIS Controls v8.1. Wie MCP zakelijk inzet, moet die grens dus bewust beheren. Hieronder vind je de belangrijkste aanvalspatronen met echte voorbeelden, gevolgd door de maatregelen die aantoonbaar werken. Nieuw met MCP? Lees eerst wat MCP is en hoe het technisch werkt.

Waarom is MCP een ander soort risico dan een gewone API?

Bij een klassieke API-koppeling voert code uit wat een ontwikkelaar heeft geprogrammeerd. Bij MCP leest het AI-model zélf de tool-beschrijvingen en tool-resultaten — en behandelt die tekst als instructies. Alles wat door een MCP-verbinding stroomt kan daardoor het gedrag van de agent beïnvloeden: een e-mail, een supportticket, een databaserij of de omschrijving van een tool. Een model kan "data" en "instructies" niet betrouwbaar van elkaar onderscheiden; er bestaat op modelniveau geen 100%-oplossing voor dit probleem. Mitigatie is daarom architectureel: je beperkt wat een gemanipuleerde agent überhaupt kán doen. Wie dit principe begrijpt — het model volgt tekst, ongeacht waar die vandaan komt — begrijpt negentig procent van MCP-security.

Wat is prompt injection via tool-resultaten?

Bij indirecte prompt injection verstopt een aanvaller instructies in content die de agent via een tool binnenhaalt. De gebruiker vraagt iets onschuldigs; de agent leest onderweg de kwaadaardige tekst en voert die uit. Prompt injection staat op plek 1 in de OWASP Top 10 voor LLM-applicaties, en MCP vergroot het aantal aanvoerkanalen drastisch.

Het bekendste voorbeeld is de "Toxic Agent Flow" in de GitHub MCP server, gedemonstreerd door Invariant Labs in mei 2025. Een ontwikkelaar vraagt zijn agent om "de open issues te checken". Eén publiek issue bevat een verborgen injectie. De agent gehoorzaamt, springt met hetzelfde GitHub-token naar de privé-repositories van de gebruiker en lekt de inhoud — in de demo inclusief salarisgegevens — via een publieke pull request. Cruciaal: dit was géén bug in de servercode — de tools waren niet vergiftigd, de data was dat.

Wat zijn tool poisoning en rug-pull-aanvallen?

Bij tool poisoning zitten de kwaadaardige instructies niet in de data, maar in de tool-beschrijving zelf — tekst die het model leest maar de mens vrijwel nooit ziet. Invariant Labs demonstreerde een simpele "tel twee getallen op"-tool waarvan de beschrijving het model stiekem opdroeg om ~/.cursor/mcp.json (met API-keys) uit te lezen en als parameter mee te sturen. Voor de gebruiker een rekenmachine; voor het model een exfiltratiecommando. De kernles: de mens keurt goed wat hij ziet, het model handelt naar wat het leest. Dat gat is de hele aanvalsklasse.

Een rug pull gaat een stap verder: de server gedraagt zich netjes bij installatie, wordt goedgekeurd, en wijzigt daarna stilletjes zijn tool-definities. MCP staat toe dat servers hun tools bijwerken zonder nieuwe toestemming, en de meeste clients detecteren die wijziging niet. In de WhatsApp-demo van Invariant Labs deed een server zich voor als "random fact of the day"-tool en muteerde bij de tweede start in een tool die via de mee-geïnstalleerde whatsapp-mcp de volledige berichtgeschiedenis naar het nummer van de aanvaller stuurde. Verwant hieraan is tool shadowing: een kwaadaardige server beschrijft zijn tools zo dat ze het gedrag van een ándere, vertrouwde server in dezelfde agent onderscheppen.

Wat is de "lethal trifecta"?

Het nuttigste denkmodel voor beslissers komt van onderzoeker Simon Willison (juni 2025). Een agent wordt gevaarlijk zodra hij in één sessie alle drie deze eigenschappen heeft: (1) toegang tot privédata — je mail, repositories, database; (2) blootstelling aan onvertrouwde content — webpagina's, tickets, e-mails die een aanvaller kan beïnvloeden; (3) een exfiltratiekanaal — mail versturen, een PR openen, een HTTP-request doen. Twee van de drie is te overleven; alle drie tegelijk betekent dat wie de onvertrouwde content beheerst, je privédata kan uitlezen én naar buiten sturen. MCP maakt het juist makkelijk om per ongeluk alle drie te combineren, omdat je tools van verschillende leveranciers vrij mengt. Meta formuleerde hetzelfde als de "Agents Rule of Two": geef een sessie maximaal twee van de drie eigenschappen.

Het schoolvoorbeeld is het Supabase-incident (juli 2025). Een agent was gekoppeld met de service_role-key, die by design alle Row-Level Security omzeilt. Een aanvaller verstopte instructies in een supportticket. De agent las het ticket (onvertrouwde content), selecteerde rijen uit een privétabel met integratie-tokens (privédata) en schreef ze terug in de supportthread (exfiltratiekanaal), waar de aanvaller ze in platte tekst kon aflezen. Oorzaak: te ruime credentials plus prompt injection. Oplossing: read-only modus en scoped keys — oftewel: de trifecta doorbreken.

Confused deputy en token-diefstal

Het confused deputy-probleem raakt vooral MCP servers die als proxy voor een externe API fungeren. Zo'n proxy bezit autoriteit (een statisch OAuth client-ID); een aanvaller verleidt hem die autoriteit voor de verkeerde partij in te zetten. Het canonieke scenario uit de officiële MCP-specificatie: de aanvaller registreert een kwaadaardige client met een eigen redirect-URL, stuurt het slachtoffer een link, en omdat diens browser nog een consent-cookie heeft, slaat de externe auth-server het toestemmingsscherm over — de autorisatiecode belandt bij de aanvaller. De spec verbiedt daarom expliciet token passthrough: een MCP server mag nooit tokens accepteren die niet aan hemzelf zijn uitgegeven, en moet het audience-claim (aud) van elk token valideren.

Token-diefstal is de tweede grote credential-dreiging. MCP servers bewaren vaak langlevende, breed gescopete geheimen — API-keys, OAuth-tokens, databasekeys, SSH-keys — en die lekken langs meerdere routes. CVE-2025-6514 in mcp-remote (CVSS 9.6, volgens JFrog 437.000+ downloads geraakt) liet een kwaadaardige server API-keys, cloudcredentials en SSH-keys stelen via remote code execution. De MCP Inspector-RCE (CVE-2025-49596) legde het complete bestandssysteem van ontwikkelaars bloot. En via SSRF kan een kwaadaardige server OAuth-discovery-URL's naar het cloud-metadata-adres 169.254.169.254 laten wijzen om IAM-credentials te oogsten. Hoe breder de scope van een token, hoe groter de schade als het lekt.

Supply-chain-risico en typosquatting

De meeste MCP servers zijn community-projecten die je met één npx- of pip-regel installeert en die met jouw volledige gebruikersrechten draaien. Dat is klassiek npm/PyPI-supply-chain-risico, maar dan met de credentials van je AI-agent eraan gekoppeld. Het vlaggenschip-incident is postmark-mcp (september 2025), volgens Snyk de eerste kwaadaardige MCP server die in het wild werd betrapt. De aanvaller bouwde vertrouwen op met vijftien schone versies; versie 1.0.16 voegde één regel code toe die elke uitgaande e-mail — wachtwoordresets, facturen, interne memo's — via BCC naar de aanvaller kopieerde. Circa 1.600 downloads vóór verwijdering. De les: een vertrouwd pakket kan in één puntrelease kwaadaardig worden.

Typosquatting versterkt dit risico. Volgens de UpGuard-studie uit 2026 (18.000 Claude Code-configuraties, vier registries) is 10–16% van alle MCP servers in de onderzochte registries een typosquat of lookalike, en bestaan er per officiële merkserver 3 tot 15 ongeverifieerde imitaties — er circuleerden bijvoorbeeld negen verschillende "HubSpot"-servers waarvan slechts één echt. De registry-hygiëne loopt sterk uiteen: van 57 zwaar gemodereerde servers in de GitHub MCP Registry tot 17.000+ grotendeels ongemodereerde servers op MCP.so. Ook hostingplatforms zelf zijn een doelwit: bij de Smithery-breach (oktober 2025) lekte via path traversal een token dat 3.000+ gehoste servers beheerste. Welke bronnen wél te vertrouwen zijn, lees je in betrouwbare bronnen.

Welke maatregelen werken echt?

Geen enkele maatregel is op zichzelf voldoende; het werkende patroon in 2026 is gelaagde verdediging — scanner plus gateway plus credential-beheer plus menselijk toezicht. De checklist:

1. Allowlists via een MCP gateway. Houd een privéregister bij van goedgekeurde servers en laat een gateway dit afdwingen: staat een server niet op de lijst, dan komt de verbinding niet tot stand. Op beheerde apparaten pusht je MDM een niet-overschrijfbare allowlist.
2. Read-only en minimale scopes. Kies read-only modi waar beschikbaar en gebruik scoped keys in plaats van admin- of service_role-keys. Begin met een minimale scope en verhoog pas als een geprivilegieerde actie het echt vereist.
3. Human-in-the-loop. De MCP-specificatie stelt dat er altijd een mens moet kunnen ingrijpen bij tool-aanroepen. Vraag goedkeuring bij acties met gevolgen — betalen, mailen, verwijderen, publiceren — maar niet bij elke leesactie, anders ontstaat goedkeuringsmoeheid.
4. OAuth-hygiëne. Audience-gebonden tokens, geen token passthrough, per-client consent en aparte upstream-tokens, conform de officiële spec.
5. Sandboxing. Draai servers in containers met een read-only root-filesystem en alleen gerichte mounts naar de mappen die ze echt nodig hebben; strip gevaarlijke syscalls met seccomp/AppArmor.
6. Egress-controle. Zet onvertrouwde servers op een geïsoleerd netwerk zonder uitgaande routes, of achter een egress-proxy die interne en metadata-bestemmingen blokkeert. Dit schakelt zowel SSRF als het exfiltratiekanaal van de trifecta uit.
7. Logging en tool pinning. Centraliseer audit-logs in de gateway en hash de geïnstalleerde tool-definities (bijvoorbeeld met mcp-scan): elke wijziging geeft een alarm — de directe verdediging tegen rug pulls.

Scanners zoals mcp-scan (Invariant Labs/Snyk) en Cisco's mcp-scanner detecteren poisoning en injectiepatronen vóór ingebruikname, maar zijn geen garantie: een audit van AppSecSanta (april 2026) over 33 servers en 433 tools leverde bruikbare maar ruisrijke resultaten op. Combineer pre-deploy scanning dus altijd met runtime-handhaving. Meer praktische configuratietips vind je op tips & tricks.

Hoe vet je een MCP server vóór toelating?

Voor bedrijven is het toelatingsproces belangrijker dan welke losse tool dan ook. Werk met getrapte goedkeuring: volledig gevette servers direct toelaten, twijfelgevallen alleen in een sandbox, en een expliciete sign-off vóór opname in de allowlist. Screen tool-beschrijvingen op poisoning voordat een server ontwikkelomgevingen bereikt, pin versies en monitor op wijzigingen na installatie — de postmark-les. De officiële MCP-registry ondersteunt namespace-verificatie, waarbij uitgevers eigenaarschap aantonen via GitHub, DNS of HTTP; geef geverifieerde namespaces altijd voorrang.

Tot slot: security en compliance zijn twee kanten van dezelfde medaille. Wie MCP servers toegang geeft tot persoonsgegevens of financiële systemen, krijgt ook te maken met de AVG, NIS2 en de AI Act. Hoe die verplichtingen zich tot MCP verhouden, lees je in MCP en wetgeving. Voor sectoren als banken & fintech en juridisch & compliance gelden bovendien zwaardere eisen dan gemiddeld.

Veelgestelde vragen

Zijn MCP servers veilig om te gebruiken?

MCP zelf is een neutraal protocol; de veiligheid hangt af van welke servers je toelaat en welke rechten je ze geeft. Behandel elke third-party MCP server als niet-vertrouwde code met jouw credentials eraan gekoppeld, en gebruik allowlists, least privilege en menselijke goedkeuring voor gevoelige acties.

Wat is prompt injection bij MCP?

Prompt injection betekent dat een aanvaller instructies verstopt in content die het AI-model via een tool leest — bijvoorbeeld een GitHub-issue of supportticket. Het model volgt die instructies alsof ze van de gebruiker komen. Volgens OWASP is prompt injection risico nummer 1 voor LLM-applicaties.

Wat is de lethal trifecta?

De lethal trifecta (Simon Willison, juni 2025) is de combinatie van drie eigenschappen in één agent-sessie: toegang tot privédata, blootstelling aan onvertrouwde content, en een kanaal om data naar buiten te sturen. Alle drie tegelijk maakt een agent exploiteerbaar; verwijder minstens één van de drie.

Wat is een rug-pull-aanval bij MCP servers?

Een rug pull is een MCP server die zich bij installatie netjes gedraagt en later stilletjes zijn tool-definities wijzigt in kwaadaardige instructies. De meeste clients detecteren die wijziging niet. Tool pinning (het hashen van tool-definities, bijvoorbeeld met mcp-scan) vangt dit af.

Zijn er al echte MCP-beveiligingsincidenten geweest?

Ja. Onder meer de postmark-mcp-backdoor (september 2025, eerste kwaadaardige MCP server in het wild), CVE-2025-6514 in mcp-remote (437.000+ downloads, CVSS 9.6), het Supabase-databaselek en het Asana cross-tenant-lek dat circa 1.000 klanten raakte.

Hoe controleer ik of een MCP server betrouwbaar is voordat ik hem toelaat?

Beoordeel vier dimensies: authenticatiemethode (OAuth boven statische API-keys), reputatie van de uitgever (officieel vs. persoonlijk account), compliance-documentatie (echte SOC 2-audit) en de blast radius bij compromittering. Scan daarnaast de tool-beschrijvingen op poisoning en pin de versie.

Welke maatregelen beschermen tegen onveilige MCP servers?

Gelaagde verdediging: een allowlist van goedgekeurde servers, read-only modi en minimale OAuth-scopes, human-in-the-loop bij gevolgen-acties, sandboxing in containers, egress-controle op uitgaand verkeer en centrale logging via een MCP gateway. Geen enkele maatregel is op zichzelf voldoende.

Laatst bijgewerkt: 2026-07-05