Model Context Protocol: vertrouwen bindt aan de naam, niet aan de inhoud

Eén goedkeuring, oneindig veel aanroepen

In de praktijk wordt een MCP-server goedgekeurd op het moment dat een host ermee verbindt: de tool-beschrijvingen komen binnen, een gebruiker keurt ze goed, en vanaf dat moment kan het model ze aanroepen. Wat er daarna gebeurt staat niet beschreven als een herhaalde controle — het is een lijst die is opgehaald, niet een contract dat bij elke aanroep opnieuw wordt getekend.

Dat gat tussen “goedgekeurd bij het verbinden” en “vertrouwd bij elke aanroep daarna” is precies waar drie los van elkaar gepubliceerde kwetsbaarheden op uitkomen, elk op een andere plek in het protocol.

Drie plekken waar het vertrouwen breekt, met hetzelfde patroon

Tool poisoning. Invariant Labs omschreef het in april 2025 zo: “malicious instructions embedded within MCP tool descriptions that are invisible to users but visible to AI models.” De tool-beschrijving die een gebruiker in een goedkeuringsscherm ziet, is niet gegarandeerd dezelfde tekst als wat het model leest — en het model volgt wat het leest. Hoe wijdverbreid dit werkt, mat MCPTox (augustus 2025) op 45 operationele MCP-servers en 353 echte tools.

De auteurs noteren zelf waarom dit geen randgeval is: “more capable models are often more susceptible, as the attack exploits their superior instruction-following abilities.” Een aanval die op instructievolgen leunt, wordt niet zwakker naarmate een model beter instructies volgt — hij wordt sterker.

Rug pull. Bij tool poisoning is de server vanaf het begin kwaadaardig. Bij een rug pull is dat niet zo: de server is legitiem op het moment van goedkeuren, en verandert pas daarna. Check Point Research documenteerde dat patroon in augustus 2025 als CVE-2025-54136 (“MCPoison”) in de Cursor-editor: een aanvaller committet een onschuldige MCP-configuratie naar een gedeelde repository, wacht tot een slachtoffer die goedkeurt, en wijzigt de configuratie daarna in een kwaadaardig commando. Cursor voerde het gewijzigde commando uit zonder een nieuwe goedkeuring te vragen, omdat — in de woorden van de onderzoekers — “once an MCP is approved, future modifications to its command or arguments are trusted without any additional validation or prompt”, en die vertrouwensbinding gold “only to the name” van de tool-entry, niet de inhoud ervan. Cursor 1.3 (eind juli 2025) verplicht sindsdien een nieuwe goedkeuring bij elke wijziging.

Confused deputy. De derde plek zit niet in de tool-beschrijving maar in de autorisatielaag. De officiële Security Best Practices van het protocol zelf beschrijven het “confused deputy”-patroon in detail: een MCP-proxyserver die met een vaste client_id tegen een externe autorisatieserver praat, gecombineerd met dynamische clientregistratie en een consent-cookie, laat een aanvaller een autorisatiecode naar zijn eigen server omleiden zonder dat de gebruiker een tweede keer iets goedkeurt. De documentatie is expliciet over de oorzaak: de proxy behandelt toestemming als eigenschap van het gedeelde client_id, niet van de specifieke cliënt die op dat moment iets vraagt.

De lethal trifecta: er hoeft geen kwaadwillende server bij te zijn

Alle drie de kwetsbaarheden hierboven vragen om iets dat kapot is — een vervalste beschrijving, een gewijzigde configuratie, een lekke proxy. Het scenario dat Simon Willison in juni 2025 de “lethal trifecta” noemde, heeft dat niet nodig. Zijn stelling: zodra een agent tegelijk beschikt over (1) toegang tot privédata, (2) blootstelling aan onvertrouwde inhoud, en (3) een manier om naar buiten te communiceren, is het resultaat exploiteerbaar — ongeacht of elke afzonderlijke tool zich precies gedraagt zoals beloofd.

