MCP ha ora un modo specificato con cui un agente può autenticarsi senza un umano nel loop. SEP-1046 aggiunge il grant OAuth client_credentials al Model Context Protocol come estensione ufficiale, con private_key_jwt (client assertion JWT secondo RFC 7523) come metodo di autenticazione client raccomandato e i client secret semplici ammessi per compatibilità. È stato accettato a ottobre 2025 e nei mesi successivi è arrivato negli SDK TypeScript, Python e ora Ruby. Se fate girare agenti in un contesto enterprise, questo è il pezzo del puzzle che stavate aspettando, che ne conosceste o meno il numero di SEP.

Una confessione prima della sostanza: questo post ha rischiato di non essere scritto. Il mondo dell'AI agentica si muove abbastanza in fretta da rendere lo scriverne un problema di pianificazione a sé; SEP-1046 è rimasto nella mia cartella bozze mentre altre tre cose andavano in produzione, e ho trovato il tempo solo ora perché la sinossi di Brad Webb sui pattern di autorizzazione MCP enterprise è finita nella mia coda di lettura e ha reso il quadro abbastanza completo da valere il vostro tempo. Leggete anche il suo pezzo. Questo è il mio punto di vista più breve e più di parte su cosa conta davvero per i team enterprise.

Come una issue GitHub diventa un layer di sicurezza

Il 24 luglio 2025 Darin McAdams ha aperto la issue #1046 sul repo della specifica MCP. Il pedigree qui conta: McAdams ha passato quasi 26 anni in Amazon, l'ultimo tratto come Senior Principal Software Engineer, e ha scritto questa proposta nelle sue ultime settimane lì prima di passare all'azienda di identity security Defakto Security come Architect. La proposta è breve e chirurgica: la specifica di autorizzazione MCP originale menzionava il flusso client credentials, le revisioni successive lo hanno tolto, e la specifica è finita per tacere sullo scenario enterprise più comune in assoluto, un workload che deve chiamare un server MCP quando nessun utente finale è presente per passare da una schermata di consenso interattiva.

La proposta è stata accettata come SEP-1046 e finalizzata il 30 ottobre 2025, pubblicata come estensione MCP io.modelcontextprotocol/oauth-client-credentials anziché come modifica alla specifica core. Poi sono arrivate le implementazioni: PrivateKeyJwtProvider nell'SDK TypeScript, PrivateKeyJWTOAuthProvider nell'SDK Python e, più di recente, un commit di Koichi ITO (koic, noto per RuboCop) che aggiunge il supporto private_key_jwt all'SDK Ruby ufficiale, completo di scenario di conformance. Questa progressione, proposta, SEP accettata, implementazioni indipendenti che passano una suite di conformance condivisa, è l'aspetto di un protocollo che cresce. Due anni fa "auth MCP" voleva dire un bearer token in una variabile d'ambiente e una preghiera.

Perché le client credentials contano: gli agenti non hanno un browser

Il flusso OAuth authorization code, su cui si basa la specifica MCP di base, presuppone un umano. Qualcuno vede una schermata di consenso, si autentica presso l'identity provider e delega una fetta della propria autorità al client. Quel modello va bene per Claude Desktop che si collega al vostro CRM. Non va bene per i workload che le aziende deployano davvero: un agente di riconciliazione notturno, una pipeline CI che interroga un server MCP interno, un agente supervisore che smista lavoro ad agenti specialisti alle 3 di notte. Nessuno è sveglio per cliccare "Consenti".

Client credentials è il pattern del service account presente in ogni playbook IAM enterprise, applicato a MCP. Il workload ha la propria identità, registrata in anticipo nella vostra piattaforma di identità, e si autentica come se stesso. Nessuna sessione utente presa in prestito, nessuna automazione con browser headless che finge di essere una persona, nessun personal access token a lunga vita incollato con lo scotch in un secrets manager. L'agente è un principal di prima classe con i propri entitlement, il proprio audit trail e il proprio ciclo di vita. Se il vostro team di sicurezza ha bloccato i rollout MCP perché "gli agenti si autenticano come Dave", questa è la risposta da dargli.

private_key_jwt: il default giusto, e il suo costo

