Physical Address
304 North Cardinal St.
Dorchester Center, MA 02124
La notizia non è la macchina virtuale: è che dentro non c'è niente da rubare. Il 22 ottobre 2026 Google Cloud ha presentato Agent Compute Engine, servizio che assegna a ogni agente AI una microVM dedicata con isolamento hardware e zero credenziali al suo interno. Il ragionamento è brutale e convincente: se un agente viene manipolato da una prompt injection, nell'ambiente non trova chiavi API, token OAuth o accessi alla rete privata del cliente. Sul fronte opposto, però, Google non ha pubblicato né prezzi né densità per agente, e la preview è rimandata ai prossimi mesi: chi deve fare budget nel 2027 oggi non ha numeri su cui calcolare.
Agent Compute Engine: una microVM per ogni sessione
Agent Compute Engine è un servizio di calcolo di Google Cloud in cui ogni sessione di agente gira in una microVM single-tenant, con kernel e accesso root propri, delimitata dall'hypervisor Cloud Hypervisor e dotata di dischi Hyperdisk. L'host è un'appliance senza stato con filesystem di base in sola lettura, su silicio Titan e IPU Titanium.
Google l'ha annunciato ad AGNTCon + MCPCon, il raduno organizzato dalla Linux Foundation a San Jose il 22 e 23 ottobre. Il servizio non nasce come prodotto commerciale: alimenta già Gemini come agente per il lavoro, l'agente di programmazione Antigravity e le pipeline interne di valutazione e reinforcement learning.
L'architettura separa due parti. L'harness, il cervello, chiama il modello e resta completamente fuori dal sandbox. Il sandbox, le mani, esegue codice, comandi shell e browser. L'harness invia comandi espliciti verso l'interno; nulla risale senza passare dai controlli.
Dentro il sandbox non ci sono credenziali
La microVM non contiene chiavi API, token OAuth né chiavi di service account, in memoria o su disco. Non ha nemmeno una scheda di rete standard, un gateway predefinito o un accesso diretto alla VPC del cliente. Tutto il traffico attraversa un confine virtio-vsock verso un proxy locale, poi un gateway esterno.
L'agente riceve soltanto un certificato SPIFFE valido per la sessione e un token di identità a breve scadenza. Le credenziali reali restano fuori: Agent Gateway le sostituisce al volo nella richiesta, dopo aver verificato host, utente, sandbox, sessione e policy.
Le quattro identità di un agente
Google definisce 4 identità per ogni carico di lavoro agente, ciascuna con una sede e un perimetro distinti:
- User identity: autentica il task complessivo, mai le singole operazioni dell'agente.
- Delegated on-behalf-of identity: la delega crittografica dell'utente, custodita in un servizio di autorizzazione centrale e mai sul nodo di calcolo.
- Agent Workload Identity: identità SPIFFE a breve scadenza, l'unica ammessa nel sandbox; indica solo quale sandbox ha inviato un pacchetto.
- Agent Workforce Identity: l'account e le risorse proprie dell'agente, quando opera come assistente autonomo.
Il risultato pratico è che la terza identità, anche se esfiltrata, non serve a chiamare direttamente le API. Google assume che un attaccante controlli tutto ciò che sta dentro il sandbox: il progetto parte da quel presupposto, non lo esclude.
Agenti in pausa e memoria condivisa
Un agente trascorre gran parte della sua vita in attesa: Anthropic ha misurato che l'80% di una sessione Claude è attesa di una persona. Google costruisce l'efficienza su questo. Quando il sandbox segnala che non ci sono comandi né task in background, l'host esegue un checkpoint della microVM inattiva e la porta a zero risorse attive; alla chiamata successiva lo stato viene ripristinato dallo snapshot.
La densità per host arriva da copy-on-write e dal mapping DAX delle immagini pre-riscaldate: le pagine di sistema operativo e librerie esistono una volta sola per server, e ogni agente consuma memoria privata solo per le pagine che modifica davvero.
I numeri pubblicati riguardano Agent Substrate, non ACE
Accanto al servizio, Google ha annunciato Agent Substrate, runtime open source per Kubernetes che gira su GKE e su qualsiasi altro cluster, in modalità zero-trust, con microVM oppure gVisor, compatibile con framework diversi come Claude Code, OpenClaw e Hermes.
Qui esistono cifre: fino a 10 volte la densità del calcolo tradizionale, un test con 200.000 agenti, 500 attivazioni al secondo e sospensione/ripresa sotto i 500 millisecondi. Con questi valori, attivare una volta l'intera flotta del benchmark richiede 200.000 diviso 500, cioè 400 secondi.
La distinzione è decisiva e va letta con attenzione, perché le testate che hanno coperto l'annuncio non la trattano tutte allo stesso modo. The Decoder lega la densità "10 volte" ad Agent Substrate; MarkTechPost elenca gli stessi valori sotto il fratello open source; la ricostruzione italiana è la più esplicita nel separare i due prodotti. Per Agent Compute Engine non esistono tempo di avvio, densità per server, prezzo o data di preview. E i benchmark di Substrate li ha misurati Google, senza dettagli su hardware e metodo.
Hervé Bizira, Chief Business Officer di Nous Research, sintetizza il beneficio della piattaforma: risolve il problema "preservando risorse di calcolo preziose".
La governance si allarga a Cloud Run, GKE e ai portatili
La seconda metà dell'annuncio riguarda il controllo. Arrivano token tracking con attribuzione della spesa e tetti di budget, model routing e supporto per identity provider di terze parti come Ping Identity e SailPoint. Queste funzioni si estendono a Cloud Run, GKE, Agent Runtime e managed endpoint.
Le funzioni di Agent Gateway entrano in preview nel trimestre; la governance cross-cloud e ibrida via proxy Envoy è annunciata per breve tempo, così come il controllo degli agenti locali come Claude Code e Antigravity CLI sui dispositivi gestiti.
Cosa cambia per chi costruisce agenti
Due conseguenze concrete. La prima è architetturale: su Agent Compute Engine non si può più incorporare una chiave nel codice dell'agente e lasciarlo lavorare, perché ogni chiamata a un backend passa per Agent Gateway dopo i controlli di policy. Chi ha costruito agenti "tutto dentro il container" deve rifare il percorso di autenticazione, non solo spostarlo.
La seconda riguarda il conto. Zero credenziali, nessuna interfaccia di rete e una sola identità spendibile nel sandbox riducono il perimetro d'attacco a chi riesce a far ragionare male l'agente, non a chi riesce a sottrarre un token. Ma la governance degli agenti locali su Claude Code e Antigravity CLI dice altro: Google sa che molti agenti girano fuori dalla sua infrastruttura, sul portatile dello sviluppatore, e che il controllo deve seguirli lì.
Il test vero, per chi dovrà scegliere, non sarà la dimostrazione con Gemini. Sarà poter mettere un prezzo per agente in un foglio di budget: oggi quel numero non esiste.
Fonti
