Het MCP-lek dat AI-agents omvormt tot supply-chain risico

Als we denken over het beveiligen van AI-systemen, gaat onze aandacht meestal uit naar het model zelf: de trainingsdata, prompt injection of output filtering. Maar er duikt een kritieke kwetsbaarheid op in het verbindingsweefsel dat deze modellen in staat stelt te handelen: de protocollen die AI-agents koppelen aan de tools en data die ze gebruiken. Het Model Context Protocol (MCP), een populaire standaard voor het verbinden van AI-agents met externe bronnen zoals databases, API's en softwaretools, introduceert een subtiel maar krachtig nieuw aanvalsoppervlak. Onderzoek toont aan dat deze protocollaag zijn eigen klasse van beveiligingsproblemen creëert, waarbij vertrouwde toolintegraties veranderen in een potentieel risico voor de software supply-chain [1].

Waarom dit nu belangrijk is

Het kernprobleem is niet zomaar een variant van prompt hacking. Het is een structureel defect in hoe AI-agents hun omgeving waarnemen en vertrouwen. MCP stelt agents in staat om tools te ontdekken en te gebruiken via gestandaardiseerde beschrijvingen. Deze beschrijvingen, of toolmetadata, vertellen de agent wat de tool doet, hoe deze aan te roepen en welke parameters te gebruiken. Dit systeem is ontworpen voor flexibiliteit en interoperabiliteit, maar creëert stilletjes een kritieke afhankelijkheid. Het begrip van de agent van een tool: en dus zijn gedrag: wordt volledig bepaald door deze metadata. Als die metadata vergiftigd is, wordt het vertrouwen van de agent in de tool zijn achilleshiel.

Deze aanvalsvector, 'tool poisoning' genoemd, omvat het inbedden van kwaadaardige instructies rechtstreeks in de metadata van een tool [2]. In tegenstelling tot traditionele aanvallen die zich richten op de prompt van het model, maakt deze methode gebruik van de protocollaag. Een vergiftigde toolbeschrijving kan de agent bijvoorbeeld instrueren om een databasequery zo te formatteren dat gevoelige gegevens worden blootgesteld, of om een API aan te roepen met parameters die een kwetsbaarheid aan serverzijde activeren. Omdat de agent deze instructie ontvangt als onderdeel van het vertrouwde tool-discoveryproces, kan hij de kwaadaardige actie uitvoeren zonder verdachte gebruikersprompt. De integriteit van de toolbeschrijving is in dit scenario belangrijker dan de eigen veiligheidsmaatregelen van het model.

Het risico escaleert van een abstract concept naar een concreet implementatieprobleem bij het overwegen van echte MCP-integraties. Een advisory uit 2026 over een MCP-serverpakket voor Atlassian-producten toonde aan hoe dit meerdere kwetsbaarheden aan elkaar kon koppelen [3]. De advisory verbond Server-Side Request Forgery (SSRF), diefstal van inloggegevens en traditionele prompt injection via een gecompromitteerde MCP-toolserver. Dit illustreert dat een enkele vergiftigde tool in een gedeeld MCP-ecosysteem een supply-chainprobleem kan worden, wat elke agent beïnvloedt die er verbinding mee maakt. Organisaties kunnen hun eigen AI-modellen rigoureus controleren, maar als ze die modellen aansluiten op een gemeenschappelijk gedeelde MCP-server met een vergiftigde tool, wordt de volledige functionaliteit van de agent aangetast.

Wat er in de praktijk verandert

Dit creëert een klassieke software supply-chain-aanval, die doet denken aan kwetsbaarheden in traditionele softwarebibliotheken. Je vertrouwt een component omdat het veel wordt gebruikt en legitiem lijkt, maar de beschrijving ervan bevat een verborgen payload. Voor AI-agents is de 'component' de tooldefinitie. De aanval vereist niet dat de kerncode of modelgewichten van de agent worden gecorrumpeerd; het vereist alleen het corrumperen van de instructies die de agent vertellen hoe hij een ogenschijnlijk goedaardige tool moet gebruiken. Dit verschuift de beveiligingslast. Verdediging moet zich nu uitstrekken tot voorbij het AI-model om de volledige tool-discovery- en protocolverwerkingspijplijn te omvatten.

De implicaties zijn bijzonder significant voor bedrijven die processen automatiseren met AI-agents. Een agent die is toegewezen aan klantensupport, die een vergiftigde tool gebruikt om toegang te krijgen tot de supportticketdatabase, zou per ongeluk gegevens kunnen lekken. Een agent die cloudinfrastructuur beheert, geleid door kwaadaardige metadata, zou beveiligingsinstellingen verkeerd kunnen configureren. Het lekvectoren is niet een gehackte AI; het is een gehackte gebruikershandleiding voor een tool die de AI gebruikt. Dit sluit aan bij een bredere trend in cybersecurity waarbij de meest schadelijke inbreuken vaak komen van over het hoofd geziene, 'saaiere' infrastructuur, niet de opvallende, directe aanvallen.

Het aanpakken hiervan vereist een nieuwe beveiligingsmentaliteit. Ten eerste moet toolmetadata worden behandeld als een kritiek, verifieerbaar activum. Organisaties zouden ondertekening en verificatie voor MCP-toolschema's moeten implementeren, vergelijkbaar met hoe ze softwarepakketten verifiëren. Ten tweede hebben agentimplementaties monitoring van 'toolcontext' nodig. Logs moeten niet alleen bijhouden welke prompts een agent ontving, maar ook welke tooldefinities deze consumeerde en waarop hij actie ondernam. Ten slotte moet het principe van minimale rechten van toepassing zijn op tooltoegang. Een agent zou niet in staat moeten zijn om tools van ongecontroleerde bronnen te ontdekken en te gebruiken, simpelweg omdat ze worden aangeboden op een MCP-server.

De kwetsbaarheid onderstreept dat AI-beveiliging een systeemprobleem is, niet alleen een modelprobleem. Aangezien de beveiliging van MCP zelf afhangt van de integriteit van vaak genegeerde toolmetadata, vereist het beveiligen van de agent het beveiligen van elke schakel in zijn operationele keten. Het protocol dat AI-agents in staat stelt om in de echte wereld te handelen, creëert ook een nieuw pad voor aanvallers om door hen heen te handelen. Het defect zit niet in de intelligentie van de agent, maar in het vertrouwen dat hij stelt in de beschrijvingen van de tools die hij gebruikt: een supply-chainrisico dat in het volle zicht verborgen ligt.