Il Model Context Protocol (MCP) sta rapidamente diventando uno standard comune per connettere AI agent a dati e strumenti enterprise. Sostituisce integrazioni ad-hoc per-strumento con un’interfaccia condivisa che permette agli agent di chiamare server esterni, recuperare contesto ed eseguire azioni. Ma ogni MCP server con cui un agente parla è un nuovo trust boundary. Recenti incidenti di sicurezza — inclusi un pacchetto npm malevolo che impersonava un servizio email legittimo e vulnerabilità disclose negli SDK MCP ufficiali — mostrano cosa succede quando i team trattano i server MCP come plug-and-play.
La sicurezza MCP significa trattare ciascun server come untrusted per default, fare vetting della sua fonte, scoping dell’accesso agli strumenti, isolare l’esecuzione, loggare le azioni e governare il deploy con policy esplicite. Se il tuo team sta navigando il percorso più ampio dal pilota alla produzione coperto in AI agente in produzione, la sicurezza MCP è il layer che determina se il tuo agente può toccare in modo sicuro i dati enterprise una volta arrivato.
Punti Chiave
- MCP trasforma ogni server esterno in un nuovo trust boundary. Le integrazioni MCP default-open possono esporre dati enterprise oltre lo scope previsto dall’agente.
- I top risk 2026 includono tool poisoning, prompt injection attraverso risposte dei server MCP, attacchi rug-pull e supply-chain, scope degli strumenti eccessivamente ampi e failure di validazione OAuth o token.
- Le best practice di sicurezza MCP coprono vetting e version pinning dei server, scope degli strumenti least-privilege, sandboxing dell’esecuzione, audit logging completo e approvazione human-in-the-loop per azioni sensibili.
- La governance enterprise colma il divario: policy scritta, classificazione dei dati e controlli che possono supportare l’allineamento con ISO/IEC 27001:2022 e SOC 2 — ma non stabiliscono da soli la compliance.
- I server remoti autenticati sono spesso più facili da governare se combinati con segmentazione di rete, autorizzazione scoped, controllo egress e logging centralizzato. Remoto non è automaticamente più sicuro; è più sicuro solo quando quei controlli sono in posto.
Cos’è il Model Context Protocol (MCP)?
Il Model Context Protocol è un protocollo aperto che standardizza come le applicazioni LLM si connettono a fonti di dati e strumenti esterni. Secondo la specifica ufficiale del Model Context Protocol, MCP definisce tre ruoli: host (applicazioni che gestiscono agent), client (entità dentro l’host che si connettono ai server) e server (programmi che espongono strumenti, risorse e prompt). MCP è un protocollo aperto originariamente introdotto da Anthropic, come descritto nell’introduzione di Anthropic del Model Context Protocol. Non è di proprietà esclusiva di un singolo vendor.
Perché i team vanno oltre le integrazioni ad-hoc degli strumenti
Prima di MCP, connettere un agente a un database, CRM o file store significava scrivere un’integrazione custom per strumento. MCP sostituisce questo con un protocollo condiviso dove qualsiasi client MCP-compatible può chiamare qualsiasi server. I benefici — integrazione più rapida, server riutilizzabili, portabilità del modello — sono reali, ma la stessa facilità espande la superficie di attacco. Quando uno sviluppatore può installare un MCP server in secondi, la domanda passa da “possiamo costruirlo?” a “dovremmo fidarci di questo server con i nostri dati?”
Cosa MCP Fa — e Non Fa — Sicuro per Default
MCP standardizza la comunicazione tra client e server. Non rende sicura l’integrazione completa. I seguenti rimangono responsabilità dell’host e del client: trust del server, autorizzazione, consenso, validazione dell’output e controlli di esecuzione (sandboxing, rate limiting, isolamento). La specifica nota che le descrizioni e le annotazioni degli strumenti dovrebbero essere considerate untrusted a meno che non provengano da un server trusted. MCP ti dà un modo standard di connetterti — non una garanzia che ciò a cui ti connetti sia sicuro.
Perché la Sicurezza MCP Conta Ora
Un MCP server spesso detiene credenziali per un database, file system, provider email o API business. Se il server è compromesso, over-permissioned o malevolo, la superficie di data leak si espande a tutto ciò che quelle credenziali possono raggiungere.
| Dimensione | Integrazione ad-hoc | Integrazione basata su MCP |
|---|---|---|
| Trust boundary | Un’integrazione custom per strumento | Un boundary standard per server, riutilizzato across agent |
| Scope dei permessi | Definito per integrazione, spesso rivisto | Spesso ereditato dai default del server, facilmente over-scoped |
| Auditability | Logging custom per integrazione | Call standardizzate, ma il logging deve ancora essere configurato |
| Rischio supply chain | Limitato alle dipendenze scelte | Qualsiasi server installabile diventa una potenziale dipendenza |
MCP rende banalmente facile aggiungere nuovi server, e ciascuno estende il boundary. Molti piloti girano server locali con impostazioni default — nessuna autenticazione, nessun audit log, nessuna credenziale scoped — il che va bene per una demo ma non quando l’agente tocca dati cliente reali.
Incidenti, Vulnerabilità e Pattern di Attacco MCP Documentati
Non ogni concern di sicurezza MCP è lo stesso. Alcuni sono incidenti real-world confermati. Altri sono vulnerabilità disclose patchate prima di exploitazione nota. Altri ancora sono dimostrazioni di ricerca. Questa sezione separa i tre.
Incidente confermato: pacchetto npm postmark-mcp malevolo
A settembre 2025, un pacchetto npm terzo malevolo chiamato postmark-mcp impersonava Postmark, un servizio di email delivery. Questo non era un pacchetto Postmark ufficiale — Postmark non aveva pubblicato il suo server MCP ufficiale su npm prima di questo incidente. Secondo l’avviso di sicurezza ufficiale di Postmark, il pacchetto ha costruito trust in 15 versioni, poi ha aggiunto una backdoor nella versione 1.0.16 che segretamente BCCava le email in uscita a un server esterno. L’analisi di Koi Security del pacchetto malevolo ha riportato circa 1.500 download settimanali; la destinazione BCC nascosta attribuita a Koi Security era un indirizzo al dominio giftshop.club.
Questo è stato un incidente real-world di pacchetto malevolo e supply-chain software, non un breach della piattaforma ufficiale di Postmark. L’API legittima e i servizi di Postmark non sono stati compromessi e sono rimasti non interessati. L’incidente dimostra rischio supply-chain, rischio di permessi eccessivi, failure di vetting dei server e rischio di cambiamento di versione. Il pattern è simile a un rug-pull; “rug pull” è usato qui come descrizione del pattern, non come classificazione di Postmark.
Vulnerabilità disclose: CVE-2025-66414 e CVE-2025-66416
Due vulnerabilità disclose negli SDK MCP ufficiali evidenziano rischi a livello di implementazione. Queste sono vulnerabilità di implementazione disclose, non breach real-world confermati, senza evidenza pubblica di sfruttamento in-the-wild.
CVE-2025-66414 — TypeScript SDK. Prima della 1.24.0, l’SCP MCP TypeScript SDK non abilitava la protezione DNS rebinding per default per server HTTP-based. Quando un server girava su localhost senza autenticazione usando StreamableHTTPServerTransport o SSEServerTransport, e enableDnsRebindingProtection non era abilitato, un sito web malevolo poteva bypassare la same-origin policy e invocare strumenti o risorse esposte. Non affecta il transport stdio. Fixato in 1.24.0. Vedi l’advisory GitHub per CVE-2025-66414 e il record NVD per CVE-2025-66414.
CVE-2025-66416 — Python SDK. Prima della 1.23.0, l’SCP MCP Python SDK (mcp su PyPI) non abilitava la protezione DNS rebinding per default per server HTTP-based. Quando un server girava su localhost senza autenticazione usando FastMCP con streamable HTTP o SSE, e TransportSecuritySettings non era configurato, un sito web malevolo poteva bypassare la same-origin policy e invocare strumenti o risorse esposte. Non affecta il transport stdio. Fixato in 1.23.0. Vedi l’advisory GitHub per CVE-2025-66416 e il record NVD per CVE-2025-66416.
Entrambi gli advisory notano che eseguire server MCP HTTP-based localmente senza autenticazione non è raccomandato. Le configurazioni interessate sono specifiche: il transport stdio e i server autenticati non erano interessati.
Dimostrazioni di ricerca e pattern di attacco teorici
Ricercatori di sicurezza hanno dimostrato pattern di attacco che illustrano come MCP può essere abusato. Questi sono proof of concept, non incidenti real-world confermati. I pattern di attacco MCP documentati mostrano che istruzioni malevole possono essere embedded nelle descrizioni degli strumenti visibili al modello ma non evidenti all’utente, causando l’agente a compiere azioni che l’utente non ha mai approvato. Mostrano anche come un server inizialmente benigno potrebbe successivamente introdurre prompt injection indiretta attraverso i dati restituiti, manipolando il comportamento dell’agente senza sfruttare direttamente il modello.
Top Risk di Sicurezza MCP nel 2026
Tool poisoning e server MCP malevoli
Il tool poisoning avviene quando un server embedded istruzioni malevole nelle descrizioni o nei metadata degli strumenti che il modello legge ma l’utente non vede. L’agente può seguire quelle istruzioni e compiere azioni fuori dall’intento dell’utente. L’incidente postmark-mcp è un caso confermato di server malevolo che impersonava un progetto legittimo.
Prompt injection attraverso risposte dei server MCP
Un MCP server restituisce dati — contenuti di file, righe di database, risposte API. Se quei dati contengono istruzioni, l’agente può trattarle come comandi. Poiché l’agente si fida del server come fonte di dati, il contenuto restituito diventa una superficie di injection a meno che l’host non lo validi e isoli. Per un trattamento più approfondito, consulta la sicurezza LLM per AI agente.
Risk di rug-pull e supply-chain di terze parti
Un rug-pull si verifica quando un server inizialmente sicuro cambia comportamento dopo un aggiornamento. Il rischio supply-chain si estende alle dipendenze, ai pacchetti transitive e ai server non mantenuti. Gli agent chiamano strumenti automaticamente e frequentemente, quindi il blast radius di un server compromesso è più ampio di una tipica dipendenza di libreria.
Scope degli strumenti eccessivamente ampi ed esposizione di credenziali
I server sono spesso granted permessi più ampi del necessario. Quando le credenziali passano attraverso un server compromesso o over-permissioned, l’esposizione si estende a tutto ciò che quelle credenziali possono raggiungere. Il least privilege è il controllo che limita i danni quando un server va male.
Failure di OAuth, validazione dei token e autorizzazione
L’autorizzazione MCP per server remoti HTTP-based segue le convenzioni OAuth 2.1, come descritto nella guida all’autorizzazione MCP. L’autorizzazione protegge risorse e operazioni sensibili esposte dai server MCP. OAuth non è una garanzia di sicurezza automatica: le implementazioni devono validare audience, issuer, expiration e scope dei token; i token dovrebbero essere di breve durata e conservati in modo sicuro; i flow di produzione dovrebbero usare HTTPS; credenziali, authorization header, token e authorization code non devono essere scritti nei log; e gli scope catch-all dovrebbero essere evitati in favore di scope least-privilege per strumento. MCP non implementa OAuth in modo sicuro per conto degli sviluppatori. Per una guida più ampia su token passthrough, rischi confused-deputy, SSRF e minimizzazione degli scope, consulta le best practice di sicurezza MCP.
Best Practice di Sicurezza MCP
Fare vetting e pinning di ogni MCP server
Tratta qualsiasi MCP server come software untrusted: conferma che il publisher è ufficiale, rivedi i permessi richiesti, leggi il source o un audit trusted, fai pinning a una versione specifica e preferisci server di organizzazioni di cui ti fidi. L’incidente postmark-mcp è l’esempio di ammonimento.
Enforce least privilege sugli scope degli strumenti
Grant a ciascun server l’accesso minimo richiesto. Separa scope di lettura e scrittura. Usa credenziali scoped invece di admin token condivisi. Se un server è compromesso, il danno è limitato allo scope ristretto che gli è stato granted.
Sandboxare e isolare l’esecuzione dei server MCP
Esegui i server MCP in ambienti isolati — container, VM o segmenti di rete separati — non direttamente sull’host. Non condividere file system o credenziali tra server. Il sandboxing riduce il blast radius da “il server può raggiungere tutto” a “il server può raggiungere solo ciò che gli è stato esplicitamente permesso”.
Audit logging e observability degli agent
Logga identità autenticate, scope granted, tool-call, input e output sanitizzati, decisioni di policy, eventi di approvazione, errori e outcome finali delle azioni. Credenziali, token e dati personali sensibili non devono apparire nei log. Il log è ciò che permette a un team di ricostruire eventi, provare compliance e rilevare anomalie prima che diventino incidenti.
Human-in-the-loop per azioni sensibili
Richiedi approvazione umana per azioni con impatto real-world: scritture su database di produzione, invio di email esterne, chiamate ad API a pagamento, modifica di record cliente. Le soglie dovrebbero essere basate sulla classificazione dei dati — dati pubblici possono non richiedere approvazione, mentre dati confidenziali e riservati richiedono sign-off esplicito.
Framework di Governance Enterprise per AI Agent
Policy, ownership e workflow di approvazione
La governance inizia con policy scritta: chi può approvare un nuovo MCP server, quale revisione è richiesta, chi possiede ciascun deploy di agente. Senza ownership esplicita, gli sviluppatori installano server ad-hoc e i team di sicurezza li scoprono solo dopo un incidente. Un workflow semplice — proponi, rivedi, approva, deploya — ferma la maggior parte dei rischi supply-chain prima della produzione.
Classificazione dei dati e controlli di residency
Classifica i dati come pubblico, interno, confidenziale o riservato e decidi quali classi un agente e i suoi server possono toccare. Enforce controlli di residency dove richiesto: dati soggetti a regolamentazioni EU o US non dovrebbero fluire attraverso server fuori dalla regione appropriata.
Allineare l’uso di MCP con ISO/IEC 27001:2022 e SOC 2
I controlli di sicurezza MCP possono supportare l’allineamento con ISO/IEC 27001:2022 e SOC 2, ma implementare questi controlli da soli non stabilisce la compliance. Il vetting dei server mappa alla gestione del rischio dei fornitori; il least privilege mappa al controllo degli accessi; l’audit logging mappa al monitoring; l’human-in-the-loop mappa al change management. La compliance completa richiede il più ampio sistema di gestione, valutazione dei rischi, audit interno e certificazione esterna.
Pattern di Architettura per Integrazione AI Sicura
Server MCP locali vs remoti
I server locali girano sullo stesso host — semplici per lo sviluppo, ma condividono file system e rete, aumentando il blast radius. I server remoti girano separatamente, possono essere autenticati e sono più facili da auditare. Remoto non è automaticamente più sicuro: un server remoto non autenticato su internet aperto è peggiore di un server locale propriamente configurato. I server remoti autenticati sono spesso più facili da governare se combinati con segmentazione di rete, autorizzazione scoped, controllo egress e logging centralizzato.
OAuth e connessioni MCP autenticate
L’autorizzazione MCP per server remoti HTTP-based segue le convenzioni OAuth 2.1. Usa token scoped, di breve durata e ruotati conservati in modo sicuro. Valida audience, issuer, expiration e scope dei token su ogni richiesta. Non scrivere credenziali, authorization header, token o authorization code nei log. Evita scope catch-all; grant scope least-privilege per strumento. I flow di produzione dovrebbero usare HTTPS. MCP non implementa OAuth in modo sicuro per te — consulta la guida all’autorizzazione MCP e le best practice di sicurezza MCP per requisiti a livello di protocollo e guida più ampia su token passthrough, rischi confused-deputy e minimizzazione degli scope.
Segmentazione di rete e controlli di egress
Posiziona i server MCP in subnet private con egress controllato. Restringi il traffico outbound a una allowlist di indirizzi IP e domini. Questo limita i path di exfiltration se un server è compromesso — lo stesso principio che HDWEBSOFT usa per l’email outbound attraverso un NAT Gateway con IP allowlisting. Per un contesto più ampio sull’integrazione AI sicura, consulta i nostri servizi di sviluppo AI e servizi di cybersecurity.
Un Workflow di Deploy MCP Security-First
Un deploy MCP difendibile segue un workflow ripetibile: audit del server (conferma fonte, rivedi permessi, leggi codice), scoping dei permessi (least privilege per strumento, credenziali scoped), isolamento dell’esecuzione (container o segmento di rete separato), osservazione del comportamento (logga identità, scope, tool-call, I/O sanitizzato, decisioni di policy, approvazioni, errori, outcome) e applicazione di oversight umana (approvazione per azioni sensibili basata sulla classificazione dei dati).
HDWEBSOFT applica questo workflow in engagement cliente che coinvolgono AI agent e dati enterprise. Come partner di sviluppo software certificato ISO 9001 e ISO/IEC 27001, HDWEBSOFT tratta la sicurezza come un release gate, non una checklist finale. L’obiettivo non è rallentare i team; è assicurarsi che quando un agente raggiunge la produzione, il layer MCP non sia la cosa che si rompe.
Conclusione
MCP è la direzione giusta per connettere AI agent a dati enterprise. Un protocollo condiviso è meglio di un groviglio di integrazioni custom. Ma la sicurezza MCP non è automatica. Ogni server è un trust boundary, ogni scope di strumento è un potenziale blast radius e ogni aggiornamento è una possibilità che il comportamento cambi. I team che shippano in modo sicuro fanno vetting dei server, enforce least privilege, isolano l’esecuzione, loggano ciò che conta e mantengono gli umani nel loop.
Se il tuo team sta connettendo AI agent a dati enterprise attraverso MCP, il prossimo step di maggior valore è una revisione indipendente prima della produzione. Richiedi un AI Security & Architecture Audit per identificare gap nel vetting dei server, scope degli strumenti, autorizzazione, logging e governance — e ottenere un piano di remediation concreto prima che un incidente lo forzi.
FAQ
Cos’è la sicurezza MCP?
La sicurezza MCP è la pratica di proteggere gli AI agent che si connettono a dati e strumenti esterni attraverso il Model Context Protocol. Copre il vetting dei server, scope degli strumenti least-privilege, isolamento dell’esecuzione, audit logging, controlli human-in-the-loop e governance enterprise delle integrazioni basate su MCP.
Quali sono i rischi di sicurezza MCP server più comuni?
I rischi di sicurezza MCP più comuni includono tool poisoning da server malevoli, prompt injection attraverso risposte dei server MCP, attacchi rug-pull e supply-chain di terze parti, scope degli strumenti eccessivamente ampi con esposizione di credenziali e failure di validazione OAuth o token in deploy autenticati.
Come rendo sicuro un MCP server in produzione?
Rendi sicuro un MCP server in produzione facendo vetting e pinning di ogni server, enforcendo scope degli strumenti least-privilege, sandboxando l’esecuzione del server, loggando identità autenticate e tool-call, applicando approvazione human-in-the-loop per azioni sensibili e allineando il deploy con governance enterprise e controlli di compliance.
Il Model Context Protocol è sicuro per AI agent enterprise?
MCP è sicuro per AI agent enterprise quando i team trattano ogni MCP server come un nuovo trust boundary e applicano controlli di sicurezza espliciti. MCP standardizza la comunicazione tra client e server, ma la trust del server, l’autorizzazione, la validazione dell’output e i controlli di esecuzione rimangono responsabilità dell’host e del client.
Come supporta la sicurezza MCP la compliance ISO/IEC 27001:2022 o SOC 2?
I controlli di sicurezza MCP possono supportare l’allineamento con ISO/IEC 27001:2022 e SOC 2 mappando il vetting dei server, l’accesso least-privilege, l’audit logging e la gestione del rischio dei fornitori a categorie di controllo esistenti. Implementare questi controlli da soli non stabilisce la compliance; le organizzazioni devono anche completare il più ampio sistema di gestione e i requisiti di audit.
Quando dovremmo eseguire un AI Security & Architecture Audit?
Esegui un AI Security & Architecture Audit prima di promuovere un AI agent in produzione, dopo un incidente di sicurezza o near-miss, quando connetti agent a nuove fonti di dati sensibili e ogni volta che un nuovo MCP server viene introdotto in un workflow di produzione.
