In questa lezione affronteremo uno degli aspetti più critici del Model Context Protocol (MCP), ovvero la sicurezza. Dopo aver compreso l’architettura (host, client, server) e il meccanismo di comunicazione basato su JSON-RPC, è fondamentale capire come garantire che l'interazione tra modelli linguistici, strumenti e dati avvenga in modo sicuro, controllato e conforme alle policy.
Perché la sicurezza è centrale in MCP
Quando utilizziamo MCP dobbiamo partire da una consapevolezza di base: ogni integrazione MCP espone una superficie di attacco più ampia rispetto a un sistema chiuso. Il modello non è più isolato, ma diventa un intermediario tra l’utente e una rete di servizi.
Questo significa che ogni richiesta può avere conseguenze concrete. Un comando apparentemente innocuo può tradursi in operatività, cioè in un’azione concreta: inviare un’email, aggiornare un database, accedere a delle informazioni sensibili.
In questo contesto, la sicurezza non riguarda solo la protezione dei dati ma anche il controllo delle azioni. Per questo motivo, dobbiamo progettare sistemi che non si fidino implicitamente né dell’input dell’utente né dell’output del modello. Ogni passaggio deve essere verificabile, limitato e tracciabile.
Per tale ragione dobbiamo affrontare tre problemi fondamentali:
- Autorizzazione – chi può fare cosa?
- Consenso – quando è necessario coinvolgere l’utente umano?
- Governance – come controlliamo e monitoriamo il sistema nel tempo?
MCP e principio del minimo privilegio
Uno dei principi più importanti che dobiamo adottare quando lavoriamo con MCP è quello del minimo privilegio. Questo significa che ogni componente del sistema deve avere accesso solo alle risorse strettamente necessarie per svolgere il proprio compito. Nel contesto MCP, si traduce in una progettazione attenta dei tool. Non esponiamo funzionalità generiche o troppo potenti, ma preferiamo strumenti specifici, con responsabilità ben delimitate.
Questo approccio riduce il rischio che un errore o un comportamento inatteso del modello, possa avere degli effetti amplificati. Pensiamo, ad esempio, alla differenza tra il consentire un accesso diretto a un database e offrire un tool che restituisce solo alcune informazioni filtrate. Nel primo caso, stiamo delegando troppo controllo, nel secondo, stiamo guidando l’interazione entro confini sicuri.
Adottare il minimo privilegio significa anche accettare una maggiore complessità progettuale iniziale, in cambio di una drastica riduzione dei rischi nel lungo periodo.
Autenticazione e autorizzazione
Per costruire un sistema sicuro dobbiamo distinguere chiaramente tra identità e permessi. Sapere chi sta effettuando una richiesta non è sufficiente: dobbiamo anche stabilire cosa è autorizzato a fare. L’autenticazione ci permette di verificare l’identità del client che interagisce con il server MCP. Questo avviene tipicamente attraverso meccanismi consolidati come token, chiavi API o protocolli standard come OAuth. Senza autenticazione, qualsiasi sistema MCP sarebbe esposto a accessi non controllati.
Una volta stabilita l’identità, entra in gioco l’autorizzazione. Qui definiamo le regole che determinano quali strumenti possono essere utilizzati e in quali condizioni. Non tutti gli utenti, né tutti i contesti, devono avere lo stesso livello di accesso. In un sistema ben progettato, queste regole non sono rigide ma adattive: possono dipendere dal ruolo dell’utente, dal tipo di richiesta o persino dal contesto operativo. Questo consente di costruire sistemi flessibili ma allo stesso tempo controllati.
Il consenso esplicito dell’utente
Uno degli aspetti più interessanti (e al tempo stesso delicati) di MCP è la gestione del consenso. Non tutte le azioni dovrebbero essere automatizzate. In molti casi, è necessario coinvolgere l’utente umano nel processo decisionale. Dobbiamo quindi progettare flussi in cui il modello propone, ma non esegue automaticamente. L’utente mantiene il controllo sulle operazioni più sensibili, come l’invio di comunicazioni o la modifica di dati.
Questo introduce il concetto di “human-in-the-loop”, in cui il sistema diventa collaborativo. Il modello suggerisce un’azione, il client la presenta in modo comprensibile, e l’utente decide se procedere. In questo modo non solo si aumenta la sicurezza, ma viene migliorata anche la fiducia nel sistema.
Esistono poi scenari in cui il controllo umano è meno diretto, ma comunque presente. In questi casi, le azioni possono essere eseguite automaticamente, ma devono essere registrate e verificabili. La scelta del livello di automazione dipende sempre dal rischio associato all’azione.
Governance del sistema e validazione e sanitizzazione degli input
Un errore comune consiste nel considerare affidabile l’output di un modello. In realtà, dobbiamo trattarlo come qualsiasi altro input esterno: potenzialmente errato o malevolo.
Quando il modello genera una richiesta verso un tool, quella richiesta deve essere validata. Non possiamo assumere che i parametri siano corretti o sicuri. È necessario applicare controlli rigorosi su tipi, formati e valori.
La sanitizzazione gioca un ruolo altrettanto importante. Dobbiamo prevenire attacchi che sfruttano input manipolati, come injection o formati non previsti. Anche se il modello non è malevolo, può essere indotto a generare contenuti problematici. Per questo motivo, ogni tool deve definire chiaramente cosa accetta e cosa rifiuta. Questa chiarezza diventa una linea di difesa fondamentale.
Sulla base di quanto detto fino ad ora, nella prossima lezione analizzeremo un esempio pratico di MCP Server sicuro.
Se vuoi aggiornamenti su Sicurezza, consenso e governance in MCP inserisci la tua email nel box qui sotto: