Un paio di giorni di fa ho scritto un post riguardo la mia visione del Model Context Protocol (MCP), il nuovo standard aperto per integrare modelli linguistici (LLM) con tool e sorgenti dati esterne. In un paio di giorni, forse colpa anche dell’algoritmo di Linkedin, MCP è rapidamente diventato il tema de facto del mio stream in modo permanente. Da articoli per collegare chatbot e agenti AI con servizi di terze parti fino ad articoli con visioni più estreme della mia, soprattutto in temi di sicurezza ed opportunità come il bel post di approfondimento dal titolo Everything Wrong with MCP di Shrivu Shankar che ho intercettato grazie ad una interazione di Paola Bonomo.

Insieme all’entusiasmo – ovvio – per il tema è evidente che, come per tutto, stanno emergendo ora analisi che evidenziano vulnerabilità, limiti strutturali e problemi di user experience, che in parte avevo citato anche nel mio primo post di approfondimento.

In questo post , viste le discussioni che ho letto e sulle quali mi sto confrontando in diversi ambiti, provo ad andare un po’ oltre precedente: andrò più a fondo sulle potenzialità di MCP in termini di standardizzazione e interoperabilità, ma anche le criticità legate a sicurezza, prompt injection, esperienza utente e i limiti nell’uso di LLM con molti strumenti attivi. Ho aggiunto alla fine uno spunto sul trade-off tra facilità d’uso e controllo, proponendo principi per un uso più sicuro e responsabile di MCP sia per sviluppatori che per utenti finali.

MCP come standard di integrazione

Il Model Context Protocol nasce come ho già scritto con l’obiettivo di standardizzare il modo in cui le applicazioni forniscono contesto e funzionalità ai modelli AI. La documentazione ufficiale lo paragona a una porta USB-C per le applicazioni AI: così come USB-C offre un modo unificato per collegare dispositivi diversi, MCP definisce un modo uniforme per connettere agenti AI a servizi e strumenti eterogenei. In pratica, MCP permette a sviluppatori terzi di creare “plugin” o MCP server contenenti strumenti (funzioni) e risorse che un assistente AI può invocare in chat.

Questa standardizzazione comporta enormi vantaggi di interoperabilità. I fornitori di assistenti (es. piattaforme come Claude, ChatGPT, Cursor, ecc.) possono concentrarsi sul migliorare l’interfaccia utente e le capacità conversazionali, sapendo che esiste un linguaggio comune per estendere le funzionalità. Dall’altro lato, gli sviluppatori di terze parti possono costruire servizi integrativi in modo assistant-agnostic, plug-and-play su qualsiasi piattaforma compatibile con MCP.

Esempio: immaginiamo di poter dire al nostro assistente AI: “Trova il mio paper di ricerca su Google Drive, controlla se mancano citazioni usando un motore di ricerca accademico, poi imposta la luce del soggiorno sul verde quando hai finito.” In uno scenario tradizionale, integrare manualmente questi servizi (cloud storage, ricerca web, IoT) richiederebbe molto codice ad-hoc. Con MCP, basta collegare tre server MCP di terze parti (uno per Google Drive, uno per il motore di ricerca, uno per la lampadina smart): l’assistente orchestrerà da solo le operazioni tra i vari strumenti in maniera sequenziale. Questo abilita funzionalità complesse e workflow end-to-end autonomi prima impensabili: l’LLM non solo elabora testo, ma può agire – cercare informazioni, richiamare dati privati, eseguire comandi – il tutto tramite un canale standardizzato.

Le potenzialità di MCP , senza dubbio, risiedono nella flessibilità (Bring-Your-Own-Tools: ognuno può aggiungere gli strumenti che preferisce), nella scalabilità dell’ecosistema (una volta creato un tool MCP, può essere riusato ovunque) e in un accesso al contesto più ricco per gli LLM (possono attingere a dati e servizi esterni in tempo reale invece di essere limitati al prompt statico). Questa promessa di un “AI app store universale” ha giustamente attirato attenzione e adozione rapida.

Ma, come in tuti in grandi cambiamenti, anche questo introduce anche nuove sfide da non sottovalutare.

Rischi di sicurezza e trust: cosa può andare storto?

