Google met ses agents IA dans des microVM isolées

Google a présenté le 22 octobre 2026 Agent Compute Engine, un service d’infrastructure qui attribue à chaque agent IA sa propre microVM isolée matériellement. Pensé d’abord pour Gemini, puis ouvert aux clients Google Cloud en aperçu plus tard cette année, il vise un point devenu central dans l’IA agentique : faire tourner des assistants autonomes sans sacrifier ni la sécurité ni les coûts. Le même jour, Google a aussi détaillé Agent Substrate, un runtime open source pour Kubernetes censé absorber les pics de micro-tâches que les clusters classiques gèrent mal.

Chaque agent avec sa propre boîte fermée, sans le syndrome du tiroir à secrets

Agent Compute Engine repose sur une idée simple : un agent n’a pas besoin d’un serveur entier, mais il a besoin d’un environnement qui ne déborde pas. Google lui donne donc une microVM, c’est-à-dire une machine virtuelle légère, avec accès root, noyau dédié et isolation par défaut. Quand l’agent attend un appel de modèle ou un outil, la machine se met en pause, puis reprend plus tard avec son état conservé. Cette approche combine la rapidité des conteneurs et l’isolement d’une VM, sans mélanger les deux au point de créer une surface d’attaque bancale.

Dans son analyse technique, Google explique avoir conçu cette infrastructure après avoir constaté que les VMs traditionnelles restent trop lentes pour des agents qui démarrent et s’arrêtent en continu, tandis que les conteneurs ne suffisent pas dès qu’il faut un contrôle complet du noyau et du système de fichiers. Le service s’appuie sur la pile de sécurité Titanium de Google, sur Cloud Hypervisor et sur un hôte quasi stateless, avec filesystem en lecture seule et vérification cryptographique du matériel et du firmware au démarrage. L’accès aux services externes passe par un proxy hors du bac à sable, qui ajoute les identifiants seulement quand c’est autorisé. Le message est limpide : on part du principe qu’un attaquant contrôle tout à l’intérieur, puis on lui laisse le moins possible. Pas glamour, mais efficace.

Une réponse à l’explosion des agents, pas juste à un besoin de confort

Ce lancement compte parce que les workloads agentiques deviennent vite coûteux à grande échelle. Google dit que ces usages figurent déjà parmi les consommateurs de calcul et de stockage les plus dynamiques de son parc. Pour limiter la facture, la société mise sur la mise en pause automatique des VM inactives et sur une forme de mémoire partagée entre instances, afin de réduire le coût par agent. La version cloud de Google doit aussi s’adapter à des cas très différents : assistants de code, boucles d’évaluation pour les labs, benchmarking ou charges de travail internes de Google.

Agent Substrate prolonge la même logique côté Kubernetes. Ce runtime open source ajoute un plan de contrôle léger pour gérer des millions d’appels outils de courte durée, avec snapshot de la mémoire d’un agent inactif et remise de la machine dans le pool. Google affirme qu’il peut offrir jusqu’à dix fois plus de densité qu’un calcul classique et qu’un test à 200 000 agents a tenu 500 activations par seconde, avec suspension et reprise en moins de 500 millisecondes. Les équipes peuvent choisir microVM ou gVisor, tandis que l’identité cryptographique et les proxys de sortie gardent la main sur les accès. Le tout s’ouvre à des environnements déjà en place, y compris Cloud Run, GKE et des endpoints gérés.

Google n’est pas seul, mais il vise plus large que le simple bac à sable

Le marché n’attendait pas Google pour inventer les environnements jetables d’agents. E2B, Daytona ou AWS avec Bedrock AgentCore proposent déjà des sandboxes, souvent basées sur Firecracker ou des variantes proches. La différence, ici, tient à l’intégration : Google transforme une brique interne qui fait déjà tourner Gemini, Antigravity et ses propres pipelines de formation en produit cloud. De son côté, Agent Substrate vise les équipes qui veulent garder leur infrastructure Kubernetes et éviter de réécrire tout le contrôle des accès.

Autre détail intéressant, Google ajoute des outils d’oversight comme le suivi des jetons, le routage de modèles et la prise en charge d’identités tierces comme Ping Identity et SailPoint. Le sujet ne se limite donc plus à “faire tourner” des agents, mais à savoir qui les contrôle, avec quelle identité et sur quel périmètre. C’est là que la promesse devient concrète pour les entreprises : moins d’expositions inutiles, davantage de gouvernance, et un peu moins de sueurs froides quand un agent décide de lire un e-mail au mauvais endroit. Les intégrateurs n’aiment pas les surprises ; les RSSI encore moins.