Beveilig je MCP-systeem: 11 veelvoorkomende risico's en hoe je je ertegen beschermt

Deze gids legt MCP-beveiliging uit en behandelt 11 veelvoorkomende risico's voor MCP-systemen, van indirecte promptinjectie tot compromittering van lokale servers, en de praktische stappen waarmee je je tegen elk risico kunt beschermen.

Diagram of how MCP works: the MCP host (the AI app) sends tool requests through an MCP client to an MCP server, which offers its tools and returns results to the host.

MCP-risico's vallen grofweg in drie categorieën: LLM-manipulatie, gegevens- en toegangsbeveiliging, en kwetsbaarheden in de infrastructuur.

Omdat MCP-servers vaak toegang bieden tot een groot aantal interne systemen, is het potentiële beveiligingsrisico hoog. De waarschijnlijkheid hangt echter sterk af van de configuratie.

Particulieren en bedrijven kunnen veel stappen nemen om ervoor te zorgen dat hun systemen beschermd zijn, en protocollen moeten altijd in verhouding staan tot de mogelijkheden en gegevens die verbonden MCP-servers kunnen blootstellen.

Wat zijn MCP en MCP-beveiliging?

Model Context Protocol (MCP) is een open standaard, ontwikkeld door Anthropic, voor het verbinden van op LLM's gebaseerde apps (of hosts) met externe systemen.

Een MCP-systeem bestaat uit drie kerncomponenten: de host, de client en de server. De host, vaak een AI-assistent, maakt via een client verbinding met een externe MCP-server. Daarna kan de host verzoeken sturen om externe functionaliteit uit te voeren (tools) of om gegevens (resources) of prompts op te halen die aan het contextvenster van het LLM worden toegevoegd.

MCP-beveiliging verwijst naar de protocollen die de verbindingen en componenten in een MCP-systeem beschermen. Er zijn verschillende belangrijke uitdagingen die uniek zijn voor MCP, waaronder het feit dat AI-apps vaak agentische mogelijkheden hebben en dat kwaadaardige instructies in berichten kunnen worden verwerkt.

Bekende problemen die niet specifiek zijn voor MCP, zoals promptinjectie, zwakke authenticatie en onveilige integraties van derden, vormen ook een risico. Zoals bij elk computersysteem steunt MCP voor de beveiliging op een combinatie van procedurele protocollen, zoals alleen vertrouwde servers gebruiken, en technische maatregelen, zoals API-gateways.

Hoe ernstig zijn MCP-bedreigingen?

MCP is snel een populaire LLM-technologie geworden en wordt gebruikt door veel organisaties en consumentenapps. Omdat MCP-servers programma's zijn die in code zijn geschreven, hebben ze net als elke andere applicatie kwetsbaarheden.

Wanneer organisaties MCP echter in gecontroleerde implementaties gebruiken, is het over het algemeen veilig. Er is een groot verschil tussen een systeem bouwen met vertrouwde servers en geverifieerde machtigingen en een autonome agent koppelen aan een dozijn niet-gecontroleerde servers.

Bedreiging #1: indirecte promptinjectie

Een aanvaller kan instructies die op het LLM zijn gericht plaatsen in een document, webpagina of tooluitvoer die een MCP-server retourneert. Als de host dit materiaal aan het contextvenster toevoegt, bestaat de kans dat het LLM het aanziet voor echte instructies.

Bovendien kunnen deze instructies op het eerste gezicht gepast lijken. Een opgehaald supportticket kan het LLM bijvoorbeeld opdragen gevoelige klantgegevens te exporteren voordat het een antwoord genereert.

Zo bescherm je je tegen indirecte promptinjectie

Promptinjecties moeten doorgaans op hostniveau worden aangepakt. Externe content moet als niet-vertrouwd worden gelabeld, en verzoeken om gevoelige informatie moeten geïnformeerde goedkeuring vereisen van een mens die bij het proces betrokken is (human-in-the-loop). Beveiligingstests waarbij kwaadaardige documenten of gegevens worden aangeroepen om te zien hoe de host en het LLM reageren, kunnen ook nuttig zijn.

Bedreiging #2: toolvergiftiging en rug pulls

Bij een aanval met toolvergiftiging wordt kwaadaardige code toegevoegd aan de beschrijving of het schema van een MCP-tool. Dit kan het LLM beïnvloeden in de ontdekkingsfase, wanneer MCP de beschikbare tools voor het eerst blootstelt.

Een rug pull is een speciaal type toolvergiftiging waarbij goedgekeurde metadata wordt gewijzigd. Deze vorm van toolvergiftiging kan de manier veranderen waarop een model vertrouwde tools gebruikt, in plaats van rechtstreeks een kwaadaardige tool aan te roepen.

Zo bescherm je je tegen toolvergiftiging en rug pulls

De host moet de volledige definitie van elke tool inspecteren voordat die wordt gebruikt en deze vergelijken met een lijst van goedgekeurde, vertrouwde tools, zodat eventuele wijzigingen worden gedetecteerd. Parametercontroles kunnen helpen om potentieel gevaarlijke mogelijkheden te herkennen en te markeren.

