MCP in de praktijk: AI in je eigen systemen
Steeds meer pakketten hebben een MCP-server waarmee AI in je CRM leest en schrijft. Waar je op let: rechten, schrijfacties, prompt-injectie en de AVG.
Niyazi Gökmen, Lead security · · 5 min
MCP, het Model Context Protocol, is de standaard waarmee een AI-assistent gereedschap krijgt: zoek deze klant op, maak deze taak aan, haal de openstaande facturen op. In het artikel over koppelen zonder API stond het als een van de routes om een gesloten systeem bereikbaar te maken. Inmiddels is het vooral de route waarlangs leveranciers hun eigen pakket openzetten voor AI. HubSpot biedt sinds april 2026 een algemeen beschikbare MCP-server die in het CRM kan lezen en schrijven, en voor pakketten als Exact Online en AFAS bestaan servers van derde partijen.
Dat maakt het verleidelijk om een AI-assistent aan je CRM of administratie te hangen. Het is ook de snelste manier om een model meer rechten te geven dan je een nieuwe medewerker op de eerste dag zou geven. Vier dingen leggen we daarom vast voordat een MCP-server aangaat.
Wie er tussen zit
Een MCP-server van de leverancier zelf is een koppeling met de partij die je al met je gegevens vertrouwt. Een server van een derde partij is dat niet. Die zit tussen de assistent en je pakket, krijgt toegang tot alles wat de assistent mag, en is daarmee een extra verwerker, met een eigen verwerkersovereenkomst, eigen subverwerkers en een eigen locatie waar de gegevens langskomen. Soms is dat de enige route. Maak het dan een bewuste keuze en geen installatie van een middag.
Voor een server die lokaal draait, geldt een andere vraag. Die draait met dezelfde rechten als het programma dat hem start, en kan dus meer bereiken dan alleen dat ene pakket. Installeer alleen servers waarvan je de herkomst kent, en laat medewerkers ze niet zelf toevoegen.
Rechten: per gebruiker, en eerst alleen lezen
Een goede MCP-server werkt met de rechten van de gebruiker die de assistent bedient. De MCP-specificatie beschrijft daarvoor autorisatie via OAuth, en de server van HubSpot bijvoorbeeld respecteert de bestaande rechten in het portaal. Het slechte alternatief is één beheerdersaccount waarmee iedere gebruiker via de assistent alles kan. Dan kan een stagiair met een vraag in gewone taal doen wat in het pakket zelf nooit zou mogen.
Begin met leesrechten. Een assistent die klantgegevens opzoekt, een dossier samenvat of openstaande posten opsomt, levert al veel op en kan weinig kapotmaken. Schrijfacties, zoals een record aanpassen, een mail versturen of een factuur aanmaken, zet je per handeling aan, met een bevestiging door de gebruiker vóór de uitvoering. Onomkeerbare handelingen, zoals verwijderen of iets naar buiten versturen, horen in de eerste fase niet in de gereedschapskist.
Prompt-injectie: het model leest ook wat anderen schrijven
Een assistent die in je CRM leest, leest ook de notities, mails en documenten die daar staan. Een deel daarvan is geschreven door klanten, kandidaten of leveranciers. Staat in zo'n tekst een instructie, bijvoorbeeld om alle contactgegevens naar een extern adres te sturen, dan kan een model die opvolgen alsof de gebruiker erom vroeg. Dat heet prompt-injectie, en er bestaat geen filter dat het volledig voorkomt.
De verdediging zit daarom in wat het model kan, niet in wat het leest. Een assistent die alleen kan lezen, kan niets versturen. Een assistent die kan versturen, doet dat alleen na bevestiging, met ontvanger en inhoud zichtbaar. En een assistent die tegelijk bij gevoelige gegevens kan, onbetrouwbare tekst leest én naar buiten kan communiceren, is precies de combinatie die je niet bouwt.
Logboek: elke aanroep, met invoer en uitkomst
Omdat er een model tussen zit, leidt dezelfde vraag niet altijd tot dezelfde aanroep. Achteraf wil je dus kunnen zien wat er feitelijk is gebeurd: welke gebruiker, welke tool, met welke invoer, met welk resultaat, en of er een bevestiging was. Log dat aan de kant van de server of van een tussenlaag die je zelf beheert. De chatgeschiedenis van de assistent is geen logboek: een gebruiker kan die wissen. En log verwijzingen naar records in plaats van de volledige inhoud.
Wat we afraden
Een MCP-server voor het hele bedrijf aanzetten om te kijken wat mensen ermee doen. Dan heb je binnen een week twintig toepassingen waarvan niemand weet welke gegevens erin gaan. Begin met één team, één pakket en een handvol leeshandelingen, en breid uit op basis van wat daar echt is gebruikt.
Afgeraden ook: MCP inzetten voor een stroom die elke nacht hetzelfde moet doen. Voor een vaste, herhaalbare stroom is een gewone API-koppeling voorspelbaarder, goedkoper en beter te controleren. MCP is voor de vraag die je vooraf niet kent.
Wat je nu kunt doen: zoek per pakket in je proces uit of de leverancier zelf een MCP-server levert, of dat er alleen servers van derden bestaan. Schrijf voor één team op welke vijf vragen ze het vaakst aan dat pakket stellen, en of dat lees- of schrijfvragen zijn. Dat is de afbakening voor een eerste proef: alleen die handelingen, alleen die gebruikers, met logging aan. Meet vooraf hoe lang het beantwoorden van die vijf vragen nu duurt, zodat de proef iets te bewijzen heeft.