Eigen MCP-server hosten voor bedrijfsdata: zo doe je het veilig

Een eigen MCP-server hosten voor bedrijfsdata betekent dat je AI-assistent rechtstreeks bij je eigen systemen kan, zonder dat je die data eerst naar een extern platform kopieert. MCP staat voor Model Context Protocol: de open standaard waarmee assistenten als Claude en ChatGPT verbinding maken met software van buiten. Je draait een klein stuk software dat een handvol duidelijk afgebakende acties aanbiedt, en de assistent gebruikt die acties in plaats van dat iemand handmatig exports maakt.

De vraag is niet of dit veilig kan, maar hoe je het inricht. Hieronder lees je wat een MCP-server precies is, wanneer je hem zelf host en wanneer je dat beter uitbesteedt, een stappenplan, en de checklist die je aflopen moet voordat er echte bedrijfsdata doorheen gaat.

Wat is een MCP-server, in gewone taal?

Een MCP-server is een vertaallaag tussen je AI-assistent en een systeem waar die assistent iets uit moet halen of in moet zetten. Je beschrijft per actie wat hij doet, welke gegevens hij nodig heeft en wat hij teruggeeft. De assistent leest die beschrijving en kiest zelf de juiste actie bij de vraag van de gebruiker.

Een concreet voorbeeld maakt het duidelijk. Je bouwt een MCP-server met drie acties op je ordersysteem: zoek_order, toon_leverstatus en maak_notitie. Iemand vraagt in Claude "wat is de status van de order van Jansen BV", de assistent roept zoek_order aan, krijgt een resultaat terug en formuleert het antwoord. Er is geen export, geen tussenbestand en geen kopie van je database bij een derde partij.

Het verschil met een gewone API zit in de beschrijving, niet in de techniek. Een API is gemaakt voor programmeurs die de documentatie lezen. Een MCP-server is gemaakt voor een model dat op het moment zelf moet snappen wat een actie doet. Daarom zijn de omschrijvingen belangrijker dan bij een klassieke koppeling, en houd je het aantal acties bewust klein.

Er zijn twee smaken. Een lokale MCP-server draait op de laptop van één gebruiker en start mee met de assistent. Een remote MCP-server draait op een server met een vast HTTPS-adres, en daar kan je hele team bij. Zodra het om bedrijfsdata en meerdere gebruikers gaat, heb je het over die tweede variant. De volledige specificatie staat op modelcontextprotocol.io.

Waarom zou je een MCP-server hosten voor je eigen bedrijfsdata?

De belangrijkste reden is dat je geen bulk-kopie van je database meer weggeeft. Bij de meeste AI-tools upload je documenten of synchroniseer je een hele database naar een platform van iemand anders. Bij een eigen MCP-server draait het andersom: de assistent stelt een vraag, jouw server haalt alleen op wat die vraag nodig heeft en geeft dat terug. Je systeem van waarheid blijft je eigen database; er ontstaat geen tweede, volledige kopie van je klantenbestand die ergens anders blijft staan.

Wees hier eerlijk over, want het is geen tovertruc: het antwoord dat je server teruggeeft, gaat op dat moment wél naar het AI-model om de vraag te beantwoorden, en dus naar de partij die dat model draait. Je stuurt niet meer je hele bestand vooruit, maar per vraag verlaat het opgevraagde stukje je systeem. Daarom is de winst niet "data gaat nergens heen", maar "jij bepaalt precies wat bereikbaar is en hoeveel eruit kan".

De tweede reden is dat je zelf bepaalt wat er mag. Een MCP-server geeft geen toegang tot "het CRM", maar tot de acties die jij erin zet. Zet je er alleen leesacties in, dan kan een assistent niets wijzigen, ook niet als iemand daar expliciet om vraagt. Let op: alleen-lezen stopt schrijven, niet lezen. Een brede leesactie kan nog steeds veel teruggeven, dus ontwerp je acties smal (één order op klantnaam, niet "geef alle orders") en zet er server-side een limiet op. Zo bepaal je niet alleen of er iets wijzigt, maar ook hoeveel er per aanroep naar buiten kan.