Aprire le porte dell’LLM a strumenti esterni comporta inevitabilmente dei rischi di sicurezza. Diversi ricercatori hanno già dimostrato che l’attuale design di MCP può esporre gli utenti a una varietà di exploit. In particolare, è stato mostrato come persino modelli linguistici di punta possano essere indotti con opportuni prompt malevoli a utilizzare i tool MCP in modi imprevisti, compromettendo il sistema dell’utente ( qui un esempio interessante e ben descritto MCP Safety Audit: LLMs with the Model Context Protocol Allow Major Security Exploits).

Tra i possibili attacchi documentati troviamo:

• Esecuzione di codice malevolo (Malicious Code Execution): il modello potrebbe essere persuaso a eseguire codice arbitrario sul sistema locale tramite un tool di file system o terminale, ad esempio inserendo backdoor o comandi distruttivi nei file dell’utente. Un esperimento ha mostrato che un LLM (Claude) connesso a un server MCP di filesystem a volte riesce addirittura a scrivere nel file di configurazione dell’utente un comando per ottenere un accesso remoto ogni volta che si apre il terminale (nell’esempio condiviso sopra c’è proprio questo) . In altri casi fortunatamente il modello ha riconosciuto il tentativo e rifiutato l’azione, ma basta una formulazione leggermente diversa perché esegua istruzioni pericolose senza allertare adeguatamente l’utente. Questo evidenzia quanto siano fragili le attuali difese basate solo sulle policy interne del modello.
• Accesso remoto non autorizzato (Remote Access Control): simile al caso sopra, un attaccante potrebbe ottenere il pieno controllo remoto della macchina vittima inducendo l’LLM a eseguire comandi di networking (es. avviare un server, modificare firewall, rubare chiavi API, ecc.). In uno scenario multi-utente (es. uffici condivisi), un aggressore potrebbe direttamente interagire con l’assistente di qualcun altro e sfruttare MCP per piantare accessi persistenti.
• Furto di credenziali o dati sensibili: se il modello ha accesso a file di configurazione o variabili d’ambiente tramite MCP, un prompt malevolo può istruirlo a leggere e inviare all’esterno informazioni riservate (token, password, documenti privati). Ad esempio, un tool apparentemente innocuo potrebbe richiedere di “passare il contenuto di /etc/passwd per una verifica di sicurezza”, inducendo l’LLM a consegnare informazioni di sistema riservate a un servizio esterno.

Un elemento preoccupante è che questi attacchi possono avvenire senza che l’utente se ne accorga immediatamente. MCP parte dal presupposto che i tool di terze parti siano affidabili e li integra profondamente nel flusso dell’assistente. Di fatto, i tool MCP vengono spesso inseriti nel prompt di sistema (le istruzioni di controllo interne all’LLM) anziché come input utente, conferendo loro un livello di fiducia più alto. Ciò significa che un tool compromesso o costruito con intenti malevoli può facilmente aggirare le protezioni e influenzare il comportamento dell’assistente, anche più di quanto potrebbe un normale input utente malizioso (prompt injection classico). Si parla infatti di prompt injection di terze o quarte parti: un server MCP può deliberatamente fornire output formattati in modo da manipolare l’LLM o altri server a cascata. Un esempio ancore potrebbe esser un server che potrebbe riuscire a cambiare dinamicamente nome e descrizione di un tool dopo che l’utente ha già autorizzato il suo utilizzo (rug pull attack), sfruttando il fatto che l’LLM continuerà a usarlo credendo sia affidabile.

Inoltre, con MCP un aggressore potrebbe concatenare servizi per aumentare l’efficacia dell’attacco. Immaginiamo un database aziendale esposto via MCP: un malintenzionato potrebbe inserire nel campo di testo di un record una stringa contenente un comando o una falsa eccezione che suggerisce una determinata azione (ad es. “Errore: mancano alcune righe, eseguire UPDATE ... per correggere”). Se l’assistente AI di un developer andrà a leggere quel record tramite il tool MCP, potrebbe eseguire il comando suggerito credendo sia parte del flusso logico, causando potenzialmente un Remote Code Execution o modifiche indesiderate al database. Tutto ciò pur non disponendo di un tool esplicito di esecuzione codice, ma sfruttando la capacità dell’LLM di interpretare e seguire istruzioni testuali provenienti dai dati esterni.