SEP-1046 limita deliberatamente l'autenticazione client a due opzioni. I client secret via HTTP Basic sono ammessi, perché ogni identity provider sulla faccia della terra li supporta oggi. Ma il metodo raccomandato è private_key_jwt: il client firma un'assertion JWT a vita breve con una chiave privata e presenta quella al posto di un secret. I dettagli di design nelle implementazioni degli SDK meritano una lettura, perché codificano un giudizio di sicurezza concreto:

  • L'assertion porta iss e sub impostati al client ID, aud impostato all'issuer identifier dell'authorization server, un exp di 300 secondi e un jti univoco. Le assertion rubate scadono in cinque minuti e non possono essere riutilizzate.
  • La chiave privata non lascia mai il client e non viene mai scritta nel token storage. Non c'è nessun segreto condiviso parcheggiato nel database dell'authorization server in attesa di essere esfiltrato.
  • Il client_id è del tutto omesso dal corpo della richiesta; l'identità viaggia dentro l'assertion firmata. La richiesta di token porta anche il parametro resource di RFC 8707, così il token che torna indietro è legato a un server MCP specifico invece di essere spendibile contro qualsiasi cosa accetti quell'issuer.

Il costo è la gestione delle chiavi. Le chiavi asimmetriche richiedono generazione, distribuzione, rotazione e revoca, e SEP-1046 di proposito non specifica ancora come un server scopre il JWKS del client per validare le assertion; quello aspetta il lavoro WIMSE sui JWT headless e la maturazione del draft Client ID Metadata all'IETF. In pratica significa che la maggior parte dei team partirà con i client secret e migrerà alle assertion JWT quando il tooling della propria piattaforma di identità si sarà messo al passo. Va bene così. Scegliere oggi l'opzione compatibile con un percorso di upgrade specificato è una cosa diversa dal non avere nessun percorso.

Un'omissione deliberata ha acceso il dibattito nel thread della issue: mTLS. Diversi commentatori volevano i certificati client di RFC 8705 nello scope, e l'obiezione spiega perché non ci sono: nei deployment reali il TLS termina alla CDN o al load balancer, diversi hop prima del layer applicativo dove MCP gira davvero, quindi il server non vede mai il certificato client senza acrobazie infrastrutturali. Le aziende con una PKI interna funzionante possono comunque fare mTLS tra i propri servizi; la specifica si rifiuta solo di far portare quell'assunzione a tutti gli altri.

I pattern che sopravvivono al contatto con un'azienda

