Roadmap MCP 2026: sicurezza enterprise e trasporto HTTP-native

Il 22 agosto 2026 i Core Maintainers del Model Context Protocol hanno pubblicato la roadmap 2026 del Model Context Protocol, annunciata sul blog ufficiale del progetto: il documento che indica dove andrà il protocollo nei prossimi sei-dodici mesi. Non è un annuncio di prodotto: è la lista delle cose che verranno sistemate prima che MCP possa considerarsi davvero adatto alla produzione aziendale. Due delle cinque aree prioritarie riguardano esattamente i problemi che oggi bloccano un’azienda quando prova a portare un agente AI oltre il proof of concept: chi è l’agente che chiama, e come parla con i sistemi.

In questo articolo scoprirai:

• Cosa dice la roadmap MCP 2026 e perché arriva proprio adesso
• Identità degli agenti: il punto in cui l'autorizzazione MCP si rompe
• Un solo trasporto: HTTP-native anche per i server MCP locali
• Messaggistica agentica, primitivi e SDK: cosa cambia per chi sviluppa
• Cosa fare oggi se stai scegliendo lo stack per gli agenti AI

Cosa dice la roadmap MCP 2026 e perché arriva proprio adesso

La roadmap ufficiale organizza il lavoro in cinque aree prioritarie: primitive di messaggistica agentica, unificazione e hardening del trasporto HTTP-native, identità degli agenti e sicurezza enterprise, primitivi migliorati, developer experience degli SDK. Il meccanismo è esplicito e vale la pena capirlo: le Specification Enhancement Proposal (SEP) che rientrano in queste aree ottengono revisione accelerata e la probabilità più alta di accettazione, mentre le altre «non vengono rifiutate automaticamente, ma aspettatevi una coda più lunga e un’asticella più alta». In altre parole, la roadmap non descrive solo il futuro: lo alloca.

Il documento arriva dopo la release 2026-07-28, quella che ha reso il core del protocollo stateless, abbiamo raccontato quel passaggio in dettaglio nell’analisi della specifica MCP stateless. Il tempismo non è casuale. Secondo i dati raccolti da Toloka, a marzo 2026 esistevano oltre 9.400 server MCP pubblici, con i server privati stimati conservativamente a 3-4 volte quel numero, e gli SDK viaggiavano a 97 milioni di download mensili, +4.750% in sedici mesi. Il protocollo è già ovunque; quello che manca è l’infrastruttura di garanzie che un reparto IT chiede prima di firmare.

Il divario si vede nei numeri di adozione raccolti nella stessa analisi di Toloka: l’80% delle applicazioni enterprise rilasciate nel Q1 2026 include almeno un agente AI (era il 33% nel 2024), ma solo il 17% delle organizzazioni ha agenti AI pienamente in produzione, mentre oltre il 60% conta di arrivarci entro due anni. Fra intenzione e messa a terra ci sono decine di punti percentuali, e la roadmap è la mappa di cosa li causa.

Identità degli agenti: il punto in cui l’autorizzazione MCP si rompe

È l’area più importante per chi deve mettere un agente in produzione, e i maintainer la descrivono senza giri di parole: «l’autorizzazione MCP presuppone una persona con un browser al momento del consenso». Nella realtà chi chiama è sempre più spesso un carico di lavoro cloud con un’identità propria, che agisce per conto di un utente che non è presente, o che genera sotto-agenti a cui dovrebbe toccare un’autorità più stretta di quella del genitore. Il risultato, oggi, è che i server MCP esistenti si reggono su API key incollate e refresh token a vita lunga, la peggiore combinazione possibile in un contesto regolamentato.

DPoP e workload identity nella roadmap MCP 2026

La risposta della roadmap non è inventare uno standard nuovo, ed è la scelta giusta: adotta quelli che esistono. Il primo pezzo è DPoP, il meccanismo descritto dalla RFC 9449 (Proposed Standard IETF, settembre 2023), che lega il token a una coppia di chiavi asimmetriche invece di lasciarlo utilizzabile da chiunque lo possieda: l’RFC dice che così «i token esfiltrati diventano da soli inutilizzabili». Un token bearer rubato è un accesso; un token DPoP rubato senza la chiave privata non è niente. Accanto a DPoP la roadmap mette Workload Identity Federation (SEP-1933), l’Identity Assertion JWT Authorization Grant usato dall’estensione Enterprise-Managed Authorization e il token exchange della RFC 8693, coordinandosi con i working group IETF OAuth e WIMSE.

C’è anche un tema che vale la pena tenere d’occhio: l’attestazione di presenza umana, cioè distinguere un client interattivo da un agente headless. È esattamente la distinzione su cui si gioca la superficie di attacco di un sistema agentico, un tema che tocchiamo anche parlando di prompt injection negli agenti AI aziendali e del fatto che il modello da solo non basta a rendere sicuro un agente.

Un solo trasporto: HTTP-native anche per i server MCP locali

La seconda area ad alto impatto è meno appariscente ma cambia i costi di gestione. Con la 2026-07-28 il core del protocollo è diventato stateless, sessioni e handshake fuori dal protocollo, richieste che possono atterrare su qualsiasi istanza, e abbiamo analizzato quel passaggio nel dettaglio nel pezzo sulla specifica 2026-07-28. Il punto da tenere qui è la conseguenza operativa che ne deriva, sintetizzata da Obot: «un server MCP remoto non è più diverso da qualsiasi altro carico di lavoro HTTP». Si ospita, si scala e si osserva con gli strumenti che l’azienda ha già. Ma questo vale solo per i server remoti, ed è precisamente il buco che la roadmap vuole chiudere adesso.

HTTP su stdio: un binding unico anche per i server MCP locali