Bedreiging #3: buitensporige machtigingen

Het komt vaak voor dat gebruikers MCP-servers en verbonden LLM's (via de host) meer machtigingen geven dan nodig is voor een taak. Bijvoorbeeld schrijfrechten terwijl alleen-lezen zou volstaan, of volledige toegang tot een intern bestandssysteem (zoals Google Drive).

Deze sluipende uitbreiding van machtigingen kan de impact van andere kwetsbaarheden, zoals kwaadaardige toolaanroepen, vergroten. Het komt vaak voor dat machtigingen zich “opstapelen” doordat gebruikers binnen een bedrijf rechten toekennen tijdens hun dagelijkse werk met AI-tools (privilege-accumulatie).

Zo bescherm je je tegen buitensporige machtigingen

De meest directe manier om je tegen dit probleem te beschermen, is door machtigingen en OAuth-scopes (lezen, schrijven, volledige toegang enz.) te beperken. Goedkeuringen door gebruikers, vooral voor gevoelige bewerkingen, spelen hierbij een belangrijke rol, maar machtigingen moeten ook op systeemniveau worden beheerd (besturingssysteem, MCP-host en server).

Bedreiging #4: zwakke authenticatie en autorisatie

Authenticatie verifieert de identiteit van gebruikers of applicaties die verbinding maken met een MCP-server. Autorisatie bepaalt tot welke tools en resources ze toegang hebben.

Slecht geconfigureerde MCP-servers kunnen verzoeken of tokens accepteren zonder gebruikers correct te authenticeren of toegangsbeperkingen af te dwingen. Daarnaast kunnen kwaadwillenden met gestolen inloggegevens toegang krijgen als de validatie zwak is.

Zo bescherm je je tegen zwakke authenticatie en autorisatie

Authenticatie op basis van OAuth voor MCP-servers op afstand, kortlevende tokens en op rollen gebaseerd toegangsbeheer (RBAC) zijn allemaal maatregelen die de risico's van zwakke autorisatie helpen beperken. Op rollen gebaseerde toegang is nuttig omdat die voorkomt dat gebruikers toegang krijgen tot gegevens en tools buiten hun machtigingen, zelfs als de server zelf wel toegang heeft.

Bedreiging #5: gelekte en misbruikte inloggegevens

MCP-servers gebruiken routinematig inloggegevens zoals API-sleutels en OAuth-toegangstokens om verbinding te maken met externe services. Als deze worden blootgesteld of misbruikt, kunnen aanvallers toegang krijgen tot gevoelige gegevens en functionaliteit.

Een voorbeeld is token-passthrough, waarbij een MCP-server een toegangstoken doorstuurt naar een andere service zonder te verifiëren dat het token daadwerkelijk bedoeld is voor de ontvangende service. Dit kan op zijn beurt tot lekken leiden als de ontvangende service onvoldoende beveiligd is.

Zo bescherm je je tegen gelekte en misbruikte inloggegevens

Kortlevende tokens met een beperkte scope en het regelmatig roteren van inloggegevens beperken effectief in hoeverre kwaadwillenden gelekte gegevens kunnen gebruiken. API-sleutels en inloggegevens moeten altijd veilig worden opgeslagen met een secret manager.

Bedreiging #6: confused-deputy-aanvallen

Een confused-deputy-aanval vindt plaats wanneer een aanvaller een vertrouwde applicatie misleidt om haar machtigingen te gebruiken voor een actie die niet door een legitieme gebruiker is geautoriseerd. In dit geval is de MCP-server de “deputy”.

De aanvaller misbruikt een kwetsbaarheid in een MCP-server (zoals zwakke OAuth-verificaties) om een kwaadaardig proces uit te voeren, zoals een toolaanroep of het ophalen van gegevens.

Zo bescherm je je tegen confused-deputy-aanvallen

Autorisatievalidatie, waarbij van elke toolaanroep wordt geverifieerd dat die bij een specifieke gebruiker hoort, helpt confused-deputy-aanvallen te beperken. Daarnaast moeten gevoelige acties, zoals gegevensexports, expliciete autorisatie vereisen.

Bedreiging #7: kwaadaardige servers en gecompromitteerde afhankelijkheden

