MCP: guida sicura al Model Context Protocol

Il Model Context Protocol, abbreviato MCP, è uno standard aperto che permette alle applicazioni AI di scoprire e utilizzare dati, prompt e strumenti messi a disposizione da server compatibili. Evita di costruire un connettore proprietario differente per ogni combinazione tra assistente, database e applicazione.

Il vantaggio è evidente: lo stesso server MCP può rendere disponibili una procedura, la ricerca di un ticket o la preparazione di una bozza a più client compatibili. Ma lo standard non trasforma automaticamente una connessione in un’integrazione sicura. MCP definisce il collegamento; identità, permessi e approvazioni restano responsabilità dell’architettura.

Questa guida spiega il protocollo senza presupporre conoscenze specialistiche e mostra come valutarlo in una PMI, distinguendo connessione locale e remota, lettura e scrittura, credenziali e autorità dell’utente.

Che cos’è MCP

MCP è un protocollo di scambio basato su messaggi strutturati. Standardizza come un’applicazione AI individua le capacità disponibili, legge una risorsa o richiede l’uso di uno strumento. Il modello non deve conoscere i dettagli di ogni API aziendale: vede descrizioni e schemi pubblicati dal server MCP attraverso il client.

Una metafora utile è quella di un connettore universale. Il connettore stabilisce forma e comunicazione, ma non decide chi possa accedere al dispositivo, quali dati possa leggere o quali operazioni possa compiere. Per questo compatibilità e autorizzazione sono problemi distinti.

La specifica dell’architettura MCP attribuisce all’host il coordinamento, il consenso e l’applicazione delle policy. I server devono invece offrire capacità focalizzate e non dovrebbero ricevere l’intera conversazione o vedere gli altri server collegati.

Host, client e server

L’architettura comprende tre ruoli.

Host

È l’applicazione che contiene l’esperienza AI: un assistente desktop, un editor di codice o una soluzione aziendale. Decide quali server configurare, quali capacità presentare e quale contesto inviare. Deve mostrare all’utente le richieste sensibili e applicare i limiti stabiliti.

Client MCP

L’host crea normalmente un client separato per ogni server. Il client gestisce la comunicazione, la versione del protocollo e le capacità supportate. La relazione uno-a-uno aiuta a mantenere separati i confini tra server differenti.

Server MCP

Il server collega il protocollo a una sorgente o a un’applicazione: file, database, CRM, ticketing, repository o API. Può essere un processo locale avviato dall’host oppure un servizio remoto raggiunto tramite rete.

Un server non dovrebbe diventare un accesso universale all’azienda. È preferibile creare componenti delimitati, per esempio ticket-read, customer-read e ticket-draft, invece di un unico server con credenziali amministrative.

Tool, risorse e prompt

La documentazione ufficiale sull’architettura distingue tre primitive principali.

Primitiva	A cosa serve	Esempio aziendale	Rischio tipico
Tool	Richiedere una funzione	cercare un ticket o preparare una bozza	effetto indesiderato o permessi eccessivi
Resource	Leggere un contenuto identificabile	procedura, record o schema del database	esposizione di dati non autorizzati
Prompt	Offrire un modello di interazione riutilizzabile	traccia per analizzare una richiesta	istruzioni obsolete o manipolate

Il client può elencare ciò che il server espone e decidere cosa rendere disponibile. La scoperta dinamica è utile, ma una nuova capacità non dovrebbe diventare automaticamente operativa in produzione: va sottoposta alla stessa revisione di una modifica applicativa.

Lettura e azione non sono equivalenti

Una resource che restituisce una procedura è generalmente meno rischiosa di un tool che modifica un ordine. Conviene classificare ogni capacità in quattro livelli:

lettura di dati non sensibili;
lettura di dati riservati;
preparazione di una bozza senza effetto esterno;
azione che modifica, invia, acquista o cancella.

I livelli superiori richiedono identità più forte, autorizzazione esplicita, log e spesso approvazione umana.

MCP, tool calling, RAG e API

Questi concetti vengono spesso confusi.

Concetto	Problema che risolve
API	Espone dati o operazioni di un sistema
Tool calling	Permette al modello di proporre una funzione con argomenti strutturati
MCP	Standardizza scoperta e scambio tra host AI e server di capacità
RAG	Recupera contenuti pertinenti per costruire il contesto
Agente	Decide e concatena più passaggi entro i limiti concessi

MCP può utilizzare API già esistenti: il server fa da adattatore e pubblica strumenti più comprensibili per il client AI. Il tool calling rimane il meccanismo con cui il modello propone una chiamata. Il RAG riguarda invece recupero, citazioni e aggiornamento dei documenti.

Non serve MCP per ogni integrazione. Se un’applicazione utilizza una sola API stabile e un solo modello, una funzione diretta può essere più semplice. MCP diventa interessante quando gli stessi connettori devono essere riutilizzati, i client sono più di uno o le capacità devono essere scoperte in modo standardizzato.

Connessione locale e remota

La specifica corrente prevede due trasporti principali.

Stdio per processi locali

Con stdio l’host avvia il server come processo e comunica attraverso input e output standard. Non esiste una porta di rete da pubblicare. È adatto a strumenti locali e riduce la superficie esposta, ma non crea una sandbox: il processo possiede i permessi dell’utente o del servizio che lo esegue.

Installare un server MCP locale equivale quindi a installare software. Se può leggere l’intera cartella personale o accedere alle variabili d’ambiente, il modello potrebbe indirettamente richiedere proprio quelle operazioni. La policy di sicurezza ufficiale invita a valutare provenienza, configurazione e privilegi dei server locali come si farebbe con qualsiasi pacchetto. Lo stesso principio vale quando si progetta un ambiente di AI locale per professionisti e PMI.

Streamable HTTP per servizi remoti

Con Streamable HTTP il server è un servizio indipendente raggiunto tramite un endpoint HTTP. È adatto a scenari multiutente e centralizzati, ma introduce TLS, autenticazione, gestione dei token, firewall, rate limit e osservabilità.

La specifica Streamable HTTP corrente è cambiata rispetto alle revisioni precedenti. Client e server devono dichiarare la versione supportata e gestire consapevolmente la compatibilità: copiare configurazioni datate senza verificare la versione può produrre errori difficili da diagnosticare.

Un esempio pratico per una PMI

Immaginiamo un assistente interno per il service desk. Deve consultare procedure e stato dei ticket, poi preparare una bozza di aggiornamento. Non deve chiudere ticket né inviare comunicazioni senza conferma.

Il server potrebbe esporre:

procedure://rete/vpn come resource di sola lettura;
tickets_get_status(ticket_id) come tool di consultazione;
tickets_prepare_update(ticket_id, text) come preparazione;
nessun tool tickets_close nella prima fase.

Il flusso corretto è questo:

l’utente si autentica nell’host;
l’host collega un’identità aziendale al client MCP;
il server filtra dati e ticket in base all’utente;
il modello propone la consultazione necessaria;
il backend valida identificativo e autorizzazione;
il server restituisce soltanto i campi utili;
l’assistente prepara la bozza;
una persona conferma l’eventuale aggiornamento.

Il modello non riceve password, token del gestionale o accesso SQL generico. Il server utilizza credenziali custodite in un gestore di segreti e applica nuovamente i permessi a ogni chiamata.

Un server minimale in Python

L’SDK ufficiale può generare schemi a partire da tipi e funzioni. Questo esempio dimostrativo espone soltanto una consultazione su dati fittizi:

from mcp.server import MCPServer

mcp = MCPServer("ticket-demo")

@mcp.tool()
def ticket_get_status(ticket_id: str) -> str:
    """Legge lo stato di un ticket dimostrativo autorizzato."""
    tickets = {"INC-100": "in lavorazione"}
    return tickets.get(ticket_id, "non trovato")

Il codice è intenzionalmente semplice. In produzione, prima della lettura servono identità, controllo di appartenenza, timeout, log e gestione degli errori. La guida ufficiale alla costruzione di un server include esempi per Python, TypeScript e altri linguaggi; la documentazione Python v2 mostra anche MCP Inspector per provare strumenti e risorse.

Autenticazione, autorizzazione e segreti

Sono tre livelli differenti.

Autenticazione: verifica chi sta effettuando la richiesta.
Autorizzazione: decide se quell’identità può usare quella capacità su quello specifico oggetto.
Segreto: credenziale tecnica usata per raggiungere un sistema a valle.

Il token non deve diventare un lasciapassare universale. La specifica di autorizzazione MCP usa meccanismi basati su OAuth per i trasporti HTTP e raccomanda scope progressivi e privilegi minimi. Per i server stdio le credenziali vengono normalmente fornite dall’ambiente, che deve essere protetto.

Vietato il token passthrough

Un server MCP non dovrebbe accettare un token destinato a un altro servizio e inoltrarlo senza controllo. Le considerazioni ufficiali di sicurezza richiedono che i token siano legati al destinatario previsto e vietano il passaggio diretto verso API a valle. Il server deve ottenere una credenziale separata e appropriata per il servizio chiamato.

Per un servizio remoto applica almeno HTTPS, validazione dell’audience, token brevi, rotazione, PKCE dove previsto e scope aderenti alla singola operazione.

I rischi da controllare

Server non attendibile

Un server locale può leggere file, avviare processi o usare la rete in base ai privilegi concessi. Un server remoto può registrare dati o presentare capacità diverse nel tempo. Usa sorgenti verificate, versioni bloccate, firma o hash dei pacchetti e un inventario approvato. Se il server include modelli o componenti scaricabili, applica anche la checklist su licenze e provenienza dei modelli open weights.

Prompt injection indiretta

Una resource, un’e-mail o una pagina recuperata può contenere istruzioni ostili. I contenuti esterni sono dati, non autorizzazioni. L’host deve mantenere separate policy e contenuto, ridurre gli strumenti disponibili e chiedere conferma per gli effetti rilevanti.

Tool poisoning e descrizioni ingannevoli

Il modello sceglie spesso gli strumenti in base a nome, descrizione e schema. Una descrizione alterata può tentare di deviare l’uso del tool o richiedere dati non necessari. Registra e confronta le definizioni esposte, non soltanto il codice del server.

Confused deputy

Un server che possiede privilegi più ampi dell’utente può essere indotto ad agire come delegato confuso. Ogni richiesta deve portare identità, oggetto e autorizzazione verificabili; un accesso tecnico al CRM non autorizza automaticamente tutti gli utenti a vedere tutti i clienti.

SSRF e accesso alla rete interna

URL e metadata recuperati dinamicamente possono essere sfruttati per raggiungere indirizzi interni. Le best practice MCP raccomandano validazione degli URL, restrizioni sugli IP, controllo dei redirect ed eventualmente un proxy di uscita.

Come progettare un server MCP sicuro

Un dominio ristretto: ticket, documenti o inventario, non “tutto il gestionale”.
Lettura e scrittura separate: credenziali e approvazioni diverse.
Tool specifici: evita shell, SQL o richieste HTTP generiche.
Schemi restrittivi: campi obbligatori, enum, lunghezze e formati.
Autorizzazione per oggetto: non limitarti al ruolo generale.
Risultati minimizzati: restituisci solo i dati necessari.
Segreti esterni: vault o secret manager, mai prompt e file di configurazione condivisi.
Timeout e rate limit: contengono errori, loop e abuso.
Approccio prepare/execute: una bozza prima dell’azione.
Versione e proprietario: ogni server deve avere responsabile, release e rollback.

Per agenti capaci di concatenare più strumenti, applica anche la checklist di sicurezza degli agenti AI. Il numero massimo di passi, il budget e il kill switch appartengono all’host e all’orchestrazione, non al protocollo. Per l’adozione aziendale, questi controlli devono confluire nella più ampia governance prevista dall’AI Act.

Test, audit e gestione operativa

Prima della produzione usa MCP Inspector o un client di test e verifica casi normali e ostili.

