Wat is het Model Context Protocol (MCP) — en waarom is het belangrijk voor de beveiliging van bedrijfsgegevens

Als uw organisatie AI-assistenten inzet — of dit van plan is — zult u te maken krijgen met het Model Context Protocol. MCP is de opkomende standaard die bepaalt hoe AI-tools zoals Claude en Microsoft Copilot verbinding maken met bedrijfssystemen: bestandsopslagplaatsen, kennisbanken, databases en zakelijke applicaties.

Het is, kort gezegd, de infrastructuur die AI bruikbaar maakt in een zakelijke context. En zoals bij de meeste infrastructuur is het onzichtbaar als het goed werkt en rampzalig als dat niet het geval is. Voor CIO’s, IT-directeuren en VP AI-leiders is MCP geen detail voor ontwikkelaars. Het is een beslissing over AI-gegevensbeheer die bepaalt of de AI-inzet van uw organisatie veilig, compliant en controleerbaar is — of helemaal niets van dat alles.

Samenvatting voor het management

Belangrijkste idee: Het Model Context Protocol wordt snel de standaardinterface voor het verbinden van AI-assistenten met bedrijfsdata en -systemen. Hoe een organisatie MCP implementeert — en of die implementatie governance op ondernemingsniveau bevat — bepaalt of AI-adoptie waarde creëert of risico’s veroorzaakt.

Waarom dit relevant is: De meeste MCP-implementaties op de markt zijn ontworpen voor het gemak van ontwikkelaars, niet voor governance op ondernemingsniveau. Organisaties die ongecontroleerde MCP-integraties inzetten, verbinden AI-tools met gevoelige databronnen zonder de toegangscontroles, audittrails of compliance-documentatie die gereguleerde sectoren vereisen. Het moment om een governancebeslissing over MCP te nemen is vóór de inzet, niet nadat een beveiligingsincident of een onderzoek door toezichthouders u daartoe dwingt.

5 Belangrijkste inzichten

1. MCP is de opkomende standaard voor AI-naar-systeemintegratie, waardoor AI-assistenten kunnen werken met bedrijfsdata — uploaden, downloaden, zoeken en beheren van bestanden — via een universeel protocol in plaats van op maat gemaakte point-to-point-verbindingen.
2. Het protocol zelf is neutraal ten aanzien van governance. Een MCP-server kan worden geïmplementeerd met governance op ondernemingsniveau, zoals toegangscontrole, logs en compliance-handhaving — of zonder deze zaken. De governance zit niet in het protocol; het zit in de implementatie.
3. Ongecontroleerde MCP-implementaties geven AI-tools doorgaans brede toegang tot gekoppelde systemen via overgeprivilegieerde serviceaccounts, zonder autorisatie per gebruiker, zonder logging per handeling en zonder handhaving van gevoeligheidslabels.
4. Governance op MCP-niveau vereist minimaal zes controles: OAuth 2.0-authenticatie met inloggegevens buiten de AI-context opgeslagen, autorisatie per handeling via RBAC en ABAC, auditlogging op attribuutniveau, pad- en scopecontroles, rate limiting en beoordeling van gevoeligheidslabels.
5. Een gecontroleerde MCP-server die bestaande data governance-beleidsregels uitbreidt naar AI-interacties — in plaats van aparte AI-specifieke governance-infrastructuur te vereisen — is het architectuurpatroon dat snelle en verdedigbare AI-inzet in ondernemingen mogelijk maakt.

Wat is het Model Context Protocol en waar komt het vandaan?

Het Model Context Protocol is een open standaard, oorspronkelijk ontwikkeld door Anthropic, die definieert hoe AI-assistenten communiceren met externe tools en databronnen. Voor MCP was het verbinden van een AI met een bedrijfssysteem afhankelijk van maatwerk integratiecode voor elke combinatie van AI-tool en databron — een gefragmenteerde, dure aanpak die leidde tot inconsistente beveiligingsimplementaties en aanzienlijke onderhoudslast.

MCP lost dit op via standaardisatie. Een organisatie die een MCP-server bouwt of inzet voor een dataopslagplaats, kan elke MCP-compatibele AI-assistent verbinden met die opslagplaats zonder nieuwe integratiecode te schrijven. De AI vraagt de MCP-server welke bewerkingen beschikbaar zijn, de MCP-server beschrijft zijn mogelijkheden en de AI gebruikt die om met de data te werken. Vanuit technisch architectuurperspectief werkt MCP vergelijkbaar met hoe USB apparaatverbindingen standaardiseerde — een universele interface die de noodzaak voor eigen connectors tussen elk apparaatpaar elimineert.

Het protocol wordt snel omarmd binnen de AI-sector. Grote AI-platforms zoals Claude, Microsoft Copilot en een groeiend ecosysteem van zakelijke AI-tools ondersteunen MCP nu als native integratiemethode. Voor IT-leiders in ondernemingen betekent deze ontwikkeling één ding: MCP is geen opkomende technologie om in de gaten te houden. Het is een nieuwe standaard die governance vereist.

Hoe MCP werkt in een zakelijke context

In de praktijk bestaat een MCP-inzet uit drie componenten. De AI-client — Claude, Copilot of een andere MCP-compatibele assistent — is de interface waarmee gebruikers hun data benaderen. De MCP-server zit tussen de AI-client en de dataopslag; deze ontvangt verzoeken van de AI, valideert ze, voert toegestane bewerkingen uit en retourneert de resultaten. De dataopslag is het bedrijfs­systeem dat wordt benaderd — een bestandsdeling, een document management platform, een kennisbank of een andere contentopslag.

Wanneer een gebruiker een AI-assistent vraagt om “het Henderson-contract te vinden en te delen met juridisch,” vertaalt de AI dat verzoek in natuurlijke taal naar een reeks MCP-bewerkingen: zoeken naar een bestand dat aan bepaalde criteria voldoet, het ophalen en een deelactie starten. Elk van deze bewerkingen is een afzonderlijk verzoek aan de MCP-server. De MCP-server beslist per verzoek of het wordt uitgevoerd — en die beslissing is waar governance wel of niet plaatsvindt.

Dit is het architectuurdetail dat IT-leiders moeten begrijpen: de AI heeft geen directe toegang tot bedrijfsdata. De AI vraagt de MCP-server om namens haar data te benaderen. De MCP-server is het controlepunt. Een MCP-server met sterke governancecontroles — authenticatie, autorisatie, logging, rate limiting — zorgt voor een veilige, controleerbare AI-integratie. Een MCP-server zonder deze controles zorgt voor een AI die alles kan doen wat het serviceaccount mag doen, zonder beperkingen per gebruiker, zonder logging en zonder compliance-documentatie. Het AI-risicoprofiel van een MCP-inzet wordt volledig bepaald door wat er op dat controlepunt gebeurt.

Waarom standaard MCP-implementaties niet geschikt zijn voor ondernemingen

De meeste MCP-servers die vandaag beschikbaar zijn, zijn ontworpen voor individuele ontwikkelaars en kleine teams. Ze lossen het connectiviteitsprobleem effectief op — ze maken het eenvoudig om een AI-tool te verbinden met een bestandssysteem of API. Wat ze niet oplossen, is het governanceprobleem op ondernemingsniveau. Het standaardpatroon van MCP-implementatie kent vier structurele tekortkomingen die het ongeschikt maken voor gereguleerde bedrijfsomgevingen.

De eerste tekortkoming is toegangscontrole. Standaard MCP-implementaties verbinden de AI met een databron via een serviceaccount of API-sleutel, waardoor de AI toegang krijgt tot alles waar dat account bij kan. Er is geen autorisatie per gebruiker — als één gebruiker via de MCP-integratie toegang heeft tot een bestand, hebben alle gebruikers dat feitelijk, omdat de AI altijd onder hetzelfde serviceaccount werkt, ongeacht wie het verzoek doet. Dit is direct in strijd met zero trust-beveiligingsprincipes en creëert hetzelfde risico van overmatige rechten dat identity & access management-programma’s proberen te voorkomen.

De tweede tekortkoming is de volledigheid van de audittrail. MCP-implementaties op ontwikkelaarsniveau loggen op applicatieniveau, als ze al loggen. Ze registreren dat de AI een verzoek heeft gedaan — niet welke gebruiker het heeft geautoriseerd, niet welke specifieke data is opgehaald, niet welke actie ermee is uitgevoerd. Voor organisaties die onder HIPAA, GDPR, SOX of FedRAMP vallen, is dit niet alleen een logging-tekortkoming — het is een compliance-tekortkoming. Deze kaders vereisen documentatie op attribuutniveau van datatoegang die generieke MCP-logging niet biedt.

De derde tekortkoming is credentialbeveiliging. Veel lichte MCP-implementaties slaan API-sleutels of authenticatietokens op in configuratiebestanden of omgevingsvariabelen — toegankelijk voor iedereen die de configuratie kan lezen, inclusief, in sommige architecturen, het AI-model zelf via het contextvenster. Een prompt injection-aanval op een AI met toegang tot zijn eigen credentials is een datalek dat wacht om te gebeuren. Zero trust-databescherming vereist dat credentials onder geen enkele omstandigheid via AI-prompts toegankelijk zijn.

