AWS e Keyfactor blindano gli agenti AI: certificati X.509 e revoca su MCP

🛡️ Executive Summary

• AWS e Keyfactor presentano un’architettura di riferimento che assegna identità crittografiche distinte agli agenti AI e verifica le autorizzazioni prima dell’accesso agli strumenti MCP.
• Il sistema combina certificati X.509, richieste firmate, deleghe dell’utente, token OAuth limitati e controlli OCSP per contrastare impersonificazione e riutilizzo delle credenziali.
• La soluzione richiede componenti aggiuntivi e un’infrastruttura PKI operativa: non è una protezione automatica di Amazon Bedrock e non elimina i rischi derivanti dalle istruzioni malevole.

AWS e Keyfactor hanno presentato un’architettura di sicurezza che permette di identificare crittograficamente gli agenti di intelligenza artificiale prima che accedano a database, API e strumenti aziendali attraverso Model Context Protocol (MCP). La proposta, pubblicata il 20 ottobre 2026, utilizza certificati X.509, deleghe firmate dagli utenti e controlli di revoca per impedire che un agente possa impersonarne un altro o utilizzare autorizzazioni non valide. L’obiettivo è affrontare un problema crescente: quando più agenti collaborano e ricevono permessi operativi, non basta sapere quale modello AI stia rispondendo, ma occorre verificare quale componente stia realmente eseguendo ogni richiesta. Non si tratta di un nuovo servizio AWS gestito, bensì di un’architettura di riferimento da implementare.

AWS introduce una catena di fiducia tra utenti, agenti e strumenti MCP

La documentazione tecnica pubblicata da AWS e Keyfactor descrive un sistema organizzato su tre livelli: autenticazione dell’utente, comunicazione tra agenti e accesso finale al server MCP. La necessità nasce dal fatto che un agente può ricevere istruzioni da un orchestratore e invocare strumenti capaci di interrogare database o inviare email. Se le credenziali vengono condivise indiscriminatamente, diventa difficile dimostrare quale componente abbia autorizzato un’operazione e impedire che un soggetto compromesso utilizzi i permessi degli altri. È importante precisare che MCP non è privo di meccanismi di autenticazione: la specifica ufficiale del protocollo prevede già un sistema di autorizzazione basato su OAuth per i trasporti HTTP. L’architettura AWS aggiunge tuttavia una verifica crittografica dell’identità dei singoli agenti e della catena di delega, complementare ai token OAuth. Il problema è concreto: una vulnerabilità di Bifrost AI Gateway aveva già mostrato come un server MCP esposto potesse diventare un punto di esecuzione di comandi non autorizzati.

Leggi anche: Agenti AI, la nuova kill chain: 157 skill malevole e tool poisoning sfuggono ai SOC

Keyfactor EJBCA assegna un certificato X.509 a ogni agente

Il sistema utilizza Keyfactor EJBCA Enterprise come autorità di certificazione, mentre Keycloak 26.2 o successivo gestisce l’identità dell’utente e lo scambio dei token OAuth. Dopo l’autenticazione viene generata una coppia di chiavi RSA da almeno 2048 bit e una richiesta di certificato, firmata dalla PKI. Ogni agente ottiene un certificato distinto, associato al proprio ruolo: nell’esempio AWS sono presenti un orchestratore, un agente MySQL e uno incaricato delle email.

L’utente firma una delega contenente le impronte SHA-256 dei certificati degli agenti autorizzati, dimostrando quali componenti possano operare per suo conto senza consegnare loro la propria chiave privata o il token completo della sessione. Il sistema impiega inoltre lo standard RFC 8693 per ottenere un token limitato al server MCP destinatario, riducendo le possibilità di riutilizzo delle credenziali presso servizi differenti. Le chiavi vengono generate nell’ambiente applicativo e non trasmesse all’autorità di certificazione; i relativi contenitori PKCS#12 possono però essere conservati in AWS Secrets Manager, dove devono essere protetti mediante politiche di accesso appropriate. La protezione delle credenziali rimane dunque una responsabilità operativa, anche in un sistema che utilizza certificati.

Firme RSA-PSS, timestamp e nonce impediscono il riutilizzo delle richieste

