MCP ha pubblicato una specifica stabile di “Enterprise-Managed Authorization”; gli altri draft per l'identità machine-to-machine — inclusi un draft OAuth client-credentials e due proposte aperte — rimangono incompleti. Per chiunque cerchi di eseguire agenti autonomi con il Model Context Protocol, ciò significa che l'attuale protocollo può verificare un utente umano, ma non offre un modo pronto all'uso per dimostrare che un processo non supervisionato sia chi afferma di essere.
Perché la roadmap è importante
La roadmap del Model Context Protocol (MCP) elenca l'identità e la sicurezza degli agenti tra le sue massime priorità. Quattro elementi erano previsti per il rilascio: un flusso browser incentrato sull'uomo, un flusso OAuth client-credentials per i servizi, un token binding basato su DPoP e un meccanismo di federazione dell'identità del workload (workload-identity federation). Solo il primo — Enterprise-Managed Authorization — ha raggiunto lo stato stabile.
Cosa fa effettivamente la specifica stabile
Enterprise-Managed Authorization consente agli amministratori IT di concedere l'accesso al server da un'unica console, invece di richiedere a ogni dipendente di approvare ogni singola connessione. Il flusso utilizza un reindirizzamento del browser e un login dell'utente, quindi una persona su un laptop può autenticarsi e, successivamente, il server si fida della sessione di quell'utente.
Il limite è evidente: il processo richiede un essere umano alla tastiera. Un agente che gira durante la notte, elabora dati o risponde ad avvisi non ha nessuno che possa cliccare su un pulsante di login. Di conseguenza, qualsiasi implementazione che dipenda da agenti non supervisionati non può utilizzare l'unica specifica che MCP garantisce attualmente.
Le opzioni in fase di draft e i loro svantaggi
Due estensioni in fase di draft mirano a fornire agli agenti una propria identità:
- SEP-1932 (DPoP) – lega i token a una coppia di chiavi pubblica-privata, rendendo inutili i token rubati.
- SEP-1933 (Workload Identity Federation) – consente agli agenti di ereditare identità già provisionate nelle piattaforme cloud.
Entrambi sono presenti come pull request aperte; nessuna delle due è stata integrata nella specifica ufficiale. Nel frattempo, l'unica altra opzione documentata è un flusso OAuth client-credentials che richiede segreti pre-registrati. Memorizzare tali segreti in un luogo accessibile a un agente crea una classica superficie di attacco: se il segreto viene compromesso, qualsiasi attaccante può impersonare l'agente.
Passaggi pratici per la produzione oggi
Poiché il protocollo non fornisce ancora un'identità nativa per gli agenti, i team possono comunque proteggere gli agenti spostando la gestione dell'identità al di fuori di MCP:
- Emettere identità verificabili a livello di workload. Sistemi come SPIRE generano certificati a breve durata legati alla root di fiducia dell'host, eliminando i segreti statici.
- Terminare le credenziali presso un gateway. Un servizio front-end detiene la chiave API o il token e inoltra le richieste per conto dell'agente, mantenendo il segreto al di fuori dell'ambiente di runtime.
- Autorizzare in base all'identità verificata, non al contenuto del token. Separare l'autenticazione (chi sta chiamando) dall'autorizzazione (cosa può fare) in modo che le policy possano essere applicate anche se il metodo di autenticazione cambia.
Cosa monitorare in seguito
Le due pull request aperte — DPoP binding e workload-identity federation — sono le uniche strade verso un vero standard di identità machine-to-machine all'interno di MCP. Se la community le integrerà, gli agenti saranno in grado di dimostrare il possesso di una chiave privata o di ereditare identità rilasciate dal cloud senza esporre segreti. Fino ad allora, qualsiasi implementazione in produzione dovrà affidarsi a framework di identità esterni o accettare il rischio di utilizzare credenziali statiche.
La conclusione è chiara: MCP può attualmente autenticare la persona dietro una richiesta, ma non autentica ancora il software che effettua la richiesta. I team che necessitano di agenti autonomi sicuri non dovrebbero aspettare il rilascio della specifica; devono costruire l'identità a livello di workload oggi stesso e tenere d'occhio le proposte in sospeso per DPoP e la federazione.