De vierde tekortkoming is het ontbreken van exfiltratiecontroles. Zonder rate limiting op MCP-bewerkingen kan een gecompromitteerd of verkeerd geconfigureerd AI-systeem data ophalen op een schaal die voor normale gebruikers onmogelijk zou zijn. Dezelfde DLP-principes die bulkdata-export voor mensen reguleren, gelden ook voor AI-agenten die duizenden bewerkingen per minuut uitvoeren — maar de meeste MCP-implementaties hebben geen vergelijkbare controles.

Directe API versus MCP: wat verandert — en welke governance nog steeds vereist is

Wat governance op MCP-niveau in de praktijk vereist

Voor IT-leiders die MCP-inzet evalueren, is de vraag niet of MCP gebruikt moet worden — het protocol wordt zo standaard dat die discussie grotendeels is beslecht. De vraag is welke governancecontroles aanwezig moeten zijn in de MCP-serverimplementatie voordat deze wordt verbonden met bedrijfsdata. Zes vereisten zijn niet-onderhandelbaar voor gereguleerde omgevingen.

Twee van deze vereisten verdienen extra toelichting omdat ze het vaakst ontbreken in standaardimplementaties en de grootste gevolgen hebben als ze ontbreken.

Autorisatie per handeling — niet per sessie — is het cruciale verschil tussen governance op ondernemingsniveau en ontwikkelaarsniveau. Een autorisatiecontrole op sessieniveau verifieert of de AI verbinding mag maken met het systeem. Een autorisatiecontrole per handeling verifieert of de specifieke gebruiker, die deze specifieke actie op deze specifieke data aanvraagt, mag doorgaan — bij elke afzonderlijke MCP-bewerking. Alleen autorisatie per handeling handhaaft het least privilege-principe in de praktijk. Autorisatie op sessieniveau creëert een venster van impliciet vertrouwen dat zero-trustarchitectuur juist uitsluit.

Credentialisolatie van het AI-model is even kritisch. OAuth 2.0-tokens moeten worden opgeslagen in de beveiligde credential store van het besturingssysteem — niet in configuratiebestanden, niet in omgevingsvariabelen die via de AI-context toegankelijk zijn en niet op enige manier via de AI-prompt worden doorgegeven. Het dreigingsmodel hier is prompt injection: een aanvaller die instructies kan injecteren in de inputstroom van de AI kan, bij een slecht beveiligde implementatie, de AI instrueren zijn credentials prijs te geven. Opslag in de OS keychain elimineert dit aanvalsoppervlak volledig. Dit is een vereiste voor Zero Trust gegevensuitwisseling, geen optionele hardeningmaatregel.

MCP en compliance: wat toezichthouders uiteindelijk zullen vragen

IT-leiders in gereguleerde sectoren — financiële sector, zorgprocessen, juridische sector, overheid — moeten ervan uitgaan dat toezichthouders uiteindelijk zullen vragen naar governance van AI-datatoegang. De signalen zijn nu al duidelijk: de data access-vereisten van de GDPR gelden voor AI-opvragingen; de HIPAA-standaard minimum necessary geldt voor AI-queries op patiëntdata; de FedRAMP-vereisten voor auditlogs gelden voor AI-bewerkingen binnen geautoriseerde informatiesystemen. Geen van deze kaders is specifiek geüpdatet voor MCP, maar dat hoeft ook niet — de bestaande vereisten zijn breed genoeg om het te dekken.

De praktische consequentie is dat organisaties die nu MCP-integraties inzetten, bij een toekomstige audit moeten kunnen aantonen dat elke AI-datatoegang via MCP geauthenticeerd was, geautoriseerd op basis van RBAC-beleid, volledig gelogd met attributie en in overeenstemming met de geldende gevoeligheidsclassificaties. Organisaties die dit bewijs niet kunnen leveren, lopen hetzelfde risico op sancties als bij elke andere ongecontroleerde datatoegang — het feit dat een AI het verzoek deed in plaats van een mens, geeft geen vrijstelling.

Er is ook een datasoevereiniteitsaspect voor organisaties die actief zijn in diverse rechtsbevoegdheden. Een MCP-server die AI-dataverzoeken via cloudinfrastructuur in een andere rechtsbevoegdheid leidt, kan GDPR-vereisten voor grensoverschrijdende overdracht activeren of conflicteren met dataresidentie-verplichtingen. Gecontroleerde MCP-implementaties die binnen de bestaande datainfrastructuur van een organisatie draaien — en niet via externe AI-leveranciers — ondervangen dit risico bij het ontwerp.

Het Shadow AI-probleem dat MCP moest oplossen — en mogelijk verergert

Een van de sterkste argumenten voor gestandaardiseerde MCP-adoptie is het indammen van shadow AI. Werknemers die AI-assistentie willen, zullen die vinden, met of zonder betrokkenheid van IT. Consumenten-AI-tools — persoonlijke ChatGPT-accounts, browsergebaseerde AI-assistenten, plug-ins van derden — worden al gebruikt in de meeste zakelijke omgevingen. Deze tools hebben geen enkele connectie met bedrijfsgovernance: geen toegangscontrole, geen audittrail, geen handhaving van dataclassificatie.

Een gecontroleerde MCP-implementatie biedt medewerkers een legitieme, door IT goedgekeurde AI-interface die daadwerkelijk krachtiger is dan de shadow-alternatieven — omdat deze toegang heeft tot gezaghebbende bedrijfsdata — terwijl volledige zichtbaarheid op risicobeheer behouden blijft. Het productiviteitsargument en het governance-argument wijzen dezelfde kant op: een goed gecontroleerde MCP-server is een beter product voor gebruikers en een beter resultaat voor securityteams dan de ongecontroleerde alternatieven die medewerkers nu al gebruiken.

Het risico keert zich om wanneer een ongecontroleerde MCP-implementatie het officiële alternatief voor shadow AI wordt. Een consumententool zonder toegang tot bedrijfsdata vervangen door een door het bedrijf goedgekeurde MCP-integratie met brede toegang tot bedrijfsdata — maar zonder autorisatie per gebruiker, zonder logging en zonder compliancecontroles — vermindert het risico niet. Het concentreert en legitimeert het. De governancecontroles maken het verschil tussen MCP als beveiligingsverbetering en MCP als beveiligingsrisico.

Hoe Kiteworks Secure MCP Server governance op ondernemingsniveau levert

MCP-governance is geen probleem dat na de inzet moet worden opgelost — het is een architectuurbeslissing die genomen moet worden voordat de eerste AI-assistent verbinding maakt met bedrijfsdata. Organisaties die dit goed doen, krijgen iets wat hun concurrenten niet hebben: de mogelijkheid om AI-productiviteit op schaal mogelijk te maken zonder het compliance- en beveiligingsrisico dat andere organisaties dwingt AI te vertragen of volledig te verbieden. De gecontroleerde MCP-implementatie is wat AI-adoptie die een competitief voordeel oplevert, onderscheidt van AI-adoptie die leidt tot aansprakelijkheid.

Kiteworks Secure MCP Server is speciaal ontwikkeld om te voldoen aan de zes governancevereisten die de zakelijke context stelt. Authenticatie wordt afgehandeld via OAuth 2.0 met PKCE — tokens opgeslagen in de OS keychain, nooit doorgegeven aan het AI-model, nooit toegankelijk via AI-prompts. Autorisatie wordt per handeling geëvalueerd via de Kiteworks Data Policy Engine, waarbij RBAC- en ABAC-beleidsregels worden afgedwongen zodat de AI de rechten van de aanvragende gebruiker overneemt en deze bij geen enkele handeling kan overschrijden. Elke MCP-bewerking wordt volledig gelogd — AI-systeem, gebruiker, geraadpleegde data, tijdstip, resultaat — en direct geïntegreerd met SIEM via de Kiteworks audit log.

Padtraversalbescherming en absolute padrestricties zijn standaard ingeschakeld, waardoor AI geen toegang krijgt tot systeem­bestanden of mappen buiten de bedoelde scope. Rate limiting voorkomt bulkextractie op sessie- en gebruikersniveau. En omdat Kiteworks Secure MCP Server binnen het Private Data Network draait, worden dezelfde data governance-beleidsregels, compliance-documentatie en beveiligingscontroles die alle andere datastromen op het Kiteworks-platform reguleren — beveiligde bestandsoverdracht, beveiligde MFT, beveiligde e-mail en meer — uitgebreid naar elke AI-interactie. Geen parallelle governance-infrastructuur. Geen apart AI-beleidsbeheer. Dezelfde gecontroleerde datalaag, uitgebreid naar MCP.

Voor CIO’s en IT-leiders die AI-productiviteit willen mogelijk maken zonder nieuwe governance-blinde vlekken te creëren, biedt Kiteworks Secure MCP Server het antwoord. Meer weten? Plan vandaag nog een demo op maat.

Aanvullende bronnen

• Blog Post
  Zero‑Trust strategieën voor betaalbare AI-privacybescherming
• Blog Post
  Hoe 77% van de organisaties faalt in AI-databeveiliging
• eBook
  AI Governance Gap: Waarom 91% van de kleine bedrijven Russisch roulette speelt met databeveiliging in 2025
• Blog Post
  Er is geen “–dangerously-skip-permissions” voor uw data
• Blog Post
  Toezichthouders zijn klaar met vragen of u een AI-beleid heeft. Ze willen bewijs dat het werkt.