Geplaatst inAI & LLM Security

MCP-beveiliging: zo voorkom je dat AI-agents toegang krijgen tot je systemen

MCP maakt het voor AI-agents eenvoudig om bestanden te lezen, tickets op te zoeken, code te schrijven en API’s aan te roepen. Precies daardoor is het ook een van de belangrijkste nieuwe beveiligingsrisico’s: een AI-agent is niet veiliger dan de MCP-servers, tokens, rechten en logging waarmee hij is verbonden.

Veel organisaties behandelen een MCP-server nog als een handige plug-in. Dat is gevaarlijk. Een MCP-server is in feite een integratielaag tussen een AI-agent en je systemen: soms met toegang tot Microsoft 365, GitHub, een database, cloudopslag of interne API’s. Als je die laag niet beheert, weet je niet welke agent welke gegevens kan lezen of welke acties hij kan uitvoeren.

In dit artikel leggen we uit wat MCP is, waarom het een aanvalsoppervlak is geworden, welke risico’s er echt toe doen en hoe je een MCP-omgeving praktisch beveiligt. We sluiten af met een veilige inventarisatie-oefening die je zonder aanvallen in je eigen organisatie kunt uitvoeren.

Wat is MCP?

MCP staat voor Model Context Protocol. Het is een protocol waarmee een AI-agent of AI-client externe mogelijkheden kan ontdekken en gebruiken. Denk aan een coding-assistent die bestanden in een repository leest, een support-agent die tickets doorzoekt, of een bedrijfsagent die documenten ophaalt uit SharePoint of Google Drive.

In een typische MCP-opzet zie je drie lagen:

  • AI-agent of MCP-client: het systeem dat beslist welke tool wordt aangeroepen.
  • MCP-server: de laag die tools beschikbaar stelt, bijvoorbeeld bestandstoegang, zoeken, databasequeries of API-acties.
  • Achterliggende systemen: de bronnen waarmee de MCP-server verbindt, zoals een CRM, cloudopslag, ticketsysteem of interne API.

Het gevaar zit niet in het idee van MCP, maar in de keten. Een agent die “alleen vragen stelt” kan via een MCP-server toegang krijgen tot systemen die veel meer kunnen dan de gebruiker doorheeft. Een agent die documenten samenvat, hoeft bijvoorbeeld geen e-mails te versturen, bestanden te verwijderen of productiedatabases te raadplegen. Toch gebeurt dat in de praktijk regelmatig, omdat rechten breed worden ingesteld en later niet meer worden opgeschoond.

Daarom is MCP-beveiliging geen modelprobleem. Het is een identiteits-, autorisatie- en integratieprobleem. Een AI-agent moet worden behandeld als een systeem met een eigen aanvalsoppervlak, niet als een tekstveld met extra mogelijkheden.

Waarom MCP nu urgent is

AI-agents worden steeds vaker ingezet voor werk dat voorheen door mensen werd gedaan: code schrijven, tickets afhandelen, documenten doorzoeken, systemen configureren of data analyseren. Dat verhoogt de productiviteit, maar ook de impact van een fout of misbruik.

Er spelen drie ontwikkelingen tegelijk:

  • Agents krijgen steeds meer rechten. Ze authenticeren zich vaak via OAuth, API-keys, personal access tokens of opgeslagen wachtwoorden.
  • MCP-servers verschijnen buiten zicht van IT. Medewerkers installeren persoonlijke agents of koppelen die aan zakelijke diensten zonder goedkeuring.
  • Kwetsbaarheden verschuiven naar de AI-stack. Niet alleen het model, maar ook tools, plug-ins, MCP-servers en agentische workflows worden onderdeel van de aanvalsketen.

Onderzoek naar agentic AI en API-security uit oktober 2026 laat zien dat organisaties moeite hebben om agents en hun acties te beheersen. Bijna de helft van de ondervraagde organisaties gaf aan dat een AI-agent in het afgelopen jaar een actie heeft uitgevoerd die niemand had bedoeld, verwacht of geautoriseerd. Hetzelfde onderzoek benoemt MCP expliciet als de laag waarmee agents externe mogelijkheden en bedrijfs-API’s bereiken. [web:19]

Daar komt bij dat het NCSC en andere Nederlandse veiligheidsdiensten waarschuwen dat AI kwetsbaarheden sneller laat vinden en misbruiken. AI verlaagt bovendien de drempel voor aanvallers: technieken die voorheen specialistische kennis vereisten, worden toegankelijker. [web:17][web:18]

Voor een organisatie betekent dat: je hoeft niet te wachten tot er een incident is. De eerste vraag is eenvoudig: welke AI-agents hebben toegang tot welke systemen, met welke identiteit en met welke rechten?

De belangrijkste MCP-risico’s

MCP-risico’s lijken op klassieke API- en integratierisico’s, maar ze worden groter omdat een agent zelfstandig kan beslissen welke tool hij aanroept. De onderstaande risico’s komen in de praktijk het vaakst voor.

Risico Wat kan er gebeuren? Praktisch voorbeeld
Shadow MCP-server Een niet-goedgekeurde server krijgt toegang tot bedrijfsdata. Een medewerker koppelt een persoonlijke AI-agent aan Microsoft 365, Slack of GitHub zonder IT-goedkeuring. [web:19]
Overbodige rechten Een agent kan meer dan nodig voor zijn taak. Een “documentlezende” agent mag ook bestanden verwijderen of e-mails versturen.
Token-misbruik Een aanvaller hergebruikt geldige toegang. Een gelekte OAuth-token of API-key geeft direct toegang tot cloudopslag of repositories. [web:19][web:20]
Kwaadaardige toolbeschrijvingen De agent wordt misleid over wat een tool doet. Een tool belooft “veilig zoeken”, maar voert een gevaarlijke actie uit.
Tool injection Onbetrouwbare content beïnvloedt toolgedrag. Een ticket, webpagina of document stuurt de agent richting een onbedoelde tool-aanroep. [web:23]
Gebrek aan logging Een incident is niet te reconstrueren. Niemand weet welke agent, welke tool en welke argumenten zijn gebruikt.
Te veel autonomie Een agent voert acties uit zonder menselijke controle. Een agent verwijdert automatisch “verouderde” bestanden of verstuurt namens een medewerker een e-mail.

De laatste twee risico’s sluiten direct aan bij eerdere artikelen op deze site. Bij prompt injection en context exploits gaat het om het beïnvloeden van wat een model als instructie behandelt. Bij excessive agency gaat het om de vraag of een agent te veel macht heeft gekregen. MCP is vaak de plek waar die twee risico’s samenkomen.

MCP is niet automatisch onveilig

Het is belangrijk om dit goed te benoemen: MCP is niet inherent slecht. Het protocol lost een reëel probleem op. Zonder standaarden moet elke AI-applicatie opnieuw integraties bouwen met bestandssystemen, databases, SaaS-platforms en interne API’s. MCP maakt die integraties herbruikbaar en gestandaardiseerd.

Het probleem ontstaat wanneer organisaties MCP-servers implementeren alsof het onschuldige plug-ins zijn. Een MCP-server die toegang geeft tot een bestandsshare, een database of een API is geen plug-in. Het is een systeem met identiteit, rechten, logging en een eigen aanvalsoppervlak.

Een veilige MCP-opzet heeft daarom dezelfde basisprincipes als elke serieuze integratie:

  • Weet welke MCP-servers er draaien.
  • Weet welke identiteit elke agent gebruikt.
  • Beperk wat elke agent mag lezen en doen.
  • Controleer elke gevaarlijke actie.
  • Log alles wat relevant is voor onderzoek.

Klinkt dat vanzelfsprekend? In de praktijk is het dat vaak niet. Veel teams weten wel welke AI-chatbot ze gebruiken, maar niet welke MCP-servers er in de organisatie draaien, welke OAuth-scopes zijn goedgekeurd of welke agent toegang heeft tot welke share.

Mini-lab: inventariseer je MCP-aanvalsoppervlak

Deze oefening vereist geen aanvallen, exploits of toegang tot productiesystemen. Het doel is inzicht krijgen in welke agents, servers en rechten er bestaan. Je kunt dit veilig uitvoeren in je eigen organisatie, mits je alleen systemen en data behandelt waarvoor je bevoegd bent.

Stap 1: maak een MCP-inventarisatie

Maak een tabel met minimaal de volgende kolommen:

MCP-server Eigenaar Gebruikers/agents Tools Achterliggend systeem Authenticatie Rechten Logging
Bestandsserver IT Coding-agent Lezen, schrijven Gedeelde schijf OAuth Lezen + schrijven Ja/nee
Ticketserver Support Support-agent Zoeken, updaten Ticketsysteem API-key Lezen + updaten Ja/nee
Web-fetch Development Onderzoeksagent URL ophalen Internet Geen Alleen lezen Onbekend

Vul de tabel eerst in op basis van documentatie, configuratiebestanden en bestaande integraties. Vraag daarna teams expliciet: “Welke AI-agent of MCP-server gebruiken jullie, en waar heeft die toegang toe?”

Let vooral op antwoorden als “die staat gewoon in mijn editor”, “die gebruikt mijn account” of “die heeft toegang tot mijn bestanden”. Dat zijn precies de situaties waarin persoonlijke toegang en zakelijke systemen met elkaar verweven raken.

Stap 2: markeer risicovolle combinaties

Geef elke rij een risico-indicatie:

  • Rood: de agent kan schrijven, verwijderen, versturen, code uitvoeren of productiedata benaderen.
  • Oranje: de agent kan gevoelige data lezen of gebruikt langlevende tokens.
  • Groen: de agent heeft alleen leesrechten op niet-gevoelige, tijdelijke data.

Let vooral op deze combinaties:

  • Een agent met internettoegang én toegang tot interne documenten.
  • Een coding-agent met shell-toegang én cloudcredentials.
  • Een support-agent die tickets kan lezen én e-mails kan versturen.
  • Een MCP-server met een brede OAuth-scope, terwijl hij maar één specifieke taak nodig heeft.
  • Een agent die draait onder het persoonlijke account van een medewerker in plaats van onder een eigen service-identiteit.

Stap 3: test de minimale-rechtenprincipes

Kies één niet-productie MCP-server en controleer de volgende vragen:

  1. Kan de agent een actie uitvoeren die niet nodig is voor zijn taak?
  2. Is er een menselijke goedkeuring nodig vóór onomkeerbare acties?
  3. Is de gebruikte identiteit gescheiden van de identiteit van de medewerker?
  4. Zijn tokens kortlevend en beperkt in scope?
  5. Is zichtbaar welke tool-aanroepen zijn gedaan, met welke argumenten en welk resultaat?

De uitkomst is meestal niet “MCP is onveilig”, maar: “deze specifieke integratie heeft te veel vertrouwen gekregen.” Dat is een bruikbare uitkomst. Het geeft je een concreet punt om te verbeteren, in plaats van een algemene waarschuwing over AI.

Beveiligingsmaatregelen die werken

Prompt filtering en een strengere system prompt kunnen helpen, maar ze zijn geen beveiligingsgrens. Een model kan misleid worden; daarom moet autorisatie buiten het model plaatsvinden. Dit principe komt ook terug in onze gids over AI- en LLM-security.

1. Behandel elke MCP-server als een interne API

Registreer eigenaarschap, versie, omgeving, gebruikte scopes, achterliggende systemen en contactpersoon. Een MCP-server zonder eigenaar is in de praktijk een onbeheerd systeem.

Minimale documentatie per MCP-server:

  • Wat doet de server?
  • Welke agent(s) gebruiken hem?
  • Welke achterliggende systemen raakt hij aan?
  • Welke identiteit en scopes gebruikt hij?
  • Welke acties zijn leesacties en welke zijn schrijfacties?
  • Wie is verantwoordelijk bij een incident?

2. Gebruik per-agent identiteiten

Laat een agent niet draaien onder de volledige identiteit van een medewerker. Gebruik een aparte service-identiteit met alleen de rechten die nodig zijn voor die specifieke agent.

Als een medewerker de organisatie verlaat, moet de toegang van de agent niet per ongeluk blijven bestaan. En als een agent misbruikt wordt, wil je kunnen zien dat het om de agent ging, niet om de persoonlijke account van een medewerker.

3. Beperk OAuth-scopes en tokens

Vraag alleen de minimaal benodigde scopes. Gebruik waar mogelijk kortlevende tokens, rotatie en aparte credentials per omgeving. Voorkom dat agents langlevende personal access tokens of opgeslagen wachtwoorden gebruiken.

Een agent die alleen bestanden moet kunnen lezen, heeft geen scope nodig om bestanden te verwijderen. Een agent die tickets moet kunnen doorzoeken, hoeft meestal geen tickets te kunnen sluiten of verwijderen.

4. Scheid lezen van schrijven

Een agent die documenten samenvat hoeft meestal niet te schrijven. Een agent die code schrijft hoeft niet automatisch productie te deployen. Maak die scheiding expliciet in rechten, niet alleen in een prompt.

Een goede vuistregel: leesrechten zijn een functie, schrijfrechten zijn een risicobeslissing. Voor elke schrijfactie moet je kunnen uitleggen waarom de agent die nodig heeft, wat het ergste gevolg is en wie de actie kan goedkeuren.

5. Zet menselijke goedkeuring op gevaarlijke acties

Vereis bevestiging bij acties zoals e-mail versturen, bestanden verwijderen, betalingen doen, rechten wijzigen of code naar productie pushen. Het model mag voorstellen doen; de autorisatie moet buiten het model plaatsvinden.

