MCP-servers voor Docs, Sheets en Slides: AI-agents veilig toegang geven

Google bracht in 2026 MCP-servers uit voor Workspace. Voor Gmail, Calendar, Drive en Chat verschenen ze op 22 april 2026, voor Docs, Sheets en Slides op 13 juli 2026 in Developer Preview. AI-agenten kunnen via het Model Context Protocol documenten, spreadsheets en presentaties lezen en aanpassen, en dat maakt de vraag actueel hoe je die toegang inricht en begrenst.

Wat MCP is en waarom het relevant is

MCP staat voor Model Context Protocol. Het is een open standaard waarmee AI-modellen en AI-agenten op een gestandaardiseerde manier toegang krijgen tot externe systemen en data. In plaats van voor elke toepassing een eigen koppeling te bouwen, spreekt een agent via MCP met een server die de toegang regelt.

Het praktische voordeel is dat een agent niet rechtstreeks in je systemen graaft, maar via een afgebakende laag werkt. De MCP-server bepaalt welke acties mogelijk zijn en hoe die worden uitgevoerd. Dat maakt het mogelijk om een agent toegang te geven tot bijvoorbeeld een spreadsheet, zonder dat je de agent volledige toegang tot alles geeft.

Voor Google Workspace is dat relevant omdat de data daar zit waar het werk gebeurt. Documenten, spreadsheets, presentaties, mail, agenda en chat vormen samen het geheugen van een organisatie. AI-agenten worden nuttiger naarmate ze bij die data kunnen, maar elke vorm van toegang brengt een vraag over beveiliging en beheer met zich mee. MCP is de manier waarop Google die toegang structureert.

Wie al bekend is met het onderwerp kent misschien het eerdere artikel over de Workspace MCP-server. Dit artikel zoomt in op de nieuwere toevoeging: Docs, Sheets en Slides.

Welke MCP-servers er zijn

Google bracht de MCP-servers in twee golven uit. Op 22 april 2026 kwamen de servers voor Gmail, Calendar, Drive en Chat. Dat dekt de kern van de communicatie en de opslag: mail, agenda, bestanden en gesprekken.

Op 21 mei 2026 volgde een uitbreiding op Drive, namelijk copy_file. Daarmee kan een agent een bestand kopiëren, wat nuttig is wanneer je met sjablonen werkt en een nieuwe versie wilt maken op basis van een bestaand bestand.

Op 13 juli 2026 kwamen daar de MCP-servers voor Docs, Sheets en Slides bij, in Developer Preview. Dat is een belangrijke uitbreiding, omdat documenten, spreadsheets en presentaties nu eenmaal het materiaal zijn waarmee kenniswerkers de dag doorbrengen. Een agent die een document kan lezen en aanpassen, kan echt werk overnemen. Een agent die alleen kan praten, blijft beperkt.

Developer Preview betekent dat de functie beschikbaar is om te testen en te gebruiken in ontwikkeling, maar nog niet als voltooide, algemeen beschikbare functionaliteit. Houd daar rekening mee bij het plannen: reken op veranderingen en test zorgvuldig voordat je iets in productie neemt.

Docs, Sheets en Slides in Developer Preview

Met de MCP-servers voor Docs, Sheets en Slides kunnen AI-agenten documenten, spreadsheets en presentaties lezen en aanpassen. Denk aan een agent die een lang contract samenvat, een agent die gegevens in een spreadsheet bijwerkt op basis van een instructie, of een agent die een presentatie opstelt uit bestaande informatie.

De kracht zit in de combinatie met de eerdere servers. Een agent kan via Drive een bestand vinden, via Docs de inhoud lezen, via Sheets gegevens ophalen en via Gmail een samenvatting sturen. Voor organisaties die Workspace breed gebruiken, ontstaat zo een agent die over de hele keten kan werken.

Dat roept direct de vraag op hoe je die agent begrenst. Een agent met toegang tot Docs, Sheets en Slides heeft in potentie toegang tot gevoelige informatie: personeelsdossiers, contracten, financiële overzichten. De MCP-laag is er juist om die toegang te structureren, maar dat vraagt nog steeds om bewuste keuzes aan jouw kant.

Begin met een afgebakende use case. Kies een taak die waarde toevoegt en een duidelijke scope heeft, bijvoorbeeld het samenvatten van openbare projectdocumentatie. Breid pas uit wanneer je vertrouwd bent met de werking en de risico's in kaart hebt gebracht.

Hoe AI-agents toegang krijgen

Een AI-agent krijgt toegang via de MCP-server. In plaats van rechtstreeks met de Workspace API's te werken, spreekt de agent met de MCP-server, die vervolgens de actie uitvoert. Dat is het punt waar je als beheerder invloed hebt.

