MCP-beveiliging in 2026: de human-in-the-loop-kloof in de specificatie

De specificatie van het Model Context Protocol geeft in duidelijke taal toe dat het menselijke goedkeuring niet kan afdwingen voordat een AI-tool handelt — die garantie is een aanbeveling voor de applicatie bovenop MCP, geen regel die MCP zelf controleert. Voor elk bureau dat zijn eigen AI, of die van een klant, via MCP aan echte bedrijfssystemen koppelt, is die ene zin het hele risicomodel. Het protocol vertelt je AI welke tools bestaan en wat ze beweren te doen. Of een mens daadwerkelijk ziet en goedkeurt wat er gaat gebeuren, wordt volledig overgelaten aan wie de client heeft gebouwd.

Wat zegt de MCP-specificatie eigenlijk over toestemming?

De sectie “Key Principles” van de specificatie is direct over de grenzen van wat het protocol garandeert:

“1. User Consent and Control — Users must explicitly consent to and understand all data access and operations… 3. Tool Safety — Tools represent arbitrary code execution and must be treated with appropriate caution… Hosts must obtain explicit user consent before invoking any tool.”

En direct daarna:

“While MCP itself cannot enforce these security principles at the protocol level, implementors SHOULD: Build robust consent and authorization flows into their applications…”

Dat is de kloof in één alinea. De principes zijn geschreven met kleine letters “must”, wat volgens de conventie die de MCP-specificatie volgt aanbeveling betekent, geen protocolniveau-vereiste. De Tools-specificatie herhaalt dezelfde structuur in het “User Interaction Model”: “there SHOULD always be a human in the loop with the ability to deny tool invocations,” naast de richtlijn dat applicaties “SHOULD… present confirmation prompts to the user for operations.” Aanbevolen. Niet afgedwongen. Niet iets dat een MCP-server kan verifiëren dat een client daadwerkelijk doet.

Dit is geen unieke fout van MCP — geen protocol kan een applicatie erbovenop dwingen zich op een bepaalde manier te gedragen. Maar het betekent dat “onze AI is verbonden via MCP” je niets vertelt over of een mens echt in de loop zit. Dat is een claim over de specifieke applicatie, en die moet je daar verifiëren, niet aannemen van de protocolnaam.

Wat gebeurt er wanneer die kloof wordt uitgebuit

Drie gedocumenteerde incidenten tonen wat de kloof in de praktijk kost, op drie verschillende punten in de keten.

Asana, juni 2025 — de isolatiefout. Asana lanceerde op 1 mei 2025 een MCP-integratie. Op 4 juni werd een tenant-isolatiebug geïdentificeerd, en de integratie werd ongeveer twee weken offline gehaald tijdens de fix. De fout liet data van één organisatie — taken, projectmetadata, teamdetails, opmerkingen en geüploade bestanden — zichtbaar worden over organisatiegrenzen heen. Ongeveer 1.000 klanten werden getroffen, en de kwetsbaarheid bestond sinds de eerste dag van de functie. Dit was niet specifiek een human-in-the-loop-fout — het is een herinnering dat de isolatiegrens rond wat een MCP-integratie kan bereiken evenveel telt als wie de call goedkeurt.

GitHub, mei 2025 — de “toxic agent flow”. Beveiligingsonderzoekers bij Invariant Labs demonstreerden een aanval waarbij een ontwikkelaar een AI-agent, verbonden via GitHub’s MCP-server, vroeg open issues op een publieke repository te reviewen. Eén geplante issue bevatte verborgen instructies. De agent las ze, gebruikte vervolgens zijn eigen al geautoriseerde toegang tot de privé repositories van de ontwikkelaar om gevoelige informatie op te halen en postte die in een pull request zichtbaar op de publieke repo. Elke individuele toolcall die de agent deed, was er één die de gebruiker echt had geautoriseerd. Wat niet was geautoriseerd — en wat geen enkele goedkeuringsprompt zou hebben opgevangen — was de combinatie: een publieke issue lezen, dan handelen op privédata, dan extern publiceren. Invariant’s eigen conclusie was direct: “This vulnerability cannot be resolved through server-side patches.” Het is een architecturaal probleem in hoe permissies samenstellen over toolcalls, geen bug in GitHub’s code.

