Se un agente AI legge contratti, ticket di assistenza o dati finanziari dentro una macchina virtuale cloud, cifrare il disco e la connessione non basta: durante l’elaborazione, memoria e stato della CPU diventano il punto esposto. Il confidential computing interviene proprio lì. Non rende sicuro un workflow mal progettato, ma riduce il numero di soggetti e componenti che devono essere considerati affidabili.

La decisione di Intel di concentrare i futuri investimenti su Trust Domain Extensions (TDX) rende il tema meno teorico. Nell’ottobre 2026 l’azienda ha indicato la piattaforma Xeon “Diamond Rapids” come ultima generazione a supportare Software Guard Extensions (SGX), garantendo comunque supporto e aggiornamenti di sicurezza per le piattaforme SGX nei primi anni Trenta. Per chi gestisce carichi AI o applicazioni sensibili, la domanda utile non è «TDX è più sicuro?», ma «quale confine di fiducia devo proteggere e come verifico che sia davvero attivo?».

Il cambio da SGX a TDX è prima di tutto operativo

SGX e TDX affrontano lo stesso problema generale — proteggere dati e codice mentre sono in uso — con perimetri diversi. SGX crea enclave all’interno di un’applicazione: lo sviluppatore seleziona le parti sensibili, modifica o adatta il software e mantiene una Trusted Computing Base molto ridotta. TDX sposta invece il confine attorno a un’intera macchina virtuale, chiamata Trust Domain.

La guida di transizione ufficiale di Intel lega la scelta a tre vantaggi operativi: semplicità di adozione, flessibilità e scalabilità. Una VM confidenziale può ospitare sistemi operativi e applicazioni esistenti senza riscrivere ogni componente come enclave. È un compromesso: aumenta il software incluso nel perimetro fidato, ma rende più praticabile la protezione di stack complessi come orchestratori, database, runtime di modelli e agenti che chiamano più servizi.

La roadmap non impone di migrare domani. Impone però di evitare due errori. Il primo è avviare nuovi progetti strettamente dipendenti da SGX senza una ragione architetturale documentata. Il secondo è trattare TDX come un rimpiazzo trasparente: un’applicazione SGX costruita intorno a enclave, attestation e rilascio selettivo delle chiavi non diventa automaticamente equivalente quando viene spostata dentro una VM.

Cosa protegge davvero una confidential VM

In una VM tradizionale, hypervisor, sistema operativo host e strumenti di amministrazione dell’infrastruttura fanno parte del modello di fiducia. TDX usa isolamento e cifratura gestiti dall’hardware per impedire a questi componenti di leggere o modificare memoria e stato della CPU del Trust Domain. La documentazione Intel descrive anche l’attestation remota: il workload può produrre una prova crittografica della piattaforma e del proprio stato iniziale.

Questo è utile quando l’organizzazione vuole elaborare dati su infrastruttura di terzi senza concedere all’operatore del cloud accesso in chiaro al workload. I casi più concreti per una PMI sono l’analisi di documenti riservati, l’inferenza su dati sanitari o finanziari, la condivisione di dataset tra due aziende e il rilascio di chiavi soltanto a un ambiente verificato.

Il confine, però, va scritto prima di comprare la tecnologia. TDX non corregge:

  • un agente autorizzato a inviare dati al destinatario sbagliato;
  • una vulnerabilità nell’applicazione o nel sistema operativo guest;
  • credenziali esposte nei log, nelle variabili d’ambiente o nelle risposte del modello;
  • un’integrazione SaaS che riceve il dato dopo che è uscito dalla VM;
  • una policy di conservazione incoerente con GDPR, contratti o procedure interne.

La mia regola pratica è questa: una confidential VM riduce la fiducia nell’infrastruttura sottostante, non la responsabilità sul software sovrastante. Se il workflow può compiere azioni esterne, servono ancora limiti, approvazioni e tracciamento. È lo stesso principio applicato ai guardrail prima del go-live di un agente AI: l’isolamento non sostituisce il controllo del comportamento.

