Google Agent Compute Engine : une microVM matérielle par agent, zéro credential dans le sandbox

Google Agent Compute Engine : une microVM matérielle par agent, zéro credential dans le sandbox

🔎 La plomberie de Gemini devient un produit — et c'est plus important qu'un nouveau modèle

Le 22 octobre, à AGNTCon+MCPCon organisé sous l'égide de la Linux Foundation, Google Cloud a annoncé Agent Compute Engine (ACE). Pas un modèle, pas un framework : l'infrastructure d'exécution qui fait tourner les agents de Gemini et d'Antigravity en interne, industrialisée et vendue comme service.

Pourquoi maintenant ? Parce que le goulot d'étranglement des agents a changé. La question n'est plus de faire fonctionner un agent — c'est d'en exécuter des dizaines de milliers sans qu'aucun ne fuie un token OAuth, et sans que la facture explose pour des processus qui dorment 95 % du temps en attendant un humain ou un déclencheur.

C'est exactement le problème que Google prétend résoudre, avec des chiffres agressifs : reprise d'un agent suspendu en moins de 500 ms, plus de 1 000 agents dormants par hôte, 500 activations par seconde sur une flotte de 200 000 agents. Des chiffres constructeur, à prendre comme tels — mais l'architecture, elle, se vérifie dans les détails techniques.

Reste une précision honnête : c'est une annonce, pas une disponibilité générale. Preview « dans les mois à venir », aucun prix publié, aucun chiffre de démarrage à froid. Ce qu'on sait vient de l'annonce officielle de Google Cloud, d'un deep dive technique et d'une analyse de The New Stack. Décortiquons ce qui est solide, et ce qui ne l'est pas encore.

L'essentiel

• Une microVM isolée matériellement par agent : chaque agent tourne dans sa propre machine virtuelle légère, sans interface réseau standard — toute sortie passe par un canal virtio-vsock puis un proxy.
• Zéro secret dans le sandbox : ni token OAuth, ni clé de service dans la microVM. Les credentials sont injectés hors sandbox par l'Agent Gateway, via un token swap en vol.
• Quatre identités agent : user, delegation, workload (SPIFFE) et workforce — un modèle d'identité pensé pour l'entreprise, pas pour la démo.
• Pause/checkpoint à zéro ressource active : un agent inactif est gelé, sa mémoire partagée en copy-on-write + DAX pour une densité annoncée 10x supérieure.
• Un jumeau open source : Agent Substrate, la version Kubernetes du système, disponible sur GKE depuis le 15 septembre et compatible Claude Code, OpenClaw et Hermes.
• Statut réel : preview « dans les mois à venir », pas de prix, pas de GA. Une déclaration d'intention industrielle, pas un produit achetable.

Outils recommandés

Ce qu'annonce Google — et ce que ce n'est pas

Google annonce un service managé d'exécution d'agents, pas encore disponible. Agent Compute Engine expose sous forme de service cloud les primitives que Google utilise en interne pour Gemini et Antigravity — la suite agent-first lancée avec Antigravity 2.0. C'est le mouvement classique du géant : l'outil qui fait tourner la maison devient un produit.

Le contexte de l'annonce compte. AGNTCon+MCPCon est un événement de la Linux Foundation, c'est-à-dire le terrain neutre où se négocient les standards. Annoncer ACE là-bas, plutôt qu'à une conférence commerciale, envoie un signal : Google joue la carte de l'infrastructure partagée, avec un jumeau open source à l'appui.

Ce que ce n'est pas : un produit disponible. Le calendrier officiel tient en une formule — preview « dans les mois à venir ». Pas de tarif, pas de date de GA, pas de chiffre de démarrage à froid. Mon avis : les benchmarks publiés portent sur le suspend/resume, jamais sur le cold start. Ce silence-là est une information.

À noter aussi : l'annonce empaquette un volet « agent governance » étendu — traçabilité et politiques d'exécution — qui complète la partie compute. Logique : une microVM par agent sans gouvernance ne sert à rien en entreprise.

Une microVM par agent, sans interface réseau : l'architecture décortiquée

Chaque agent s'exécute dans une microVM isolée au niveau matériel, dépourvue d'interface réseau standard. C'est le choix le plus radical de l'annonce, et celui qui dit le mieux l'intention de Google : traiter un agent comme un processus non fiable, jamais comme un collègue de confiance.

