2026-07-31 · RESEARCH · Het Offensive Technology-team

Beveiliging van remote MCP-servers: wat een inventarisatie van 19,321 gepubliceerde servers aantoont

De helft van de servers in het officiële Model Context Protocol-register is remote. We hebben op 31 July 2026 de volledige gepubliceerde populatie opgehaald, 19,321 unieke servers, en geanalyseerd hoe elke server wordt geleverd. 50.0% stelt een remote endpoint beschikbaar, een URL waarmee uw AI-agent via het netwerk verbinding maakt, zodat de code op de machine van iemand anders draait en u alleen de geretourneerde resultaten ziet. De andere helft, 48.3%, zijn lokale packages die op uw eigen systeem draaien waar u ze kunt inspecteren. Die enkele splitsing is het beveiligingsvraagstuk dat in elke MCP-installatie verborgen zit: voegt u een bibliotheek toe die u zelf beheert, of koppelt u uw agent aan de server van een vreemde? Daar komt nog bij dat 30.5% van de servers om een credential vraagt voordat ze werken, en de remote helft verwijst naar 7,420 verschillende hosts van derden. Geen van deze cijfers noemt een specifieke server, een bedrijf of een persoon. Het zijn de basiscijfers van een ecosysteem dat door de meeste teams sneller wordt omarmd dan geauditeerd.

Wat een remote MCP-server daadwerkelijk is

Het Model Context Protocol is de verbindingslaag waarmee een AI-agent externe tools kan aanroepen: een ticket lezen, een database bevragen, een pull request openen. Een server biedt een reeks tools aan, de agent kiest er een, stuurt argumenten en leest het antwoord terug in zijn werkcontext. Er zijn twee manieren waarop die server u kan bereiken. Een local server is een package, op npm, PyPI of een OCI-image, dat u zelf installeert en draait; het communiceert met de agent via stdio op uw eigen machine. Een remote server is een URL. Uw agent opent een verbinding, stuurt tool calls uit en streamt de resultaten terug.

Het verschil is een trust boundary. Bij een lokale server staan de code, de dependencies en het uitgaande netwerkverkeer allemaal op hardware die u beheert en kunt inspecteren. Bij een remote server staat de code op de infrastructuur van de beheerder. U ziet het niet, u kunt de exacte versie niet vastzetten via een hash zoals bij een package, en elk argument dat uw agent stuurt, samen met alles wat uw agent als context voor de aanroep heeft meegegeven, gaat naar die beheerder. De geretourneerde tool-resultaten worden vervolgens door de agent vertrouwd alsof het zijn eigen redenering betreft. Die retourroute is precies waar tool-poisoning en indirecte prompt injection plaatsvinden.

Hoe de 19,321 gepubliceerde servers worden geleverd

Hier is de gehele populatie, onderverdeeld naar hoe elke server uw agent bereikt. Het remote-aandeel valt het meeste op, omdat daar de trust boundary uw machine verlaat.

De precieze verdeling verdient een duidelijke toelichting, omdat de afgeronde helften een detail verbergen. Van de 19,321 servers, zijn er 8,642 (44.7%) uitsluitend remote, zonder lokaal package dat u in plaats daarvan zou kunnen draaien. Nog eens 1,014 (5.2%) bieden zowel een remote endpoint als een lokaal package aan, zodat u kunt kiezen. 9,323 (48.3%) zijn uitsluitend een lokaal package, en een resterend deel van 342 (1.8%) heeft noch een package noch een werkend endpoint opgegeven. Dus wanneer een server remote is, is dit meestal zonder fallback: het gebruik ervan betekent dat u het endpoint van de derde partij accepteert, of de server helemaal niet gebruikt.

De vraag om credentials: een derde van de servers wil uw sleutels

Een tool die uw GitHub-issues leest of uw observability-stack bevraagt, moet zich ergens authenticeren, dus verzoeken om credentials zijn te verwachten. Het getal is alsnog het vermelden waard: 30.5% van de gepubliceerde servers, 5,888 in totaal, geeft minstens één credential op in de vorm van een secret, een omgevingsvariabele of een auth-header waarvan de naam een token bevat zoals KEY, TOKEN, SECRET, PASSWORD, of AUTH. Ongeveer één op de drie servers wil een actief credential voordat deze iets uitvoert.