De derde reden is actualiteit. Een geëxporteerd bestand is verouderd op het moment dat je het opslaat. Een MCP-server bevraagt het echte systeem, dus het antwoord klopt met de voorraad van dit moment. Dat is het verschil tussen een AI die over je bedrijf praat en een AI die je bedrijf kent, iets waar we eerder over schreven in AI met geheugen.

Tot slot: het schaalt naar je hele team. Eén gehoste server bedienen tien of honderd collega's, zonder dat iedereen lokaal iets installeert of een API-sleutel in een assistent plakt. Hoe zo'n koppeling er in de praktijk uitziet, lieten we zien in Claude koppelen aan je bedrijfssystemen.

Self-hosten of managed hosting: wat kies je?

Dit is de kern van de beslissing, en het antwoord hangt af van wie het beheer doet. De MCP-server zelf is meestal een paar honderd regels code. Het werk zit in alles eromheen: inloggen, certificaten, rechten, logging, updates en toezicht. Dat is precies wat een managed platform van je overneemt.

Kies self-hosten als je al een beheerde serveromgeving hebt met iemand die hem onderhoudt, als je data om compliance-redenen fysiek op je eigen infrastructuur moet blijven, of als de MCP-server binnen je netwerk moet draaien omdat het bronsysteem niet vanaf internet bereikbaar is. Reken dan op het opzetten van OAuth, TLS-certificaten die vernieuwd moeten worden, een audittrail en een monitoringsopstelling. Dat is goed te doen, maar het is echt werk en het is nooit af.

Kies managed als je die serverkennis niet in huis hebt of hem liever elders inzet, als je binnen dagen in plaats van weken live wilt, en als je niet zelf een OAuth-implementatie wilt onderhouden. Je levert dan in op controle over de onderliggende machine, en je moet dus wel weten waar het platform draait en wat het met je data doet. Voor de meeste MKB-bedrijven valt de afweging hier uit, om dezelfde reden dat je je e-mail ook niet meer op een eigen mailserver draait.

Er is een tussenweg die vaak goed werkt: begin managed, met een verwerkersovereenkomst en hosting binnen de EU. Als het aantoonbaar waarde oplevert en de eisen strenger worden, kun je dezelfde code alsnog naar eigen infrastructuur verhuizen. De MCP-server is niet het stuk dat je vastzet, de standaard is open en de code blijft van jou.

Zo zet je een MCP-server op in vijf stappen

1. Kies één systeem en drie acties. Begin niet met "alles ontsluiten". Pak het systeem waar de meeste vragen over binnenkomen en bedenk de drie handelingen die mensen wekelijks doen. Klein beginnen levert sneller iets bruikbaars op en houdt de risico's overzichtelijk. Voor de bekende pakketten schreven we de koppelkant al uit in AI koppelen aan Exact, AFAS of HubSpot.
2. Maak de acties alleen-lezen én smal. In de eerste versie mag de assistent opzoeken en samenvatten, meer niet. Geef elke leesactie zo min mogelijk terug: één record op een zoekterm, met een server-side limiet, in plaats van een actie die de hele tabel dumpt. Alleen-lezen voorkomt wijzigen, niet leeglezen. Schrijfacties voeg je pas toe als je in de logs ziet dat de leesacties doen wat je verwacht.
3. Zet authenticatie ervoor. Een remote MCP-server hoort achter OAuth 2.1 met PKCE te staan, zodat elke gebruiker persoonlijk inlogt en je toegang per persoon kunt intrekken. Een gedeelde API-sleutel is geen alternatief: die kun je niet herleiden naar één persoon en niet intrekken zonder iedereen te raken.
4. Beperk wat de server zelf mag. Geef de server een eigen account in het bronsysteem met de minimale rechten, niet het account van de directeur. Zet daarnaast vast met welke externe adressen de server mag praten, zodat data er niet ongemerkt uit kan lopen.
5. Zet er logging op en kijk mee. Log elke aanroep: wie, welke actie, welke parameters, welk resultaat. De eerste weken lees je die logs echt door. Je ziet dan welke vragen mensen stellen en welke acties je omschrijving verkeerd begrepen wordt.

