← Nieuwste papers
💻 computer science

MCP-DPT: A Defense-Placement Taxonomy and Coverage Analysis for Model Context Protocol Security

Dit paper introduceert een taxonomie voor de plaatsing van verdedigingsmaatregelen binnen het Model Context Protocol (MCP) die aantoont dat bestaande beveiligingsbenaderingen vaak architectonisch misaligneren en dat er kritieke gaten bestaan in de bescherming op de lagen van host-orchestratie, transport en supply chain.

Oorspronkelijke auteurs: Mehrdad Rostamzadeh, Sidhant Narula, Nahom Birhan, Mohammad Ghasemigol, Daniel Takabi

Gepubliceerd 2026-04-10
📖 4 min leestijd☕ Koffiepauze-leesvoer

Oorspronkelijke auteurs: Mehrdad Rostamzadeh, Sidhant Narula, Nahom Birhan, Mohammad Ghasemigol, Daniel Takabi

Oorspronkelijk artikel gelicentieerd onder CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). Dit is een AI-gegenereerde uitleg van het onderstaande artikel. Het is niet geschreven of goedgekeurd door de auteurs. Raadpleeg het oorspronkelijke artikel voor technische nauwkeurigheid. Lees de volledige disclaimer

Stel je voor dat een Grote Taalmodel (LLM) een slimme, maar soms naïeve assistent is. Deze assistent kan niet alleen praten, maar ook acties uitvoeren: e-mails sturen, bestanden zoeken, of code schrijven. Om dit te kunnen doen, heeft de assistent "gereedschappen" nodig.

MCP (Model Context Protocol) is de standaard die deze assistent in staat stelt om nieuwe gereedschappen van derden (zoals een weer-app, een database of een chatbot) aan te sluiten. Het is alsof je een universele stopcontactadapter hebt die het mogelijk maakt om elk elektrisch apparaat op je muur aan te sluiten.

Het probleem? Iedereen kan een nieuw stopcontact of een nieuw apparaat op de markt brengen. En sommige van die apparaten zijn niet wat ze zeggen te zijn.

Het Probleem: Een onveilige bouwplaats

De auteurs van dit paper merken op dat we tot nu toe vooral gekeken hebben naar hoe hackers deze slimme assistenten kunnen misleiden (bijvoorbeeld door valse instructies in de gereedschappen te verstoppen). Maar ze hebben vergeten te vragen: "Wie is er precies verantwoordelijk om dit te stoppen?"

Stel je voor dat je een huis bouwt met een onbekende aannemer, een twijfelachtige leverancier van ramen, en een elektricien die je niet kent. Als er brand ontstaat, weten we niet of de brandweer (de software), de aannemer (de server), of de leverancier (de markt) de schuld is.

De Oplossing: Een "Verdedigings-Plattegrond"

De auteurs hebben een nieuwe manier bedacht om naar veiligheid te kijken, genaamd MCP-DPT. In plaats van alleen te kijken naar de aanval, kijken ze naar waar je de beveiliging moet plaatsen in het hele systeem.

Ze hebben het systeem opgedeeld in 6 lagen, alsof je een burcht verdedigt:

  1. De Koning (Het Model): De slimme assistent zelf. Kan hij niet overtuigd worden om slechte dingen te doen?
  2. De Slotmeester (De Host/Toepassing): De software die de assistent draait. Hij moet controleren of de assistent niet te veel macht krijgt.
  3. De Bode (De Client/SDK): De boodschapper die de assistent en de gereedschappen verbindt. Is de boodschapper eerlijk?
  4. De Werkplaats (De Server/Het Gereedschap): Waar de daadwerkelijke actie plaatsvindt. Is het gereedschap veilig?
  5. De Weg (Transport/Netwerk): De weg waarop de berichten reizen. Kan iemand onderweg de post stelen of vervalsen?
  6. De Markt (Registries/Supply Chain): Waar je de nieuwe gereedschappen kiest. Is de leverancier betrouwbaar?

De Grote Ontdekking: We verdedigen de verkeerde poort

De auteurs hebben gekeken naar alle bestaande beveiligingssoftware (zoals virusscanners en firewall-tools) die er nu is. Hun conclusie is verrassend en zorgwekkend:

  • We zijn gek op het verdedigen van de Werkplaats (Laag 4): We hebben veel tools die kijken of een specifiek gereedschap veilig is voordat het wordt gebruikt. Dit is als het controleren van elke baksteen die in de muur wordt gelegd.
  • We vergeten de Weg en de Markt (Laag 5 en 6): Er is bijna geen enkele tool die controleert of de weg veilig is (of hackers berichten vervalsen) of of de markt waar we de gereedschappen kopen betrouwbaar is.
  • De Slotmeester slaapt (Laag 2): De software die de assistent aanstuurt, heeft vaak geen sterke beveiliging om te voorkomen dat de assistent per ongeluk iets gevaarlijks doet.

Een Creatieve Analogie: De "Rug Pull"

Stel je voor dat je een nieuwe robot koopt (een gereedschap) bij een onbekende verkoper op een rommelmarkt (de Markt).

  • De robot ziet er perfect uit en belooft je te helpen met tuinieren.
  • De huidige beveiliging kijkt alleen naar de robot zelf als hij in je tuin staat (Laag 4). Hij ziet er veilig uit.
  • Maar de verkoper heeft een verborgen knop in de robot geplaatst die pas na 3 dagen wordt geactiveerd (een "rug pull").
  • Omdat niemand de markt (de verkoper) controleerde en niemand de weg (de leveringsketen) bewaakte, komt de robot binnen.
  • Zodra de knop wordt ingedrukt, steelt de robot je gouden tuinmeubelen.
  • De beveiliging in je tuin (Laag 4) is te laat; de schade is al gebeurd.

Wat betekent dit voor de toekomst?

De auteurs zeggen: "We bouwen muren rondom de gereedschappen, maar we vergeten de poortwachters bij de markt en de bewaking op de weg."

Om echt veilig te zijn, moeten we:

  1. De Markt schoonmaken: Betrouwbare bronnen voor gereedschappen creëren.
  2. De Weg beveiligen: Zorgen dat berichten niet onderweg worden gemanipuleerd.
  3. De Slotmeester wakker maken: De software die de assistent aanstuurt, moet strengere regels hanteren voordat hij iets toestaat.

Kortom: We zijn te gefocust op het controleren van de gereedschappen zelf, terwijl de echte gevaren vaak schuilen in wie ze levert, hoe ze worden vervoerd, en wie ze aanstuurt. De auteurs geven ons een kaartje om te zien waar we onze beveiliging echt moeten plaatsen.

Verdrinkt u in papers in uw vakgebied?

Ontvang dagelijkse digests van de nieuwste papers die bij uw onderzoekswoorden passen — met technische samenvattingen, in uw taal.

Probeer Digest →