MCP-servers kunnen kwaadaardige code bevatten (het zijn in wezen externe programma's) of steunen op gecompromitteerde afhankelijkheden, zoals bibliotheken van derden. Dit is een probleem in de softwaretoeleveringsketen en geen probleem dat uniek is voor MCP.

Dit kan bijvoorbeeld eenvoudig gebeuren als een aanvaller een integratie verspreidt die legitiem lijkt. Zodra die is ingesteld, kan die inloggegevens stelen en hergebruiken, gevoelige gegevens benaderen en niet-geautoriseerde bewerkingen uitvoeren.

Zo bescherm je je tegen kwaadaardige servers en gecompromitteerde afhankelijkheden

Installeer MCP-servers alleen uit vertrouwde en gecontroleerde bronnen. Beoordeel indien mogelijk hun code en controleer altijd eventuele externe afhankelijkheden. Zorg ervoor dat servers regelmatig worden bijgewerkt en gepatcht.

Bedreiging #8: server-side request forgery (SSRF)

Bij server-side request forgery (SSRF) misleidt een aanvaller een MCP-server om netwerkverzoeken te sturen naar interne adressen die de gebruiker niet wilde benaderen.

Dit kan gebeuren wanneer een MCP-server een tool blootstelt die informatie ophaalt van een URL. Als een aanvaller de URL-parameter kan beïnvloeden, kan die deze wijzigen in het gewenste netwerkadres, zoals een interne API of cloudservice. Dit kan ertoe leiden dat gevoelige gegevens worden opgehaald en mogelijk toegankelijk worden gemaakt

Zo bescherm je je tegen server-side request forgery (SSRF)

MCP-servers moeten URL's altijd valideren, de toegang tot beperkte interne netwerkadressen blokkeren en uitgaande netwerktoegang voorkomen. Ook voor omleidingen moet dit protocol worden gevolgd.

Bedreiging #9: sessiekaping

Bij sessiekaping neemt een aanvaller de controle over een actieve verbinding tussen een MCP-client en een server.

Een aanvaller kan bijvoorbeeld een sessie-ID stelen uit een slecht beveiligde MCP-applicatie (bijv. een host of een server). Als de MCP-server dit ID accepteert, kan de aanvaller mogelijk tools aanroepen met de legitieme machtigingen van de gebruiker.

Zo bescherm je je tegen

Het risico op sessiekaping kan worden verkleind met strikte identiteitsverificatie in alle applicaties binnen een MCP-systeem. Versleuteling tussen MCP-clients en servers op afstand is ook essentieel om te voorkomen dat sessie-ID's worden achterhaald.

Bedreiging #10: mix-up-aanvallen

Bij een mix-up-aanval misleidt de aanvaller een MCP-client om een autorisatiecode te sturen naar een kwaadaardige autorisatieserver die zich tussen de client en de MCP-server bevindt. Een autorisatieserver is een applicatie die OAuth-toegangstokens uitgeeft nadat is gecontroleerd of de gevraagde toegang is geautoriseerd.

Als een MCP-host verbinding maakt met meerdere services die elk een andere autorisatieserver gebruiken, kan een aanvaller mogelijk één ervan in handen krijgen (bijvoorbeeld door een kwaadaardige service te registreren) en de client ertoe brengen een autorisatiecode die door een legitieme server is uitgegeven naar de kwaadaardige server te sturen. Door deze verwisseling kan de aanvaller zich mogelijk voordoen als de geautoriseerde applicatie en toegang krijgen tot beschermde services.

Zo bescherm je je tegen mix-up-aanvallen

MCP-clients moeten de identiteit van de autorisatieserver gedurende het hele OAuth-proces verifiëren. Concreet moeten ze de issuer-identifier (iss) van de server vergelijken met de verwachte identiteit en afwijkingen weigeren.

Bedreiging #11: compromittering van lokale MCP-servers

Veel MCP-servers draaien op de lokale computer van een gebruiker. De gebruiker installeert de server mogelijk van een derde partij of bouwt die zelf. Als een aanvaller deze lokale MCP-server kan compromitteren, kan die mogelijk toegang krijgen tot grote delen van het lokale systeem.

Een aanvaller kan op verschillende manieren toegang krijgen. De aanvaller kan een kwaadaardige server verspreiden die zich voordoet als een legitieme integratie, de configuratie van een MCP-host zo aanpassen dat die een kwaadaardige opdracht geeft, of toegang krijgen tot een MCP-server die draait in een omgeving met onvoldoende beveiligingsmaatregelen, bijvoorbeeld via DNS-rebinding, waarbij een browser wordt misleid om verzoeken te sturen naar een localhost-service.

Zo bescherm je je tegen compromittering van lokale MCP-servers

Sandboxing en strikte toestemmingsprotocollen zijn belangrijk bij het gebruik van lokale MCP-servers. MCP-servers mogen uitsluitend worden geïnstalleerd van vertrouwde aanbieders, en machtigingen van het besturingssysteem moeten beperken tot welke mappen ze toegang hebben.

MCP-kwetsbaarheden zijn vaak oude bedreigingen in een nieuw jasje

MCP-kwetsbaarheden komen vaak voort uit nieuwe toepassingen van bekende risico's en aanvalsmethoden. MCP biedt aanvallers nieuwe manieren om deze kwetsbaarheden uit te buiten via de interacties tussen LLM's, MCP-servers en externe services.

Er bestaan natuurlijk MCP-specifieke bedreigingen. Het is echter goed om te onthouden dat standaard beveiligingsprotocollen, zoals het afdwingen van strikte autorisatie, het gebruik van vertrouwde aanbieders en bescherming tegen promptinjecties, al veel bijdragen aan de beveiliging van elke MCP-implementatie.