SGX o TDX: la scelta dipende dal confine

SGX resta sensato quando l’applicazione è già progettata attorno a una piccola enclave, la minimizzazione della Trusted Computing Base è un requisito forte e il team possiede competenze specifiche per mantenerla. TDX è più adatto quando bisogna isolare un workload completo, migrare software esistente o distribuire più componenti che devono comunicare dentro lo stesso ambiente protetto.

La differenza si vede in un caso semplice. Un servizio che custodisce una sola chiave crittografica e firma richieste può beneficiare di un’enclave molto limitata. Un sistema RAG aziendale con parser, database vettoriale, runtime del modello, API e coda di job è invece più facile da racchiudere in una VM confidenziale. Non significa che ogni componente diventi affidabile: significa che l’host e l’hypervisor escono dal gruppo di componenti autorizzati a osservare la memoria del workload.

Per nuovi progetti eviterei una decisione basata soltanto sul marchio del processore. Azure offre confidential VM con Intel TDX e AMD SEV-SNP; Google Cloud documenta TDX su specifiche famiglie di macchine. Il requisito deve essere espresso in termini verificabili: isolamento della memoria, attestation, gestione delle chiavi, immagini supportate, disponibilità geografica, procedure di aggiornamento e costo misurato sul carico reale.

Un pilot TDX in sei passaggi

1. Seleziona un workload stretto

Parti da un processo con dati sensibili e confini chiari, non dall’intera piattaforma. Un buon pilot può essere l’estrazione di clausole da contratti, la classificazione di ticket con dati personali o la generazione di un report su documenti riservati. Definisci input, output, dipendenze, durata dei dati in memoria e sistemi esterni contattati.

2. Scrivi il threat model

Indica da chi vuoi proteggere il workload: amministratore cloud, hypervisor compromesso, altra VM sullo stesso host, operatore interno o fornitore applicativo. TDX è pensato per isolare il Trust Domain dal software privilegiato esterno, ma non risolve ogni attacco. Le linee guida Intel per gli sviluppatori ricordano che hypercall, memoria condivisa, MMIO, port I/O e altre interfacce verso l’host diventano superfici da trattare come non fidate.

3. Crea una baseline non confidenziale

Esegui lo stesso workload su una VM standard con lo stesso sistema operativo, numero di vCPU, memoria e dataset di prova. Registra latenza, throughput, consumo di memoria, tempi di avvio, errori applicativi e costo. Senza questa baseline, qualsiasi giudizio sulle prestazioni della confidential VM resta impressionistico.

4. Avvia la VM confidenziale con un’immagine supportata

Verifica prima regione, famiglia macchina, immagine del sistema operativo e funzionalità di attestation disponibili. Non assumere che una configurazione accettata dal pannello cloud garantisca tutte le proprietà desiderate. Per esempio, la documentazione di Google Cloud distingue le misure registrate nel MRTD e nei registri runtime RTMR; Microsoft Azure distingue l’attestation trasparente durante il boot dai controlli aggiuntivi eseguibili nel guest.

5. Collega l’attestation al rilascio dei segreti

Limitarsi a vedere una spunta «confidential» nella console non è un controllo. Il valore nasce quando un verifier controlla la prova e un Key Management Service rilascia chiavi o credenziali solo se piattaforma, firmware e configurazione rispettano una policy. La sequenza corretta è: il workload produce evidence, il verifier la valida, la policy decide e soltanto allora il secret diventa disponibile.

La policy deve anche gestire gli aggiornamenti. Firmware, microcode, bootloader e kernel modificano le misure; una regola troppo rigida può bloccare il servizio dopo una patch, una troppo larga accetta stati non previsti. Serve quindi un processo di approvazione delle nuove baseline, con rollback e alert, non un hash copiato una volta in produzione.

6. Testa guasti e uscita dal perimetro

