Google ouvre son infrastructure sécurisée pour agents aux clients du cloud

Google se prépare à rendre publique l'infrastructure interne qui alimente ses agents Gemini sous forme de service cloud. Annoncé lors de la conférence AGNTCon+MCPCon de la Linux Foundation à San Jose, Agent Compute Engine entrera en phase d'aperçu pour les utilisateurs de Google Cloud plus tard cette année, offrant des microVM à isolation matérielle pour l'exécution d'agents IA.

Ce qui s'est passé

Le nouveau service, Agent Compute Engine, fournit à chaque agent IA sa propre microVM isolée. Cette architecture combine les temps de démarrage rapides des conteneurs avec les frontières de sécurité robustes des machines virtuelles traditionnelles. Cette annonce marque un tournant significatif, car Google fait passer cette technologie d'un usage interne pour Gemini, Antigravity et les pipelines d'entraînement de modèles à une offre commerciale destinée aux développeurs externes.

Ce lancement place Google en concurrence directe avec d'autres grands fournisseurs proposant des bacs à sable pour agents. Des startups comme E2B et Daytona offrent déjà des environnements similaires, utilisant souvent des microVM Firecracker ou une isolation basée sur des conteneurs. AWS propose également Bedrock AgentCore, qui attribue à chaque session d'agent sa propre microVM et suspend la facturation pendant les périodes d'inactivité. L'entrée de Google tire parti de son échelle massive, visant à soutenir la croissance rapide des charges de travail agentiques, qui sont devenues parmi les plus grandes consommatrices de calcul et de stockage dans ses centres de données.

Comment cela fonctionne

Agent Compute Engine répond à la tension entre vitesse et sécurité dans l'exécution des agents. Les machines virtuelles traditionnelles offrent une forte isolation mais sont trop lentes au démarrage et à la suspension pour les tâches éphémères typiques des agents IA. Les conteneurs sont rapides mais manquent de l'isolation au niveau du noyau nécessaire pour une exécution de code sûre. La solution de Google utilise une microVM à isolation matérielle qui démarre rapidement et peut être pointée (checkpointed) lorsqu'elle est inactive. Lorsqu'un agent attend une réponse du modèle ou une saisie utilisateur, l'hôte sauvegarde l'état de la microVM sur disque et libère les ressources actives, reprenant instantanément lorsque c'est nécessaire.

La sécurité est intégrée dès la base de chaque session. Chaque microVM s'exécute sur un hôte sans état avec un système de fichiers en lecture seule, vérifié cryptographiquement au démarrage via la plateforme de sécurité Titan et Titanium IPU de Google. Les microVM elles-mêmes fonctionnent sur Cloud Hypervisor, un moniteur open source, et chaque instance dispose de son propre noyau invité et d'un accès root. Crucialement, ces environnements ne conservent aucun secret en mémoire ou sur disque. L'identité est gérée via des jetons de courte durée et limités à la session, et tout le trafic est chiffré. L'accès réseau est proxifié à l'extérieur du bac à sable, les identifiants n'étant injectés qu'après vérification de la délégation utilisateur via le Gateway Agents de Google.

Détails clés

• Agent Compute Engine sera disponible en aperçu pour les utilisateurs de Google Cloud plus tard en 2026.
• Chaque agent s'exécute dans une microVM mono-locataire à isolation matérielle avec son propre noyau invité.
• Le système effectue des points de contrôle (checkpoints) des microVM inactives pour libérer les ressources actives tout en préservant l'état.
• La sécurité repose sur les plateformes Titan et Titanium IPU de Google pour la vérification matérielle.
• Aucun secret n'est stocké en mémoire ou sur disque dans l'environnement du bac à sable.
• Tout le trafic réseau est proxifié et chiffré, les identifiants étant gérés hors de la VM.

Pourquoi c'est important

Pour les ingénieurs développant des systèmes agentiques, la sécurité reste le principal obstacle à l'adoption. Les agents nécessitent souvent un accès de niveau root pour exécuter du code, naviguer sur le web ou interagir avec des scripts shell, créant un risque significatif s'ils sont compromis. En fournissant un bac à sable où un attaquant contrôlant l'agent ne trouve rien de valeur, Google réduit la responsabilité associée à l'exécution de code non fiable. Cette approche « rien à voler » permet aux développeurs d'accorder des permissions plus larges aux agents sans exposer des infrastructures sensibles ou des identifiants.

Les gains d'efficacité issus du checkpointing des agents inactifs impactent également les coûts et la scalabilité. Puisque les agents passent la plupart de leur temps à attendre des entrées externes, payer pour des ressources de calcul complètes durant ces périodes est gaspilleur. En suspendant la microVM et en libérant les ressources CPU actives, l'infrastructure peut supporter des densités plus élevées d'agents concurrents. Ce modèle soutient les boucles longues pouvant durer plusieurs semaines, permettant des workflows complexes comme l'apprentissage par renforcement et l'évaluation de modèles à grande échelle, qui étaient auparavant difficiles à gérer économiquement.

Ce que vous pouvez faire

• Surveillez la console Google Cloud pour le lancement de l'aperçu d'Agent Compute Engine plus tard cette année.
• Évaluez vos charges de travail agentiques actuelles pour identifier les tâches nécessitant une isolation de niveau root versus une simple conteneurisation.
• Revoyez les protocoles de sécurité pour la gestion des identifiants des agents afin de les aligner sur les modèles d'identité basés sur proxy.
• Envisagez de tester Agent Substrate sur vos clusters Kubernetes existants si un service managé n'est pas préféré.
• Effectuez des benchmarks des temps de suspension et de reprise des agents pour estimer les économies potentielles issues du checkpointing des états inactifs.
• Explorez l'intégration avec des outils comme Claude Code ou OpenClaw si vous utilisez le runtime Substrate open source.