Knapp ein Jahr lang lautete die ehrliche Antwort auf „ist es sicher, einen KI-Assistenten an meine Notizen anzuschließen?“, dass die Verbindung sie nur liest. Das galt für die meisten MCP-Server für Besprechungsnotizen, und es machte die Sicherheitsfrage einfach: Ein Werkzeug, das nichts ändern kann, kann auch nicht das Falsche ändern.
Dort liegt die interessante Frage nicht mehr. Assistenten vergeben inzwischen Tags, benennen Sprecher um, starten Transkriptionen neu und veröffentlichen Notizen in geteilten Kanälen — und die brauchbare Fassung der Frage ist enger: Was muss erfüllt sein, bevor Sie ein Modell Ihre Daten ändern lassen? Vier Dinge, und keines davon lautet „der Anbieter verspricht, sorgfältig zu sein“: Der Client fragt vor dem Aufruf nach, die Änderung ist eng genug, um sie in einem Satz zu beschreiben, unumkehrbare Änderungen sind als solche gekennzeichnet, und es gibt ein Protokoll, das Sie hinterher lesen können.
In diesem Artikel geht es darum, wo diese Grenze verläuft. Wenn Ihnen das Protokoll selbst neu ist, klärt was ein MCP-Server ist zuerst die Grundlagen.
„Schreibzugriff“ ist ein einziger Ausdruck für drei sehr verschiedene Dinge, und sie in einen Topf zu werfen ist das, was das Thema bedrohlicher wirken lässt, als es ist.
Etikettieren. Tags, Titel, Sprechernamen. Das ergänzt oder ersetzt Metadaten neben einer Aufnahme. Wenn der Assistent das falsche Meeting taggt, öffnen Sie die App und nehmen das Tag wieder weg. Der schlimmste Fall ist Aufräumen hinter einem übereifrigen Modell.
Inhalte ersetzen. Eine erneute Transkription einer Aufnahme erzeugt einen neuen Text und verwirft den alten — samt der Korrekturen, die Sie von Hand gemacht haben. Nichts hat Ihren Rechner verlassen, aber etwas, das Ihnen gehörte, ist weg. Das ist die Klasse, in der „umkehrbar“ stillschweigend aufhört zu stimmen.
Den Rechner verlassen. Eine Aufnahme in einem Team-Kanal veröffentlichen, ein Transkript per E-Mail teilen, jemandem Zugriff geben. Hier betrifft die Änderung nicht in erster Linie Ihre Daten — sie betrifft, wer sie gesehen hat. Rückgängig ist eine technische Operation an einer sozialen Tatsache, und sie funktioniert nicht.
Ein Sicherheitsmodell, das diese drei als eine einzige Einstellung behandelt, liegt in beide Richtungen falsch: zu laut für die erste, zu großzügig für die dritte.
MCP hat dafür ein Vokabular. Eine Werkzeugdefinition kann Annotationen tragen:
readOnlyHint (das Werkzeug liest nur), destructiveHint (es überschreibt
womöglich, statt zu ergänzen), idempotentHint (ein zweiter Aufruf ändert nichts
weiter) und openWorldHint (es greift auf externe Systeme zu). Ein Server, der
ein Werkzeug zum Teilen ohne openWorldHint veröffentlicht, beschreibt sich
falsch.
Zwei Sätze der Spezifikation entscheiden, wie viel dieses Vokabular wert ist. Erstens zur Pflicht des Clients: „Aus Gründen der Vertrauenswürdigkeit und Sicherheit SOLLTE immer ein Mensch in der Schleife sein, der Werkzeugaufrufe ablehnen kann.“ Zweitens zu den Annotationen selbst: Clients „MÜSSEN Werkzeug-Annotationen als nicht vertrauenswürdig betrachten, sofern sie nicht von vertrauenswürdigen Servern stammen.“
Zusammengelesen klären diese beiden Sätze die Architektur. Annotationen sind die Art, wie ein Server ein Risiko deklariert; sie sind kein Schloss, das er zusperren könnte. Die Schranke sitzt im Client, und die Bestätigungsabfrage, die Sie vor dem Lauf eines Werkzeugs sehen, ist eine Entscheidung Ihres Clients, informiert durch die Deklaration des Servers. Claude Code etwa fragt bei MCP-Werkzeugen standardmäßig nach, bei seinen eigenen eingebauten Werkzeugen nicht.
Die praktische Folge ist unbequem und gehört klar gesagt: Der Moment, in dem Sie überhaupt etwas entscheiden, ist der Moment, in dem Sie eine Dauererlaubnis erteilen. Nach „immer erlauben“ ist der Dialog kein Kontrollpunkt mehr. Erteilen Sie sie pro Werkzeug statt pro Server — stündlich suchen ist in Ordnung, stündlich teilen nicht.
Die brauchbare Achse ist nicht Lesen gegen Schreiben. Sie ist, was ein Fehler kostet.
| Aktion | Rückgängig | Warum |
|---|---|---|
| Ein Tag setzen oder entfernen | Ja, in der App | Metadaten neben der Aufnahme |
| Eine Aufnahme oder einen Sprecher umbenennen | Ja, in der App | Ein Etikett, nicht der Inhalt |
| Transkription neu starten | Nein | Ersetzt den Text samt manueller Korrekturen |
| In einem Team-Kanal veröffentlichen | Nein | Kolleginnen und Kollegen haben es vielleicht schon gelesen |
| Ein Transkript per E-Mail teilen | Nein | Empfänger behalten, was sie bekommen haben |
Alles in den unteren drei Zeilen verdient jedes einzelne Mal eine ausdrückliche Bestätigung; alles in den oberen zwei wahrscheinlich nicht. Die Werkzeugliste ist der Ort, an dem ein Anbieter angibt, welche davon er anbietet, und sie ist es wert, gelesen zu werden, bevor Sie irgendetwas verbinden.
Bestätigungsabfragen nutzen sich ab. Eine einzige Rechercheaufgabe kann Dutzende davon erzeugen, auch für Werkzeuge, die gar nichts ändern können, und das dokumentierte Ergebnis ist, dass Menschen die Abfragen pauschal abschalten, statt die nächste zu lesen. Ein Kontrollpunkt, der Sie darauf trainiert, ihn wegzuklicken, ist keiner.
Ein Protokoll nutzt sich nicht ab, weil man es im Nachhinein liest und nur dann, wenn man eine Frage hat. Die Empfehlungen der Spezifikation an Clients umfassen das Protokollieren der Werkzeugnutzung zu Prüfzwecken, und dieselbe Überlegung gilt für den Server: Wenn ein Assistent etwas ändern kann, sollten Sie hinterher sehen können, was er geändert hat, wann und an welchem Datensatz.
Der brauchbare Test für jede MCP-Integration mit Schreibzugriff: Wenn das Modell gestern Nacht etwas getan hat, das ich nicht erwartet habe, wo würde ich das heute nachlesen? Lautet die Antwort „nirgends“, dann hat der Bestätigungsdialog das gesamte Sicherheitsmodell allein getragen.
Es gibt zwei Wege, einen Assistenten am Ändern zu hindern, und sie sind nicht austauschbar.
Pro Client, in dessen eigener Konfiguration. Ein im Nur-Lese-Modus
gestarteter Server veröffentlicht nur seine Lesewerkzeuge. Der Unterschied zum
Ablehnen von Aufrufen ist nicht kosmetisch: Ein Werkzeug, das das Modell nicht
sieht, ist ein Werkzeug, das es nicht vorschlägt, sodass Sie nie „ich
veröffentliche das jetzt im Team-Kanal“ gefolgt von einem Fehler bekommen. In
Speak-Y ist das die Option --read-only in den args des Servers, und sie lässt
sechs Lesewerkzeuge stehen.
Global, in der App. Ein Schalter, der alle verbundenen Clients auf einmal abdeckt, ganz gleich, welcher gefragt hat.
Der Unterschied zählt, weil eine Option in der Konfigurationsdatei von Cursor Cursor zügelt und sonst nichts. Die Option pro Client sagt „Cursor darf nur lesen, Claude Code darf alles“; nur der Schalter in der App ist eine Aussage über alle zusammen.
Speak-Y trennt die beiden Hälften bewusst, und die Trennung ist von außen sichtbar.
Lesen ist lokal und braucht nichts Laufendes. Suche, Transkripte, Zusammenfassungen, Action Items und Tags kommen aus der Bibliothek auf Ihrem Mac, von einem eigenen Prozess nur lesend geöffnet; die App muss nicht laufen. Zum Lesen wird nichts hochgeladen — wobei, wie bei jedem MCP-Server, alles Gelesene als Teil des Gesprächs an Ihren Modellanbieter geht, was eine andere Frage ist als die, wo die Daten liegen.
Änderungen laufen über die laufende App. Taggen, Umbenennen, Neu-Transkribieren und das Veröffentlichen in einem Team-Kanal führt derselbe Code aus, der hinter den Schaltflächen der Oberfläche sitzt, nicht eine zweite Implementierung mit eigener Vorstellung von den Regeln. Läuft die App nicht, sagen diese Werkzeuge das, statt halb zu funktionieren.
Jede Aktion wird deklariert und protokolliert. Die ändernden Werkzeuge werden
mit readOnlyHint: false veröffentlicht; erneute Transkription und
Kanalveröffentlichung tragen zusätzlich destructiveHint, und die
Veröffentlichung trägt openWorldHint, weil sie die eine Aktion ist, die den
Rechner verlässt. Die letzten 50 Aktionen stehen unter
Einstellungen → Integrationen mit Zeit, Operation, Datensatz und Ergebnis —
und ohne Transkripttext, der sonst die Aufnahme überleben würde, aus der er
stammt. Der Schalter für Assistenz-Aktionen liegt auf demselben Bildschirm, und
der Server ist in jedem Tarif kostenlos.
Geprüft am 13. August 2026, jeweils in der Dokumentation des Anbieters:
Die Liste von Fireflies ist die interessante, denn „teile dieses Transkript mit diesen E-Mail-Adressen“ ist genau die Klasse von Aktion, bei der die Bestätigung des Clients das Einzige ist, was zwischen einer falsch verstandenen Anweisung und einem Empfänger steht. Das ist keine Kritik an der Funktion — sie in der Werkzeugliste zu nennen ist die ehrliche Art, sie auszuliefern. Es ist ein Argument dafür, diese Liste zu lesen, bevor man einem ganzen Server eine Dauererlaubnis erteilt.
Nichts davon verlangt, den Absichten eines Anbieters zu vertrauen, und genau darum geht es. „Ist es sicher, einen Assistenten meine Daten ändern zu lassen?“ hat keine allgemeine Antwort, zerfällt aber in Fragen, die eine haben: was sich ändert, wer bestätigt, was umkehrbar ist und wo es aufgeschrieben steht.
Wenn Sie noch keinen Assistenten verbunden haben, ist der praktische Einstieg Besprechungsnotizen über MCP verbinden, wo die Einrichtung und die ersten Prompts durchgegangen werden, bevor irgendetwas davon relevant wird.
In einem engen Sinn ja: Ein Werkzeug, das nichts ändern kann, kann auch nicht das Falsche ändern. Aber Nur-Lesen ist ein grobes Instrument, kein Sicherheitsmodell. Was tatsächlich schützt, ist zu wissen, welche Änderungen umkehrbar sind, einen Client zu haben, der vor den unumkehrbaren nachfragt, und hinterher nachlesen zu können, was getan wurde. Ein Nur-Lese-Server liefert die erste Eigenschaft, indem er die Funktion aufgibt.
Das ist eine Eigenschaft Ihres Clients, nicht des Servers. Die MCP-Spezifikation sagt, es sollte immer ein Mensch in der Schleife sein, der einen Werkzeugaufruf ablehnen kann, und Clients wie Claude Code fragen bei MCP-Werkzeugen standardmäßig nach. Server können ein Werkzeug per Annotation als ändernd oder destruktiv deklarieren, doch die Spezifikation verlangt von Clients, solche Annotationen als nicht vertrauenswürdig zu behandeln, solange der Server es nicht ist: Sie informieren die Rückfrage, erzwingen sie aber nicht.
Der Bestätigungsdialog ist für dieses Werkzeug kein Kontrollpunkt mehr, und jeder weitere Aufruf läuft ohne Rückfrage. Für ein Suchwerkzeug ist das ein vernünftiger Handel, für ein Werkzeug, das Daten mit anderen Menschen teilt, ein schlechter. Erteilen Sie die Dauererlaubnis pro Werkzeug statt pro Server, und behandeln Sie das Aktionsprotokoll als das, was beantwortet, was wirklich geschehen ist.
Ja, wenn der Server einen Nur-Lese-Modus unterstützt, der in der Konfiguration des jeweiligen Clients gesetzt wird. Speak-Y tut das: --read-only in den args der MCP-Konfiguration eines Clients veröffentlicht diesem Client nur die Lesewerkzeuge, sodass Cursor aufs Lesen beschränkt bleibt, während Claude Code vollen Zugriff behält. Ein Schalter in der App gilt dagegen für alle Clients zugleich.
Zwei Klassen. Eine erneute Transkription ersetzt den aktuellen Text einer Aufnahme samt aller von Hand vorgenommenen Korrekturen. Das Veröffentlichen einer Aufnahme in einem Team-Kanal macht sie für Kolleginnen und Kollegen sichtbar, und ein späteres Entfernen macht das Gelesene nicht ungelesen. Tags, Titel und Sprechernamen sind Etiketten und lassen sich in der App zurückändern.