Steeds meer organisaties zetten AI-agents in om taken uit te voeren: systemen bevragen, bestanden openen of API’s aanroepen. Met het Model Context Protocol (MCP) kunnen die agents via zogenaamde MCP servers toegang krijgen tot externe tools en actuele bedrijfsdata. Het probleem: juist die server vormt vaak een toegangspunt tot gevoelige gegevens en credentials—waardoor een lek niet alleen informatie blootlegt, maar ook handelingsmogelijkheden geeft aan aanvallers.
In dit artikel leggen we uit wat MCP servers doen, welke patronen vaak leiden tot het blootstellen van enterprise secrets, en welke maatregelen je vandaag al kunt toepassen om risico’s te beperken.
Wat zijn MCP servers en waarom zijn ze zo kritisch?
MCP is een open standaard die AI-assistenten de mogelijkheid geeft om buiten de eigen “kennis” te treden. In plaats van alleen tekst te genereren, kan een agent via MCP acties uitvoeren in echte systemen—bijvoorbeeld een database raadplegen, een intern document openen of een API-call doen.
Daar zit de kern van het risico in de MCP server: dit is het stukje software dat als tussenlaag fungeert tussen de AI-agent en de systemen die de agent mag gebruiken. Om die acties te verrichten, heeft die server doorgaans toegang nodig tot de bijbehorende credentials zoals API-tokens, service account keys en andere geheimen.
Als een MCP server in verkeerde handen valt (of onveilig is ingericht), dan worden secrets niet alleen leesbaar. Door het “actiegerichte” karakter van agents kan een gelekt geheim ook direct worden gebruikt om systemen te benaderen en misbruik te maken.
Hoe MCP servers secrets kunnen blootstellen
Veel MCP-omgevingen worden gebouwd met het oog op snelheid: een server moet aan de praat en verbindingen moeten werken. Die focus op functionaliteit kan ertoe leiden dat de beveiliging niet dezelfde aandacht krijgt als bij andere productiesystemen. Hieronder staan de meest voorkomende routes waarlangs enterprise secrets in MCP-omgevingen kunnen lekken.
1) Plaintext credentials in configuratiebestanden
Een veelvoorkomende valkuil is dat MCP servers tokens en sleutels opslaan in lokale configuratiebestanden. In sommige setups betekent “deployen” simpelweg dat je een configuratiereeks plakt met daarin de credentials zelf. Als dat bestand vervolgens op een schijf achterblijft, kan het later worden gekopieerd, overgenomen of—gevaarlijk—per ongeluk in een Git-repository terechtkomen.
Zodra een aanvaller toegang krijgt tot de serveromgeving, kunnen die secrets vervolgens direct worden uitgelezen.
2) Credential sprawl door gebrek aan centrale controle
Wanneer secrets niet op één plek worden beheerd, ontstaat “sprawl”: dezelfde API key of token duikt op in meerdere configuraties en omgevingsvariabelen. Dat gebeurt vaak in dev, staging en productie, waar parallele kopieën blijven bestaan.
Een bijkomend risico is dat niemand een volledig overzicht heeft van alle varianten. Daardoor worden tokens minder vaak (of te laat) vervangen. Het gevolg: langlevende, statische credentials blijven bruikbaar voor aanvallers.
3) Prompt injection via documenten of webcontent
Niet elk incident vraagt om “knock-out” toegang van buitenaf. Omdat AI-agenten instructies en context lezen uit de content die ze ontvangen, kan een aanvaller proberen verborgen instructies mee te smokkelen in bijvoorbeeld een document, ticket of webpagina. Dat fenomeen wordt vaak prompt injection genoemd.
Als de agent die verborgen aanwijzingen als valide commando’s behandelt, kan hij tools misbruiken of—cruciaal—geheimen doorgeven die bedoeld waren om beschermd te blijven.
4) Over-permissionering: te brede toegang komt in productie terecht
Bij het bouwen van integraties is het verleidelijk om ruimere rechten te geven zodat je snel door kunt. In veel projecten wordt vervolgens vergeten om die scope te versmallen zodra de code af is. Als least privilege niet consequent wordt toegepast, kan één gecompromitteerde agent of server verregaande toegang krijgen.
Dan is de impact groter dan nodig: een enkel incident kan meer systemen raken dan strikt vereist is voor de oorspronkelijke taak.
5) Risico door exposed servers en supply chain-achtige scenario’s
Daarnaast ligt er een supply chain-risico in het model zelf: iedereen kan een MCP server publiceren. Als je zonder voldoende verificatie met een onbe-trouwde MCP server koppelt, kan dat tegen je werken.
In de context van MCP is eerder een voorbeeld genoemd waarbij een remote clientcomponent (een OAuth-proxy die zeer vaak is gedownload) kwetsbaar kon worden voor command injection. Dat type aanval kan leiden tot remote code execution op de machine van de proxygebruiker—waarbij vervolgens credentials kunnen worden geobserveerd of misbruikt.
Dit onderstreept dat “even koppelen” niet hetzelfde is als “veilig koppelen”.
Praktische maatregelen om enterprise secrets op MCP servers te beveiligen
Het is belangrijk om te beseffen dat MCP een nieuwe laag toevoegt tussen AI-agenten en bedrijfsystemen. Je kunt dus niet volstaan met de beveiligingsaanpak voor alleen de backend of alleen de agent. Je moet gericht beleid toepassen op de MCP-laag.
Centraliseer secrets en stop met hardcoding
Een van de meest directe oplossingen is stoppen met het opnemen van credentials in configuratiebestanden, omgevingsvariabelen of broncode. Breng geheimen onder in één beheerde secret-store. Zo verminder je twee problemen tegelijk: plaintext exposure en credential sprawl.
In plaats van veel kopieën die overal blijven rondzwerven, haalt een agent de benodigde geheimen op het moment van gebruik uit een centrale bron.
Werk met korte-livesecrets en automatische rotatie
Langlevende tokens zijn aantrekkelijk voor aanvallers omdat ze langdurig bruikbaar blijven. Geef daarom de voorkeur aan korte levensduur en automatische rotatie. Wanneer credentials uitgeven worden met een vervaldatum, wordt het window of opportunity kleiner.
Dat betekent ook: als er onverhoopt een geheim lekt, is het vaak niet meer geldig op het moment dat een aanvaller ermee probeert te handelen.
Hanteer least privilege voor elke agent-taak
Beperk de toegang tot wat nodig is. Geef agents alleen rechten voor de systemen en data die de taak daadwerkelijk vereist. Dat zorgt ervoor dat een compromis beperkt blijft tot een deel van het bedrijfslandschap—en voorkomt dat over-permissionering de impact vergroot.
Laat gevoelige acties niet volledig autonoom gebeuren
Voor handelingen die gevoelige data raken, is een extra beveiligingsstap verstandig: een human-in-the-loop. Denk aan expliciete bevestiging voordat een agent een geheim onthult (of onversluierd opslaat), een record verwijdert of richting productie communiceert.
Deze controle kan prompt injection helpen dempen, omdat een agent niet zomaar “door kan lopen” op basis van misleidende context.
Gebruik end-to-end encryptie en een zero-knowledge benadering
Een sterke richtlijn is om secrets end-to-end te versleutelen en ze pas op te halen op het moment dat het echt nodig is. Met een zero-knowledge aanpak blijft een secret-store ook bij een compromis zo min mogelijk bruikbaar voor een aanvaller.
Het idee: zelfs als iemand de vault krijgt, kan die persoon de inhoud niet lezen.
Log en audit alle acties van agents en MCP servers
AI-agenten bewegen snel en voeren handelingen uit zonder continue menselijke sturing. Daarom is het essentieel dat je volledige logging en auditing implementeert van wat er werd benaderd en wanneer.
Dat helpt bij compliance, maar is ook onmisbaar bij incident response: je wilt precies kunnen reconstrueren welke tools zijn gebruikt, welke data is geraadpleegd en welke secrets zijn geraakt.
Maak een inventaris van MCP servers en voorkom “shadow AI”
Je kunt alleen goed beveiligen wat je ook kunt zien. Zorg dat je zicht hebt op welke MCP servers draaien, welke versies actief zijn en welke credentials ze gebruiken. Dat maakt ongecontroleerde “shadow AI”—ongeplande koppelingen met live secrets—zichtbaar en aanpasbaar.
Waarom secret management voor AI agents anders (maar niet ingewikkelder) moet
Met MCP wordt het speelveld voor secrets verlegd: niet alleen applicaties, maar ook de integratielaag tussen agent en systemen krijgt toegang tot de “sleutels”. Daardoor hoort rigor bij die laag: dezelfde discipline als bij andere productieomgevingen.
Concreet komt het neer op gecontroleerde opslag (geen hardcoding), gecontroleerde distributie (centralisatie), gecontroleerde toegang (least privilege) en gecontroleerde handelingen (bevestiging voor gevoelige acties).
Gerelateerde beveiligingsinzichten om mee te nemen
Secret blootstelling en misbruik van tokens zijn niet uniek voor MCP. Ook bij andere supply chain of agent-achtige situaties zie je dat het gevaar vaak ontstaat zodra rechten te breed zijn of wanneer integraties te weinig verifieerbaar zijn. Als je dit thema verder wilt verbreden, zijn deze artikelen relevant:
- LiteLLM supply chain aanval: 2.500 organisaties geraakt
- GitHub Actions flaw bij Snowflake: command injection uitgelegd
- AI-gedreven kwetsbaarheden: waarom patchen niet volstaat
Conclusie: beveilig MCP servers als toegangspoort tot je enterprise
MCP servers geven AI-agents kracht door verbindingen met interne tools en data mogelijk te maken. Tegelijkertijd maken ze van die serverlaag een plek waar enterprise secrets samenkomen—en waar het mis kan gaan via plaintext configuraties, credential sprawl, prompt injection, over-permissionering en supply chain-achtige koppelingen.
De beste aanpak begint met het professionaliseren van secret management: centraliseer credentials, gebruik korte-lived tokens, dwing least privilege af, voeg controle toe bij gevoelige acties, versleutel end-to-end en log alles. Alleen dan maak je de AI-laag net zo veilig als de rest van je productieomgeving.
Bron: https://thehackernews.com/2026/08/how-mcp-servers-can-expose-enterprise.html
