Protocollo di Contesto del Modello: Rischi di Sicurezza e Mitigazioni

L’adozione dell’AI sta avanzando rapidamente, passando da progetti pilota alla pratica quotidiana a livello di infrastruttura. La curva del budget riflette questo cambiamento. Gartner prevede che la spesa mondiale per l’AI raggiunga $2.52T nel 2026, con un aumento del 44% anno su anno. Allo stesso tempo, si prevede che la spesa per la cybersecurity dell’AI crescerà di oltre il 90% nel 2026, un chiaro segnale che più l’AI è integrata nelle operazioni aziendali, maggiore diventa la superficie di attacco.

Man mano che le organizzazioni operativizzano i LLM, la vera sfida si sposta dalla qualità delle risposte a un’esecuzione sicura. Non è più sufficiente che un modello spieghi cosa fare. In molti contesti, il valore deriva dall’azione, dal contesto giusto e dall’interazione con i sistemi in cui avviene il lavoro. Ciò include repository di codice, piattaforme di ticketing, strumenti SaaS, database e servizi interni.

Prima del Model Context Protocol, ogni integrazione di strumenti era come costruire un cavo personalizzato diverso per ogni dispositivo, per poi scoprire che ogni fornitore di LLM usava una spina leggermente diversa. MCP standardizza il connettore e il formato del messaggio; pertanto, gli strumenti possono esporre le capacità una volta sola, e più modelli possono usarle in modo coerente. Il risultato è uno sviluppo più rapido, meno integrazioni personalizzate e una manutenzione a lungo termine più bassa mentre l’adozione si diffonde nell’ecosistema.

Questo cambiamento è già visibile nei supporti AI focalizzati sulla cybersecurity. Ad esempio, Uncoder AI di SOC Prime è alimentato da strumenti MCP che trasformano un LLM in un copilota di cybersecurity contestualmente consapevole, supportando un’integrazione più semplice, la flessibilità dei fornitori, connessioni pre-configurate e una gestione dei dati più controllata. Ad esempio, MCP consente ricerche semantiche attraverso il Threat Detection Marketplace, trovando rapidamente regole per sorgenti di log o tipi di minaccia specifici e riducendo il tempo di ricerca manuale. Tutto questo è supportato da privacy e sicurezza al suo interno.

Tuttavia, in generale, quando MCP diventa un percorso comune tra agenti e sistemi critici, ogni server, connettore e ambito di permessi diventa rilevante per la sicurezza. Token troppo ampi, isolamento debole e tracciati audit incompleti possono trasformare la comodità in esposizione di dati, azioni non intenzionali o movimenti laterali.

Questa guida spiega come funziona MCP, quindi si concentra sui rischi di sicurezza pratici e sulle mitigazioni.

Cos’è MCP?

Da quando è stato rilasciato in open-source da Anthropic nel novembre 2024, il Model Context Protocol ha rapidamente guadagnato trazione come il livello di connessione tra agenti AI e gli strumenti, API e dati su cui si basano.

Al suo centro, MCP è un modo standardizzato per le applicazioni alimentate da LLM di comunicare con sistemi esterni in modo coerente e controllato. Sposta gli assistenti AI oltre la conoscenza statica e di formazione temporale consentendo loro di recuperare contesti freschi ed eseguire azioni tramite interfacce approvate. Il risultato pratico è un agente AI più accurato e utile, poiché può lavorare con dati operativi reali.

Componenti chiave

L’architettura del Model Context Protocol è basata su un insieme semplice di componenti che coordinano il modo in cui un LLM scopre capacità esterne, recupera il contesto corretto e scambia richieste e risposte strutturate con i sistemi connessi.

• Host MCP. L’ambiente in cui il LLM viene eseguito. Gli esempi includono un IDE alimentato da AI o un’interfaccia conversazionale incorporata in un prodotto. L’host gestisce la sessione utente e decide quando sono necessari contesti o azioni esterne.
• Client MCP. Un componente all’interno dell’host che gestisce la comunicazione del protocollo. Scopre i server MCP, richiede i metadati sulle capacità disponibili e traduce l’intento del modello in richieste strutturate. Inoltre, restituisce le risposte all’host in una forma che l’applicazione può usare.
• Server MCP. Il servizio esterno che fornisce contesto e capacità. Può accedere a sorgenti dati interne, piattaforme SaaS, strumenti di sicurezza specializzati o flussi di lavoro proprietari. È qui che le organizzazioni tipicamente applicano autorizzazioni specifiche del sistema, filtraggi dati e guide operative.
  
  