Microsoft, 30 juni 2026 — de hergoedkeuringskloof. Het beveiligingsteam van Microsoft publiceerde een directe waarschuwing over een mechaniek ingebakken in het vertrouwensmodel zelf: de beschrijving van een tool — de tekst die een gebruiker leest en goedkeurt voordat hij een AI de tool laat gebruiken — kan na die goedkeuring veranderen, en niets in het protocol vereist dat de client opnieuw vraagt. Microsoft’s eigen woorden: “In configurations where description changes do not trigger a re-approval workflow, the updated instructions become active without additional review.” Een tool die op dag één veilig leek, kan op dag dertig stilletjes worden herdefinieerd, en een gebruiker die hem eenmaal heeft goedgekeurd, heeft geen reden te weten dat het is gebeurd. Microsoft beschreef MCP als “the fastest-growing part of the agentic AI supply chain” — en dat is precies waarom deze specifieke kloof elke maand die onopgelost blijft belangrijker wordt.

Daarnaast zijn twee concrete CVE’s het waard te kennen als je MCP-tooling evalueert: CVE-2025-49596, een kritieke (CVSS 9.4) remote code execution-kwetsbaarheid in Anthropic’s eigen MCP Inspector-tool, en CVE-2025-6514, een kritieke (CVSS 9.6) command-injection-kwetsbaarheid in het veelgebruikte mcp-remote-pakket, getriggerd door een kwaadaardige autorisatie-URL van een server. Beide zijn gepatcht, maar beide illustreren dat de tooling rond MCP dezelfde klasse kloof had als het vertrouwensmodel van het protocol: dingen die een gebruiker redelijkerwijs inert achtte, bleken dat niet te zijn.

Wat “human-in-the-loop” in de praktijk moet betekenen

Omdat het protocol het niet afdwingt, zijn de vragen die het waard zijn te stellen over elke AI-verbonden tool — inclusief die van sSystm zelf — de vragen die “human-in-the-loop” van een slogan in iets controleerbaars maken:

1. Wacht een schrijfactie echt op een persoon, elke keer, of alleen bij eerste gebruik? Eén goedkeuring bij verbinding is niet dezelfde garantie als goedkeuring per actie.
2. Als de beschrijving of het gedrag van een tool verandert, triggert dat hergoedkeuring, of treedt het stilletjes in werking? Dit is precies de kloof die Microsoft in juni 2026 signaleerde.
3. Is de token of credential beperkt tot de data van één organisatie, of zou een gecompromitteerde sessie meerdere tenants kunnen bereiken? Dit faalde bij Asana — niet de goedkeuringsstap, maar de isolatiegrens erachter.
4. Is er een audit trail van wat de AI daadwerkelijk deed, los van wat het werd gevraagd te doen? Samengestelde aanvallen zoals de GitHub-case komen alleen achteraf aan het licht als de individuele stappen zijn gelogd.
5. Wie beheert de specificatie, en hoe actief evolueert het beveiligingsmodel? MCP werd op 9 december 2025 gedoneerd aan de Agentic AI Foundation onder de Linux Foundation, met Anthropic, Block, OpenAI, Google, Microsoft, AWS en Cloudflare allemaal betrokken — een teken dat het ecosysteem consolideert rond gedeeld bestuur in plaats van elke vendor onafhankelijk te laten patchen.

sSystm’s eigen MCP-endpoint geeft een per-gebruiker token uit beperkt tot de organisatie van die gebruiker, en elke schrijfactie die een AI voorstelt — via de ingebouwde Build AI of een verbonden externe client — blijft als een pending actie staan tot een persoon het goedkeurt. Dat is geen claim dat MCP dit afdwingt; het is het tegenovergestelde punt. Omdat het protocol dat niet doet, moet het bewust in de applicatie worden ingebouwd, en het is de moeite waard dit expliciet te controleren in plaats van aan te nemen van “het gebruikt MCP.” Lees meer over hoe de goedkeuringsgrens werkt in hoe AI en mensen de sSystm-werkruimte delen, hoe het isolatiemodel eruitziet in onze beveiligingsarchitectuur, en de mechanica van het verbinden van externe AI via MCP in hoe je je AI met je bureau verbindt via MCP.