Geeky Saturday: staat jouw MCP-server per ongeluk open naar het internet? Zo check je het vandaag nog

Het is zaterdag. Dus tijd voor iets dat niet alleen interessant klinkt, maar dat je ook echt kunt nalopen.

Werk je met AI-agents, tool-integraties of experimentele agent-workflows, dan is de kans groot dat je de afgelopen maanden iets met MCP hebt gedaan of overwogen. Model Context Protocol is aantrekkelijk omdat het agents op een nette manier laat praten met tools, systemen en data. Maar precies daar zit ook het risico. Trend Micro waarschuwde eind april dat het aantal blootgestelde MCP-servers inmiddels bijna verdrievoudigd is en dat die blootstelling niet alleen leidt tot datatoegang, maar ook tot credential theft, lateral movement en in het slechtste geval volledige cloudcompromise.

Dat klinkt groot, maar het probleem begint vaak klein. Een testserver die “even” op een publiek IP hangt. Een MCP-endpoint zonder goede authenticatie. Een container met environment variables die te veel rechten heeft. Een cloudkoppeling die vanuit een proof of concept nooit meer is afgebouwd. Daarom deze Geeky Saturday: geen abstract verhaal, maar een hands-on checklijst.

Stap 1: check of jouw MCP-server überhaupt publiek bereikbaar is

De eerste vraag is simpel: kan iemand buiten jouw vertrouwde netwerk jouw MCP-server bereiken?

Dat klinkt basaal, maar hier gaat het vaak mis. Zeker in cloudomgevingen of snelle testdeployments wordt een server soms rechtstreeks gepubliceerd zonder dat iemand nog bewust stilstaat bij de exposure. Trend Micro beschrijft juist netwerkblootstelling als de kern van het risico, omdat aanvallers dan niet eerst een intern foothold nodig hebben om met de MCP-laag te praten.

Praktische checks:

• kijk of je MCP-server achter een interne reverse proxy of private network boundary hangt
• controleer security groups, NSG’s, firewall rules en ingress policies
• check of er een publieke DNS-entry of publiek IP aan hangt
• scan je eigen omgeving op open poorten en bekende MCP-endpoints
• laat iemand buiten het eigen netwerk testen of de service bereikbaar is

Als het antwoord “ja, hij is publiek benaderbaar” is, dan heb je meteen je eerste actiestap.

Stap 2: kijk niet alleen naar bereikbaarheid, maar ook naar authenticatie

Een server die bereikbaar is, hoeft nog geen ramp te zijn, zolang authenticatie en autorisatie goed zijn geregeld. Alleen daar zit bij MCP-omgevingen nog regelmatig zwakte. Zeker in experimentele setups is het verleidelijk om authenticatie tijdelijk uit te zetten of te vertrouwen op netwerkvertrouwen alleen.

Trend Micro wees al eerder op MCP-gerelateerde risico’s rond ontbrekende authenticatie en slechte secret handling. Dat maakt exposed servers aantrekkelijk, juist omdat ze vaak dicht op tools en gevoelige context zitten.

Praktische checks:

• vereist jouw MCP-server altijd authenticatie
• gebruik je tokens of secrets die per omgeving gescheiden zijn
• zijn er default credentials of hardcoded secrets aanwezig
• worden tokens geroteerd
• is er least privilege toegepast op wat een verbonden client mag doen

Een MCP-server zonder sterke authenticatie is in feite geen “handige testcomponent”, maar een uitnodiging.

Stap 3: inventariseer welke tools en rechten erachter hangen

Nu komt de belangrijkste vraag: wat kan een succesvolle verbinding eigenlijk doen?

Veel teams denken vooral aan de server zelf, maar vergeten de macht van de gekoppelde tools. Een MCP-server die alleen een onschuldige read-only knowledge source ontsluit, is iets anders dan een server die shell-toegang, repo-acties, cloudbeheer, databases of SaaS-adminfuncties doorgeeft aan een agent.

Daarom moet je per MCP-server exact weten:

• welke tools eraan gekoppeld zijn
• welke accounts of service principals daarachter hangen
• of writes mogelijk zijn
• of secrets, cloudresources of codebases bereikbaar zijn
• of toolacties gelogd worden

