Per circa un anno la risposta onesta a «è sicuro collegare un assistente IA ai miei appunti?» era che il collegamento si limitava a leggerli. Valeva per la maggior parte dei server MCP per le note delle riunioni, e rendeva facile la questione della sicurezza: uno strumento che non può cambiare nulla non può cambiare la cosa sbagliata.
La domanda interessante non è più lì. Oggi gli assistenti mettono tag alle registrazioni, rinominano chi parla, rifanno la trascrizione e pubblicano note in canali condivisi — e la versione utile della domanda è più stretta: che cosa deve essere vero prima di lasciare che un modello modifichi i propri dati? Quattro cose, e nessuna è «il fornitore promette di stare attento»: il client chiede prima della chiamata, la modifica è abbastanza circoscritta da stare in una frase, ciò che è irreversibile è marcato come tale, e c'è un registro che si può leggere dopo.
Questo articolo riguarda dove passa quella linea. Se il protocollo in sé è una novità, che cos'è un server MCP copre prima le basi.
«Accesso in scrittura» è una sola espressione per tre cose molto diverse, ed è il metterle insieme che rende l'argomento più spaventoso di quanto sia.
Etichettare. Tag, titoli, nomi di chi parla. Aggiungono o sostituiscono metadati accanto a una registrazione. Se l'assistente mette il tag alla riunione sbagliata, si apre l'applicazione e lo si toglie. Il caso peggiore è riordinare dopo un modello troppo entusiasta.
Sostituire il contenuto. Rifare la trascrizione di una registrazione produce un testo nuovo e butta via quello vecchio — comprese le correzioni fatte a mano. Nulla ha lasciato la macchina, ma qualcosa di proprio non c'è più. È qui che «reversibile» smette in silenzio di essere vero.
Uscire dalla macchina. Pubblicare una registrazione in un canale del team, inviare una trascrizione per email, dare accesso a qualcuno. Qui la modifica non riguarda in primo luogo i dati — riguarda chi li ha visti. Annullare è un'operazione tecnica su un fatto sociale, e non funziona.
Un modello di sicurezza che tratti queste tre come un unico interruttore sbaglierà in entrambe le direzioni: troppo rumoroso per la prima, troppo permissivo per la terza.
MCP ha un vocabolario per questo. La definizione di uno strumento può portare
annotazioni: readOnlyHint (lo strumento si limita a leggere),
destructiveHint (può sovrascrivere invece di aggiungere), idempotentHint
(chiamarlo due volte non cambia altro) e openWorldHint (raggiunge sistemi
esterni). Un server che pubblica uno strumento di condivisione senza
openWorldHint si sta descrivendo male.
Due frasi della specifica decidono quanto valga quel vocabolario. La prima, sul dovere del client: «Per fiducia, sicurezza e protezione, DOVREBBE esserci sempre una persona nel circuito, con la possibilità di negare l'invocazione degli strumenti». La seconda, sulle annotazioni stesse: i client «DEVONO considerare le annotazioni degli strumenti non attendibili, a meno che non provengano da server attendibili».
Lette insieme, sistemano l'architettura. Le annotazioni sono il modo in cui un server dichiara il rischio; non sono una serratura che il server possa chiudere. Il cancello sta nel client, e la richiesta di conferma che compare prima dell'esecuzione di uno strumento è una decisione del client, informata dalla dichiarazione del server. Claude Code, per esempio, imposta gli strumenti MCP in modo che chiedano, mentre i suoi strumenti interni non chiedono.
La conseguenza pratica è scomoda e vale la pena dirla chiaramente: il momento in cui si decide qualcosa è il momento in cui si concede un permesso permanente. Dopo «consenti sempre», la finestra non è più un controllo. Il permesso si concede per singolo strumento e non per server — cercare ogni ora va bene, condividere ogni ora no.
L'asse utile non è lettura contro scrittura. È quanto costa un errore.
| Azione | Si annulla | Perché |
|---|---|---|
| Aggiungere o togliere un tag | Sì, nell'applicazione | Metadato accanto alla registrazione |
| Rinominare una registrazione o chi parla | Sì, nell'applicazione | Un'etichetta, non il contenuto |
| Rifare la trascrizione | No | Sostituisce il testo, correzioni manuali comprese |
| Pubblicare in un canale del team | No | I colleghi potrebbero averla già letta |
| Inviare una trascrizione per email | No | Chi l'ha ricevuta se la tiene |
Tutto ciò che sta nelle ultime tre righe merita una conferma esplicita ogni volta; ciò che sta nelle prime due probabilmente no. L'elenco degli strumenti è il punto in cui un fornitore dichiara quali di queste azioni offre, e vale la pena leggerlo prima di collegare qualsiasi cosa.
Le richieste di conferma si logorano. Un singolo compito di ricerca può produrne decine, anche per strumenti che non modificano nulla, e il risultato documentato è che le persone disattivano gli avvisi in blocco invece di leggere il successivo. Un controllo che abitua a chiuderlo non è un controllo.
Un registro non si logora, perché si legge a posteriori e solo quando c'è una domanda. Le stesse indicazioni della specifica ai client includono la registrazione dell'uso degli strumenti a fini di verifica, e lo stesso ragionamento vale per il server: se un assistente può modificare qualcosa, si deve poter vedere dopo che cosa ha modificato, quando e su quale registrazione.
La prova utile per qualunque integrazione MCP con accesso in scrittura: se stanotte il modello ha fatto qualcosa di inatteso, dove lo si leggerebbe domani? Se la risposta è «da nessuna parte», la finestra di conferma reggeva da sola l'intero modello di sicurezza.
Ci sono due modi per impedire a un assistente di modificare le cose, e non sono intercambiabili.
Per client, nella configurazione di quel client. Un server avviato in
modalità di sola lettura pubblica soltanto i suoi strumenti di lettura. La
differenza rispetto al rifiutare le chiamate non è cosmetica: uno strumento che
il modello non vede è uno strumento che non proporrà, quindi non capita mai di
sentirsi dire «pubblico subito nel canale del team» seguito da un errore. In
Speak-Y è il parametro --read-only negli args del server, e lascia in piedi
sei strumenti di lettura.
A livello globale, nell'applicazione. Un interruttore che copre tutti i client collegati insieme, indipendentemente da quale abbia chiesto.
La distinzione conta perché un parametro nel file di configurazione di Cursor trattiene Cursor e nient'altro. Il parametro per client dice «Cursor può solo leggere, Claude Code può fare tutto»; solo l'interruttore nell'applicazione è un'affermazione su tutti quanti.
Speak-Y separa le due metà di proposito, e la separazione si vede da fuori.
La lettura è locale e non richiede nulla in esecuzione. Ricerca, trascrizioni, riassunti, punti d'azione e tag arrivano dalla libreria sul proprio Mac, aperta in sola lettura da un processo separato; l'applicazione non deve essere in esecuzione. Nulla viene caricato perché l'assistente possa leggerlo — anche se, come per qualsiasi server MCP, tutto ciò che legge viene inviato al fornitore del modello come parte della conversazione, che è una questione a parte rispetto a dove i dati sono conservati.
Le modifiche passano dall'app in esecuzione. Mettere tag, rinominare, ritrascrivere e pubblicare in un canale del team sono eseguiti dallo stesso codice che sta dietro i pulsanti dell'interfaccia, non da una seconda implementazione con una propria idea delle regole. Se l'applicazione non è in esecuzione, quegli strumenti lo dicono invece di funzionare a metà.
Ogni azione è dichiarata e registrata. Gli strumenti che modificano sono
pubblicati con readOnlyHint: false; la ritrascrizione e la pubblicazione in un
canale portano in più destructiveHint, e la pubblicazione porta
openWorldHint, perché è l'unica azione che esce dalla macchina. Le ultime 50
azioni sono elencate in Impostazioni → Integrazioni con ora, operazione,
registrazione ed esito — e senza il testo della trascrizione, che altrimenti
sopravvivrebbe alla registrazione da cui proviene. L'interruttore per le azioni
dell'assistente è nella stessa schermata, e il server è gratuito in tutti i
piani.
Verificato il 13 agosto 2026 sulla documentazione di ciascun fornitore:
L'elenco di Fireflies è quello interessante, perché «condividi questa trascrizione con questi indirizzi email» è esattamente la classe di azione in cui la conferma del client è l'unica cosa tra un'istruzione letta male e un destinatario. Non è una critica alla funzione — dichiararla nell'elenco degli strumenti è il modo onesto di rilasciarla. È un argomento per leggere quell'elenco prima di concedere un permesso permanente a un intero server.
Nulla di tutto questo richiede di fidarsi delle intenzioni di un fornitore, ed è questo il punto. «È sicuro lasciare che un assistente modifichi i miei dati?» non ha una risposta generale, ma si scompone in domande che ce l'hanno: che cosa cambia, chi conferma, che cosa si può annullare e dove viene messo per iscritto.
Se non si è ancora collegato un assistente, il punto di partenza pratico è collegare le note delle riunioni via MCP, che percorre la configurazione e i primi prompt prima che tutto questo diventi rilevante.
Lo è in un senso ristretto: uno strumento che non può cambiare nulla non può cambiare la cosa sbagliata. Ma la sola lettura è uno strumento grezzo, non un modello di sicurezza. A proteggere davvero è sapere quali modifiche sono reversibili, avere un client che chiede prima di quelle irreversibili e poter leggere dopo che cosa è stato fatto. Un server in sola lettura offre la prima proprietà rinunciando alla funzione.
È una proprietà del client, non del server. La specifica MCP dice che dovrebbe sempre esserci una persona nel circuito, con la possibilità di negare l'invocazione di uno strumento, e client come Claude Code impostano gli strumenti MCP in modo che chiedano. I server possono dichiarare uno strumento come modificante o distruttivo tramite annotazioni, ma la specifica impone ai client di considerarle non attendibili se il server non è attendibile: informano la richiesta di conferma, non la impongono.
La finestra di conferma smette di essere un controllo per quello strumento, e ogni chiamata successiva parte senza chiedere. È uno scambio ragionevole per uno strumento di ricerca e pessimo per uno strumento che condivide dati con altre persone. Il permesso permanente si concede per singolo strumento e non per server, e il registro delle azioni resta la cosa che dice davvero che cosa è successo.
Sì, se il server prevede una modalità di sola lettura impostata nella configurazione del client. Speak-Y la prevede: aggiungendo --read-only agli args nella configurazione MCP di un client, a quel client vengono pubblicati soltanto gli strumenti di lettura, così Cursor resta limitato alla lettura mentre Claude Code mantiene l'accesso completo. Un interruttore dentro l'applicazione vale invece per tutti i client insieme.
Due classi. Rifare la trascrizione sostituisce il testo attuale di una registrazione, comprese le correzioni fatte a mano. Pubblicare una registrazione in un canale del team la rende visibile ai colleghi, e toglierla dopo non la fa dimenticare. Tag, titoli e nomi di chi parla sono etichette e nell'applicazione si possono riportare com'erano.