Un altro rischio è la fuga involontaria di dati (data leakage). Anche senza attori malevoli, l’autonomia conferita agli agenti può portare l’assistente a divulgare informazioni sensibili a servizi di terze parti. Ad esempio, un utente potrebbe collegare il proprio Google Drive e un servizio di web publishing via MCP per farsi aiutare a redigere un post sul blog. Se l’LLM, nel tentativo di essere utile, decide di leggere referti medici privati dal Drive per arricchire il post, potrebbe inviarne estratti a un servizio esterno (es. un correttore grammaticale online) senza un’esplicita intenzione dell’utente. In mancanza di controlli granulari, l’AI può mescolare dati pubblici e privati violando le aspettative di privacy dell’utente.

In parole povere l’ MCP amplia la superficie d’attacco dei sistemi basati su LLM. Ogni tool aggiunto è un potenziale vettore di exploit se non viene validato e autorizzato con attenzione. Purtroppo, allo stato attuale MCP non prevede meccanismi standard di sandbox o gestione permessi: se l’utente abilita un tool che cancella file, il modello potrebbe teoricamente usarlo senza ulteriore conferma. Questo impone molta fiducia sia nell’LLM (che dovrebbe capire da solo quando non eseguire istruzioni pericolose) sia nei fornitori terzi dei tool. Come osservato da molti, combinare LLM con dati e azioni reali è “intrinsecamente rischioso e amplifica rischi esistenti o ne crea di nuovi”.

Esperienza utente: assenza di conferme e costi nascosti

Oltre ai rischi di exploit deliberati, MCP presenta criticità sul piano UX (user experience) e di controllo da parte dell’utente. L’idea di fondo di MCP è fornire un’esperienza fluida, dove l’assistente AI può chiamare strumenti esterni in autonomia per aiutare l’utente a raggiungere un obiettivo.

Ma così tanta autonomia, non è forse troppa autonomia?

Attualmente, il protocollo lascia molte decisioni critiche all’assistente, senza livelli di avvertimento o conferma differenziati.

Una prima criticità è che MCP non definisce livelli di rischio per gli strumenti che il modello può utilizzare. Tutti i tool, dal più innocuo al più potente, vengono esposti all’LLM sullo stesso piano. Immaginiamo una chat assistita da vari plugin: leggi_diario_personale(), prenota_volo(), elimina_file(). Alcune azioni sono banali o facilmente reversibili, altre costose o irreversibili e pericolose, ma il modello potrebbe non avere piena consapevolezza di questa differenza. Spetta all’applicazione che implementa MCP chiedere conferma all’utente, ma non esiste uno standard obbligatorio: un particolare client potrebbe limitarsi a elencare i tool disponibili e lasciare che l’utente abiliti tutto in blocco.

È facile inoltre che l’utente sviluppi col tempo la pessima abitudine di confermare automaticamente (modality YOLO scherza qualcuno) tutte le azioni proposte, se la maggior parte delle volte sono innocue routine. Così, il giorno in cui l’LLM decide di usare elimina_file("foto_vacanze") o di “aiutare” prenotando e pagando un volo senza dettagli corretti, il danno è fatto in un click distratto. La mancanza di indicatori di rischio o di gravità per i tool è dunque un problema: l’utente non riceve un segnale chiaro quando l’agente sta per fare qualcosa di potenzialmente pericoloso o costoso.

Un secondo problema di UX legato a MCP è l’assenza di conferme visive e preview per azioni sensibili. Poiché il protocollo per design fa transitare i risultati dei tool come semplice testo non strutturato (o blob binari per immagini/audio), l’interfaccia dell’assistente spesso mostra solo la risposta finale dell’LLM e pochi dettagli sull’azione compiuta. Questo va bene per notifiche o dati testuali, ma diventa inadeguato in casi come: prenotare un taxi o un volo, pubblicare un post sui social, inviare un’email importante. L’utente avrebbe bisogno di verificare dettagli cruciali – ad esempio confermare che l’AI ha scelto l’indirizzo giusto per il taxi, o vedere un’anteprima formattata di un post prima di renderlo pubblico. Con l’attuale MCP queste garanzie “visuali” non sono integrate: il modello potrebbe dirci di aver fatto X, ma non c’è un meccanismo standard per fornirci un link di conferma, una finestra di dialogo, o un risultato parziale strutturato. Tutto dipende dall’implementazione del singolo tool e dall’interfaccia dell’applicazione host. Questo può portare a errori difficili da intercettare prima che sia troppo tardi, specie se l’agente opera autonomamente in background.