Concrètement : pas de carte réseau virtuelle classique, pas de pile IP exposée au guest. Toute communication sortante emprunte virtio-vsock, un canal socket hôte-invite du standard virtio, vers un proxy côté hôte qui décide de ce qui passe. Un agent compromis ne peut pas ouvrir une connexion arbitraire vers l'extérieur : chaque flux est médié, journalisé, filtrable par politique.

Le périmètre d'explosion est réduit d'autant. Un agent piégé par une injection de prompt — le risque numéro un en production — reste confiné dans sa microVM : pas de mouvement latéral, pas de scan interne, pas d'appel sortant non autorisé. Le stockage suit la même logique, avec un volume Hyperdisk dédié par microVM.

Ce n'est pas une lubie de Google, c'est une tendance de fond. Jensen Huang veut enfermer les agents IA dans des conteneurs, comme les navigateurs — le parallèle est exact : on a appris à isoler du code non fiable venu du web, on va apprendre à isoler du code semi-autonome qui agit pour vous. Et l'enjeu monte d'un cran depuis que Google Research laisse les agents réécrire le système qui les entoure : quand l'agent peut modifier son propre environnement, l'isolation matérielle cesse d'être une option.

Point de transparence : Google ne détaille pas l'hyperviseur utilisé derrière ces microVMs. L'isolation « matérielle » annoncée place le curseur au-dessus des sandboxes conteneurisées — c'est le niveau Firecracker ou équivalent.

Zéro secret dans le sandbox : le token swap en vol via Agent Gateway

La microVM ne contient aucun credential : ni token OAuth, ni clé de service, jamais. L'injection se fait à l'extérieur du sandbox, au moment de l'appel, par l'Agent Gateway. C'est, à mon sens, la partie la plus importante de l'annonce.

Le problème résolu est bien connu des équipes qui produisent des agents. Aujourd'hui, on colle le token GitHub dans une variable d'environnement, la clé d'API dans le secret manager du pod — et l'agent, s'il est manipulé par une injection de prompt, peut lire son propre environnement et exfiltrer ce qu'il contient. Le secret dans le sandbox, c'est le secret à portée de main de l'attaquant.

L'approche ACE inverse le modèle. L'agent s'exécute avec une identité interne anonyme, sans aucun secret. Quand il émet un appel sortant, la requête transite par l'Agent Gateway, qui effectue un token swap en vol : il retire l'identité interne, attache le vrai credential — token OAuth, clé de service — au dernier saut, hors de la microVM. L'agent ne peut pas fuir ce qu'il n'a jamais possédé.

Ce modèle s'appuie sur quatre identités agent distinctes, présentées par Google :

• User : l'agent agit en tant que l'utilisateur final, avec ses droits.
• Delegation : l'agent agit au nom de l'utilisateur, avec des scopes restreints et traçables.
• Workload : identité machine de l'agent elle-même, au standard SPIFFE, la référence open source des identités de workload.
• Workforce : identité de l'agent comme membre de l'organisation, pour les agents internes d'entreprise.

Pourquoi c'est structurant : la question « qui a fait quoi ? » a une réponse par construction, et la surface d'exfiltration des secrets disparaît du sandbox. De quoi alimenter le débat sur l'authentification des serveurs MCP, au cœur de MCPCon. Car les frameworks actuels — Claude Code, OpenClaw, un agent maison — placent presque tous vos tokens dans l'environnement d'exécution. Le jour où vos agents tournent 24/7 avec des accès en écriture, ce détail devient la ligne rouge entre la démo et la production.

Pause, checkpoint, densité 10x : l'économie du modèle

Un agent inactif est suspendu à zéro ressource active, et Google revendique une densité de 10x grâce à la mémoire copy-on-write. C'est le volet qui rend le modèle économiquement viable — et peut-être le plus difficile à reproduire.

Le constat de départ : un agent passe l'essentiel de sa vie à ne rien faire. Il attend une validation humaine, un déclencheur, le résultat d'un outil. Hébergé classiquement, il consomme CPU et RAM pendant cette attente. À l'échelle de milliers d'agents, c'est intenable.