L'articolo di Webb inquadra la decisione meglio di qualsiasi tabella comparativa di protocolli: partite da dove ha origine l'autorità dell'agente, non da un menù di flussi OAuth. Tutto il resto discende da quella domanda. Tre pattern coprono quasi ogni caso enterprise:

  • Autorità utente delegata per gli strumenti interattivi: gli entitlement dell'umano fluiscono all'agente attraverso il flusso authorization code. La trappola qui è il token pass-through, inoltrare il token dell'identity provider a monte direttamente al server MCP. Funziona in una demo e in produzione accoppia la vostra piattaforma di agenti a un formato di token e a un modello di trust altrui. Scambiate il token con uno a vita breve emesso per quello specifico server MCP, con validazione dell'audience applicata. Il requisito del resource indicator RFC 8707 nella specifica esiste esattamente per far fallire il riciclo di token generici.
  • Identità macchina per i workload non presidiati: client credentials di SEP-1046, preferite private_key_jwt, un client registrato per ogni workload agente, non un unico client "agents" condiviso per l'intera piattaforma. Il blast radius segue la granularità della registrazione.
  • Doppia identità per la via di mezzo interessante: un agente che agisce per conto di un utente ma gira senza presidio. Il token dovrebbe rappresentare sia l'attore (l'agente) sia il soggetto (l'utente), cosa che il token exchange supporta e che la maggior parte degli authorization server oggi sa esprimere. È il pattern che tiene rispondibile in un audit la domanda "quale umano è responsabile di questa azione", che è la domanda che il vostro team compliance farà davvero.

Sulla registrazione in sé: SEP-991 ha reso gli OAuth Client ID Metadata Document il pattern preferito per client e server senza una relazione preesistente, un URL HTTPS come identificatore del client. Elegante per l'ecosistema aperto; per un'azienda chiusa, la pre-registrazione tramite la piattaforma di identità aziendale resta il default più solido, perché vi dà ownership, allow-listing e controllo del ciclo di vita, e toglie dal vostro threat model un'intera classe di problemi SSRF legati al fetch dei metadata.

SEP-1046 è una corsia, non tutta la strada

Basta un'ora nel label auth del repo della spec perché l'inquadratura da singolo SEP crolli: esiste un gruppo di lavoro auth permanente con un ritmo di riunioni fisso, e una coda di proposte che disegna la prossima fase dell'autorizzazione MCP in azienda. SEP-1488 aggiunge securitySchemes ai metadati dei tool per i server ad auth mista, un server che espone tool pubblici accanto a tool protetti da OAuth. SEP-1489 standardizza l'errore con cui un tool innesca un flusso OAuth a metà sessione, cioè la step-up authorization in termini di agenti. SEP-2742 vuole che i server remoti dichiarino in anticipo i loro metodi di autenticazione, così un client sa a cosa va incontro prima di connettersi. La firma dei messaggi HTTP torna con la PR #2752 dopo che SEP-1415 era rimasta dormiente. E l'hardening continua ad arrivare tra un SEP di punta e l'altro: validazione dell'issuer RFC 9207 obbligatoria contro gli attacchi mix-up (#1721), Rich Authorization Requests secondo RFC 9396 (#1670), inoltro dei refresh token per l'accesso offline (#1735), e un cantiere aperto per snellire la spec di autorizzazione delegando alle RFC OAuth su cui poggia (#3054). Se in azienda la sicurezza degli agenti è vostra, quella coda di issue è la vostra roadmap. Leggetela come leggete il vostro backlog.

Cosa farne lunedì

In concreto, per un team di piattaforma o di sicurezza che sta portando MCP dentro un'organizzazione:

  • Fate l'inventario di ogni integrazione MCP e classificatela: interattiva, non presidiata, o che agisce per conto di qualcuno. Il flusso segue la classe, mai il contrario.
  • Date a ogni agente non presidiato il proprio client registrato nel vostro identity provider. Partite con i client secret se il vostro tooling lo impone, ma mettete private_key_jwt in roadmap subito e verificate se il vostro SDK lo supporta già. TypeScript, Python e Ruby lo fanno.
  • Applicate la validazione dell'audience su ogni server MCP che operate. Un token emesso per un server deve fallire su un altro. È il controllo più economico di tutto lo stack e il più comunemente saltato.
  • Vietate il token pass-through in code review, allo stesso modo in cui vietate l'SQL costruito con le stringhe. È la SQL injection dell'identità degli agenti: comodo, ovunque, e sbagliato.
  • Tenete i permessi degli agenti in sola lettura per default e mettete un gate su ogni percorso che modifica stato, la stessa postura che ho sostenuto al layer infrastrutturale nel post sul gateway di Agents on Call. L'autenticazione vi dice chi è l'agente; non dice nulla su cosa dovrebbe avere il permesso di fare.

Il punto più ampio: ogni mese, un altro pezzo di "le aziende non possono adottare gli agenti a causa di X" si risolve in silenzio in qualche issue GitHub. L'auth era la X più grossa. Un anno fa la risposta onesta a "come si autenticano i nostri agenti non presidiati verso i server MCP" era un'alzata di spalle. Ora è un numero di SEP, due metodi di autenticazione client e test di conformance in tre SDK. Stiamo tutti imparando cosa possiamo costruire, e come, un po' di più ogni settimana. I team che seguono queste crepe mentre si chiudono spediranno con un anno di anticipo rispetto ai team che aspettano un manuale finito, perché non ci sarà.

Leggi questo dopo

L'identità è solo metà della sicurezza degli agenti. IAM for LLM Apps: Least Privilege When the Caller Is a Model copre la metà dell'autorizzazione su AWS. Sul sito gemello, Agent Toolkit for AWS: The Docs Have a New Reader guarda cosa succede quando l'agente che consuma la vostra infrastruttura è anche quello che legge il manuale, e su ercanermis.com trovate la mappa completa di cosa scrivo e dove.

Riferimenti