Livelli

• Livello dati. Questo livello interno si basa sul protocollo JSON-RPC e gestisce la comunicazione client-server. Copre la gestione del ciclo di vita e le primitive base che MCP espone, inclusi strumenti, risorse, prompt e notifiche.
• Livello di trasporto. Questo livello esterno definisce come i messaggi effettivamente si muovono tra client e server. Specifica i meccanismi e i canali di comunicazione, inclusa la configurazione della connessione specifica del trasporto, l’incorniciatura dei messaggi e l’autorizzazione.
  
  

Concettualmente, il livello di dati fornisce il contratto e le semantiche, mentre il livello di trasporto fornisce la connettività e il percorso di applicazione per uno scambio sicuro.

Come funziona MCP?

MCP si posiziona tra il LLM e i sistemi esterni che il tuo agente pianifica di utilizzare. Invece di dare al modello accesso diretto a database, app SaaS o servizi interni, MCP espone capacità approvate come strumenti e fornisce un modo standard per richiamarli. Il LLM si concentra sulla comprensione della richiesta e nel decidere cosa fare successivamente. MCP gestisce la scoperta dello strumento, l’esecuzione e il ritorno dei risultati in un formato prevedibile.

Un flusso tipico può sembrare il seguente:

• L’utente fa una domanda o assegna un compito. Il prompt arriva nell’applicazione AI, anche detto host MCP.
• Scoperta dello strumento. Il client MCP verifica uno o più server MCP per vedere quali strumenti sono disponibili per questa sessione.
• Iniezione del contesto. MCP aggiunge dettagli rilevanti dello strumento al prompt, così il LLM sa cosa può usare e come richiamarlo.
• Generazione della chiamata allo strumento. Il LLM crea una richiesta strutturata dello strumento, fondamentalmente una chiamata di funzione con parametri.
• Esecuzione nel servizio a valle. Il server MCP riceve la richiesta e la esegue contro il sistema target, spesso tramite un’API come REST.
• Risultati restituiti e utilizzati. L’output ritorna all’applicazione AI. Il LLM può usarlo per fare un’altra chiamata o per scrivere la risposta finale.
  
  

Ecco un semplice esempio di come funziona in Uncoder AI. Tu chiedi: “Trova rilevamenti per il dumping delle credenziali che funzionano con i log di Windows Security.”

• Il LLM si rende conto che ha bisogno di accedere a una libreria di rilevamenti, non solo alla propria conoscenza.
• Tramite MCP, Uncoder AI chiama lo strumento di ricerca rilevamenti pertinente collegato al Threat Detection Marketplace di SOC Prime.
• Il server MCP esegue la ricerca e restituisce un breve elenco di rilevamenti corrispondenti.
• Uncoder AI poi rivede i risultati e risponde con un elenco pulito di cinque regole di rilevamento.

Rischi e vulnerabilità di MCP

Il Model Context Protocol espande ciò che un LLM può fare collegandolo a strumenti, API e dati operativi. Questa capacità è il valore, ma è anche il rischio. Una volta che un assistente può recuperare contesto interno e innescare azioni attraverso servizi collegati, MCP diventa parte del tuo piano di controllo. La postura di sicurezza non è più definita solo dal modello, ma dai server di cui ti fidi, dai permessi che concedi e dalle guide che applichi attorno all’uso degli strumenti.

Considerazioni chiave sulla sicurezza di MCP

I server MCP servono da colla tra host e una vasta gamma di sistemi esterni, inclusi potenzialmente quelli non fidati o rischiosi. Comprendere la tua esposizione richiede visibilità su ciò che si trova su ogni lato del confine del server, quali host e client LLM lo stanno chiamando, come è configurato il server, quali server di terze parti sono abilitati e quali strumenti il modello può effettivamente invocare nella pratica.

