Ongeveer een jaar lang was het eerlijke antwoord op "is het veilig om een AI-assistent aan mijn notities te koppelen?" dat de koppeling ze alleen las. Dat gold voor de meeste MCP-servers voor vergadernotities, en het maakte de veiligheidsvraag eenvoudig: een tool die niets kan wijzigen, kan niet het verkeerde wijzigen.
Daar zit de interessante vraag niet meer. Assistenten taggen inmiddels opnamen, hernoemen sprekers, transcriberen opnieuw en publiceren notities in gedeelde kanalen — en de bruikbare versie van de vraag is smaller: wat moet er waar zijn voordat u een model uw gegevens laat wijzigen? Vier dingen, en geen daarvan is "de leverancier belooft voorzichtig te zijn": de client vraagt het voor de aanroep, de wijziging is smal genoeg om in één zin te beschrijven, onomkeerbare wijzigingen zijn als zodanig gemarkeerd, en er is een logboek dat u achteraf kunt lezen.
Dit artikel gaat over waar die grens loopt. Is het protocol zelf nieuw voor u, dan behandelt wat een MCP-server is eerst de basis.
"Schrijfrechten" is één term voor drie heel verschillende dingen, en juist het op één hoop gooien maakt het onderwerp enger dan het is.
Labelen. Tags, titels, sprekernamen. Die voegen metadata naast een opname toe of vervangen ze. Tagt de assistent de verkeerde vergadering, dan opent u de app en haalt u de tag weg. Het ergste geval is opruimen achter een al te enthousiast model.
Inhoud vervangen. Een opname opnieuw transcriberen levert een nieuwe tekst op en gooit de oude weg — inclusief de correcties die u met de hand hebt gemaakt. Er is niets van uw machine af gegaan, maar iets wat van u was, is verdwenen. Dit is de klasse waarin "omkeerbaar" stilletjes ophoudt te kloppen.
De machine verlaten. Een opname in een teamkanaal publiceren, een transcript per e-mail delen, iemand toegang geven. Hier gaat de wijziging niet in de eerste plaats over uw gegevens — maar over wie ze heeft gezien. Ongedaan maken is een technische handeling op een sociaal feit, en dat werkt niet.
Een veiligheidsmodel dat deze drie als één instelling behandelt, zit er in beide richtingen naast: te luidruchtig voor de eerste, te toegeeflijk voor de derde.
MCP heeft hier een woordenschat voor. Een tooldefinitie kan annotaties dragen:
readOnlyHint (de tool leest alleen), destructiveHint (hij kan overschrijven
in plaats van toevoegen), idempotentHint (twee keer aanroepen verandert verder
niets) en openWorldHint (hij reikt naar externe systemen). Een server die een
deeltool publiceert zonder openWorldHint beschrijft zichzelf verkeerd.
Twee zinnen uit de specificatie bepalen wat die woordenschat waard is. Ten eerste over de plicht van de client: "Omwille van vertrouwen, veiligheid en beveiliging ZOU er altijd een mens in de lus moeten zijn die tool-aanroepen kan weigeren." Ten tweede over de annotaties zelf: clients "MOETEN tool-annotaties als onbetrouwbaar beschouwen tenzij ze van vertrouwde servers komen."
Samen gelezen leggen die de architectuur vast. Annotaties zijn de manier waarop een server risico aankondigt; ze zijn geen slot dat de server kan dichtdraaien. De poort zit in de client, en het bevestigingsvenster dat u ziet voordat een tool draait, is een beslissing van uw client, gevoed door wat de server aangeeft. Claude Code laat MCP-tools bijvoorbeeld standaard vragen, terwijl zijn eigen ingebouwde tools dat niet doen.
Het praktische gevolg is ongemakkelijk en verdient het om ronduit gezegd te worden: het moment waarop u iets beslist, is het moment waarop u staande toestemming geeft. Na "altijd toestaan" is het venster geen controle meer. Geef die toestemming per tool en niet per server — elk uur zoeken is prima, elk uur delen niet.
De bruikbare as is niet lezen tegenover schrijven. Het is wat een fout kost.
| Actie | Ongedaan maken | Waarom |
|---|---|---|
| Een tag toevoegen of verwijderen | Ja, in de app | Metadata naast de opname |
| Een opname of spreker hernoemen | Ja, in de app | Een label, niet de inhoud |
| Opnieuw transcriberen | Nee | Vervangt de tekst, handmatige correcties inbegrepen |
| Publiceren in een teamkanaal | Nee | Collega's hebben het misschien al gelezen |
| Een transcript per e-mail delen | Nee | Ontvangers houden wat ze hebben gekregen |
Alles in de onderste drie rijen verdient elke keer een expliciete bevestiging; alles in de bovenste twee waarschijnlijk niet. In de toolslijst zegt een leverancier welke van deze acties hij aanbiedt, en die is het lezen waard voordat u iets koppelt.
Bevestigingsvensters slijten. Eén onderzoekstaak kan er tientallen opleveren, ook voor tools die niets kunnen wijzigen, en het gedocumenteerde resultaat is dat mensen de meldingen in één keer uitzetten in plaats van de volgende te lezen. Een controle die u aanleert om hem weg te klikken, is geen controle.
Een logboek slijt niet, omdat u het achteraf leest en alleen als u een vraag hebt. De specificatie raadt clients zelf aan het gebruik van tools te loggen voor controledoeleinden, en dezelfde redenering geldt voor de server: als een assistent iets kan wijzigen, hoort u achteraf te kunnen zien wat hij heeft gewijzigd, wanneer, en bij welke opname.
De bruikbare toets voor elke MCP-koppeling met schrijfrechten: als het model vannacht iets onverwachts heeft gedaan, waar zou ik daar vandaag over lezen? Is het antwoord "nergens", dan droeg het bevestigingsvenster in zijn eentje het hele veiligheidsmodel.
Er zijn twee manieren om een assistent te beletten dingen te wijzigen, en ze zijn niet uitwisselbaar.
Per client, in de configuratie van die client. Een server die in
alleen-lezen-modus start, publiceert alleen zijn leestools. Het verschil met het
weigeren van aanroepen is niet cosmetisch: een tool die het model niet ziet, is
een tool die het niet voorstelt, dus krijgt u nooit "ik publiceer dat nu in het
teamkanaal" gevolgd door een foutmelding. In Speak-Y is dat de vlag
--read-only in args van de server, en er blijven zes leestools over.
Globaal, in de app. Eén schakelaar die alle gekoppelde clients tegelijk dekt, ongeacht welke het vroeg.
Het onderscheid doet ertoe, omdat een vlag in het configuratiebestand van Cursor alleen Cursor beteugelt. De vlag per client zegt "Cursor mag alleen lezen, Claude Code mag alles"; alleen de schakelaar in de app is een uitspraak over allemaal.
Speak-Y splitst de twee helften bewust, en die splitsing is van buitenaf zichtbaar.
Lezen is lokaal en er hoeft niets te draaien. Zoeken, transcripten, samenvattingen, actiepunten en tags komen uit de bibliotheek op uw Mac, alleen-lezen geopend door een apart proces; de app hoeft niet te draaien. Er wordt niets geüpload om de assistent te laten lezen — al gaat, zoals bij elke MCP-server, alles wat hij leest als onderdeel van het gesprek naar uw modelaanbieder, en dat is een aparte vraag dan waar de gegevens staan.
Wijzigingen lopen via de draaiende app. Taggen, hernoemen, opnieuw transcriberen en publiceren in een teamkanaal worden uitgevoerd door dezelfde code die achter de knoppen in de interface zit, niet door een tweede implementatie met eigen ideeën over de regels. Draait de app niet, dan zeggen die tools dat in plaats van half te werken.
Elke actie wordt aangekondigd en gelogd. De wijzigende tools worden
gepubliceerd met readOnlyHint: false; opnieuw transcriberen en publiceren in
een kanaal dragen daarnaast destructiveHint, en publiceren draagt
openWorldHint, omdat het de enige actie is die de machine verlaat. De laatste
50 acties staan in Instellingen → Integraties met tijd, bewerking, opname en
uitkomst — en zonder transcripttekst, die anders de opname zou overleven waar
hij vandaan kwam. De schakelaar voor assistentacties staat op hetzelfde scherm,
en de server is gratis in elk abonnement.
Gecontroleerd op 13 augustus 2026, in de documentatie van elke leverancier zelf:
De lijst van Fireflies is de interessante, want "deel dit transcript met deze e-mailadressen" is precies de klasse actie waarbij de bevestiging van de client het enige is dat tussen een verkeerd gelezen instructie en een ontvanger staat. Dat is geen kritiek op de functie — het in de toolslijst benoemen is de eerlijke manier om hem uit te brengen. Het is een argument om die lijst te lezen voordat u een hele server staande toestemming geeft.
Niets hiervan vraagt om vertrouwen in de bedoelingen van een leverancier, en dat is het punt. "Is het veilig om een assistent mijn gegevens te laten wijzigen?" heeft geen algemeen antwoord, maar valt uiteen in vragen die dat wel hebben: wat er verandert, wie bevestigt, wat omkeerbaar is, en waar het is vastgelegd.
Hebt u nog geen assistent gekoppeld, dan is vergadernotities koppelen via MCP het praktische startpunt; dat loopt de installatie en de eerste prompts langs voordat iets hiervan relevant wordt.
In één beperkt opzicht wel: een tool die niets kan wijzigen, kan niet het verkeerde wijzigen. Maar alleen-lezen is een bot instrument, geen veiligheidsmodel. Wat u werkelijk beschermt, is weten welke wijzigingen omkeerbaar zijn, een client die het vraagt voor de onomkeerbare, en achteraf kunnen lezen wat er is gebeurd. Een alleen-lezen server geeft u die eerste eigenschap door de functie op te geven.
Dat is een eigenschap van uw client, niet van de server. De MCP-specificatie zegt dat er altijd een mens in de lus zou moeten zijn die een tool-aanroep kan weigeren, en clients als Claude Code laten MCP-tools standaard vragen. Servers kunnen een tool via annotaties als gegevenswijzigend of destructief aanmerken, maar de specificatie verplicht clients die annotaties als onbetrouwbaar te behandelen tenzij de server vertrouwd is: ze voeden het bevestigingsvenster, ze dwingen niets af.
Het bevestigingsvenster is voor die tool geen controle meer, en elke volgende aanroep draait zonder te vragen. Voor een zoektool is dat een redelijke ruil, voor een tool die gegevens met andere mensen deelt een slechte. Geef staande toestemming per tool in plaats van per server, en behandel het actielogboek als het antwoord op wat er werkelijk is gebeurd.
Ja, als de server een alleen-lezen-modus kent die u in de configuratie van de client zelf zet. Speak-Y kent die: --read-only toevoegen aan args in de MCP-configuratie van een client publiceert alleen de leestools voor die client, dus Cursor kan tot lezen beperkt blijven terwijl Claude Code volledige toegang houdt. Een schakelaar in de app geldt juist voor alle clients tegelijk.
Twee klassen. Opnieuw transcriberen vervangt de huidige tekst van een opname, inclusief handmatige correcties. Een opname in een teamkanaal publiceren maakt hem zichtbaar voor collega's, en hem later weghalen maakt het gelezene niet ongelezen. Tags, titels en sprekernamen zijn labels en kunt u in de app terugzetten.