Security-checklist voor een MCP-server met bedrijfsdata

Loop deze punten af voordat je echte data aansluit. Ze zijn geordend op hoe vaak het misgaat, niet op hoe ingewikkeld ze zijn.

• Persoonlijke authenticatie via OAuth 2.1 met PKCE. Elke gebruiker logt in met een eigen account. PKCE is de beveiliging die voorkomt dat een onderschepte inlogcode door iemand anders ingewisseld kan worden, en is beschreven in RFC 7636. Geen gedeelde sleutels in configuratiebestanden.
• Toegangslijst per server. Leg vast wie er bij mag. Niet iedereen met een bedrijfsmail hoeft bij de financiële cijfers te kunnen, en een vertrekkende collega moet je in één handeling kunnen verwijderen.
• Minimale rechten in het bronsysteem. De server krijgt een eigen serviceaccount met precies de rechten die de acties nodig hebben. Zo blijft de schade beperkt als er iets misgaat.
• Alleen-lezen tenzij anders besloten. Schrijfacties zijn een aparte beslissing per actie, met een expliciete bevestigingsstap voor onomkeerbare handelingen.
• Uitgaand verkeer op een whitelist. Leg vast met welke adressen de server contact mag maken. Dit is je vangnet tegen het scenario hierboven: zelfs als een brede leesactie of een prompt-injectie de assistent zover krijgt data te verzamelen, kan je server die niet naar een willekeurig extern adres wegsturen. Zonder die grens kan een fout of een kwaadaardige instructie data naar buiten sturen zonder dat iemand het ziet.
• Audittrail die je kunt uitleggen. Wie heeft wanneer welke actie uitgevoerd, en met welk resultaat. Dit heb je nodig bij een incident, en je toezichthouder of accountant vraagt er vroeg of laat naar.
• Hosting binnen de EU en een verwerkersovereenkomst. Als er persoonsgegevens door de server lopen, ben je verwerkingsverantwoordelijke. De Autoriteit Persoonsgegevens legt uit wat dat betekent; wij zetten de praktische kant op een rij in AI en je bedrijfsdata: wat moet je regelen voor AVG en de AI Act?.
• Secrets die niemand kan uitlezen. Wachtwoorden en tokens horen in een versleutelde omgevingsvariabele, niet in de code en niet in een gedeeld document.
• Bewaartermijn voor logs. Logs met bedrijfsdata bewaar je zo lang als nodig en niet langer. Leg de termijn vast en ruim automatisch op.
• Een testomgeving met neptata. Ontwikkel en demonstreer op testdata. De verleiding om "even met de echte database" te testen is groot en gaat een keer mis.

Wat gaat er in de praktijk mis?

De meest gemaakte fout is te veel acties tegelijk aanbieden. Bij dertig acties kiest een assistent regelmatig de verkeerde, en wordt het onvoorspelbaar. Bij drie tot acht scherp omschreven acties gaat het bijna altijd goed. Minder is hier echt beter.

De tweede fout is vage omschrijvingen. "Haalt gegevens op" zegt een model niets. "Zoekt een order op klantnaam of ordernummer en geeft status, leverdatum en regels terug" wel. Je omschrijving is geen documentatie achteraf, het is de instructie waarop het model zijn keuze baseert.

De derde fout is beveiliging uitstellen tot na de pilot. In de praktijk gaat een geslaagde pilot ongemerkt over in productie, en dan staat er een server zonder inlog aan het internet met je klantdata erachter. Zet authenticatie er vanaf dag één voor, ook als er nog maar twee mensen meedoen.

De vierde fout is niet meten. Zonder logs weet je niet welke acties gebruikt worden, welke vragen mislukken en of het iemand tijd bespaart. Dan blijft het bij een leuke demo.

Wat kost het?

De kosten vallen uiteen in bouwen en draaien. Het bouwen van een eerste MCP-server met een paar acties is een kwestie van dagen, niet maanden, mits het bronsysteem een bruikbare API heeft. Zonder API wordt het een ander gesprek, want dan moet je die laag eerst maken.