Forza un’attestation non valida, un’immagine non approvata, un secret assente e un aggiornamento della VM. Controlla che il workload fallisca chiuso e che non ripieghi su credenziali statiche. Poi segui il dato: se il risultato viene inviato a un SaaS, scritto in un bucket pubblico o copiato nei log, la protezione durante l’elaborazione ha soltanto spostato il punto debole.

Attestation: la prova va trasformata in una decisione

L’attestation non è un bollino di conformità. È un insieme di misure e firme che descrive l’ambiente. Su TDX, il modulo misura il firmware del Trust Domain e conserva valori dedicati per la fase iniziale e per la catena di avvio. Il verifier deve controllare firma, certificati, versione della Trusted Computing Base, stato di revoca e valori ammessi dalla policy.

Per una PMI, la parte difficile non è generare una quote: è decidere cosa succede dopo. Un’architettura minima dovrebbe prevedere:

  • un’identità distinta per il workload, non condivisa con VM standard;
  • una policy versionata che definisca le misure ammesse;
  • un servizio di verifica separato dal workload attestato;
  • secret con durata breve e rilascio condizionato;
  • log dell’esito, senza registrare chiavi o contenuti sensibili;
  • un percorso di emergenza che non disattivi silenziosamente i controlli.

Se il team non ha ancora una gestione matura di identità, chiavi e aggiornamenti, il pilot dovrebbe includerla esplicitamente. TDX rende più forte il confine hardware, ma aumenta il valore di una policy errata: un verifier configurato male può autorizzare in modo coerente l’ambiente sbagliato.

Prestazioni e I/O vanno misurati sul caso reale

La cifratura della memoria e le transizioni tra Trust Domain e hypervisor hanno un costo. In test Intel su processori Xeon Scalable di quarta generazione, l’effetto osservato sui workload intensivi su CPU e memoria è arrivato fino al 5%, mentre i carichi I/O hanno mostrato impatti più variabili e superiori. È un dato del fornitore su una piattaforma e configurazione precise, non una percentuale da inserire in un budget senza test.

Il motivo è architetturale. La memoria privata del Trust Domain non è direttamente accessibile ai componenti non fidati; operazioni I/O possono richiedere memoria condivisa, copie e transizioni aggiuntive. Intel sta sviluppando TDX Connect per consentire I/O fidato e ridurre questi passaggi, ma la stessa analisi prestazionale ufficiale raccomanda di distinguere workload CPU, memoria e I/O.

Per un sistema AI misura almeno tempo al primo token, token al secondo, latenza delle chiamate al database vettoriale, trasferimenti verso acceleratori, avvio a freddo e costo per richiesta completata. Se il workload usa GPU, verifica separatamente la protezione del tratto CPU-GPU e l’attestation dell’acceleratore: proteggere la VM CPU non prova automaticamente che tutto il percorso del dato sia confidenziale.

La decisione per una PMI

Una PMI dovrebbe adottare TDX quando esiste un rischio concreto sui dati in uso, l’infrastruttura è condivisa o gestita da terzi e l’attestation può essere collegata a una decisione reale sulle chiavi. Non dovrebbe adottarlo per compensare applicazioni non aggiornate, permessi eccessivi o processi senza proprietario.

Il percorso sensato è un pilot di due o quattro settimane su un workload ristretto, con baseline prestazionale, threat model, policy di attestation e prova di fail-closed. Il risultato non è «la VM parte»: è la dimostrazione che un ambiente non approvato non riceve i segreti, che gli aggiornamenti sono governabili e che il sovraccarico resta sostenibile.

Il passaggio da SGX a TDX segnala una preferenza industriale per l’isolamento a livello di VM, più semplice da distribuire sugli stack esistenti. La take operativa è meno comoda: più facile da adottare non significa automatico da verificare. Il progetto vale quando hardware, attestation, gestione delle chiavi e controlli applicativi formano una sola catena; se uno di questi elementi resta implicito, la dicitura “confidential” è soltanto una proprietà dell’infrastruttura, non del processo aziendale.

Fonti