La revisione del Model Context Protocol pubblicata il 28 luglio 2026 modifica profondamente il modo in cui client e server MCP gestiscono stato, autorizzazione e interfacce applicative. È il più ampio aggiornamento del protocollo dalla sua introduzione e, già entro la fine del primo giorno, tutti e quattro gli SDK Tier 1 supportavano la nuova versione. Anche l’Agents SDK di Cloudflare era compatibile fin dal lancio, con servizi come Sentry e Linear tra i primi utilizzatori. La specifica introduce un core stateless progettato per funzionare più facilmente su normali infrastrutture HTTP, un sistema di autorizzazione basato nativamente su OAuth, interfacce renderizzate dal server attraverso MCP Apps e una nuova gestione dello stato che non dipende più dalla sessione persistente tra un client e una specifica istanza server. Il cambiamento migliora scalabilità, bilanciamento del carico e distribuzione degli agenti, ma trasferisce una parte rilevante dei controlli di sicurezza verso gateway, endpoint e applicazioni che implementano MCP.
Nel precedente modello, una sessione poteva rappresentare il principale contesto attraverso cui associare un client a un server e applicare determinate verifiche. La nuova specifica elimina invece l’header Mcp-Session-Id e gli handshake initialize/initialized che collegavano un client a una particolare istanza. Informazioni come versione del protocollo, caratteristiche del client e capability vengono ora trasmesse direttamente all’interno di ogni richiesta, permettendo a qualsiasi istanza disponibile di elaborarla. Questa architettura rende possibile utilizzare più facilmente round-robin load balancing e autoscaling, ma significa anche che una decisione di sicurezza presa soltanto all’inizio della sessione non è più sufficiente: identità, autorizzazioni, scope e validità dello stato devono essere controllati nuovamente a livello di singola richiesta.
La gestione dello stato viene affidata anche a portable state handles, identificatori che possono essere trasferiti esplicitamente tra differenti chiamate agli strumenti. Dal punto di vista operativo questi handle permettono di mantenere continuità tra operazioni senza richiedere una connessione persistente al medesimo server, ma diventano contemporaneamente oggetti sensibili. Un handle è infatti una stringa che può comparire nel contesto elaborato dall’agente e, se viene recuperata o inserita attraverso un contenuto controllato da un attaccante, può essere utilizzata come credenziale valida. Un payload di prompt injection incorporato, per esempio, in un ticket Jira, in un documento recuperato dal sistema oppure nella risposta di un tool può introdurre nel flusso dell’agente un handle controllato o permettere di esporne uno già valido. L’attacco non richiede necessariamente di compromettere direttamente il server MCP: sfrutta il fatto che il modello legge e utilizza informazioni provenienti da sorgenti esterne e che lo stato è ora trasportabile tra chiamate.
La conseguenza è un possibile handle hijacking. Se il server accetta l’handle senza verificare che l’identità che lo presenta coincida con quella alla quale era stato originariamente assegnato, un agente può utilizzare uno stato appartenente a un’altra identità o a un differente contesto operativo. La prompt injection rappresenta in questo caso il meccanismo con cui il valore viene inserito o sottratto, mentre la vulnerabilità effettiva nasce dalla mancata validazione dell’handle a ogni richiesta. La protezione non può quindi limitarsi a filtrare i prompt: l’endpoint deve considerare gli handle input non affidabili, associarli a identità e scope precisi e controllare ogni volta che il soggetto che li presenta sia autorizzato a utilizzarli. Anche gli output degli strumenti e i documenti recuperati dall’agente devono essere trattati come possibili vettori di istruzioni ostili, perché sono proprio questi contenuti a poter introdurre handle o comandi nel contesto conversazionale.
Un secondo cambiamento riguarda MCP Apps, che consente ai server di fornire HTML interattivo direttamente al client AI. L’interfaccia viene visualizzata all’interno di un iframe sandboxed, permettendo agli strumenti MCP di offrire UI più ricche senza obbligare il client a realizzarle autonomamente. Questo meccanismo introduce però nell’ecosistema agentico una classe di vulnerabilità già conosciuta nel web tradizionale: lo stored cross-site scripting. Un attaccante potrebbe memorizzare HTML o JavaScript malevolo attraverso un tool MCP e fare in modo che il contenuto venga successivamente visualizzato dall’agente o da un altro utente. La sandbox limita ciò che lo script può fare direttamente, ma il contesto nel quale viene renderizzato è particolarmente sensibile, perché il client AI può essere contemporaneamente collegato a codice sorgente, terminali, filesystem e altri server MCP. La sicurezza delle UI generate dai server deve quindi essere gestita anche sull’endpoint e sull’IDE, verificando quali server possono produrre HTML e sottoponendo quel contenuto a controlli analoghi a quelli utilizzati per script esterni nelle normali applicazioni web.
La revisione introduce inoltre un modello di autorizzazione OAuth nativo. Questo semplifica l’integrazione con sistemi di identità standard, ma richiede che i token siano strettamente vincolati al server per cui sono stati emessi. Un token destinato a un determinato MCP server non dovrebbe quindi poter essere riutilizzato contro un altro endpoint. Per ridurre questo rischio, l’implementazione raccomandata combina OAuth 2.1 con PKCE, consenso specifico per ciascun client, controllo rigoroso dei redirect URI e audience-bound tokens. Un gateway identity-aware dovrebbe essere posto davanti ai server MCP e rifiutare ogni richiesta che non presenti un token valido per quella specifica audience. L’autenticazione iniziale da sola non è più sufficiente, perché il protocollo stateless richiede che l’autorizzazione venga verificata su ogni singola chiamata.
Anche la Tasks extension, introdotta per consentire agli agenti di avviare operazioni asincrone e di lunga durata, risente dello stesso cambiamento. In assenza di una sessione persistente, la proprietà di un task non può essere determinata semplicemente in base alla connessione dalla quale è stato creato. Ogni attività deve invece essere associata esplicitamente all’identità e agli scope autorizzati. Un agente che recupera, modifica o continua un task deve dimostrare di avere ancora diritto ad accedere a quell’operazione, indipendentemente dal server che riceve la richiesta o dalla connessione utilizzata. Il passaggio da sicurezza basata sulla sessione a sicurezza basata sull’identità diventa quindi comune sia agli handle sia ai processi asincroni.
La modifica del protocollo rende inoltre meno visibili alcuni attacchi agli strumenti di sicurezza che lavorano prevalentemente a livello di rete. Poiché lo stato viene trasferito nel livello applicativo e parte dell’elaborazione avviene direttamente all’interno del client o dell’IDE, un gateway di rete può verificare autenticazione e richieste ma non necessariamente osservare cosa viene renderizzato da MCP Apps, cosa esegue un server MCP locale o quali operazioni vengono effettuate dal processo host. La visibilità deve quindi estendersi all’endpoint, includendo il processo che ospita l’agente, i server MCP locali e il rendering delle interfacce. Un’architettura basata esclusivamente sul monitoraggio del traffico di rete rischia di non intercettare proprio i passaggi nei quali una prompt injection viene trasformata in una credenziale riutilizzata o in un’azione eseguita dall’agente.
L’impatto potenziale è rilevante anche per la diffusione raggiunta dal protocollo. Gli SDK MCP Tier 1 registrano complessivamente quasi mezzo miliardo di download al mese, mentre gli SDK TypeScript e Python hanno superato ciascuno il miliardo di download complessivi. Una scansione Censys effettuata alla fine di aprile aveva inoltre individuato 12.520 servizi MCP esposti direttamente a Internet, in un protocollo che non impone autenticazione per impostazione predefinita, mentre OX Security aveva precedentemente stimato che un problema di progettazione legato al trasporto STDIO potesse interessare fino a 200.000 server. Nel maggio 2026 anche l’Artificial Intelligence Security Center della NSA aveva pubblicato indicazioni dedicate a MCP, evidenziando come la velocità di adozione stesse superando la maturità del relativo modello di sicurezza. La nuova architettura stateless non elimina questi problemi preesistenti, ma cambia il punto nel quale devono essere applicate molte delle difese.
Per le implementazioni già operative, la migrazione richiede quindi di spostare i controlli al livello delle singole chiamate. Ogni server dovrebbe verificare identità, audience e autorizzazioni per ogni richiesta, mentre gli handle devono essere trattati come dati non affidabili e vincolati esplicitamente al soggetto che li ha ricevuti. I contenuti provenienti da tool, ticket, documenti e altre sorgenti utilizzate dall’agente devono essere sottoposti a controlli per individuare istruzioni o valori inseriti artificialmente. Parallelamente è necessario censire quali server MCP siano autorizzati a inviare interfacce HTML verso client e IDE e predisporre controlli specifici sul contenuto renderizzato. La semplice esecuzione di unit test non è sufficiente a validare queste proprietà, perché problemi come contaminazione dello stato tra differenti istanze server, riutilizzo di handle tra scope diversi o contenuti UI inattesi emergono più facilmente quando server e agenti vengono testati attraverso workflow reali e modelli effettivamente incaricati di utilizzare gli strumenti.
La specifica del 28 luglio avvia infine un nuovo ciclo di deprecazione della durata di dodici mesi. Roots, sampling e logging sono stati contrassegnati come deprecati, insieme al precedente trasporto HTTP+SSE, e la loro rimozione non dovrebbe quindi avvenire prima della metà del 2027. Per i team che utilizzano MCP questo significa che la migrazione verso il nuovo protocollo non riguarda soltanto il passaggio a un core stateless o l’aggiornamento degli SDK: richiede anche di rivedere la posizione dei controlli di sicurezza, perché la sessione non rappresenta più l’unità principale su cui costruire fiducia e autorizzazione. Nel nuovo modello ogni richiesta, ogni handle, ogni task e ogni interfaccia renderizzata deve essere considerata separatamente e verificata nel punto in cui viene effettivamente utilizzata.
Questo articolo è stato redatto con il supporto di strumenti di intelligenza artificiale (AI)