Un terzo aspetto spesso trascurato è quello dei costi nascosti. A differenza di protocolli tradizionali dove i dati scambiati sono relativamente piccoli e a costo trascurabile, nell’universo LLM il “contesto” ha un costo computazionale ed economico significativo. MCP, ampliando il contesto con risultati di tool, può generare risposte voluminose. Un output di qualche centinaio di kilobyte può costare diversi centesimi di dollaro in termini di utilizzo del modello, e 1 MB di testo generato può arrivare a costare circa 1 dollaro per richiesta. Quel testo potrebbe venire incluso in ogni successivo prompt durante la conversazione, sommando più addebiti. Ciò significa che se un tool MCP restituisce un risultato molto lungo (es. il contenuto di un lungo documento, o una lista di dati estesa), l’utente potrebbe bruciare il proprio budget rapidamente senza accorgersene, finché non arriva la fattura o finché il servizio non inizia a rallentare. Sono già emerse lamentele da parte di utenti e sviluppatori di agenti AI riguardo a costi imprevedibili dovuti a integrazioni MCP token-inefficienti. Attualmente, sta al singolo sviluppatore di tool limitare prudentemente la quantità di dati restituiti (magari tagliando risultati o implementando paginazione), ma il protocollo in sé non impone limiti di lunghezza. Un miglioramento proposto è di fissare un massimale sul risultato o quantomeno rendere visibile e configurabile la quantità di contesto aggiunto da ogni tool, così da responsabilizzare chi sviluppa MCP server a essere efficiente.

Dal punto di vista UX MCP eccelle in comodità, ma pecca in controlli e trasparenza verso l’utente. Non fornisce per default né una graduatoria di pericolosità dei tool, né un sistema strutturato di conferme per azioni critiche, né indicatori chiari dell’impatto in termini di costi/risorse. Questo lascia spazio a errori umani (conferme affrettate, fiducia eccessiva nell’agente) e a situazioni in cui l’utente perde il controllo fine di ciò che sta accadendo. Le implementazioni dovranno colmare queste lacune con soluzioni personalizzate, ma idealmente lo standard stesso potrebbe evolvere per includere best practice di sicurezza ed esperienza utente più robuste.

Limiti strutturali: LLM con troppi tool, interpretazione ed efficienza

Un altro tema emerso nelle analisi recenti è che MCP, pur estendendo le capacità degli LLM, non elimina i limiti intrinseci dei modelli – anzi, in certi casi li amplifica. Collegare “più strumenti possibile” potrebbe sembrare una buona idea per massimizzare la versatilità di un assistente AI, ma all’atto pratico ci sono dei trade-off di performance e affidabilità.

Innanzitutto, gli LLM attuali mostrano un calo di affidabilità man mano che cresce il contesto e la complessità delle istruzioni da seguire. Ogni tool MCP aggiunto porta con sé descrizioni, parametri e possibili azioni che l’AI deve tenere a mente. Se da un lato più strumenti significano più opportunità, dall’altro rappresentano più carico cognitivo per il modello. In effetti, è stato osservato che aumentando il numero di tool e di dati connessi, le prestazioni dell’assistente possono degradare sensibilmente, mentre il costo per ogni singola richiesta aumenta (più informazioni da elaborare in input/output). In scenari reali, potrebbe diventare necessario far scegliere all’utente quali integrazioni attivare di volta in volta, invece di tenerle tutte sempre attive, per evitare di appesantire inutilmente ogni risposta.