Test	Risultato atteso
Identificativo appartenente a un altro utente	accesso negato senza perdita di dati
Campo mancante o troppo lungo	errore di validazione controllato
Tool non approvato	capacità non presentata o chiamata bloccata
Resource con istruzioni malevole	contenuto trattato come non affidabile
Token destinato a un altro servizio	rifiuto per audience errata
Doppia richiesta di scrittura	nessun effetto duplicato
Servizio a valle non disponibile	timeout limitato e passaggio umano
Nuova versione del server	test di regressione prima dell’attivazione

Un audit utile deve ricostruire: utente, host, client, server e versione; tool o resource; parametri essenziali; decisione di autorizzazione; approvatore; esito e durata. Non registrare segreti o interi documenti se non sono necessari.

Per workflow prevedibili, n8n con AI può orchestrare approvazioni e gestione degli errori. MCP può fornire il connettore, ma il workflow deve restare responsabile di sequenza, retry e condizioni di arresto.

Errori da evitare

installare server MCP casuali come se fossero semplici prompt;
usare l’identità personale o amministrativa dell’utente;
esporre un endpoint remoto senza TLS e autenticazione;
presentare al modello tutti i tool disponibili nell’azienda;
considerare stdio equivalente a una sandbox;
inoltrare token destinati a servizi differenti;
autorizzare per ruolo senza verificare lo specifico record;
eseguire cancellazioni, invii o pagamenti senza anteprima;
aggiornare automaticamente server e dipendenze in produzione;
conservare log pieni di prompt, documenti e segreti.

Checklist di adozione per una PMI

Il caso d’uso richiede davvero connettori riutilizzabili?
Host, client, server e proprietari sono identificati?
Ogni tool è classificato per lettura, bozza o azione?
Il server usa un’identità dedicata e privilegi minimi?
I dati restituiti sono filtrati per utente e oggetto?
Segreti e token sono fuori dal contesto del modello?
Il trasporto scelto è coerente con il perimetro?
Sono presenti TLS, OAuth e scope quando il server è remoto?
Tool e risorse sono versionati e sottoposti ad approvazione?
Azioni sensibili richiedono conferma e idempotenza?
Log e metriche permettono la ricostruzione degli eventi?
Esistono disattivazione rapida, rollback e referente umano?

FAQ

MCP rende sicura un’integrazione AI?

No. Standardizza la comunicazione, ma sicurezza e governance dipendono da host, server, sistema di identità, rete e applicazioni collegate.

Serve MCP per usare il tool calling?

No. Una funzione può essere dichiarata direttamente tramite l’API del modello. MCP è utile per scoprire e riutilizzare capacità tra client compatibili.

Un server locale è automaticamente privato?

No. Può avere accesso a file, variabili d’ambiente e rete secondo i privilegi del processo. Deve essere valutato e isolato come qualsiasi software installato.

Meglio stdio o Streamable HTTP?

stdio è adatto a un processo locale avviato dall’host. Streamable HTTP è adatto a servizi remoti o condivisi, ma richiede una progettazione completa di autenticazione, TLS, autorizzazione e osservabilità.

Posso creare un server MCP con Python o Node.js?

Sì. Esistono SDK ufficiali per entrambi. Parti da un tool di sola lettura, usa schemi restrittivi e prova il server con dati dimostrativi prima di collegare sistemi reali.

MCP sostituisce le API aziendali?

Normalmente no. Il server MCP spesso utilizza le API esistenti e le presenta all’applicazione AI attraverso un contratto standardizzato e più focalizzato.

Conclusioni

MCP può ridurre il costo delle integrazioni e rendere riutilizzabili strumenti e dati tra applicazioni AI differenti. Il valore cresce quando il server ha una responsabilità chiara e il protocollo rimane separato dall’autorità.

Per una PMI il percorso prudente parte da un server locale o interno, un solo dominio e funzioni di sola lettura. Identità dedicate, privilegi minimi, test e audit vengono prima delle capacità di scrittura. Il connettore abilita la comunicazione; soltanto le policy possono concedere il permesso.

Fonti ufficiali

Vuoi ricevere altre guide pratiche su AI locale, integrazioni e governance? Iscriviti gratuitamente alla newsletter di Basi di AI.