Trend Micro koppelt exposed MCP-servers expliciet aan cloudcontrole en verder reikende compromise-scenario’s. Dat is alleen mogelijk omdat de server niet op zichzelf staat, maar een schakel is naar andere systemen.

Stap 4: controleer je secrets en environment variables

In veel agentprojecten leeft gevoelige configuratie in environment variables, config files of container settings. Dat is handig, snel en in development vaak logisch. Maar zodra zo’n omgeving publiek of half-publiek draait, verandert dat gemak in risico.

Kijk daarom expliciet naar:

• API keys
• cloud access tokens
• database credentials
• repo tokens
• webhook secrets
• service account permissies

Vraag je per secret af:

• is dit echt nodig voor deze server
• is dit beperkt genoeg in rechten
• is dit tijdelijk of structureel
• is rotatie ingericht
• wordt misbruik zichtbaar in logging

Als één MCP-server brede secrets bevat, hoeft een aanvaller niet eens veel verder te zoeken.

Stap 5: kijk of je logging bruikbaar genoeg is

Veel teams hebben wel logs, maar geen bruikbare logs. Dat verschil is groot.

Je wilt niet alleen weten dát een MCP-server draaide, maar ook:

• welke client verbinding maakte
• welke tools werden aangeroepen
• welke acties zijn uitgevoerd
• of er onverwachte requests of foutpatronen waren
• of er verbindingen waren buiten normale tijdvakken of herkomst

Zonder die zichtbaarheid kun je achteraf nauwelijks reconstrueren of een incident alleen exposure was, of ook daadwerkelijk misbruik.

Stap 6: maak van je proof of concept geen permanente uitzondering

Dit is misschien wel de meest menselijke fout. Veel risico’s ontstaan niet uit slechte intenties, maar uit succesvolle pilots die nooit opnieuw zijn beoordeeld.

Een team bouwt iets slims. Het werkt. Mensen gebruiken het. Dan blijft het staan. Eerst als test, daarna als handige interne tool, en uiteindelijk als semi-productiecomponent zonder dat iemand formeel heeft gekeken naar netwerkpositie, identiteiten, logging of lifecycle.

Juist MCP-projecten lopen hier risico, omdat ze vaak ontstaan uit experimenteerdrift. Dat is op zich goed. Maar het vraagt wel één discipline: iedere proof of concept die waarde krijgt, moet opnieuw langs security en governance.

Flowerbed-check: zo zou ik vandaag prioriteren

Als je dit vandaag in één uur wilt nalopen, pak dan deze volgorde:

1. Zoek alle MCP-servers op. Weet je niet zeker hoeveel het er zijn, dan is dat al een signaal.
2. Controleer publieksbereikbaarheid. Alles wat direct vanaf internet bereikbaar is, krijgt prioriteit.
3. Begrijp de gekoppelde rechten. Welke tools en accounts zitten erachter?
4. Check secrets en permissies. Vooral op cloudtoegang, repo-acties en write-functies.
5. Beoordeel logging en monitoring. Kun je misbruik detecteren of alleen hopen dat het niet gebeurt?
6. Beslis: sluiten, beperken of herontwerpen. Niet ieder endpoint hoeft weg, maar ieder endpoint moet bewust beheerd worden.

Onze conclusie

MCP is niet het probleem. Onzichtbare of slecht beheerde MCP-exposure is het probleem.

Juist omdat MCP agents krachtiger maakt, moet je harder kijken naar bereikbaarheid, rechten, authenticatie en logging. Trend Micro’s recente waarschuwingen maken duidelijk dat dit geen theoretisch risico meer is. Exposed MCP-servers worden een serieuze aanvalsvector, ook richting cloudomgevingen.

Dus dit is de Saturday takeaway: als je met agents bouwt, check je MCP-server vandaag nog. Niet volgende sprint. Niet na een incident review. Vandaag.

Wil je dat Flowerbed meekijkt naar jouw agent-architectuur, MCP-exposure of AI-governance rondom tools en integraties? Plan dan een afspraak met Flowerbed engineering. Dan brengen we samen in kaart waar de grootste risico’s zitten en hoe je snel van experiment naar beheersbare inzet gaat.