Va considerato poi che utilizzare correttamente degli strumenti tramite linguaggio naturale è di per sé un compito non banale per gli LLM. Pochi dataset di addestramento contenevano esempi di agenti che chiamano API o funzioni esterne, quindi la capacità di tool use spesso non è innata ma deriva da fine-tuning o prompt engineering. Benchmark specializzati mostrano che anche modelli avanzati hanno un basso successo percentuale nel portare a termine correttamente task multi-step con strumenti. Ad esempio, su un set di compiti come prenotare un volo seguendo policy specifiche, uno dei migliori modelli disponibili nel 2025 riusciva a completare autonomamente solo circa il 16% delle operazioni previste. Ciò implica che all’aumentare della complessità delle azioni richieste (soprattutto se coinvolgono più strumenti in sequenza), l’agente potrebbe fallire o doversi arrendere, restituendo risultati parziali o errati.

Un ulteriore limite è la comprensione contestuale dell’AI rispetto a ciò che i tool offrono. MCP presuppone che gli strumenti siano progettati per essere generici e assistant-agnostic, ma nella realtà ogni assistente o utente potrebbe avere esigenze diverse. Ad esempio, un server MCP per Google Drive potrebbe fornire funzioni come list_file(nome), read_file(file_id), delete_file(file_id). Un utente inesperto potrebbe pensare che collegando questo server al suo ChatGPT, potrà semplicemente chiedere: “Trova il file FAQ che ho scritto ieri per il cliente X”. In assenza di un vero motore di ricerca indicizzato nei contenuti, l’LLM proverà magari a chiamare list_file con vari nomi, fallendo se il file non ha “FAQ” nel titolo.

L’utente rimane deluso perché si aspettava un comportamento più “intelligente”, mentre avrebbe bisogno che il tool stesso implementi una ricerca full-text o query semantiche — funzionalità non previste senza un’architettura aggiuntiva. Analogamente, richieste come “Quante volte appare la parola ‘AI’ nei documenti che ho scritto?” mettono in crisi l’assistente: potrebbe dover aprire decine di file (read_file) e contare, finendo il contesto disponibile dopo alcuni risultati e dando magari un numero incompleto. Operazioni di aggregazione o di join di dati attraverso più fonti (es. “incrocia l’ultimo report vendite con i profili LinkedIn dei candidati”) sono ancora più proibitive: il modello non ha una memoria persistente su cui fare calcoli o confronti complessi oltre i limiti del prompt. Questi esempi illustrano come collegare un dato strumento non garantisce automaticamente che l’AI sappia svolgere qualsiasi compito correlato – se il compito richiede logica o capacità oltre quelle offerte esplicitamente dai tool, l’LLM tenterà soluzioni sub-ottimali o dichiarerà di non poterlo fare.

C’è poi una questione di compatibilità variabile tra modelli e formati di strumenti. MCP definisce l’interfaccia, ma piccoli dettagli (come la descrizione testuale dei tool, gli schemi di risposta attesi, l’uso di markdown o XML nei prompt) possono influire sul rendimento a seconda del modello usato. Ad esempio, si è notato che Claude (Anthropic) interpreta meglio descrizioni di tool strutturate in un certo modo, mentre GPT-4 preferisce altri formati. Quindi un set di tool potrebbe funzionare benissimo con un assistente e meno con un altro, confondendo l’utente che tende a dare la colpa all’applicazione (“Quest’app non è capace di fare X”) quando in realtà è una combinazione di design del tool e idiosincrasie del modello AI.

Riassumendo, MCP ha un grandissimo potenziale ma non è una bacchetta magica e come sempre “per i grandi poteri ricevuti, ci vuole una grande responsabilità” : rimane vincolato ai limiti attuali degli LLM in termini di capacità di ragionamento, contesto e azione. Aggiungere più fonti dati e più funzioni può dare l’illusione di un “super assistente” onnisciente, ma in pratica rischia di peggiorare l’efficacia (assistente più lento, più costoso e talvolta confuso) se non progettato con criterio. Serve equilibrio nel numero di integrazioni attive contemporaneamente e consapevolezza che l’AI potrebbe non sfruttarle appieno come farebbe un umano senza un lavoro ulteriore di ottimizzazione. Questi limiti strutturali suggeriscono che, accanto all’entusiasmo, è necessaria prudenza e responsabilità: ogni nuova integrazione va testata e compresa a fondo per evitare di sovraccaricare o disorientare il modello.

Trade-off tra facilità d’uso e controllo/verificabilità