Het draaien is de post die mensen onderschatten bij self-hosten. Een server kost weinig, maar het beheer eromheen kost aandacht: updates, certificaten, toegangsbeheer, monitoring en iemand die kijkt als het stilstaat. Bij managed hosting zit dat in het maandbedrag, en dat is meestal goedkoper dan de uren die je er zelf in stopt.

Onze eigen managed MCP- en API-host, DenkOps, is precies hiervoor gebouwd: je zet je server erop en de OAuth-inlog, HTTPS, toegangslijsten per project, audittrail en uitgaande whitelist zitten er standaard omheen. Gehost in de EU. Dat scheelt het grootste deel van de checklist hierboven, terwijl je code van jou blijft.

Waar begin je?

Begin bij de vraag die het vaakst gesteld wordt in je bedrijf. Niet bij de techniek. Als collega's elke week hetzelfde opzoeken in hetzelfde systeem, dan is dat je eerste MCP-server, en zijn dat je eerste drie acties. Bouw die, zet hem achter een fatsoenlijke inlog, en kijk twee weken mee in de logs.

Wil je sparren over welk systeem zich het beste leent en of self-hosten of managed bij jouw situatie past? Plan een gesprek, dan kijken we samen naar je systemen en wat er realistisch te halen valt.

Veelgestelde vragen

Wat is een MCP-server precies?

Een MCP-server is een klein stuk software dat een AI-assistent toegang geeft tot een systeem via een vast aantal duidelijk omschreven acties. MCP staat voor Model Context Protocol, de open standaard die assistenten als Claude en ChatGPT gebruiken om met externe software te praten. De assistent leest de omschrijving van elke actie en kiest zelf welke hij bij een vraag nodig heeft.

Kan ik een MCP-server beter zelf hosten of laten hosten?

Zelf hosten past als je al een beheerde serveromgeving hebt, als je data om compliance-redenen op eigen infrastructuur moet blijven, of als het bronsysteem niet vanaf internet bereikbaar is. Managed hosting past als je die serverkennis niet in huis hebt of binnen dagen live wilt, omdat OAuth, TLS-certificaten, toegangsbeheer en monitoring dan geregeld zijn. De MCP-server zelf is meestal een paar honderd regels code; het werk zit in alles eromheen.

Is een MCP-server veilig voor bedrijfsdata?

Ja, mits je hem goed inricht. De basis: persoonlijke authenticatie via OAuth 2.1 met PKCE, een serviceaccount met minimale rechten in het bronsysteem, een whitelist voor uitgaand verkeer en een audittrail van elke aanroep. Besef daarbij dat alleen-lezen wijzigen voorkomt maar niet leeglezen, en dat het antwoord van een tool naar het AI-model gaat. Vertrouwelijkheid komt dus van smal ontworpen acties, de uitgaande whitelist, toegang per persoon en EU-hosting met een verwerkersovereenkomst, niet van alleen-lezen op zich. De grootste risico's zijn een server zonder inlog die aan het internet hangt, en te ruime rechten of te brede leesacties.

Wordt mijn data gekopieerd naar een AI-platform?

Niet in bulk, en dat is het verschil. Je uploadt of synchroniseert niet je hele database naar een derde partij; je systeem van waarheid blijft je eigen database. Wel gaat het antwoord dat je server per vraag teruggeeft op dat moment naar het AI-model om de vraag te beantwoorden. Vertrouwelijkheid regel je daarom met smal ontworpen acties, een uitgaande whitelist, toegang per persoon en EU-hosting met een verwerkersovereenkomst, zodat je stuurt wat er per vraag bereikbaar is.

Hoe lang duurt het om een eerste MCP-server te bouwen?

Een eerste MCP-server met drie tot vijf acties is een kwestie van dagen, mits het bronsysteem een bruikbare API heeft. Heeft dat systeem geen API, dan moet die laag er eerst komen en wordt het een groter traject. Begin met het systeem waar de meeste vragen over binnenkomen en houd het aantal acties bewust klein.