• Problema del Deputy Confuso. Se un server MCP può agire con privilegi più ampi dell’utente, potrebbe eseguire azioni che l’utente non dovrebbe poter innescare. Il modello sicuro è che il server agisca per conto dell’utente con consenso esplicito e ambiti di minimo privilegio, non con un’identità di servizio generalizzata.
• Passaggio di Token. Passare token client attraverso API a valle senza una corretta convalida rompe i confini di fiducia e può vanificare i controlli degli utenti. Le linee guida MCP trattano questo come un anti-pattern ad alto rischio perché rende l’autorizzazione ambigua e difficile da verificare.
• Dirottamento di Sessione e Iniezione di Eventi. Le connessioni con stato possono essere abusate se gli identificatori di sessione possono essere rubati, ripetuti o ripristinati da un attaccante. La gestione sicura delle sessioni è importante perché le chiamate agli strumenti diventano una sequenza, non una singola richiesta, e gli aggressori colpiscono l’anello più debole in quella catena.
• Compromissione del Server MCP Locale. I server locali possono essere potenti, e quel potere taglia in entrambi i modi. I rischi includono il funzionamento di codice non fiduciario, comportamenti di avvio non sicuri e l’esposizione di un servizio locale in modo che un altro sito o processo possa raggiungerlo. Le distribuzioni locali necessitano di isolamento, legame rigoroso e impostazioni predefinite sicure.
• Fallimenti della Minimizzazione dello Scopo. Ambiti eccessivamente ampi aumentano il raggio di esplosione e indeboliscono la governance. Le specifiche evidenziano le insidie nella progettazione degli ambiti, come sovraccaricare un singolo ambito per molte operazioni o pubblicizzare un supporto eccessivo degli ambiti. Gli ambiti di minimo privilegio e una chiara separazione delle capacità di lettura e scrittura sono essenziali.
  
  

Molti rischi di MCP si mappano a fondamentali di sicurezza familiari; pertanto, i server MCP dovrebbero essere trattati come qualsiasi altra superficie di integrazione. Le organizzazioni devono applicare controlli sulla catena di approvvigionamento, eseguire la scansione del codice e delle dipendenze, fissare le versioni, e rivedere i cambiamenti prima del rilascio. Inoltre, è importante rafforzare gli endpoint con un’autenticazione e autorizzazione robuste, limiti di velocità e impostazioni predefinite sicure. Queste pratiche eliminano una gran parte dei fallimenti prevenibili.

La specifica MCP fornisce un elenco di migliori pratiche di sicurezza, con modelli di attacco comuni e mitigazioni pratiche che puoi applicare quando costruisci o gestisci host, client e server MCP.

Principali Rischi di Sicurezza di MCP

Per rendere l’elenco attuabile, è utile raggruppare le minacce MCP nei modelli di rischio più comuni che i difensori vedono nelle implementazioni reali.

Iniezione di Prompt

Gli attaccanti creano input che spingono l’assistente a un uso degli strumenti non sicuro o alla divulgazione di dati sensibili.

Suggerimento di mitigazione: limitare l’accesso agli strumenti, applicare politiche di chiamata e monitorare l’uso degli strumenti per modelli anomali.

Iniezione di Prompt Indiretta

Istruzioni ostili possono arrivare tramite contenuti recuperati ed essere trattate come intenti fidati.

Suggerimento di mitigazione: segregare i contenuti non fidati, sanificarli e impedire che gli strumenti vengano invocati in base a istruzioni trovate nei dati esterni.

Avvelenamento degli Strumenti

Descrizioni degli strumenti, parametri o predefiniti possono essere manipolati per guidare le decisioni del modello.

Suggerimento di mitigazione: trattare i metadati degli strumenti come input non fiduciario, rivedere le definizioni degli strumenti come il codice e richiedere controlli di integrità prima degli aggiornamenti.

Ombreggiatura degli Strumenti e Collisione dei Nomi degli Strumenti

Strumenti simili possono impersonare quelli legittimi e catturare richieste.

Suggerimento di mitigazione: mantenere una lista di approvazione dei server e degli strumenti approvati, e fallire chiuso quando un’identità dello strumento non può essere verificata.

Fallimenti di Autorizzazione del Deputy Confuso

Un server esegue azioni utilizzando i propri privilegi ampi piuttosto che i permessi legati all’utente.

Suggerimento di mitigazione: utilizzare il consenso esplicito, applicare ambiti legati all’utente e convalidare i token secondo le linee guida di autorizzazione MCP.

Tramissione di Token e Debole Convalida dei Token

L’inoltro dei token o l’accettazione di token senza una corretta convalida del pubblico compromette l’autorizzazione.

Suggerimento di mitigazione: proibire il passaggio, convalidare il pubblico del token e seguire il flusso basato su OAuth definito per i trasporti HTTP.

Dirottamento di Sessione

Gli attaccanti abusano di sessioni ripristinabili o identificatori rubati per iniettare eventi o impersonare un client.

Suggerimento di mitigazione: legare strettamente le sessioni, ruotare gli identificatori, applicare timeout e registrare ripristini e anomalie.

Compromissione del Server Locale

I server MCP locali possono essere sfruttati per accedere a file, eseguire comandi o passare ad altre risorse se non isolati.

Suggerimento di mitigazione: isolare i server locali, minimizzare i privilegi del sistema operativo, limitare l’accesso al file system ed evitare di esporre servizi locali oltre quanto richiesto.

Scopi Eccessivi e Creep dei Permessi

Gli ambiti ampi creano accessi non intenzionali e i permessi tendono ad accumularsi nel tempo.

Suggerimento di mitigazione: dividere gli strumenti di lettura e scrittura, rivedere regolarmente gli ambiti e mantenere i set di ambiti minimi e specifici per compito.

Mancanza di Auditabilità e Debole Risposta agli Incidenti

Se non riesci a correlare prompt, chiamate agli strumenti, token e azioni a valle, le indagini diventano congetture.

Suggerimento di mitigazione: centralizzare i log, allegare ID di correlazione e registrare l’intento delle chiamate agli strumenti, i parametri e i risultati in un formato compatibile con SIEM.

La conclusione pratica è che MCP dovrebbe essere sicurizzato come un livello di integrazione ad alto impatto. Assume che gli output degli strumenti non siano fidati, minimizza i permessi, applica un’identità e un’autorizzazione forti e investi presto in un monitoraggio che possa collegare i prompt alle chiamate agli strumenti e alle azioni a valle.

SOC Prime segue le migliori pratiche di sicurezza e privacy stabilite per proteggere i clienti e garantire il funzionamento affidabile della piattaforma SOC Prime e delle capacità abilitate da AI. Il team SOC Prime ha anche creato e rilasciato in open-source AI/DR Bastion, un sistema di protezione GenAI completo progettato per salvaguardare contro prompt malevoli, attacchi di iniezione e contenuti dannosi. Il sistema incorpora diversi motori di rilevamento che operano in sequenza per analizzare e classificare gli input degli utenti prima che raggiungano applicazioni GenAI.

Inoltre, la piattaforma SOC Prime supporta l’integrazione con AIDEFEND (Artificial Intelligence Defense Framework), una base di conoscenza aperta, focalizzata sull’AI, di contromisure difensive per minacce emergenti AI/ML. Supportato da Uncoder AI, il AIDEFEND-native MCP rende questa conoscenza immediatamente attuabile. I professionisti della sicurezza possono chiedere difese contro minacce specifiche, ottenere guide dettagliate sulle tecniche, generare liste di controllo rapide o estrarre frammenti di codice sicuro per implementare controlli più rapidamente e con meno sovraccarico di ricerca.

Qual è il futuro della sicurezza MCP?

Le preoccupazioni sulla sicurezza riguardanti MCP sono valide, ma la standardizzazione è anche una grande opportunità per migliorare il controllo. Man mano che l’adozione di MCP cresce, le organizzazioni ottengono una superficie di sicurezza più coerente dove possono applicare le stesse politiche e il monitoraggio attraverso l’uso degli strumenti, invece di assicurare un’integrazione personalizzata diversa per ogni modello e ogni sistema riverbero.