MCP maakt die combinatie makkelijker dan wat eraan voorafging, simpelweg omdat het protocol bedoeld is om tools van verschillende aanbieders moeiteloos samen te voegen in één agent. Precies dat overkwam de officiële GitHub-server (14.000 sterren) in mei 2025: Invariant Labs liet zien dat een gebruiker die zijn agent vraagt “bekijk de open issues” op een publieke repository, genoeg is. Een aanvaller plaatst een issue met verborgen instructies; de agent leest het tijdens een routinetaak, wordt daardoor omgeleid, haalt gegevens uit een privérepository van dezelfde gebruiker in de context, en publiceert die — via een eigen, autonoom geopende pull request — in de publieke repository. Geen van de tools loog over wat hij deed: “issues lezen”, “privécode lezen” en “een PR openen” werkten allemaal precies zoals gedocumenteerd. Het probleem was dat één agent alle drie tegelijk mocht.

De onderzoekers waren daar zelf duidelijk over: “this is not a flaw in the GitHub MCP server code itself, but rather a fundamental architectural issue that must be addressed at the agent system level.” Willison's eigen overzicht bevestigt dat dit geen incident is maar een patroon — hij noemt vergelijkbare gevallen bij onder meer Microsoft 365 Copilot, GitLab's Duo Chatbot, Slack en Google Bard.

Wat de spec zelf al zegt

Geen van dit alles is onbekend bij wie het protocol onderhoudt — voor een deel ervan. De Security Best Practices behandelen confused deputy uitgebreid, met een compleet stappenplan en verplichte tegenmaatregelen. Ze verbieden token passthrough met zoveel woorden (“MCP servers MUST NOT accept any tokens that were not explicitly issued for the MCP server”), beschrijven SSRF via OAuth-metadata-discovery, en behandelen het compromitteren van lokale servers die met dezelfde rechten draaien als de client zelf.

Wat op diezelfde pagina — met versiedatum 2026-07-28, dus recenter dan alle drie de kwetsbaarheden hierboven — niet met zoveel woorden voorkomt, zijn de termen “tool poisoning” en “rug pull”. De onderliggende oorzaak (een tool-lijst die kan wijzigen zonder herkeuring) raakt de spec aan via notifications/tools/list_changed, maar of een client daarbij opnieuw om goedkeuring moet vragen is een implementatiekeuze, geen protocolvereiste. Cursor loste dat pas op in versie 1.3, eind juli 2025 — als productbeslissing, niet omdat de spec het voorschreef.

Wat ik hieruit zou bouwen

• Behandel een MCP-server als onvertrouwde invoerbron, niet als een aangesloten functiebibliotheek. Zowel de beschrijving als de respons van een tool zijn tekst die van buiten komt — dezelfde categorie als de issue, de pagina, het bestand uit het eerdere stuk.
• Toets elke nieuwe servercombinatie aan de lethal trifecta vóórdat hij live gaat, niet erna. Het GitHub-geval had geen bug nodig, alleen een combinatie.
• Pin een tool-definitie op inhoud, niet op naam. Een hash van de beschrijving die verandert zonder nieuwe goedkeuring, is precies het signaal dat een rug pull achterlaat.
• Schaal credentials per server af. Token passthrough is door de spec zelf verboden, en dat verbod bestaat omdat een token dat overal geldig is, ook overal fout kan gaan.
• Vertrouw “officieel” en “populair” niet als vervanging voor gelezen code. De GitHub-server had 14.000 sterren en werkte precies zoals beloofd — dat was het probleem, niet de oplossing.

Wat dit onderzoek niet aantoont

• Niet dat MCP onveiliger is dan een eigen, ongestandaardiseerde tool-integratie zou zijn geweest — geen van de bronnen hier maakt die vergelijking.
• Niet dat elke MCP-server een risico is. MCPTox test hoe agents reageren op vergiftigde metadata, niet hoeveel van de 45 onderzochte servers zelf al vergiftigd waren.
• Niet dat CVE-2025-54136 nog openstaat — die is gepatcht in Cursor 1.3.
• Niet dat de drie beschreven patronen de volledige dreiging dekken. De spec zelf noemt aanzienlijk meer, waaronder SSRF, mix-up-aanvallen en misbruik van localhost-redirects.
• En niet dat een geschreven MUST in een specificatie hetzelfde is als gedrag in een implementatie — CVE-2025-54136 laat precies het tegendeel zien.

Waar het ophoudt