Dit is vooral belangrijk bij agentische workflows. Een agent die alleen informatie ophaalt, is makkelijker te beveiligen dan een agent die zelfstandig beslist om een wijziging door te voeren. Hoe autonomer de agent, hoe strakker de controles moeten zijn.

6. Monitor tool-aanroepen

Log minimaal:

  • Welke agent de aanroep deed.
  • Welke MCP-server en tool werd gebruikt.
  • Welke argumenten werden meegestuurd.
  • Welke identiteit en scopes werden gebruikt.
  • Wat het resultaat was.
  • Of er een menselijke goedkeuring was.

Zonder deze trace is het vrijwel onmogelijk om te bepalen of een agent normaal werkte of werd misbruikt. Logging is dus geen administratieve luxe, maar een voorwaarde voor incidentonderzoek.

Wat betekent dit voor Nederlandse organisaties?

Voor Nederlandse organisaties is MCP vooral een kwestie van toegangsbeheer en zichtbaarheid. De vraag is niet alleen of je AI gebruikt, maar welke digitale sleutels en machtigingen je aan AI geeft.

Voor organisaties die onder NIS2 vallen, past MCP-beheer vanzelfsprekend in bestaand beveiligingsbeleid: asset-inventarisatie, toegangsbeheer, logging, incidentrespons en leveranciersbeheer. Een MCP-server is een asset. Een agent met OAuth-toegang is een identiteit. Een tool-aanroep is een gebeurtenis die je moet kunnen terugzien in je logging.

Voor het MKB is de insteek eenvoudiger: sta persoonlijke AI-agents niet zomaar toe op zakelijke accounts, en koppel AI alleen aan systemen waarvan je de rechten volledig kunt uitleggen. Begin niet met een compleet AI-governanceprogramma, maar met één vraag: “Welke acties mag deze assistent uitvoeren als hij misleid wordt?”

Deze vraag sluit aan bij de bredere trend die we eerder beschreven in ons artikel over het cyberdreigingslandschap: AI versnelt zowel aanval als verdediging. De organisaties die het beste voorbereid zijn, zijn niet noodzakelijk degene met de meeste AI-tools, maar degene die weten welke rechten en gegevens die tools gebruiken.

Veelgemaakte fouten

  • “De agent heeft alleen leesrechten.” Leesrechten kunnen al gevoelig zijn als de agent toegang heeft tot e-mail, HR-data, contracten of klantgegevens.
  • “We vertrouwen de leverancier.” Een bekende leverancier vermindert risico, maar elimineert het niet. Blijf scopes, tokens en logging controleren.
  • “De system prompt verbiedt het.” Een instructie in een prompt is geen autorisatiecontrole.
  • “We loggen het eindantwoord.” Het eindantwoord zegt weinig zonder de gebruikte tools, argumenten en identiteiten.
  • “We hebben één centrale AI-agent.” Zelfs dan kunnen plug-ins, MCP-servers en persoonlijke integraties extra rechten introduceren.

Checklist voor vandaag

  • Maak een inventaris van alle MCP-servers en AI-agents.
  • Identificeer welke agents OAuth-toegang, API-keys of opgeslagen wachtwoorden gebruiken.
  • Verwijder ongebruikte of ongeautoriseerde MCP-integraties.
  • Vervang brede persoonlijke tokens door beperkte service-identiteiten.
  • Beperk elke tool tot de minimaal benodigde rechten.
  • Vereis menselijke goedkeuring voor onomkeerbare acties.
  • Log elke tool-aanroep, inclusief argumenten en resultaat.
  • Test regelmatig of een agent meer kan dan nodig is.

Tot slot

MCP maakt AI nuttiger omdat het agents verbindt met de systemen waarin organisaties echt werken. Maar diezelfde verbinding maakt MCP tot een serieuze beveiligingslaag. Een agent die alleen kan praten, is beperkt gevaarlijk. Een agent die via MCP kan lezen, schrijven, authenticeren en acties uitvoeren, moet worden behandeld als een systeem met productietoegang.

De beste eerste stap is daarom geen nieuw securityproduct, maar een eerlijke inventarisatie. Weet welke agents er draaien, welke MCP-servers ze gebruiken, welke identiteiten ze hebben en welke acties ze mogen uitvoeren. Daarna kun je gericht rechten verkleinen, logging verbeteren en menselijke controles inrichten.

Heb je ervaring met MCP in je eigen organisatie, of wil je een praktische lab-opzet delen? Laat het weten. We werken graag samen aan concrete, veilige oefeningen voor AI-security; zie ook onze CTF- en lab-pagina.

Bronnen en verder lezen

Tags: