★ DISPONIBILE PER FORMAZIONE E PROGETTI
enrico chiolo

Sicurezza di MCP

I rischi di sicurezza introdotti dall'accesso dei modelli linguistici a strumenti esterni, i controlli disponibili, l'autenticazione e i contratti dei gateway enterprise.

Sicurezza di MCP riguarda i rischi che nascono quando un modello linguistico può usare strumenti esterni. Un server può permettergli di leggere dati sensibili, eseguire codice o modificare sistemi. Ogni capacità aggiunta amplia quindi ciò che un errore o un attacco può raggiungere.

I tool MCP hanno però un vantaggio rispetto a una shell con accesso libero a internet: espongono operazioni definite e possono essere registrati, limitati e controllati singolarmente. Il protocollo restringe il confine d’azione, ma non elimina gli attacchi.1

I rischi principali

Red Hat raggruppa i rischi in sei categorie.1

  • Delega confusa (confused deputy): il server agisce con i permessi dell’utente sbagliato oppure permette di raggiungere risorse che quell’utente non dovrebbe vedere.
  • Catena di fornitura: un server installato da terzi è codice eseguibile. Può essere malevolo fin dall’inizio oppure diventarlo dopo un aggiornamento.
  • Esecuzione di comandi non autorizzati: un server locale può passare input non controllato alla shell o a un processo di sistema. Isolamento e validazione degli argomenti riducono il rischio.
  • Prompt injection: un documento, un’email o una pagina web può contenere istruzioni nascoste che il modello scambia per comandi. Se il modello dispone di tool, quelle istruzioni possono trasformarsi in azioni.
  • Tool injection: un server può descrivere i propri tool in modo ingannevole o cambiarli dopo l’installazione, inducendo il modello a scegliere un’operazione diversa da quella attesa.
  • Abuso delle richieste al modello: un server può chiedere al client ulteriori elaborazioni, generando costi o facendo trattare dati che l’utente non intendeva condividere.

I controlli vanno applicati in più punti. Il client deve mostrare le azioni sensibili e chiedere conferma. Il server deve limitare i permessi, validare gli input e funzionare in un ambiente isolato. L’organizzazione deve verificare versioni e dipendenze come farebbe con qualsiasi altro software. Le analisi statiche del codice e delle dipendenze, spesso indicate con le sigle SAST e SCA, fanno parte di questo controllo.1

Il modello di minaccia di Willison

Simon Willison chiama trifecta letale la presenza contemporanea di tre condizioni:

  1. il modello legge dati non attendibili, come email o pagine scritte da terzi;
  2. può eseguire azioni, per esempio scrivere o spendere denaro;
  3. può essere manipolato da una prompt injection nascosta nei dati.

Il pericolo nasce dalla combinazione. Un’email ostile, da sola, è soltanto un contenuto; diventa molto più rischiosa se il modello che la legge può anche inviare file o creare utenti.

Nel 2025 Willison criticava MCP perché permetteva agli utenti di collegare molti tool senza comprenderne i rischi. Nel 2026 ha parzialmente rivisto la posizione: un insieme limitato di tool è più facile da controllare di una shell generale con accesso a internet. MCP può quindi ridurre la superficie d’azione, senza risolvere il problema della prompt injection.2

LA TRIFECTA LETALE (WILLISON) dati non attendibili web · email capacità di azione tool che scrive attaccabilità via prompt injection agente pericoloso l’agente è pericoloso quando le tre condizioni coesistono nella stessa sessione

La "trifecta letale" di Simon Willison: accesso a dati non attendibili, capacità di eseguire azioni e attaccabilità tramite prompt injection. MCP riduce il pericolo restringendo il confine, ma non lo elimina.

Autenticazione e autorizzazione

Autenticazione e autorizzazione rispondono a due domande: chi sta chiamando il server e quali azioni può compiere. MCP usa OAuth, lo standard che permette a un’applicazione di agire per conto di un utente senza riceverne la password.

Nel modello OAuth tradizionale, ogni client deve essere registrato in anticipo presso il server. Questo è poco pratico in un ecosistema nel quale client e server possono incontrarsi per la prima volta al momento della connessione. MCP aveva inizialmente adottato la registrazione dinamica, indicata come DCR. La specifica del 2026 preferisce invece i Client ID Metadata Documents (CIMD): l’identificatore del client è un URL dal quale il server legge un documento con le sue proprietà.34

La stessa release aggiunge controlli contro la scelta di un server di autorizzazione sbagliato e migliora il supporto per applicazioni desktop e da riga di comando. Le estensioni enterprise permettono inoltre di autorizzare centralmente un insieme di server, riducendo le richieste di login ripetute.34

Questi meccanismi non sostituiscono il principio del minimo privilegio. Anche un client autenticato deve ricevere soltanto i permessi necessari, e il server deve verificare per conto di quale utente sta agendo.1

I contratti dei gateway enterprise

Un gateway MCP si colloca tra i client e i servizi aziendali. Può tradurre una chiamata MCP in una normale API, applicare regole di sicurezza e registrare il traffico. Proprio perché concentra queste funzioni, un errore nel gateway può aggirare i controlli di più servizi.

Il caso Agentgateway descritto da Aonan Guan evidenzia tre proprietà da proteggere:5

  1. Gli argomenti devono restare nel campo previsto. Durante la traduzione verso OpenAPI, un valore destinato al corpo della richiesta non deve poter modificare URL, query o header.
  2. L’ispezione deve coprire l’intero messaggio. Se il gateway legge soltanto una parte del corpo, deve rifiutare la richiesta o dichiarare che il controllo è incompleto. Altrimenti un contenuto vietato può essere nascosto oltre il limite esaminato.
  3. La sessione deve restare legata al backend corretto. Nelle versioni stateful, riutilizzare un identificatore di sessione su una route diversa poteva aggirare policy differenti.

La specifica stateless del 2026 elimina il terzo problema perché rimuove l’identificatore di sessione. Restano invece i rischi introdotti dalla traduzione e dall’ispezione delle richieste. Si veda MCP stateless (spec 2026-07-28).

Voci correlate

Bibliografia e sitografia

  • Red Hat, Model Context Protocol (MCP): Understanding security risks and controls, 1 luglio 2025. redhat.com
  • Simon Willison, Stateless MCP has recaptured my interest, 31 luglio 2026. simonwillison.net
  • MCP Blog, The 2026-07-28 Specification, 28 luglio 2026. blog.modelcontextprotocol.io
  • MCP Blog, One Year of MCP — November 2025 Spec Release, 25 novembre 2025. blog.modelcontextprotocol.io
  • Aonan Guan, Enterprise MCP Gateway Security in Practice with Agentgateway, Agentic AI Foundation, 20 agosto 2026. aaif.io

Footnotes

  1. Red Hat, Model Context Protocol: Understanding security risks and controls, 2025. ↩ ↩2 ↩3 ↩4

  2. Simon Willison, Stateless MCP has recaptured my interest, 2026. ↩

  3. MCP Blog, The 2026-07-28 Specification, 2026. ↩ ↩2

  4. MCP Blog, One Year of MCP, 2025. ↩ ↩2

  5. Aonan Guan, Enterprise MCP Gateway Security in Practice with Agentgateway, AAIF, 2026. ↩