Combineer dat met het remote-aandeel en het risico wordt duidelijker. Wanneer u een credential aan een lokale server geeft, blijft het secret in uw eigen omgeving en gebruikt de tool het vanaf uw machine. Wanneer u een credential aan een remote server geeft, geeft u het door aan de beheerder of autoriseert u de beheerder om er namens u mee te handelen. In beide gevallen wordt de beheerder houder van uw sleutel. Als die beheerder onzorgvuldig omgaat met logs of gecompromitteerd raakt, wordt het credential dat u voor één tool hebt afgebakend het hulpmiddel van een aanvaller. Least privilege is hier niet optioneel: een server moet een token krijgen dat precies is afgebakend voor wat de tools nodig hebben, en niets meer.

Waar de remote endpoints zich daadwerkelijk bevinden

De remote helft verwijst niet naar een handvol vertrouwde clouds. De 9,656 servers met een remote endpoint zijn verspreid over 7,420 verschillende hosts. De longtail is reëel: 98.1% van die hosts bedient precies één server, wat neerkomt op heel veel onafhankelijke beheerders, elk een afzonderlijke partij die u zou moeten doorlichten. Als uw agenten het register integraal zouden overnemen, zouden ze verbindingen openen naar duizenden verschillende endpoints, waarvan de meeste worden beheerd door partijen waar u nog nooit van hebt gehoord.

Aan het andere uiterste van de verdeling zien we concentratie. De enkele grootste gateway-host bedient 13.5% van alle remote servers, en de tien drukste hosts nemen 18.9% van de remote endpoints voor hun rekening. Ongeveer een kwart van de remote servers maakt gebruik van een gedeelde, multi-tenant host in plaats van een eigen domein. Dat is het tweesnijdend zwaard van elke marktplaats: een paar aggregators verwerken een groot deel van het verkeer, wat handig is, maar ook betekent dat één beheerder of één storing een groot deel van het ecosysteem kan raken. We noemen die hosts niet bij naam; het gaat om de structuur, niet om het adres.

De dreiging die er niet was: verborgen Unicode

Eén goed gedemonstreerde MCP-aanval verbergt instructies voor de agent in de tekstvelden die een server publiceert, met behulp van onzichtbare tekens: Unicode tag-codepunten, zero-width joiners, bidirectionele besturingstekens en ANSI escapes. De agent leest ze, een menselijke beoordelaar niet. We hebben elk voor het model zichtbaar tekstveld van alle 19,321 servers gescand op die codepuntklassen. Het resultaat is een zuivere nul: 0 van de 19,321 servers bevatte een niet-afdrukbaar of op injection gericht teken in hun registry-metadata.

Dat is goed nieuws met een kanttekening, en die kanttekening is belangrijk. Het register publiceert de naam, titel en beschrijving van een server, maar niet de beschrijvingen van de afzonderlijke tools die deze beschikbaar stelt. Dat zijn juist de velden die bij elke aanroep in de context van de agent worden geladen en het meest waardevolle doelwit vormen voor een aanval met verborgen instructies. Onze nul geeft aan dat de metadata-laag van het register zelf vandaag schoon is. Het wil niet zeggen dat de tools achter die servers dat ook zijn, omdat het register dat oppervlak niet beschikbaar stelt om passief te lezen. De eerlijke conclusie is dus specifiek: op de laag die we kunnen meten zonder de server van iemand aan te raken, wordt het kanaal voor onzichtbare tekens niet gebruikt.

Hoe een aanvaller dit register leest

Bekijk deze cijfers vanuit het perspectief van de persoon die beslist of een beveiligingsmaatregel ertoe doet. Een aanvaller die via AI-tooling een organisatie wil binnendringen, heeft twee duidelijke opties, en deze inventarisatie toont aan dat beide op schaal haalbaar zijn. De eerste is het beheren van een server: publiceer iets nuttigs, zorg dat het wordt geïnstalleerd, en u ontvangt rechtmatig elk verzoek dat de agent stuurt en u beheert elk resultaat dat deze leest. Aangezien de helft van het register al remote is, wekt nog een remote server geen argwaan. De tweede is het compromitteren van een beheerder die al het vertrouwen van vele teams geniet, en de concentratie aan de top van de hostverdeling laat zien waar die hefboomwerking zit.