De precieze inrichting hangt af van het platform waarmee je werkt en van de configuratie van de MCP-server. Wat in alle gevallen geldt, is dat je bepaalt welke agent toegang krijgt, namens wie die handelt en tot welke data die toegang reikt. Zonder die keuzes is er geen sprake van beheerste toegang.

Denk na over de identiteit waarmee de agent werkt. Handelt de agent namens een specifieke gebruiker, of namens een service-account? Die keuze bepaalt welke data de agent kan zien. Een agent namens een gebruiker ziet wat die gebruiker mag zien. Een agent namens een service-account kan breder toegang hebben, wat krachtig maar ook risicovol is.

Denk ook na over logging. Je wilt kunnen terugvinden wat een agent heeft gedaan en wanneer. Dat is niet alleen belangrijk voor de beveiliging, maar ook voor het vertrouwen van gebruikers. Als een agent een document aanpast, moet duidelijk zijn dat het gebeurde en waarom.

Toegang inrichten en begrenzen

Het inrichten van agenttoegang is een beheertaak, geen bijzaak. De MCP-servers maken toegang mogelijk, maar de grenzen bepaal jij.

Een eerste principe is minimale rechten. Geef een agent alleen de toegang die nodig is voor de taak. Heeft een agent alleen leesrechten nodig op een specifieke map, geef dan geen schrijfrechten op de hele Drive. Beperk de scope tot wat strikt nodig is en breid pas uit wanneer daar een goede reden voor is.

Een tweede principe is scheiding. Gebruik aparte agents of aparte accounts voor verschillende taken. Zo voorkom je dat één agent met brede rechten alles kan. Als er iets misgaat, blijft de schade beperkt tot het deel waar die agent toegang toe had.

Een derde principe is controle op externe verbindingen. Een agent die via MCP met Workspace praat, kan ook met andere systemen praten. Zorg dat je weet welke verbindingen er zijn en welke data daarbij het systeem verlaat. Voor organisaties met eisen rond datasoevereiniteit is dat een punt dat aandacht verdient.

Een vierde principe is beheer van de levensduur. Agents en de bijbehorende inrichting verouderen. Een agent die voor een project is opgezet, blijft vaak actief nadat het project is afgelopen. Neem het opruimen van agenttoegang mee in je periodieke beheerronde.

Waar je als beheerder op moet letten

Als beheerder is het je taak om de balans te vinden tussen nut en risico. MCP-servers zijn een krachtig hulpmiddel, maar ze introduceren ook een nieuwe vorm van toegang die je moet begrijpen.

Weet welke MCP-servers beschikbaar zijn in je omgeving en wie ze gebruikt. Net als bij andere integraties geldt: wat je niet in kaart hebt, kun je niet beheren. Een overzicht van actieve agents en hun rechten is het startpunt.

Beoordeel de gevoeligheid van de data waar een agent bij kan. Combineer dat met de vraag of de agent echt nodig is voor het werk. Soms is een agent handig, maar niet noodzakelijk. Terughoudendheid is een legitieme beheerkeuze.

Kijk naar de samenhang met je andere maatregelen. Data regions bepalen waar data wordt opgeslagen en verwerkt. Je Workspace-beveiligingsinstellingen bepalen wie wat mag. MCP-toegang moet daarbinnen passen, niet erbuiten. Een agent mag geen achterdeur worden om je eigen beleid te omzeilen.

En test in Developer Preview met echte scenario's. Juist omdat de functie nog in ontwikkeling is, leer je het meest van het daadwerkelijk uitproberen van een use case, in een omgeving waar een fout geen ramp is.

Van losse servers naar een samenhangende laag

De MCP-servers zijn per product opgezet, maar werken in de praktijk samen. Een agent kan via Drive een bestand vinden, via Docs de inhoud lezen, via Sheets gegevens ophalen en via Gmail een samenvatting sturen. De afzonderlijke servers vormen zo een laag waarmee een agent over het hele platform kan werken.

Dat maakt de beheerafweging ook breder. Je beoordeelt niet een enkele koppeling, maar de totale toegang die een agent krijgt. Een agent die alleen leest, is een ander risico dan een agent die ook kan schrijven. Breng daarom in kaart welke servers en welke tools een agent gebruikt, en stem de rechten daarop af.

Werken met een afgebakende scope

Een praktisch uitgangspunt is om te beginnen met een gebruiker-gebonden agent en minimale rechten. Handelt een agent namens een specifieke gebruiker, dan ziet hij wat die gebruiker ziet en niet meer. Werk je met een service-account, dan kan de agent breder kijken, wat krachtig is maar ook om extra waarborgen vraagt.

Maak de scope expliciet en controleer hem periodiek. Een agent die voor een project is opgezet, blijft vaak actief nadat het project is afgelopen. Neem het opruimen van agenttoegang mee in je beheerronde, zodat oude rechten niet blijven staan.