Nel tutorial pubblicato il 20 ottobre 2026, AWS descrive un’architettura di riferimento che usa certificati X.509 per identificare gli agenti IA e verificare le loro richieste; la specifica MCP prevede invece un’autorizzazione OAuth facoltativa per i trasporti HTTP. Sono controlli su livelli diversi: l’autorizzazione riguarda l’accesso tramite il trasporto, mentre i certificati legano le richieste all’identità crittografica dell’agente.
Questo schema aiuta a separare l’accesso di un utente o di un’applicazione da ciò che può fare ciascun agente. AWS lo presenta come esempio basato su servizi cloud e componenti di terze parti.
L’autorizzazione MCP e l’identità dell’agente hanno ambiti diversi
La specifica MCP definisce un meccanismo OAuth facoltativo per i trasporti HTTP. Per le implementazioni che usano STDIO, indica invece di ricavare le credenziali dall’ambiente. Questa autorizzazione di trasporto non equivale a identificare con un certificato il singolo agente o a verificare le richieste firmate tra agenti.
| Meccanismo | Ambito | Funzione | Trasporto o confine |
| Autorizzazione MCP basata su OAuth | Facoltativa; riguarda i trasporti HTTP | Autorizza l’accesso secondo il meccanismo previsto dalla specifica | Trasporto HTTP; per STDIO si usano credenziali dell’ambiente |
| Identità X.509 dell’esempio AWS | Identità degli agenti, delega dell’utente e richieste tra agenti | Associa le richieste firmate a certificati e controlla la delega | Utente-sistema, agente-agente e agente-server MCP |
L’esempio AWS può usare anche un token con audience limitata al server MCP. Questo limita il servizio a cui il token è destinato; la firma della richiesta e il certificato servono invece a verificare l’identità dell’agente e il contenuto inviato.
I tre confini di fiducia e la catena di controlli
AWS organizza il modello attorno a tre passaggi: dall’utente al sistema, da un agente a un altro e dall’agente al server MCP. Nel primo, l’utente accede tramite OAuth e autorizza gli agenti. Negli altri, le firme e i certificati aiutano a verificare chi invia la richiesta e se rientra nella delega ricevuta.
Il flusso descritto parte da un accesso Keycloak. Il sistema scambia poi il token per uno con audience limitata al server MCP, senza consegnare agli agenti il token dell’intera sessione. L’applicazione genera localmente una coppia di chiavi RSA e invia a EJBCA una richiesta di firma del certificato. La chiave privata resta nell’applicazione; AWS descrive la conservazione del certificato e della chiave in un pacchetto PKCS#12 dentro AWS Secrets Manager.
L’utente firma una dichiarazione di delega che identifica i certificati degli agenti tramite le impronte SHA-256 e include il soggetto, l’ora di emissione e la scadenza. Quando un agente invia una richiesta, firma con RSA-PSS-SHA256 il contenuto, il nome dello strumento, gli argomenti, l’ora e un nonce, cioè un valore casuale usato una sola volta.
Prima di autorizzare lo strumento, il server MCP verifica il token e la sua audience, la firma e la freschezza della richiesta, la delega e la coerenza tra nome utente, soggetto delegante e certificato dell’agente. AWS descrive inoltre controlli sulla catena di certificati, sui permessi del ruolo, sull’unicità del nonce e sullo stato di revoca tramite OCSP.
Finestra temporale, replay e revoca
Nell’esempio, la finestra predefinita di validità di una richiesta è di 60 secondi e il nonce è lungo 128 bit. Il sistema conserva ogni nonce nella cache antireplay per il doppio della finestra configurata: con il valore predefinito, sono 120 secondi. Un nuovo tentativo richiede quindi una nuova busta firmata e un nonce diverso.
Il profilo di certificato usato come esempio ha una validità di sette giorni. AWS descrive controlli OCSP a ogni richiesta e il rifiuto della validazione se il responder OCSP non è raggiungibile. Il flusso di revoca descritto comprende la revoca dei certificati dell’utente e degli agenti, l’eliminazione dei segreti da AWS Secrets Manager senza periodo di recupero e la chiusura della sessione Keycloak.
Prerequisiti e portata del progetto
Per seguire l’esempio servono Keycloak 26.2 o successivo, Python 3.9 o successivo ed EJBCA Enterprise con REST API V1 e un responder OCSP. Sono inoltre richiesti accesso ad Amazon Bedrock, Amazon RDS for MySQL, Amazon SES e AWS Secrets Manager. AWS abbina Amazon Bedrock all’AWS Strands Agents SDK e usa FastMCP per il server degli strumenti.
Il README del repository AWS Samples definisce il progetto una dimostrazione per apprendimento e sviluppo e richiede ulteriori misure di sicurezza e una revisione prima dell’uso in produzione.