Het cijfer over credentials werkt als versterker. Een derde van de servers krijgt al het vertrouwen van een secret, dus een vergiftigde of overgenomen server is niet beperkt tot het lezen van verkeer; deze kan sleutels bezitten die toegang geven tot de systemen achter de tools. Dit is dezelfde uitbreiding van een footprint die we beschrijven in onze gids over wat aanvallers daadwerkelijk over uw bedrijf kunnen zien, maar dan één laag verder naar binnen verplaatst: het oppervlak is niet langer alleen uw openbare DNS en diensten, het is de verzameling externe servers waar uw agenten geautoriseerd voor zijn om mee te communiceren. Elk daarvan is een dependency, en dependencies zijn hoe moderne inbreuken beginnen.

Hoe u remote MCP-servers onder controle houdt

Niets hiervan is een argument tegen remote MCP-servers. Het is een argument om ze te behandelen als de dependencies van derden die ze zijn. Als u agenten gebruikt tegen MCP-tooling, is dit de actielijst.

• Hanteer een allow-list, geen open register. Bepaal welke specifieke servers uw agenten mogen gebruiken en zet deze vast. Dat de helft van het register remote is, betekent dat u bij de helft kiest voor het vertrouwen in een beheerder. Kies dus bewust in plaats van te installeren bij ontdekking.
• Geef de voorkeur aan lokaal wanneer beide bestaan. Voor de 5.2% die zowel een package als een endpoint aanbieden: het lokale package houdt de code en het netwerkverkeer op uw eigen machine. Kies hiervoor als de tool niet echt remote hoeft te zijn.
• Baken elk credential af per tool. Aangezien 30.5% van de servers om een secret vraagt, geeft u een token uit dat strikt beperkt is tot wat de tools van de server nodig hebben, roteert u dit, en geeft u nooit een breed sleutelrecht aan een server die u niet hebt geauditeerd.
• Behandel tool-output als niet-vertrouwde invoer. Resultaten die door een server worden geretourneerd, kunnen instructies bevatten die op uw agent zijn gericht. Beperk wat de agent ermee mag doen en laat een tool-resultaat niet stilzwijgend geprivilegieerde acties uitvoeren.
• Weet wie er aan de andere kant zit. Een remote endpoint verwijst naar de host van iemand. Zorg dat u voor de servers waar u van afhankelijk bent de beheerder kent, en onthoud dat de meeste hosts in dit register één enkele server bedienen die door één partij wordt beheerd.

Methode, zodat een criticus de cijfers kan vertrouwen

De dataset is van onszelf, opgebouwd uit een openbare bron en uitsluitend geaggregeerd. We hebben de openbare catalogus-API van het officiële Model Context Protocol-register bevraagd en de gehele catalogus doorgenomen op 31 July 2026, waarbij 62,430 versierecords zijn opgeslagen. We hebben dat teruggebracht tot de 19,321 servers die zijn aangemerkt als de huidige, nieuwste versie, wat de gededupliceerde actieve populatie is en de noemer voor elk percentage hier. De wijze van implementatie werd geclassificeerd op basis van de door elke server opgegeven packages en remote endpoints; het credential-cijfer telt elke opgegeven omgevingsvariabele of auth-header waarvan de naam een secret-achtig token bevat; de hostconcentratie werd berekend door de hostnaam van elk remote endpoint op te lossen; en de scan op verborgen tekens controleerde elk tekstveld tegen het Unicode tag-blok, zero-width- en bidirectionele opmaaktekens, ANSI escapes en andere besturings- en private-use-codepunten.

We hebben alleen de openbare API van het register zelf gelezen. We hebben met geen enkele van de vermelde servers verbinding gemaakt, geen enkel verzoek naar een endpoint van een beheerder gestuurd en niets over individuele personen verzameld. Het lezen van een openbare catalogus is een passieve handeling; het aanraken van de hosts daarin is dat niet, en dat hebben we dan ook niet gedaan.

Wat dit niet bewijst

Een getal zonder de beperkingen ervan is marketing, dus hier zijn de grenzen van deze uitkomsten.