Un tema trasversale a quanto discusso sopra è il delicato bilanciamento tra comodità e controllo. MCP nasce per rendere facile ed immediato estendere le capacità di un modello – in altre parole, massimizzare la facilità d’uso sia per chi sviluppa (standard unico, integrazioni plug-in) sia per l’utente finale (chiedi in linguaggio naturale e l’AI fa tutto). Tuttavia, questa facilità intrinseca porta con sé una perdita di visibilità e governabilità sulle azioni dell’agente AI.

Da un lato dello spettro abbiamo la “completa autonomia”: l’utente collega molti tool e permette all’agente di agire senza dover confermare ogni passo. L’esperienza è fluida e quasi “magica” – pochi input in linguaggio naturale producono output complessi e multi-step. Ma come abbiamo visto, ciò può portare a comportamenti indesiderati o rischiosi non verificati, e rende difficile ricostruire a posteriori cosa sia andato storto ( scarsa verificabilità). Se qualcosa va storto – ad esempio dati sensibili inviati ad un servizio esterno, o un file cancellato – l’utente o l’amministratore si trovano a dover interpretare i log della conversazione e delle chiamate API per capire quale prompt o quale tool abbia causato l’evento. Non c’è una traccia strutturata facilmente consultabile di tutte le azioni autorizzate, a meno che l’applicazione host non la implementi manualmente.

Dall’altro lato c’è la “massimo controllo/manualità”: l’utente mantiene il potere decisionale su ogni chiamata di tool (conferme frequenti, step intermedi mostrati, scelta esplicita di quali integrazioni usare per ciascun task). Questo approccio minimizza i rischi, ma sacrifica molta della comodità. L’agente diventa meno autonomo e più un sistema di suggerimento, dove l’utente deve comunque fare da supervisore costante. Inoltre, troppe interruzioni e richieste di conferma possono peggiorare l’esperienza d’uso, frustrando l’utente o inducendolo ad aggirare le protezioni pur di non essere disturbato di continuo.

Verificabilità e controllo più granulari spesso significano aggiungere complessità all’ecosistema MCP. Ad esempio, si potrebbe voler un registro dettagliato di tutte le operazioni compiute tramite MCP (chi le ha scatenate, con quali parametri, risultati, timestamp) per poter effettuare audit di sicurezza. Realizzare ciò richiede estensioni al framework o log robusti lato client/server, e magari strumenti di analisi dedicati. Allo stesso modo, introdurre livelli di permission per i tool (lettura/scrittura, accesso limitato a certe risorse, ecc.) rende il sistema più sicuro ma anche più macchinoso da configurare rispetto alla semplice plug-and-play attuale.

È evidente che c’è un trade-off: facilità d’uso vs. complessità di controllo. MCP nella sua forma base ha scelto di ottimizzare la prima a scapito della seconda. Sta ora alla comunità e ai progettisti decidere come riequilibrare la bilancia. Nel prossimo e ultimo punto, discuteremo alcune possibili soluzioni e linee guida per mitigare i rischi senza rinunciare ai benefici di MCP.

Blockchain, una soluzione strutturale?

Per affrontare strutturalmente (ma che non risolverebbero a mio avviso tutti i problemi) i rischi di sicurezza e i limiti di verificabilità evidenziati finora, una soluzione potenziale potrebbe arrivare dalla blockchain e dall’uso di un sistema di identità decentralizzata (DID). La blockchain offre naturalmente risposte alle criticità che MCP manifesta:

• Autenticazione robusta e decentralizzata: ogni utente e tool MCP potrebbe disporre di un’identità registrata su blockchain tramite DID (Decentralized Identifier), che garantisce l’origine e l’integrità delle richieste senza affidarsi a un’unica autorità centralizzata.

• Audit e tracciabilità immutabile: le operazioni effettuate tramite MCP verrebbero registrate su blockchain creando un log immodificabile, utile per audit, debugging e risoluzione di controversie.

• Autorizzazioni granulari tramite smart contract: le regole sui permessi e sulle operazioni consentite ai tool MCP potrebbero essere gestite da smart contract trasparenti e verificabili, eliminando il rischio di esecuzioni incontrollate o dannose.

Come potrebbe funzionare un sistema MCP basato su blockchain?

Un’implementazione pratica potrebbe basarsi su:

• Identità decentralizzata (DID): gli utenti e gli sviluppatori registrano le loro identità utilizzando un sistema decentralizzato (es. Ethereum Name Service, Solana DID), firmando digitalmente ogni richiesta MCP con una chiave privata.

• Smart contract di autorizzazione: i permessi per ciascun tool MCP vengono definiti esplicitamente in smart contract che limitano automaticamente le azioni eseguibili. Le azioni ad alto rischio potrebbero richiedere una firma esplicita aggiuntiva dell’utente.

• Registrazione delle operazioni: ogni chiamata agli strumenti MCP genererebbe eventi registrati permanentemente, facilitando controlli retroattivi e audit automatici.

Perché tale soluzione sia sostenibile nel tempo e facilmente adottabile, è fondamentale definire ulteriori requisiti:

• Standardizzazione: scegliere blockchain ad alta interoperabilità (ad esempio Ethereum, Solana, o altre chain compatibili) e definire chiaramente gli standard DID utilizzabili.

• Privacy e riservatezza: adottare tecniche avanzate (zero-knowledge proofs) per garantire la riservatezza di dati sensibili, evitando di renderli pubblicamente visibili sulla blockchain.

• Usabilità e gestione chiavi: semplificare il recupero degli account smarriti e implementare meccanismi di backup sicuri per la gestione delle chiavi private, evitando complessità eccessiva per gli utenti non tecnici.

• Governance decentralizzata: prevedere modalità per aggiornamenti dello standard MCP e dei relativi smart contract tramite governance decentralizzata (es. DAO), per garantire evoluzione e sicurezza nel tempo.

L’integrazione della blockchain in MCP rappresenterebbe a mio avviso un ulteriore passo importante verso quella convergenza di cui parlo da un po’ e vero la creazione di uno standard realmente maturo, sicuro e scalabile. La capacità di autenticare richieste, autorizzare operazioni e tracciare eventi in modo decentralizzato potrebbe trasformare MCP da semplice protocollo di integrazione a piattaforma completa e (più) sicura per l’automazione avanzata con LLM.

Verso un uso responsabile e sicuro di MCP: proposte e principi

Nonostante le criticità evidenziate, il Model Context Protocol rimane dal mio punto di vista un’innovazione importante e utile, oltre che un cambio radicale di modelli ed ecosistemi inteeri. La chiave sta nell’adottarlo in modo responsabile, implementando misure di sicurezza e di design che ne mitigano i difetti. Di seguito provo a buttare giu  alcune proposte e principi – rivolti sia a sviluppatori di tool/applicazioni, sia a utenti avanzati – per migliorare la progettazione della sicurezza e l’affidabilità di MCP senza perdere i vantaggi della standardizzazione:

