Il Model Context Protocol rende più uniforme il collegamento tra applicazioni AI, dati e strumenti. Questa comodità non decide però quali operazioni siano sicure: un server MCP esegue i tool con i permessi realmente disponibili nel proprio ambiente. Se gli assegniamo una credenziale amministrativa, un filesystem esteso e una rete senza limiti, attraverso i tool esposti l’assistente acquisisce una superficie d’azione molto più ampia del compito che dovrebbe svolgere.
MCP concede capacità, non una semplice connessione
In un’architettura MCP, l’host coordina uno o più client che dialogano con server capaci di esporre risorse, prompt e tool. I tool possono interrogare un archivio, leggere file, creare un ticket, inviare un messaggio o modificare un record. Collegare un server significa quindi decidere quali azioni entrano nel perimetro operativo dell’assistente.
La specifica raccomanda di mantenere una persona nel processo, permetterle di negare le invocazioni e mostrarle chiaramente le operazioni sensibili. L’interfaccia di approvazione è importante, ma arriva dopo una scelta più fondamentale: il server e la sua identità tecnica non dovrebbero possedere capacità che non servono allo scopo dichiarato.
Quando una configurazione diventa inutilmente pericolosa
Una configurazione fragile usa l’account personale o amministrativo di un operatore, scope completi, tool generici come esecuzione SQL o shell, lettura e scrittura nello stesso server e approvazioni disattivate. Se il processo locale gira con tutti i privilegi dell’utente e può raggiungere liberamente rete e filesystem, ogni errore o istruzione ostile dispone di un raggio d’azione sproporzionato.
Il problema non è soltanto un’azione esplicitamente malevola. Il modello può selezionare il tool sbagliato, interpretare male un obiettivo, ripetere una richiesta non idempotente o comporre due capacità che, prese singolarmente, sembravano innocue. Senza limiti applicati fuori dal modello, una frase nel prompt come “non modificare mai i dati” resta una preferenza, non un controllo di sicurezza.
Least privilege: concedere solo ciò che serve
La configurazione dovrebbe partire da un’identità dedicata al server o delegata all’utente, mai da un account personale o amministrativo condiviso, con credenziali revocabili, token a breve durata, scope minimi e una allowlist dei soli tool necessari. L’accesso può essere limitato a specifici tenant, viste, tabelle, directory o insiemi di documenti. Se il caso d’uso richiede analisi, il punto di partenza ragionevole è una credenziale di sola lettura su dati minimizzati.
Lettura e scrittura vanno separate anche quando appartengono allo stesso processo. Il reader può consultare una vista, una replica o uno snapshot controllato; il writer espone azioni di dominio ristrette, con schema preciso e validazione deterministica, invece di comandi generici. I privilegi si elevano soltanto quando l’operazione lo richiede e l’utente approva target e parametri effettivi.
Read-only protegge l’integrità, non risolve ogni rischio
Una credenziale realmente read-only riduce il rischio di modificare o cancellare la fonte dati, ma può ancora leggere informazioni eccessive. Può inoltre generare query costose o trasferire risultati verso un altro strumento. Minimizzazione dei campi, filtri per riga, limiti sul numero di record, timeout, rate limit e controllo della rete in uscita proteggono riservatezza e disponibilità oltre all’integrità.
Anche le annotazioni MCP come readOnlyHint, destructiveHint, idempotentHint e openWorldHint sono descrizioni utili, non una sandbox. Un server non fidato può dichiararle in modo scorretto e un client può non applicare alcuna policy. La garanzia di sola lettura deve esistere nella credenziale, negli scope OAuth, nei permessi dell’API o del database, nel filesystem e nel runtime.
Anche il dato letto può contenere istruzioni ostili
Documenti, email, pagine web e risultati restituiti dai tool sono dati non attendibili. Un contenuto può tentare di convincere il modello a ignorare l’obiettivo, recuperare informazioni riservate o chiamare un altro strumento. È prompt injection indiretta: non scompare perché il server che ha letto il documento era autorizzato.
Quando possibile conviene estrarre campi strutturati invece di passare contenuti grezzi, separare fonti interne e contenuti aperti e impedire tecnicamente le combinazioni più pericolose. Autorizzazione, validazione degli input, minimizzazione e trattamento degli output come dati non attendibili e decisione sulle azioni consentite devono vivere nel codice e nelle policy, non nell’interpretazione del modello.
Approvazioni e audit devono descrivere l’azione reale
Una conferma generica concessa all’inizio della sessione non equivale all’approvazione di ogni effetto successivo. Per scritture, invii esterni, esportazioni sensibili e operazioni irreversibili, la persona dovrebbe vedere il tool, la destinazione e i parametri che verranno utilizzati. Chi approva deve poter interrompere l’azione senza perdere il contesto necessario a decidere.
I log utili registrano attore, build o versione del server e, dove disponibile, versione o hash della definizione del tool, timestamp, correlation ID, decisione, risultato ed errore. Token, cookie, segreti e dati personali non necessari non devono finire nei log; gli identificativi necessari all’audit vanno minimizzati e protetti con accessi e tempi di conservazione adeguati. L’audit sostiene indagine e miglioramento, ma non sostituisce i limiti preventivi: sapere chi ha cancellato un record è meno efficace che impedire al reader di poterlo cancellare.
Un pattern concreto: separare raccolta e consultazione
Per una dashboard di analisi, un percorso prudente è usare API ufficiali con credenziali read-only, raccogliere i dati fuori dal processo web, validarli e minimizzarli, quindi installare uno snapshot canonico che l’interfaccia può soltanto leggere. Se un domani un assistente MCP dovesse analizzare quelle metriche, potrebbe consultare lo snapshot invece delle fonti originali.
Le future azioni su CRM, ticket o campagne andrebbero esposte su un piano distinto, con credenziali separate, tool specifici, approvazione e tracciabilità. Questa separazione riduce il rischio e rende più comprensibile il sistema: prima si osserva, poi si propone, infine una persona autorizza l’eventuale modifica.