MCP (Model Context Protocol) werd gepositioneerd als een universele schakel voor AI-modellen, agents en ontwikkelomgevingen—vergelijkbaar met hoe USB-C verschillende apparaten verenigt. Inmiddels hebben veel teams en ontwikkelaars MCP-servers gebouwd en gedeeld. Maar juist in die praktijk zit een opvallende blinde vlek: de MCP server-risico’s ontstaan niet door het protocol zelf, maar door het vertrouwen dat organisaties eraan geven.
Een onderzoeksteam keek daarom naar wat mensen daadwerkelijk installeren: community-publicaties in populaire MCP-marktplaatsen. Daarbij troffen ze geen effectieve “bouncer” die servers op veiligheid toetst, én geen sluitende mechanismen om te verifiëren wat een server echt doet—met directe gevolgen voor governance en datastromen.
Waarom MCP server-risico’s vooral een vertrouwensprobleem zijn
De kern van het probleem is simpel: iedereen kan een MCP-server schrijven en publiceren. Waar mobiele app-distributie in het verleden te maken kreeg met geautomatiseerde controles voordat apps naar gebruikers gingen, kent het MCP-ecosysteem volgens het onderzoek geen vergelijkbaar loket dat inhoud en gedrag vóór publicatie automatisch verifieert.
Zelfs als er wel “reviews” zouden bestaan, lossen die het fundamentele gat niet volledig op. Het gaat namelijk om een verschil tussen wat je in een repository ziet en wat er op de server daadwerkelijk wordt uitgevoerd. Code review vertelt je wat een ontwikkelaar publiceert, maar niet noodzakelijk wat de operationele endpoint draait zodra een agent verbinding maakt.
Met andere woorden: de repository kan “veilig” ogen, terwijl de server in de praktijk ander gedrag vertoont. Dat maakt trust meteen onderdeel van het aanvalsoppervlak.
Wat er mis kan gaan zodra een agent verbinding maakt
Governance is de laatste jaren strakker geworden in cloudomgevingen. Denk aan regels voor datalocatie, Zero Trust-achtige grenzen, gedetailleerde toegangsrechten (IAM) en supply chain-audits. In veel organisaties blijven die controles hangen bij klassieke integraties—maar MCP-verbindingen kunnen buiten dat gecontroleerde kader vallen.
Het onderzoek analyseerde 15.465 publiek geïndexeerde MCP-servers over vijf MCP-registries. Na deduplicatie resulteerden de resultaten in 5.095 unieke hostnames. Daarmee ontstond een beeld van waar MCP-servers fysiek of logisch draaien en welke datastromen mogelijk zijn als agents de verbindingen gebruiken.
1) Data kan buiten geaccepteerde jurisdicties terechtkomen
Een deel van de hostnames blijkt buiten de Verenigde Staten te resideren. Concreet losten 15,6% van de hostnames op naar infrastructuur buiten de VS. Het rapport noemt daarbij ook cases binnen China en Rusland.
Voor security teams betekent dit: wanneer een agent data naar zo’n MCP-server verstuurt, kan die informatie in een land belanden waar het team geen expliciet goedkeuringsproces voor heeft doorlopen. Dat raakt aan compliance, datalocatiebeleid en incidentafhandeling.
2) Sommige servers lijken op persoonlijke netwerken te draaien
Verder wijst het onderzoek op traffic die via consumententunneldiensten loopt. 0,45% van de onderzochte routeerde verkeer via consumer tunneling services, met name ngrok (zonder exacte verdere detaillering in deze samenvatting).
Het onderzoek koppelt dit aan publieke MCP-servers die mogelijk draaien op machines van particulieren en vermoedelijk via thuisnetwerken. Dat maakt de operationele stabiliteit en controleerbaarheid kwetsbaar: het is lastiger om harde beveiligingsgaranties, monitoring en toegangsscheiding af te dwingen op “onbekende” endpoints.
3) Domeinen kunnen “verdwijnen” en opnieuw op een andere eigenaar belanden
Een ander aandachtspunt zijn “dangling domains”: domeinen die niet meer resolven. In de set viel 2,3% no-resolving hostnames op. Daarnaast stonden er gevallen op verlopen domeinen die volgens het onderzoek opnieuw te registreren zijn voor relatief lage jaarlijkse kosten.
Het gevolg daarvan is direct: als een domein wisselt van eigenaar, kan een nieuwe partij dezelfde serveridentiteit voortzetten. Agents die nog steeds geconfigureerd zijn om daarheen te verbinden, kunnen zonder dat het team het tijdig merkt nieuwe (onbekende) gedragspatronen oproepen.
De locatie en het gedrag van een server kunnen veranderen
Zelfs als een MCP-server vandaag op een “vriendelijke” plek draait, betekent dat niet dat het morgen zo blijft. Het onderzoek wijst erop dat operators servers kunnen starten op een schoon ogend IP-adres en later de routing aanpassen naar een andere locatie.
Daarmee wordt het moeilijker om statische aannames te gebruiken. Governance is niet alleen een momentopname, maar een proces: je wilt kunnen aantonen waar verbindingen naartoe gaan en wat er wordt uitgevoerd gedurende de hele gebruiksperiode.
Waarom “in GitHub we trust” hier niet genoeg is
In de wereld van software supply chain is het al vaker misgegaan met overschat vertrouwen in wat je ziet. Het onderzoek sluit aan op die les: als je alleen vertrouwt op zichtbare broncode in een repository, mis je het gedrag dat daadwerkelijk op de server gebeurt.
Dat verschil wordt bij MCP extra belangrijk omdat verbindingen vaak draaien in geautomatiseerde agentworkflows. Zodra een agent consistent met een endpoint communiceert, wordt het doel automatisch een onderdeel van de operationele keten. Dan is het niet meer “alleen een dependency”, maar een runtime component van je AI-omgeving.
Wat security teams nu kunnen doen (zonder te wachten op een perfecte markt)
Het onderzoek concludeert dat het protocol zelf niet het probleem is. De aanbeveling is daarom: maak het vertrouwen afdwingbaar. Zolang marktplaatsen niet voorzien in sterke vetting, code signing en origin verification, ligt de verantwoordelijkheid bij ondernemingen om hun eigen controles te bouwen.
Praktisch betekent dat doorgaans het volgende:
- Stel beleid op voor toegestane endpoints: verbind agents niet automatisch met “alles wat publiek is”, maar met een gecontroleerde allowlist.
- Werk governance rondom datalocatie bij: toets niet alleen cloudaccounts, maar ook externe endpoints waar gegevens naartoe kunnen.
- Modelleer het runtime gedrag: neem aan dat serveruitvoering kan afwijken van wat in de repository zichtbaar is.
- Monitor en detecteer afwijkingen: let op wijzigingen in DNS-resolutie, nieuwe routingpatronen of onverwachte geografische verschuivingen.
- Maak “geen review” zichtbaar: als een endpoint geen duidelijke verifieerbare herkomst heeft, behandel die als verhoogd risico in plaats van als standaard trust.
Deze aanpak voelt streng, maar past bij een realiteit waarin “trust” anders al snel verandert in een aanvalskans. Het is—zoals het onderzoek het frameert—een jungle, en zonder extra bouncer fungeert de omgeving zelf als filter.
Extra context: live sessie over AI attack surface
Wie dieper wil gaan, kan aansluiten bij een webinar dat het onderzoeksteam aankondigt. Daarin staat centraal hoe AI de cloud threat landscape verandert en wat security teams kunnen doen. De sessie wordt vermeld op 13 oktober om 12:00 PM ET, met sprekers van Latio en OX Security.
Als je daarnaast zoekt naar bredere lessen over hoe agenten misbruik kunnen maken van toegang of hoe security het best rapporteerbaar maakt richting het bestuur, zijn er op de site ook relevante publicaties. Zo kun je bijvoorbeeld lezen over CISO boardvragen om security rapportage scherper te maken, of over OpenAI-agenten bij Wikimedia en de risico’s daarvan.
Conclusie
MCP server-risico’s zijn in feite risico’s van vertrouwen. Het onderzoek laat zien dat er veel publieke MCP-servers beschikbaar zijn zonder harde guardrails, review of afdwingbare verificatie. Daardoor kunnen agents verbinding maken met endpoints buiten geaccepteerde jurisdicties, via onzekere thuisnetwerk-achtige routes, of naar domeinen die later van eigenaar wisselen.
Wil je MCP inzetten binnen een onderneming, behandel dan elke verbinding als onderdeel van je security perimeter. Pas allowlisting, governance, monitoring en runtime threat modeling toe—tot marktplaatsen echte “bouncers” bieden.
Bron: https://thehackernews.com/2026/10/welcome-to-jungle-what-we-found-inside.html
