Google AX isole les agents IA dans Kubernetes

AX sépare l’agent du cluster

Ce qui compte le plus dans AX n’est pas Kubernetes lui-même, mais la tentative de faire de l’exécution de code d’agent potentiellement non fiable une entité d’infrastructure distincte. Dans le dépôt officiel de Google, le projet est présenté comme un runtime déclaratif qui isole les tâches, connecte les espaces de travail, limite le réseau sortant et met à l’échelle les charges d’agents sur un cluster.

En septembre 2026, AX, ou Agent Executor, est publié sous licence Apache 2.0. Ses principaux primitifs illustrent clairement le modèle d’exécution : Task lance une tâche d’agent, Workspace lui fournit un contexte de fichiers ou un dépôt, Gateway définit l’accès extérieur, et Model configure le fournisseur de modèle ainsi que les identifiants.

Il ne s’agit donc pas d’un simple Kubernetes Job avec un conteneur. AX vise des processus d’agents durables et avec état, qui ont besoin d’un contexte de travail géré et d’une frontière réseau nette. Ce sont précisément les éléments qui deviennent difficiles à maîtriser lorsqu’un agent peut écrire des fichiers, exécuter du code et contacter des systèmes externes.

AX n’est toutefois pas autonome. La documentation du dépôt cite parmi les prérequis un cluster Kubernetes, le générateur d’images ko, un registre de conteneurs accessible au cluster et l’Agent Substrate Control API. Une grande partie de l’exécution réelle se trouve dans Agent Substrate, tandis qu’AX assure la gestion déclarative et l’orchestration.

Google présente AX comme un orchestrateur haute performance conçu pour des milliards de charges d’agents autonomes par cluster. L’affirmation est ambitieuse, mais les documents disponibles ne proposent pas de suite officielle de benchmarks reproductibles. Pour l’instant, c’est un objectif architectural, pas un chiffre sur lequel je m’appuierais pour dimensionner une plateforme.

L’isolation devient une partie du modèle d’agent

AX apporte un changement utile : la sécurité de l’agent ne dépend plus d’un ensemble de conventions internes à l’application, mais d’objets d’infrastructure distincts. Le réseau, l’espace de travail, le modèle et la tâche exécutable reçoivent des frontières explicites, descriptibles et contrôlables via un processus proche de Kubernetes.

Cette approche profite surtout aux plateformes où des agents différents, avec du code non fiable ou des droits d’accès distincts, fonctionnent simultanément. Pour une petite installation, le coût d’entrée peut être élevé : au-delà de Kubernetes, il faut gérer un registre, la construction des images et une couche Agent Substrate séparée.

Je vérifierais d’abord non pas l’échelle annoncée, mais la solidité des frontières : contournement du Gateway réseau, traitement des identifiants de modèle, reprise des longues tâches et comportement lors des défaillances de la couche de contrôle. L’idée d’AX est saine, mais sa valeur dépendra de la capacité à contenir de manière prévisible un agent défaillant dans sa propre sandbox.

Nous avons précédemment expliqué comment déployer un agent IA autonome auto-hébergé avec des contrôles DevOps sécurisés et une exploitation continue. La sandbox AX de Google prolonge cette réflexion en apportant l’isolation Kubernetes aux charges des agents.