La réponse d'ACE : pause/checkpoint. L'agent inactif est gelé — mémoire capturée, zéro ressource active — puis repris à la demande. Selon le deep dive de Google Cloud, la reprise prend moins de 500 ms, avec 500 activations par seconde mesurées sur une flotte de 200 000 agents. Et plus de 1 000 agents dormants par hôte, rendus possibles par deux techniques : la mémoire de base partagée en copy-on-write (les agents dormants lisent les mêmes pages, la copie n'a lieu qu'à l'écriture) et le mapping direct type DAX, qui évite de dupliquer l'image mémoire de référence.

Autrement dit : du serverless pour agents, mais avec l'isolation d'une VM au lieu d'un conteneur. La facturation suivra vraisemblablement le temps actif — mais Google n'a rien publié sur le pricing, je le répète.

Deux réserves de journalisme. Un : ces chiffres sont des annonces constructeur, mesurées sur l'infrastructure de Google, pas un benchmark indépendant reproductible. Deux : ils portent sur le resume, pas sur le démarrage à froid d'une microVM neuve — donnée absente des posts, et pourtant décisive pour les agents déclenchés par événement.

Agent Substrate : le jumeau open source qui désamorce le lock-in

Google publie aussi Agent Substrate, la version Kubernetes ouverte du même système, disponible sur GKE depuis le 15 septembre. Autrement dit : la partie la plus intéressante de l'annonce est déjà testable, sans attendre la preview d'ACE.

Substrate apporte les mêmes primitives sur un cluster Kubernetes : microVM par agent, pause/checkpoint, modèle d'identité. La compatibilité annoncée est large — les runtimes agents majeurs sont visés, dont Claude Code (qui tire le meilleur de Claude Opus 4.7 ou Claude Sonnet 4.6 selon vos besoins), OpenClaw et Hermes. Côté Hermes, l'écosystème d'extensions et plugins devient directement exécutable dans ce type d'infrastructure.

Pourquoi open-sourcer le jumeau de votre produit managé ? Parce que ça neutralise l'objection numéro un — le lock-in — au moment précis où AWS et Azure occupent le même terrain. Et parce que ça alimente la dynamique de standardisation portée par la Linux Foundation : si les primitives (identité, isolation, cycle de vie) deviennent des briques communes, Google vend de l'excellence d'exploitation, pas une cage.

Pour les équipes qui auto-hébergent déjà leurs agents — typiquement avec des modèles locaux via Ollama — Substrate est la voie réaliste vers ce modèle d'isolation sans dépendre du cloud de Google. Si vous partez de zéro, notre guide pour créer un agent IA couvre les bases avant d'aborder ce niveau d'infrastructure.

Face à AWS AgentCore, Azure dynamic sessions et E2B : qui apporte quoi

Personne ne combine aujourd'hui isolation matérielle, zéro secret dans le sandbox et suspend/resume massif — mais les chiffres de Google sont des promesses, quand ceux d'AWS sont un produit en GA.

Lecture rapide. AgentCore est le produit à battre sur la maturité : GA, intégration Bedrock, limites documentées (8 heures par microVM de session, instances jusqu'à 14 jours). Mais la gestion des credentials reste largement à votre charge — c'est précisément là que Google frappe.

Azure dynamic sessions excelle sur un créneau différent : démarrer un sandbox de code en sub-seconde pour un interpréteur ou un serveur MCP. C'est du jetable court-cycle, pas de l'hébergement d'agents longévifs avec identité d'entreprise.

E2B reste mon choix par défaut pour prototyper : open source, excellente expérience développeur, microVMs Firecracker. Mais vous y gérez vous-même le problème des secrets — exactement ce qu'ACE prétend industrialiser.

Le verdict honnête : l'avance revendiquée par Google est réelle sur le papier (credentials + pause/resume + densité), mais elle est invérifiable tant qu'il n'y a ni preview publique ni prix. AWS a l'expérience du GA ; Google a peut-être la meilleure architecture. La réponse s'écrira au moment du GA — et au moment des tarifs.

Ce que ça change selon votre profil

Rien aujourd'hui si vous n'êtes pas sur GCP ; beaucoup demain si vous produisez des agents en entreprise. Le calendrier d'adoption dépend moins de la technologie que de votre plateforme actuelle.

Vous êtes une entreprise sur GCP : testez Agent Substrate sur GKE dès maintenant, il est disponible depuis le 15 septembre. C'est le meilleur moyen d'évaluer la promesse ACE avec vos propres workloads, avant que la preview managée n'ouvre.

Vous êtes une équipe AWS : AgentCore Runtime est en GA et fait le travail d'isolation par session. Surveillez le pricing d'ACE à sa sortie — la bataille se jouera sur le coût d'un agent dormant et sur la gouvernance des identités.

Vous êtes développeur solo ou petite équipe : E2B ou Substrate auto-hébergé couvrent 90 % des besoins. Pour vos expérimentations, un VPS simple suffit largement — Hostinger fait tourner un agent de veille pour quelques euros par mois. Côté modèles, les APIs IA gratuites permettent de tester sans carte bancaire, et notre sélection des meilleurs LLM pour les agents IA vous aide à choisir le cerveau — d'un GPT-5.5 généraliste à un Claude Opus 4.7 pour le raisonnement long.

Vous êtes RSSI ou architecte sécurité : le modèle des quatre identités est la conversation à lancer maintenant, avant même la preview. Cartographiez quels agents de votre SI agissent en tant que qui — user, delegation, workload, workforce — et vous aurez une longueur d'avance quand l'outil arrivera.

Et pour choisir par-dessus l'infrastructure : notre comparatif des meilleurs agents IA autonomes passe au crible les runtimes qui tourneront demain dans ces microVMs.

❌ Erreurs courantes

Erreur 1 : planifier une migration sur une annonce

ACE n'a ni prix, ni GA, ni chiffre de cold start. Ce qui ne va pas : bâtir une roadmap sur un post de blog. La solution : pilotez Agent Substrate sur GKE pour valider les primitives, et gardez ACE comme option d'achat à évaluer au moment du GA.

Erreur 2 : croire que la microVM remplace votre gouvernance

L'isolation matérielle et le token swap éliminent deux classes de risques — le mouvement latéral et l'exfiltration de secrets. Pas les autres. Politiques d'autorisation, audit des actions, limitation des scopes en delegation : ça reste votre travail. Et n'importe pas vos tokens dans l'environnement par habitude : le modèle ne tient que si le sandbox reste vide.

Erreur 3 : comparer les benchs d'annonce aux SLA de production

Les 500 ms de resume et les 1 000 agents dormants par hôte sont des chiffres Google, mesurés sur la flotte Google. Ce ne sont pas des SLA, et rien n'indique qu'ils seront contractuels à la preview. Benchmark sur vos workloads, avec vos modèles — un agent propulsé par Gemini 3.1 Pro n'a pas le même profil mémoire qu'un agent GPT-5.5 chargé d'outils lourds.

❓ Questions fréquentes

Quand Agent Compute Engine sera-t-il disponible ?

Google annonce une preview « dans les mois à venir », sans date de GA ni conditions d'accès. En attendant, Agent Substrate — le jumeau open source — est disponible sur GKE depuis le 15 septembre. Les deux posts du blog Google Cloud restent les sources de référence pour suivre le calendrier.

Quel est le prix d'Agent Compute Engine ?

Aucun tarif n'a été publié à l'annonce. On peut s'attendre à une facturation au temps actif — le pause/checkpoint y invite —, au vCPU, à la mémoire et au stockage Hyperdisk, mais c'est de la spéculation. Comparez au moment du GA avec la facturation à l'usage d'AgentCore, et vérifiez sur cloud.google.com.

Agent Substrate remplace-t-il Agent Compute Engine ?

Non, ce sont deux faces du même système. Substrate est la version open source sur Kubernetes, que vous opérez vous-même sur GKE ou ailleurs. ACE est le service managé, avec les optimisations d'échelle de Google (densité 10x, activations par seconde). Substrate pour le contrôle, ACE pour déléguer l'exploitation.

Est-ce compatible avec Claude Code, OpenClaw ou Hermes ?

Agent Substrate revendique la compatibilité avec ces trois runtimes, ce qui permet d'exécuter des agents propulsés par Claude Opus 4.7, GPT-5.5 ou un modèle local dans des microVMs isolées. Pour ACE, Google n'a montré que sa propre pile — la compatibilité des runtimes tiers reste à confirmer à la preview.

Faut-il quitter AWS AgentCore pour ACE ?

Non, pas aujourd'hui. AgentCore est en GA avec des limites claires (sessions jusqu'à 8 h par microVM, instances jusqu'à 14 jours) et une intégration AWS complète. ACE est une architecture prometteuse mais non disponible et sans prix. Réévaluez au GA, avec vos chiffres réels d'agents dormants.

✅ Conclusion

Google vient de dire tout haut ce que l'industrie des agents chuchote depuis des mois : la bataille se joue dans l'infrastructure — isolation matérielle, zéro secret, agents qui s'endorment sans coûter un centime — et non dans un point de benchmark de plus. L'architecture d'Agent Compute Engine est la plus aboutie jamais présentée publiquement ; le produit, lui, reste à naître. En attendant la preview, testez Agent Substrate sur GKE — c'est le seul morceau de cette annonce que vous pouvez toucher dès aujourd'hui.