• Het is één register. Het officiële register is de centrale catalogus, maar er bestaan servers die er nooit in worden gepubliceerd, en andere overzichten tonen hun eigen lijsten. Dit meet de gepubliceerde, vindbare populatie, niet elke bestaande server.
• Opgegeven, niet geobserveerd. De wijze van implementatie en de credentials zijn afkomstig van wat elke server opgeeft in zijn registervermelding. Een server zou een secret kunnen vereisen dat niet is vermeld, of een package kunnen aanbieden dat niet echt wordt ondersteund. We hebben het manifest gemeten, geen live installatie.
• Remote is een risico-oppervlak, geen oordeel. Een remote server is niet onveilig enkel omdat deze remote is. Veel servers worden goed beheerd door serieuze partijen. De 50.0% is de omvang van de vertrouwensbeslissing, geen telling van kwaadwillende actoren.
• De nul is specifiek afgebakend. Nul hits op verborgen tekens geldt alleen voor de velden op serverniveau in het register. De beschrijvingen per tool die bij elke aanroep in een agent worden geladen, worden niet gepubliceerd voor passieve inspectie, dus dit is geen algehele goedkeuring voor de tools zelf.
• Het is een momentopname. Het register groeit dagelijks. Deze cijfers beschrijven 31 July 2026, niet een trend, en bij een nieuwe meting volgende maand zullen ze veranderen.

Veelgestelde vragen

Zijn remote MCP-servers veilig te gebruiken?

Een remote MCP-server is alleen zo veilig als de beheerder die deze draait, omdat uw agent verzoeken verstuurt naar en resultaten leest van het endpoint van die beheerder. In deze inventarisatie was 50.0% van de servers remote en maakten ze allemaal gebruik van HTTPS, dus het transport is niet de kwetsbaarheid. Vertrouwen is dat wel. Leg de servers vast die u hebt gecontroleerd en geef elke server credentials op basis van least privilege.

Wat is het verschil tussen een lokale en een remote MCP-server?

Een lokale server draait als package op uw eigen machine, waardoor u de code en het netwerkverkeer zelf kunt inspecteren. Een remote server is een URL waarmee uw agent verbinding maakt, zodat de code op de infrastructuur van iemand anders draait en u alleen de antwoorden ziet. In de inventarisatie was 48.3% uitsluitend een lokaal package, 44.7% uitsluitend remote en bood 5.2% beide aan.

Hoeveel MCP-servers zijn er?

Het officiële register vermeldde 19,321 unieke gepubliceerde servers toen we de volledige populatie ophaalden op 31 July 2026, waarbij alleen de nieuwste versie van elke server is meegeteld. Het groeit snel, dus beschouw dit als een momentopname op die datum.

Vereisen MCP-servers API-sleutels of credentials?

Veel wel. In de inventarisatie gaf 30.5% van de servers minstens één credential op in de vorm van een secret, dus ongeveer één op de drie vraagt om een sleutel of token voordat deze werkt. Dat vergroot de impact als de server of de beheerder ervan gecompromitteerd raakt.

Kan een MCP-server uw gegevens stelen?

Een kwaadwillende of gecompromitteerde server kan elk verzoek lezen dat uw agent stuurt en gemanipuleerde resultaten terugsturen naar de context van de agent, wat de basis vormt voor tool-poisoning en prompt-injection. Een remote server voegt daar de infrastructuur van de beheerder aan toe. Deze kan niet verder reiken dan de tools en credentials die u verleent, dus de verdediging bestaat uit least privilege, een geauditeerde allow-list en het niet doorgeven van secrets aan een server die u niet hebt gecontroleerd.

Wordt het MCP-register gecontroleerd?

Nee. Vermelding is enkel een publicatiestap, geen beveiligingsaudit. Het register legt vast waar een server zich bevindt, niet of de beheerder betrouwbaar is. Remote servers verwezen naar 7,420 hosts, waarvan 98.1% slechts één server bediende, dus het grootste deel van de supply chain bestaat uit een lange lijst onafhankelijke beheerders die u individueel zou moeten controleren.

Wat zijn de beveiligingsrisico's van MCP-servers?

De voornaamste risico's zijn een server die vergiftigde tool-output terugstuurt naar uw agent, een remote beheerder die elk verzoek ziet en logt, blootstelling van credentials wanneer een server om sleutels vraagt, en concentratierisico wanneer veel servers achter één gateway zitten. Geavanceerde trucs zoals verborgen Unicode waren afwezig in de metadata van het register in onze scan, 0 van de 19,321, dus het risico op korte termijn zit in vertrouwen en toegang, niet in codering.

Gerelateerde artikelen

• Wat kunnen aanvallers daadwerkelijk zien over uw bedrijf? Het oppervlak dat dit artikel verder naar binnen trekt naar de tooling van uw agent.
• Is p=none voldoende? Dezelfde methode van passieve meting, toegepast op e-mailauthenticatie.
• Autorisatie eerst. Waarom elke meting die wij publiceren netjes binnen de wettelijke grenzen blijft.