• Classificazione del rischio dei tool e conferme contestuali: Gli strumenti MCP andrebbero categorizzati per livello di rischio (basso, medio, alto) in base alle azioni che compiono. Ad esempio, leggere dati pubblici può essere low risk, modificare dati sensibili high risk. L’interfaccia utente dovrebbe poi modulare le conferme di conseguenza: niente conferma per azioni sicure di routine, conferma obbligatoria (con chiaro avviso) per operazioni distruttive o finanziariamente impegnative. In mancanza di uno standard ufficiale, alcune implementazioni iniziano a muoversi in questa direzione introducendo livelli di esecuzione: ad esempio, eseguire direttamente le azioni a basso rischio, ma richiedere un permesso esplicito per quelle medie e addirittura isolare in sandbox (es. in un container Docker) quelle ad alto rischio ().
• Sandboxing e scope limitato: Per i tool più potenti (come quelli che eseguono codice o modificano file), è consigliabile limitarne il campo d’azione. Ciò può avvenire tramite sandboxing (esecuzione in un ambiente chiuso che impedisca danni al sistema host) o definendo scope ristretti – ad esempio un tool delete_file() potrebbe essere vincolato a operare solo in una directory predefinita, impedendo cancellazioni arbitrarie in tutto il file system. Idealmente, MCP potrebbe supportare in futuro una sorta di policy di autorizzazione dichiarativa, in cui l’utente concede a un tool solo certi permessi (lettura sola, accesso solo a un certo dataset, ecc.). Nel frattempo, sta ai singoli server MCP implementare tali controlli internamente.
• Verifica e fiducia nei server MCP di terze parti: Prima di collegare un qualsiasi MCP server esterno al proprio assistente, occorre valutarne l’affidabilità. Preferire tool open source il cui codice è ispezionabile, oppure servizi di provider noti con solide politiche di sicurezza. Evitare di usare plugin da fonti sconosciute o poco trasparenti, specialmente se richiedono accesso a dati sensibili. Gli sviluppatori della piattaforma potrebbero creare un registry pubblico di server MCP verificati o con recensioni, facilitando agli utenti la scelta di integrazioni sicure.
• Trasparenza delle azioni dell’agente: L’applicazione host (es. l’interfaccia chat) dovrebbe fornire strumenti per monitorare e loggare le azioni che l’LLM compie tramite MCP. Ciò può includere un pannello di attività in tempo reale (“L’assistente sta chiamando lo strumento X con questi parametri…”), e log dettagliati consultabili successivamente. Questo aiuta sia a tranquillizzare l’utente durante operazioni lunghe o complesse (sapendo cosa sta succedendo dietro le quinte), sia a effettuare audit in caso di comportamenti sospetti o malfunzionamenti. Alcune implementazioni visualizzano già il “chain of thought” o i passi compiuti dall’agente: estenderlo con dettagli specifici dei tool MCP usati sarebbe un’ottima pratica.
• Limitare l’autonomia in contesti critici: Per task particolarmente delicati – ad esempio operazioni finanziarie, modifiche di sistema, invio di mail a larga diffusione – è saggio mantenere l’umano nel loop. Ciò significa progettare l’agent affinché si fermi prima di un punto di non ritorno e chieda conferma finale all’utente, magari mostrando un riepilogo di cosa intende fare. Questo principio si riallaccia ai livelli di rischio: nessun modello AI dovrebbe effettuare transazioni bancarie o cancellazioni massicce senza un “OK” umano, anche se in generale gli si concede autonomia su altre cose.
• Educazione dell’utente e best practice d’uso: L’utente finale va reso consapevole che uno strumento come MCP non è infallibile e richiede uso accorto. I provider di assistenti dovrebbero educare tramite documentazione e tutorial sui rischi possibili (es. evidenziando il pericolo di prompt injection attraverso esempi) e sulle funzionalità di sicurezza messe a disposizione. Un utente informato sarà più propenso a configurare correttamente i permessi, a scegliere con giudizio quali integrazioni attivare e a riconoscere eventuali segnali di comportamento anomalo dell’agente.

L’MCP rappresenta un passo significativo verso ecosistemi AI modulari e integrati, analoghi a un sistema operativo per agenti intelligenti. Le sue promesse di standardizzazione e versatilità sono reali, ma altrettanto vere sono le sfide emerse e che emergeranno in termini di sicurezza e UX. La buona notizia è che, come tutti i grandi progetti di cambiamento, vedono una partecipazione di diverse comunità che stanno già affrontando questi temi e approfondendo tecnicamente molti aspetti: dall’analisi delle vulnerabilità (esempio riportato in questo articolo MCP Safety Audit: LLMs with the Model Context Protocol Allow Major Security Exploits) alla creazione di sistemi di validazione di sicurezza automatici per server MCP, fino al dibattito su come migliorare il protocollo stesso (Everything Wrong with MCP – by Shrivu Shankar).

È probabile che vedremo evolvere sia lo standard MCP (con estensioni per gestione permessi, formati di risposta più strutturati, ecc.), sia le implementazioni lato applicazione (assistenti che guideranno meglio l’utente, magari con interfacce più ricche e controlli). Fino ad allora, il principio guida dev’essere la cautela consapevole: adottare MCP con entusiasmo, ma progettare sempre con una ”mentalità di sicurezza” e usare l’autonomia dell’AI entro limiti che possiamo gestire.

Come spesso accade nella tecnologia, la chiave è trovare il giusto equilibrio tra innovazione e controllo: sfruttare l’automazione offerta da MCP senza mai rinunciare del tutto alla supervisione umana e a misure preventive. In questo modo potremo godere dei benefici dell’AI aumentata dai tool, minimizzando al contempo i rischi per sistemi e persone.