Agent Compute Engine di Google: ogni agente AI ha la sua microVM isolata

Google ha deciso di trasformare in un prodotto per tutti l’infrastruttura che fa girare i suoi agenti. Si chiama Agent Compute Engine ed è un nuovo servizio di Google Cloud che assegna a ogni agente AI una propria microVM isolata a livello hardware, con la rapidità di avvio tipica dei container. Il debutto è stato raccontato il 22 ottobre 2026 sul blog di Google Cloud, con un approfondimento tecnico dedicato, e la disponibilità in anteprima è prevista nei prossimi mesi.

Per te che segui l’AI non è solo un dettaglio da addetti ai lavori. Dove e come gira un agente decide quanto è sicuro, quanto costa e quanto può diventare autonomo.

Cos’è Agent Compute Engine e perché Google lo ha costruito

Secondo il post tecnico di Google Cloud, il servizio nasce da un problema preciso: far funzionare centinaia di milioni di agenti contemporaneamente con le primitive di calcolo tradizionali, cioè macchine virtuali e container, è troppo lento e troppo costoso. Una macchina virtuale classica impiega da alcuni secondi a diversi minuti per avviarsi, sospendersi o riprendere. Un agente, che passa molto tempo fermo ad aspettare un utente o una risposta, non può permettersi quei tempi.

La soluzione è una microVM per ogni sessione. Ogni agente riceve un ambiente dedicato, a singolo tenant, costruito con componenti memory-safe e con mitigazioni contro gli attacchi side-channel della CPU. Quando l’agente resta inattivo, la sessione viene salvata in uno snapshot e non consuma risorse attive dell’host, per poi ripartire quando serve. L’obiettivo dichiarato è svegliare un agente più in fretta di quanto una persona se ne accorga.

I quattro scenari d’uso previsti

Google indica quattro famiglie di carichi di lavoro: agenti interattivi per consumatori e aziende, ambienti autonomi per l’ingegneria del software, valutazioni su larga scala e addestramento con rinforzo, e infine sandbox leggere a supporto di altri servizi Google. Il sistema, secondo l’azienda, alimenta già Gemini, la piattaforma Gemini, Antigravity e le pipeline interne di valutazione.

È un punto chiave: non si tratta di un esperimento, ma dell’infrastruttura già in uso per i prodotti che conosci. Se vuoi un quadro più ampio dell’ecosistema, trovi tutto nella nostra guida a Google Gemini.

Sicurezza: nessuna credenziale dentro la sandbox

La parte più interessante, per chi lavora con agenti in azienda, è il modello di sicurezza. Google parte da un’ipotesi realistica: un agente può essere ingannato, per esempio con un prompt malevolo, quindi la sandbox non deve contenere nulla che valga la pena rubare.

Per questo i sistemi ospite non hanno schede di rete virtuali standard, gateway IP predefiniti né accesso diretto alla VPC. Tutto il traffico passa da un canale virtio-vsock verso un proxy locale e poi verso un gateway esterno. Dentro la microVM non ci sono segreti persistenti, token di refresh OAuth o chiavi di service account, e non è raggiungibile nemmeno il metadata server.

Il gateway esegue uno scambio dei token in tempo reale, quindi le credenziali vere non entrano mai nell’ambiente in cui gira l’agente. Ogni microVM riceve invece un certificato SPIFFE effimero, legato alla sessione, e un token di identità a breve durata.

Hardware e host immutabili

La radice di fiducia hardware poggia sul silicio Titan e sulla Infrastructure Processing Unit Titanium di Google. Gli host sono appliance senza stato e immutabili, con filesystem di root in sola lettura garantito da dm-verity. Gli snapshot di memoria e i volumi a blocchi sono cifrati a riposo, e per collegarli o ripristinarli serve un’autorizzazione crittografica dedicata, gestita da Google o dal cliente.

Se ti interessa il tema degli attacchi agli agenti, ti consiglio di leggere anche cosa è emerso con AgentCorruption, il prompt che ha messo alla prova gli agenti AWS.

Identità e governance degli agenti

Agent Compute Engine si appoggia ai componenti di governance della piattaforma Gemini. L’Agent Registry è il catalogo controllato dagli amministratori di plugin, skill, server MCP e agenti A2A. L’Agent Identity funziona da cassaforte e intermediario di autenticazione, con identità uniche per ciascun agente. L’Agent Gateway è il punto in cui si applicano le policy e si controlla il traffico di rete.