Quando un agente invoca un altro componente, non è sufficiente presentare un certificato apparentemente valido. L’architettura richiede che ogni chiamata venga inserita in un messaggio firmato con RSA-PSS-SHA256, comprendente nome dello strumento, argomenti, timestamp e un nonce crittograficamente casuale a 128 bit. Il destinatario verifica firma digitale, catena di certificazione, ruolo del chiamante e stato di revoca, controllando contemporaneamente che il messaggio non sia troppo vecchio. La configurazione dimostrativa stabilisce una finestra temporale di 60 secondi, mentre una cache registra i nonce già utilizzati per impedire la ripetizione della stessa richiesta. Se un attaccante intercetta un messaggio valido e tenta di riproporlo, la verifica deve impedirne una seconda esecuzione. Il meccanismo non protegge soltanto dal furto di credenziali, ma dalla possibilità di alterare o riutilizzare istruzioni durante la comunicazione tra agenti. L’autenticità del chiamante non garantisce però che l’istruzione generata dal modello sia corretta, una distinzione già evidente nelle vulnerabilità MCP e supply chain che sfruttano componenti apparentemente fidati.

Il server MCP controlla quattro condizioni prima di accedere al database

La dimostrazione combina Amazon Bedrock, utilizzato per l’inferenza attraverso Strands Agents SDK, con Amazon RDS for MySQL, Amazon SES, AWS Secrets Manager ed istanze EC2 che ospitano Keycloak ed EJBCA. Prima di eseguire un’operazione, il server FastMCP verifica quattro condizioni: validità e destinatario del token OAuth, firma e certificato dell’agente, delega sottoscritta dall’utente e corrispondenza delle identità dichiarate nei diversi elementi. Un agente privo del certificato e del ruolo appropriati non dovrebbe poter invocare gli strumenti protetti, anche quando il modello linguistico produce una richiesta formalmente corretta. La protezione viene applicata quindi all’infrastruttura che esegue l’azione, anziché affidarsi esclusivamente alle istruzioni contenute nel prompt. La stessa impostazione rafforza il modello di autorizzazioni necessario alle piattaforme AWS AgentCore che stanno portando gli agenti AI nei processi aziendali. AWS specifica inoltre che IAM e certificati X.509 svolgono funzioni differenti: la PKI autentica la comunicazione tra agenti, mentre i ruoli IAM continuano a disciplinare l’accesso alle risorse del cloud.

Revoca OCSP immediata: il vantaggio operativo introduce nuove dipendenze

Il principale elemento di controllo è rappresentato da Online Certificate Status Protocol (OCSP), che permette di verificare se un certificato sia ancora valido. Quando un utente termina la sessione, il sistema revoca il suo certificato e quelli degli agenti, cancella i segreti associati e chiude la sessione Keycloak. Poiché ogni richiesta richiede una verifica OCSP, la revoca del certificato dell’utente invalida anche le deleghe già distribuite, senza attendere la scadenza naturale dei token. La configurazione è fail-closed: se il servizio OCSP non risponde, oppure una firma risulta errata, l’operazione viene negata. Questo comportamento privilegia la sicurezza rispetto alla disponibilità, ma crea una dipendenza dall’infrastruttura PKI. AWS suggerisce responder OCSP ad alta disponibilità, chiavi protette da moduli HSM e cache condivise quando gli agenti vengono distribuiti su più istanze. La cache anti-replay dell’esempio, infatti, è inizialmente conservata in memoria: in un ambiente distribuito deve essere coordinata tra le repliche, altrimenti la verifica dei nonce potrebbe non essere uniforme. Restano inoltre essenziali gli aggiornamenti dell’identity provider, come dimostrato dalla vulnerabilità Keycloak che aveva consentito il takeover degli account senza autenticazione.

Continua con:

Ninja Forms e AWS AgentCore mostrano i rischi dei componenti fidati

AWS Agent Registry governa agenti AI, Bedrock e infrastruttura cloud

I certificati identificano gli agenti, ma non rendono sicure tutte le decisioni AI

L’architettura AWS–Keyfactor affronta il problema di dimostrare chi stia operando, per conto di quale utente e con quali autorizzazioni, senza trasformare i certificati in una soluzione universale ai rischi dell’intelligenza artificiale. Un agente correttamente autenticato può comunque interpretare male una richiesta, utilizzare dati manipolati o compiere un’operazione dannosa entro i permessi assegnati. Rimangono quindi necessari controlli granulari sugli strumenti, registrazioni verificabili, supervisione umana e protezioni contro la prompt injection. L’adozione richiede inoltre una PKI funzionante, gestione del ciclo di vita dei certificati e componenti aggiuntivi che non sono automaticamente inclusi nei servizi Bedrock. Il contributo della proposta consiste nello spostare l’identità degli agenti dal livello delle istruzioni del modello a quello delle verifiche crittografiche, rendendo più difficile impersonare un componente o riutilizzarne le autorizzazioni. È un requisito sempre più importante quando l’AI non si limita a rispondere, ma accede direttamente ai sistemi produttivi aziendali.