La nuova spec MCP sposta la sicurezza verso gli sviluppatori. Checklist concreta per sicurizzare il vostro server MCP senza bloccare gli agenti IA.
La nuova specifica di Model Context Protocol, pubblicata fine giugno 2026, sposta una parte critica della responsabilità sulla sicurezza del protocollo verso gli sviluppatori che lo implementano. Concretamente: se il tuo server MCP espone uno strumento sensibile senza validazione rigorosa dei token OAuth, il buco di sicurezza viene dal tuo codice, non dal protocollo disegnato da Anthropic.
È un cambio di filosofia, non un semplice patch. Fino ad ora, MCP era rimasto relativamente permissivo su come i server gestivano l'autenticazione. La nuova versione enterprise-ready, documentata da SecurityWeek fine giugno, chiude questa libertà d'azione e spinge i team a blindare loro stessi le implementazioni. Ne avevamo già parlato in Commerce agentiche su Shopify: MCP diventa l'interfaccia standard tra agenti IA e sistemi aziendali. Resta il fatto che collegare un agente al tuo CRM o al tuo database di ordini senza protezioni è come aprire una porta che nessuno controlla.
Quello che è cambiato nella spec MCP di giugno 2026
Il protocollo MCP funziona come un'interfaccia unificata: un agente IA, Claude, Cursor, oppure qualsiasi altro client compatibile, vi si connette per chiamare strumenti esterni senza codice specifico per ogni integrazione. X (il vecchio Twitter) ha lanciato il suo server MCP fine giugno per permettere ad agenti come Claude o Grok Build di accedere direttamente alla sua piattaforma, secondo TechCrunch. HiBob ha fatto lo stesso pochi giorni prima con un'integrazione MCP che collega Slack al suo SIRH.
Questa adozione rapida ha un rovescio della medaglia. Più ci sono server MCP esposti pubblicamente, più la superficie di attacco cresce. La nuova spec risponde con requisiti più stringenti sulla gestione dei token e degli scope OAuth. Ma non li impone tecnicamente, documenta solo cosa un server "enterprise-ready" deve fare. Libero a ogni sviluppatore di seguire o ignorare.
Questo è il punto controintuitivo: una spec più sicura sulla carta può rendere l'ecosistema meno sicuro nel breve termine, perché dà l'illusione che il protocollo gestisca già il problema. Non lo fa. Documenta il problema e vi passa la palla.
I buchi di sicurezza che vediamo già nei deployment MCP
Tool poisoning: quando un server mente su cosa fa
Un server MCP dichiara i suoi strumenti tramite un manifesto in linguaggio naturale, una descrizione che l'agente legge per decidere quando chiamarlo. Nulla impedisce a un server malevolo, o compromesso, di dichiarare uno strumento "sola lettura" che in realtà scrive nel vostro database. L'agente si fida della descrizione, non del codice reale. È il vettore più documentato nella comunità di sicurezza MCP dall'inizio 2026.
OAuth mal configurato, il vettore numero uno
La maggior parte degli incidenti viene da una confusione classica: scope troppo ampi, token che non scadono mai, o peggio, token condivisi tra più agenti sullo stesso server. Un token MCP compromesso dà accesso a tutto ciò che lo scope autorizza, non solo alla richiesta in corso.
Assenza di sandboxing tra l'agente e il file system
Molti server MCP girano ancora in locale, con accesso disco quasi totale per semplificare lo sviluppo. Funziona benissimo fino al giorno in cui l'agente riceve un prompt malevolo iniettato tramite un documento esterno, ed esegue un comando shell che non avrebbe mai dovuto avere il diritto di lanciare.
Come sicurizzare un server MCP in produzione
Ecco cosa consigliamo concretamente, per ordine di priorità:
- Scope OAuth granulari, uno scope per strumento, mai uno scope globale "admin".
- Scadenza breve dei token, 15-60 minuti, con refresh esplicito invece di token che vivono settimane.
- Validazione del manifesto degli strumenti ad ogni chiamata, non solo al momento dell'handshake iniziale.
- Sandboxing sistematico, contenitore isolato, file system in sola lettura tranne directory dedicate.
- Log di audit per ogni chiamata di strumento, con alerting su pattern anomali (frequenza, orari, scope inusuali).
- Rate limiting lato server MCP, indipendente dal rate limiting dell'API sottostante.
Questa lista non ha nulla di rivoluzionario. È essenzialmente igiene API classica, applicata a un protocollo più giovane della maggior parte degli standard REST. La differenza è che ancora nessuno ha i riflessi automatici, perché MCP ha poco più di un anno di esistenza pubblica.
Un limite onesto da menzionare: queste misure rallentano lo sviluppo. Uno scope per strumento significa più configurazione ogni volta che si aggiunge un nuovo strumento. Se il vostro team deploy velocemente e itera su un MVP interno non esposto pubblicamente, questo livello di rigore può essere sproporzionato. Riservate lo a server esposti a terzi o che manipolano dati sensibili.
MCP vs API REST classica: sicurezza a confronto
| Criterio | API REST classica | Server MCP |
|---|---|---|
| Autenticazione | OAuth 2.0 / API key, standard maturo | OAuth integrato nella spec, ma implementazione variabile |
| Scoperta delle capacità | Documentazione statica (OpenAPI) | Manifesto dinamico letto dall'agente a runtime |
| Superficie di attacco | Endpoint noti, fissi | Strumenti dichiarati dinamicamente, quindi più difficili da controllare |
| Controllo di accesso | Ruoli e permessi ben consolidati | Scope ancora poco granulari in pratica |
| Maturità dell'ecosistema | 15+ anni di pattern provati | Meno di due anni, best practice ancora in evoluzione |
La tabella parla da sola: MCP non è meno sicuro di un'API REST, ma l'ecosistema di tool, scanner e buone pratiche non ha ancora raggiunto il livello. Arriverà. Nel frattempo, tocca a voi compensare.
Quello che stanno già facendo i grandi attori
Anthropic ha evoluto il suo modello Claude verso Sonnet 5 fine giugno 2026, in sostituzione di Sonnet 4.6 uscito a febbraio, secondo 9to5Mac. Un modello più capace pone meccanicamente più rischi sul fronte agentiche: più l'agente è autonomo nelle sue decisioni, più una falla MCP a monte ha conseguenze a valle. X ha scelto di esporre un server MCP pubblico per permettere ad agenti come Claude o Cursor di interagire direttamente con la sua piattaforma, una scelta che presuppone una governance dei token particolarmente rigorosa vista la scala. HiBob, dal canto suo, ha optato per un'integrazione più chiusa, collegando il suo SIRH a Slack via MCP piuttosto che esporre un server aperto a qualsiasi client.
Due filosofie, due livelli di rischio. Se il vostro e-commerce Shopify o il vostro SaaS interno sta considerando di esporre un server MCP, la domanda da farsi prima: avete davvero bisogno di un accesso aperto, o un accesso chiuso ai vostri soli agenti basta?
Conclusione
Tre punti da ricordare. Primo, la nuova spec MCP non sicurizza automaticamente i vostri deployment, documenta i requisiti che dovete implementare voi stessi. Secondo, i buchi più frequenti restano classici: scope troppo ampi, token che non scadono, sandboxing assente. Infine, il rigore ha un costo in velocità, da riservare ai server realmente esposti.
Se state già esponendo un agente IA connesso al vostro stack via MCP, o se siete ancora incerti tra una soluzione no-code e un'implementazione custom, abbiamo dettagliato i trade-off in No-code vs code per costruire un agente IA. Avete bisogno di un audit di sicurezza sul vostro server MCP prima del deploy in produzione? Contattateci su fstck.co.
Domande frequenti
Come faccio a sapere se il mio server MCP è vulnerabile al tool poisoning?
Verificate che il manifesto dichiarato da ogni strumento corrisponda esattamente al suo comportamento reale in produzione, non solo alla documentazione. Un audit semplice: loggate ogni chiamata di strumento e comparate l'azione reale (scrittura, lettura, chiamata esterna) con la descrizione annunciata nel manifesto.
Devo aspettare che MCP maturi prima di deployarlo in produzione?
No, ma dovete adattare il livello di rigore all'esposizione reale del server. Un server MCP interno, accessibile solo dai vostri propri agenti su una rete privata, tollera meno vincoli di un server esposto pubblicamente a client terzi.
Qual è la differenza tra gli scope OAuth di un'API REST e quelli di un server MCP?
Il principio è identico, limitare l'accesso a ciò che è strettamente necessario, ma la spec MCP incoraggia uno scope per strumento piuttosto che uno scope per risorsa. In pratica, molte implementazioni attuali restano ancora troppo permissive per mancanza di tool maturi per gestire questa granularità facilmente.
Un token MCP compromesso dà accesso a tutti gli strumenti del server?
Dipende interamente dalla configurazione degli scope. Se il token ha uno scope globale, sì, l'attaccante recupera tutto ciò che quello scope autorizza. Per questo la granularità degli scope non è un dettaglio opzionale, ma la prima linea di difesa.
MCP è più rischioso di un'integrazione API classica?
Non intrinsecamente più rischioso, ma meno maturo in termini di tool di audit e buone pratiche standardizzate. La scoperta dinamica delle capacità, che è il punto di forza di MCP, complica anche l'analisi statica di sicurezza che si fa facilmente su un'API REST documentata in OpenAPI.