Google distingue quattro identità. La prima è quella dell’utente, che autentica solo il compito complessivo. La seconda è l’identità delegata on-behalf-of, una concessione di lunga durata custodita in un servizio di autorizzazione centrale e mai sul nodo. La terza è la Agent Workload Identity, a vita breve e basata su SPIFFE, l’unica usata per il traffico della sandbox. La quarta è la Agent Workforce Identity, con cui l’agente agisce con un account e risorse proprie.

Per le aziende l’accesso continua a rispettare Cloud IAM e VPC Service Controls, con log di audit end-to-end. Secondo la sintesi della testata The Decoder, Google estende anche il controllo a tracciamento dei token, instradamento dei modelli e provider di identità di terze parti come Ping Identity e SailPoint, su Cloud Run, GKE e endpoint gestiti.

Efficienza e numeri: cosa dice davvero Google

Un’avvertenza utile: nel post tecnico Google non fornisce cifre precise su tempi di avvio, densità o latenza. Parla in termini qualitativi di un singolo nodo capace di ospitare ordini di grandezza più microVM attive rispetto alle macchine virtuali convenzionali.

Il trucco è la condivisione della memoria. Gli host mappano una sola volta sistema operativo, librerie ed eseguibili con DAX e Copy-on-Write, così le macchine condividono le stesse pagine di RAM fisica. Uno snapshot può poi essere clonato in migliaia di copie deduplicate in parallelo, utile per valutazioni e addestramento.

Le cifre più concrete arrivano dalla stampa. The Decoder riferisce che Google ha reso open source Agent Substrate, un runtime Kubernetes, e dichiara di poter far stare fino a dieci volte più agenti su un singolo server. In un test con 200.000 agenti, sospensione e ripresa avrebbero richiesto meno di 500 millisecondi. Sono dati forniti dall’azienda e non verificati in modo indipendente, quindi vanno letti come tali.

Scheduling globale

Un frontdoor di scheduling globale instrada le sessioni tra le regioni in base a capacità, salute dei nodi e disponibilità delle immagini, rispettando confini geografici, regole di conformità e requisiti di localizzazione dei dati. I carichi differibili e in batch riempiono la capacità nelle ore di minore richiesta.

Cosa cambia per sviluppatori e aziende

Chi sviluppa agenti oggi si arrangia spesso con container improvvisati, sandbox di terze parti o servizi dedicati. Un esempio recente è SPACE di Perplexity, la sandbox pensata per far girare gli agenti in sicurezza. L’arrivo di un’offerta nativa di un grande cloud provider sposta il confronto sul terreno dell’integrazione con identità, rete e audit già in uso in azienda.

Agli sviluppatori Google promette il controllo su immagine, identità, accesso di rete e ciclo di vita di ogni ambiente, mentre la gestione della flotta e della scalabilità resta a carico dell’azienda. Prezzi e regioni specifiche non sono stati comunicati: il post parla solo di capacità distribuita in regioni di tutto il mondo.

Va ricordato che la data di anteprima resta indefinita, indicata come prossimi mesi, e che esiste un modulo per manifestare interesse. Fino ad allora conviene trattare il servizio come una direzione strategica più che come uno strumento da adottare subito.

Perché questa mossa conta nella corsa agli agenti

Negli ultimi mesi la competizione tra i grandi laboratori si è spostata dai modelli agli strumenti che li fanno lavorare in autonomia. Anche OpenAI ha scelto Google Cloud come canale per i suoi modelli, come abbiamo raccontato nell’articolo su OpenAI nel Model Garden di Google Cloud. Con Agent Compute Engine, Google prova a presidiare anche il livello sottostante, quello dove gli agenti vivono e vengono controllati.

La scelta di isolare ogni agente con hardware dedicato e di tenere le credenziali fuori dalla sandbox riflette una lezione ormai condivisa nel settore: più un agente è autonomo, più il perimetro di sicurezza deve stare fuori dal suo controllo. Chi progetta flussi di lavoro con agenti dovrebbe chiedersi fin da ora dove vivono i suoi segreti e chi può revocarli.

Conclusioni

Agent Compute Engine è una notizia di infrastruttura, ma racconta bene dove sta andando l’AI: agenti numerosi, spesso inattivi, che devono ripartire in un istante senza mai custodire le chiavi di casa. Google ha già i numeri e il prodotto in casa, ora deve convincere il mercato con prezzi, regioni e una data di anteprima.

Il consiglio è semplice: se usi o costruisci agenti, registrati all’interesse nell’anteprima, mappa le identità che i tuoi agenti usano oggi e segui il nostro sito per gli aggiornamenti quando Google renderà pubblici dettagli e costi.