Guardando al futuro, la sicurezza MCP maturerà in alcune direzioni prevedibili:

• Assicurare i Blocchi di Costruzione MCP. La sicurezza MCP si concentrerà sempre più sulle primitive del protocollo che definiscono ciò che un agente può fare. Gli strumenti sono funzioni eseguibili e necessitano di permessi stretti e regole chiare per quando possono essere eseguiti. Le risorse agiscono come contenitori di dati e richiedono controllo accessi e convalida per ridurre le perdite e il poisoning. I prompt influenzano il comportamento e devono essere protetti con soluzioni come AI/DR Bastion contro iniezioni e modifiche non autorizzate.
• Rendere l’Identità Obbligatoria per MCP Remoto. Per qualsiasi server MCP connesso, l’autenticazione dovrebbe essere trattata come un requisito di base. I team necessitano di un modello di identità chiaro che risponda a chi sta effettuando la chiamata, cosa è loro permesso fare e quale consenso è stato concesso. Questo aiuta anche a prevenire fallimenti comuni evidenziati nella specifica, come i comportamenti del deputy confuso e i modelli di gestione dei token rischiosi.
• Applicare le Politiche Usando il Contesto Completo. Le liste di approvazione sono utili, ma i flussi di lavoro degli agenti necessitano di guide più ricche. Il prompt, l’utente, lo strumento selezionato, i parametri dello strumento e il sistema target dovrebbero tutti influenzare cosa è consentito. Con quel contesto, puoi limitare le operazioni rischiose, limitare il recupero di dati sensibili, bloccare i modelli di parametri non sicuri e richiedere controlli extra quando il livello di rischio è alto.
• Trattare il Monitoraggio come Controllo Centrale. Man mano che gli agenti concatenano le azioni, l’indagine dipende dalla possibilità di tracciare il comportamento dall’inizio alla fine. Un benchmark pratico è la registrazione che correla prompt, selezione degli strumenti, input degli strumenti, output degli strumenti e richieste a valle. Senza quel collegamento, è difficile verificare le azioni o rispondere rapidamente quando qualcosa va storto.
• Aggiungere Cancelli di Approvazione per Azioni ad Alto Impatto. Per azioni che creano, modificano, eliminano, pagano o aumentano i privilegi, la revisione umana rimane essenziale. Le implementazioni mature di MCP aggiungeranno passaggi di approvazione espliciti che fermano l’esecuzione fino a quando un utente o un flusso di lavoro di sicurezza non conferma l’azione. Questo riduce la superficie di attacco da sia il prompting malevolo che l’uso errato accidentale degli strumenti.
• Verificare i Server e Controllare gli Aggiornamenti. Man mano che l’ecosistema si espande, la fiducia e la provenienza diventano obbligatorie. Le organizzazioni si affideranno sempre di più a server MCP approvati, onboarding controllato e gestione rigorosa dei cambiamenti per gli aggiornamenti. Bloccaggio delle versioni, controlli di integrità e scansione delle dipendenze sono importanti perché i server MCP sono codice eseguibile e il comportamento degli strumenti può cambiare nel tempo, anche se le interfacce sembrano stabili.
• Mantenere i Fondamentali in Primo Piano. Anche con controlli specifici per MCP, le pratiche di sicurezza più comuni rimangono le basi. Minimo privilegio, ambiti chiari, gestione delle sessioni sicure, forti autenticazioni, endpoint rinforzati e registrazione completa dell’audit rimuovono gran parte del rischio nel mondo reale. Usa l’elenco delle migliori pratiche di sicurezza MCP come lista di controllo permanente, quindi aggiungi controlli basati sul tuo ambiente e l’appetito al rischio.
  
  

Man mano che MCP si diffonde tra più assistenti e strumenti, la sicurezza diventa la differenza tra un copilota utile e un motore di automazione non controllato. Il percorso più sicuro è semplice: trattare MCP come infrastruttura privilegiata, mantenere i permessi stretti e rendere ogni chiamata agli strumenti visibile e tracciabile. Fallo bene, e MCP può scalare i flussi di lavoro degli agenti con fiducia invece di trasformare la velocità in rischio.