Il problema che la roadmap mette in cima è la doppia pipeline. Ogni funzionalità HTTP-native oggi richiede un secondo design specifico per stdio, gli SDK mantengono due percorsi di trasporto e i metadati di protocollo sono duplicati fra header HTTP e campi del messaggio, con i server costretti a validarli in croce. La proposta è HTTP su stdio: Streamable HTTP come binding unico, parlato su stdin/stdout per i server locali, usando HTTP/2 per ottenere multiplexing mantenendo le garanzie di sicurezza e ciclo di vita di un sottoprocesso. Tradotto: un solo modello di trasporto da imparare, da implementare negli SDK e da mettere in sicurezza, invece di due che divergono a ogni release, e la fine della situazione per cui una feature esiste sul remoto e arriva sul locale sei mesi dopo, o non arriva.

Nella stessa area c’è il caching, che è la voce con l’effetto più diretto sulla bolletta: dopo l’introduzione di ttlMs e cacheScope con la SEP-2549, il lavoro punta agli ETag per versionare i risultati dei primitivi, incluse le tool call. Chi ha già letto la nostra guida su cos’è un MCP Server e cosa serve per usarlo in azienda riconoscerà il tema: la differenza fra un’integrazione che regge e una che costa troppo sta quasi sempre lì.

Messaggistica agentica, primitivi e SDK: cosa cambia per chi sviluppa

Le altre tre aree sono più tecniche ma non meno rilevanti. La prima riconosce che i carichi agentici hanno bisogno di schemi di messaggistica oltre richiesta-risposta: lavori che durano minuti, server che spingono dati, risultati in streaming, la possibilità di correggere il tiro a metà esecuzione. MCP ha accumulato più concetti per questo, Tasks (SEP-2663), subscriptions/listen, le notifiche di progresso, sparsi fra working group diversi, e i maintainer nominano il rischio con onestà rara: tre risposte diverse alla domanda «il server non ha ancora finito», senza un ciclo di vita, un modello di cancellazione e una superficie d’errore condivisi. Il lavoro di questo ciclo è una revisione di composizione, più eventi iniziati dal server (canali, sottoscrizioni, webhook) per evitare il polling costoso lato client.

Primitivi MCP e progressive discovery dei tool

Sui primitivi il problema è più circoscritto e più fastidioso: tools/call permette di restituire content e structuredContent insieme, cosa che «ha confuso autori di server e di client e ha prodotto implementazioni divergenti». Verrà ridisegnata la forma del risultato. Parte inoltre un lavoro su progressive discovery, perché i client imparino tool e risorse man mano che servono invece di ingerire tutto il catalogo all’avvio: è la risposta al server con centinaia di tool, uno scenario ordinario in azienda quando si collegano ERP e CRM, come raccontiamo parlando di integrazione di agenti AI con sistemi legacy.

L’area SDK, infine, punta a generare SDK ed esempi dalla specifica, validandoli contro una suite di conformance, «così che vengano rigenerati e rivalidati a ogni release invece di essere riparati dopo».

Cosa fare oggi se stai scegliendo lo stack per gli agenti AI

La lezione pratica di questo documento è che la roadmap va letta prima di scegliere lo stack, non dopo. Sapere che il trasporto converge su HTTP e che l’identità degli agenti si baserà su standard IETF già esistenti (DPoP, token exchange, WIF) permette di fare oggi scelte che fra sei mesi non andranno rifatte. Vale anche il contrario: costruire ora sull’API Tasks sperimentale significa mettere in conto una migrazione, perché la riprogettazione stateless l’ha cambiata. E i gap che il protocollo non copre ancora, audit trail standardizzati, multi-tenancy, rate limiting, comportamento dei gateway, restano responsabilità di chi implementa: è il capitolo che The New Stack riassume sotto la voce enterprise readiness.

Roadmap MCP 2026 e migrazioni: perché i progetti agentici si fermano

È qui che si spiega un dato altrimenti sorprendente: secondo una stima Gartner ripresa nell’analisi di Toloka, oltre il 40% dei progetti di AI agentica potrebbe essere cancellato entro il 2027 per valore poco chiaro, costi crescenti e governance debole. Non è un problema di modelli, è un problema di adozione fatta senza accompagnamento, lo stesso motivo per cui sosteniamo che nell’AI agent enterprise il servizio conta più del modello. Un protocollo che cambia due volte l’anno non è un rischio se qualcuno traduce ogni update in un piano di migrazione; lo diventa se la traduzione la deve fare da sola l’IT interna fra un ticket e l’altro.

È esattamente il punto in cui lavoriamo con Mimir: non consegniamo un agente e auguriamo buona fortuna, ma affianchiamo le aziende nell’onboarding, capire quali processi meritano davvero un agente, collegarlo agli strumenti reali con le garanzie di identità e autorizzazione che servono, e mantenere l’integrazione allineata quando la specifica si muove. Se stai valutando il passaggio dai POC MCP a un’integrazione in produzione, o vuoi semplicemente capire se il tuo caso regge, puoi parlarne con noi su mimir.bot: una consulenza iniziale serve soprattutto a decidere cosa non costruire. Per approfondire il quadro tecnico resta utile il nostro pezzo su come collegare agenti AI ai sistemi aziendali con MCP.

Fonti:

• The New MCP Roadmap — Model Context Protocol Blog
• Roadmap — Model Context Protocol (documentazione ufficiale)
• RFC 9449 — OAuth 2.0 Demonstrating Proof of Possession (DPoP), IETF
• MCP’s biggest growing pains for production use — The New Stack
• MCP is growing up: the 2026 roadmap takes shape — Obot
• The future of MCP: 2026 roadmap, enterprise adoption — Toloka AI