Risultati principali
Il 28 luglio 2026, il protocollo MCP (Model Context Protocol) è passato ufficialmente ad un'architettura aziendale di tipo stateless.
Spostandosi verso un modello stateless e introducendo app dell'interfaccia utente complete e attività asincrone, ora il protocollo passa la responsabilità di creare confini critici per la sicurezza interamente agli sviluppatori.
L'aggiornamento elimina i principali rischi storici per la sicurezza, tra cui hijacking delle sessioni a livello di protocollo, prompt dei server non richiesti e metodi di autenticazione deboli.
Tuttavia, l'introduzione di uno stato gestito dall'applicazione, di interfacce AI interattive complete e di attività asincrone di lunga durata, crea nuovi percorsi per eventuali abusi.
Se non adeguatamente protette, queste nuove funzionalità potrebbero consentire l'accesso non autorizzato ai dati dei clienti, il phishing mirato agli utenti attraverso experience AI affidabili, l'elusione dei controlli di sicurezza aziendali e l'interruzione dei servizi tramite l'abuso dei workflow di elaborazione in background.
La nuova specifica MCP 2026-07-28 rappresenta l'evoluzione architettonica più significativa del protocollo MCP (Model Context Protocol) sin dai suoi esordi. Ciò che è iniziato come strumento di integrazione dell'intelligenza artificiale per singolo utente a livello locale si sta trasformando in una piattaforma in grado di supportare implementazioni cloud-native su scala aziendale.
Dopo la pubblicazione della release avvenuta il 21 maggio 2026, la specifica finale è stata rilasciata il 28 luglio 2026, a cui segue un periodo di obsolescenza formale della funzionalità legacy della durata di 12 mesi.
L'evoluzione della superficie di attacco
Per creare questa base per le aziende, l'aggiornamento ripercorre completamente il modo con cui il protocollo gestisce i dati e l'esecuzione, introducendo un'architettura stateless supportata da richieste multi-roundtrip, nuove intestazioni HTTP standardizzate e un oggetto _meta universale per la messaggistica contestuale. Inoltre, la specifica formalizza le app e le attività asincrone del protocollo MCP, elevando, al contempo, l'integrazione OAuth a livelli eccellenti.
Mentre gran parte della discussione su queste caratteristiche si concentra sulla scalabilità e sull'interoperabilità, il loro impatto strutturale sulla superficie di attacco del protocollo è altrettanto importante. Man mano che cambia il modello di sicurezza, alcuni rischi a livello di protocollo di lunga data vengono mitigati o rimossi del tutto, mentre le nuove responsabilità si trasferiscono direttamente agli sviluppatori di applicazioni MCP (Figura 1). In ultima analisi, mentre questi cambiamenti migliorano le basi, le scelte effettuate in termini di implementazione ora dettano l'approccio generale alla sicurezza.
Superfici di attacco ridotte o eliminate
Le versioni precedenti del protocollo MCP hanno esposto diversi rischi per la sicurezza tramite sessioni gestite dal protocollo, comunicazioni avviate dal server e requisiti di autenticazione meno maturi. La nuova specifica riprogetta o rimuove molti di questi meccanismi, riducendo la superficie di attacco al livello del protocollo. Tali meccanismi includono:
Hijacking delle sessioni al livello del protocollo
Prompt del server non richiesti
Metodi di autenticazione deboli
Hijacking delle sessioni al livello del protocollo
Le versioni precedenti del protocollo MCP si basavano su un processo di inizializzazione stateful che stabiliva una sessione di lunga durata utilizzando l'intestazione Mcp-Session-Id. Questi identificatori di sessione sono generalmente obiettivi di alto valore perché i criminali che li sfruttano possono impersonificare gli utenti autenticati.
La nuova specifica rimuove completamente queste sessioni gestite dal protocollo, eliminando questo specifico vettore di attacco. Tuttavia, gli sviluppatori devono ora creare propri meccanismi di gestione dello stato sicuro (che esamineremo più avanti in questo post del blog).
Prompt del server non richiesti
Le versioni precedenti del protocollo MCP consentivano ai server di inviare richieste o prompt imprevisti ai client in momenti arbitrari tramite eventi SSE (Server-Sent Event).
Le nuove regole limitano rigorosamente questo comportamento, impedendo ai server compromessi di interrompere in modo invisibile gli utenti con interazioni impreviste e dannose.
Metodi di autenticazione deboli
L'aggiornamento impone il passaggio a rigorosi requisiti OAuth 2.1, riducendo drasticamente i rischi di autenticazione. Eliminando le password legacy e le concessioni implicite e imponendo sistemi di protezione moderni come la chiave PKCE (Proof Key for Code Exchange), il protocollo limita notevolmente il modo con cui le credenziali e i token possono essere esfiltrati o sfruttati
Nell'insieme, queste modifiche riducono drasticamente la superficie di attacco e il raggio d'azione delle sessioni correlate all'autenticazione che erano presenti nelle precedenti implementazioni del protocollo MCP.
Le nuove superfici di attacco introdotte dalla specifica
Sebbene il protocollo abbia eliminato diverse vulnerabilità, ha tuttavia introdotto anche nuove aree in cui la sicurezza dipende fortemente dalla qualità dell'implementazione, tra cui:
Hijacking del workflow tra gli agenti
Manipolazione dei metadati controllata dal client
Confusione dell'intestazione ed esposizione dei dati tramite le intestazioni
App MCP e attacchi XSS (Cross-Site Scripting) archiviati
Sfruttamento dei rischi nelle attività di background a lungo termine
Hijacking del workflow tra gli agenti
La tendenza verso un'architettura statelessness introduce piccole sfide in termini di sicurezza. Negli ambienti aziendali, le interazioni dell'intelligenza artificiale non sono sempre una semplice conversazione a richiesta singola, ma spesso richiedono una catena sequenziale di eventi, ad esempio:
Richiesta di chiarimenti: uno strumento potrebbe mettersi in pausa durante l'attività per chiedere all'utente dettagli mancanti
Verifica dell'avanzamento: un lavoro lungo potrebbe richiedere regolarmente aggiornamenti da parte del sistema
Sospensione dei workflow: un processo complesso potrebbe interrompersi per un'ora in attesa dell'approvazione da parte dell'uomo, quindi riprendere l'esecuzione dallo stato precedente
Poiché il nuovo MCP non è stateless, non utilizza sessioni permanenti per ricordare chi sono le parti coinvolte, ma, al contrario, introduce identificatori di tracciamento e oggetti di stato che il server fornisce al client. Il client quindi restituisce queste informazioni ogni volta che è pronto a riprendere il flusso di esecuzione, offrendo praticamente al client il pieno controllo sullo stato dell'attività.
Il problema in termini di sicurezza è semplice: poiché gli ID di tracciamento e gli oggetti di stato provengono direttamente dal client, il server non può fare affidamento su di essi. La Figura 2 illustra il caso in cui un server MCP utilizza ID di tracciamento prevedibili o non riesce a verificare in modo rigoroso l'integrità dell'oggetto di stato ricevuto, pertanto un criminale potrebbe indovinare o modificare questi valori per:
Eseguire l'hijacking del workflow attivo di un altro utente
Accedere alle informazioni appartenenti a un altro agente
Attivare azioni non autorizzate cross-tenant
Mentre la specifica MCP ufficiale richiede esplicitamente agli sviluppatori di verificare l'integrità di questi oggetti, non dispone di uno standard o di un'implementazione specifici, pertanto lascia l'onere di creare questo livello di sicurezza esclusivamente agli sviluppatori dei singoli server.
Manipolazione dei metadati controllata dal client
La nuova specifica introduce un oggetto _meta che consente ai client di allegare metadati personalizzati praticamente a qualsiasi messaggio MCP. Anche in una semplice richiesta, un criminale potrebbe fornire coppie di valori chiave dannosi, come {"tenant": "admin", "authenticated": true}.
Poiché questi campi non dispongono di una firma crittografica, se un server utilizza in modo intelligente questi metadati per decisioni di instradamento o autorizzazione, una singola richiesta dannosa potrebbe portare immediatamente all'escalation dei privilegi o all'accesso ai dati cross-tenant.
Confusione dell'intestazione ed esposizione dei dati tramite le intestazioni
La specifica introduce intestazioni HTTP specifiche per il protocollo MCP, come Mcp-Method e Mcp-Name, che aiutano intermediari, proxy, gateway e server a comprendere in modo coerente le richieste MCP e a instradarle correttamente.
Tuttavia, queste intestazioni introducono anche due nuovi rischi per la sicurezza:
Attacchi di confusione (desincronizzazione) del protocollo: i criminali possono inviare valori contrastanti tra le intestazioni HTTP e il corpo delle richieste JSON-RPC, sfruttando un disaccordo tra due diversi protocolli di comunicazione (HTTP e JSON-RPC), per eliminare la sincronizzazione dell'infrastruttura di back-end. Questa incoerenza può indurre proxy e server di back-end ad interpretare la stessa richiesta in modo diverso, consentendo ai criminali di bypassare i controlli di sicurezza, eludere il monitoraggio o mascherare azioni dannose.
Fughe di dati tramite x-mcp-header: questa nuova direttiva consente agli sviluppatori di mappare argomenti di strumenti specifici direttamente nelle intestazioni HTTP. Ciò consente ai proxy di instradare il traffico più velocemente senza analizzare l'intero corpo della richiesta. Tuttavia, se gli sviluppatori mappano accidentalmente input sensibili come chiavi API, token o informazioni di identificazione personale (PII), questi segreti vengono inseriti direttamente nelle intestazioni, in cui diventano visibili per tutti gli strumenti di bilanciamento del carico, i proxy e i sistemi di registrazione che si trovano lungo il percorso.
App MCP e attacchi XSS (Cross-Site Scripting) archiviati
Uno degli aggiornamenti più interessanti del protocollo MCP è il passaggio delle app MCP a un'estensione di protocollo di prima classe. Le app MCP sono i pannelli visivi interattivi che si vedono all'interno di applicazioni basate sull'intelligenza artificiale come Claude Desktop (ad esempio, moduli interattivi e dashboard, visualizzatori di documenti, schermate di monitracciamento dei workflow e delle attività).
Sebbene queste interfacce avanzate migliorino notevolmente le user experience, comportano anche i rischi tradizionalmente legati ai browser web, come gli attacchi XSS (Cross-Site Scripting) archiviati nell'ecosistema dell'intelligenza artificiale. Ad esempio, un criminale può archiviare codici HTML o JavaScript tramite uno strumento MCP. Quando un altro utente (o un agente AI) visualizza questi contenuti, lo script dannoso viene eseguito automaticamente all'interno dell'interfaccia dell'app.
Mentre la specifica MCP richiede agli agenti di eseguire questi script all'interno di un <iframe> con sandbox per impedire ai criminali di assumere completamente il controllo dell'agente AI, gli utenti sono ancora a rischio. I criminali possono comunque utilizzare il pannello compromesso per visualizzare contenuti ingannevoli, eseguire campagne di phishing per informazioni sensibili con messaggi fittizi, sottrarre i dati degli utenti attualmente visibili all'interno di quel riquadro specifico e inviare le informazioni rubate ai propri server (Figura 3).
Sfruttamento dei rischi nelle attività di background a lungo termine
L'introduzione di attività di lunga durata crea un enorme vettore di attacchi DoS (Denial-of-Service) che si basa su interazioni unidirezionali. Poiché la creazione di attività è un'operazione economica per il client, ma richiede risorse elevate per il server, un criminale può inviare una singola richiesta per generare un'operazione costosa (consumo di storage di CPU, memoria o database) e disconnettersi immediatamente.
Questo metodo di sfruttamento asincrono unidirezionale obbliga il server a elaborare carichi di lavoro pesanti anche dopo la disconnessione del client, esaurendo facilmente le risorse del server.
Conclusione
La specifica MCP 2026-07-28 segna la transizione del protocollo dall'uso locale all'implementazione su scala aziendale. Dal punto di vista della sicurezza, le modifiche non sono semplicemente miglioramenti incrementali che ridefiniscono fondamentalmente le responsabilità in termini di sicurezza: le decisioni relative alla sicurezza precedentemente applicate dal protocollo sono sempre più delegate agli sviluppatori di server e agli operatori di piattaforme MCP.
Man mano che l'adozione del protocollo MCP accelera negli ambienti cloud, la domanda più importante in termini di sicurezza non è più se il protocollo è sicuro. I team addetti alla sicurezza devono invece stabilire se le applicazioni basate sul protocollo implementano correttamente i nuovi limiti di affidabilità, i meccanismi di gestione dello stato e i modelli di esecuzione introdotti dalla specifica.
Per proteggere correttamente queste nuove superfici di attacco, i team addetti alla sicurezza devono considerare tutti i dati di stato e i metadati forniti dal client come input non attendibili applicando una rigorosa verifica crittografica, la codifica dell'output per i pannelli visivi generati dall'intelligenza artificiale e un elevato numero di risorse per le attività asincrone.
Per affrontare questa svolta, è necessario adottare un'architettura di difesa proattiva in grado di bloccare gli exploit prima che raggiungano l'infrastruttura di back-end.
Agisci subito
Akamai consente alle organizzazioni di agire subito. Sfruttando la nostra piattaforma per la sicurezza di applicazioni e API sull'edge e ampliandola con l'intelligence basata sul protocollo MCP, Akamai aiuta i team a identificare le nuove aree in cui viene utilizzato il protocollo MCP, applicare barriere di protezione pratiche durante la sperimentazione e gestire i rischi man mano che l'esposizione aumenta.
Questo approccio consente alle organizzazioni di adottare subito il protocollo MCP, affidandosi ad Akamai per migliorare la protezione, la visibilità e il controllo man mano che si sviluppa l'uso di questo protocollo.
Tag