Docker a annoncé la disponibilité de Cloud Sandboxes pour exécuter des agents d’intelligence artificielle dans des environnements microVM isolés. Le développeur peut ainsi commencer une tâche localement, puis transférer le système de fichiers vers l’infrastructure cloud de Docker afin de poursuivre les tâches de longue durée, avant de rapatrier les résultats pour examen. Cette initiative s’accompagne de la publication de la spécification Sandbox Kit sous licence Apache 2.0, Docker s’engageant à la soumettre à la Cloud Native Computing Foundation (CNCF) pour une gouvernance neutre.
L’entreprise a présenté ces évolutions lors de la conférence WeAreDevelopers World Congress North America, organisée à San José du 23 au 25 septembre 2026, à laquelle ont assisté plus de 10 000 développeurs, créateurs d’applications d’intelligence artificielle et responsables techniques, selon Docker.
Un environnement d’exécution séparé pour les tâches de longue durée
Chaque environnement Cloud Sandbox se compose d’une microVM, c’est-à-dire une petite machine virtuelle disposant de son propre noyau et de son propre daemon Docker. L’agent qui s’y trouve peut installer des dépendances, construire des applications et exécuter des conteneurs, tandis que Docker fournit la capacité de calcul nécessaire. Le développeur utilise le même outil en ligne de commande, sbx, lorsqu’il travaille localement ou dans le cloud.
En pratique, le service vise des tâches telles que la restructuration ou la migration de logiciels, qui peuvent prendre plus de temps que la durée pendant laquelle un ordinateur portable peut rester allumé. Plusieurs tâches peuvent être exécutées en parallèle sans mobiliser les ressources de la machine locale, tandis que le travail se poursuit dans le cloud même après l’extinction de l’ordinateur. Le service est actuellement disponible et Docker facture la capacité de calcul à la seconde.
Les environnements local et cloud utilisent les mêmes paquets d’agents, appelés Kits, mais les identifiants et les politiques sont configurés séparément dans chaque environnement. Le transfert de la tâche ne transfère donc pas automatiquement toutes les autorisations : il faut décider explicitement des ressources auxquelles l’agent est autorisé à accéder.
Une spécification ouverte pour décrire l’agent et ses autorisations
Sandbox Kit définit l’environnement nécessaire à l’exécution de l’agent dans un format partageable et vérifiable. Le Kit est une image OCI qui comprend l’agent et ses outils, ainsi que les déclarations relatives à l’accès aux réseaux, aux identifiants et au stockage. Les équipes peuvent la construire, la pousser, la tirer, l’inspecter et l’installer à l’aide d’une empreinte numérique, comme elles le font avec les images de conteneurs habituelles.
Ce modèle facilite la reproduction de l’environnement et rend les changements d’autorisations visibles pour les réviseurs. Si un Kit demande une destination réseau ou un identifiant supplémentaire, le changement apparaît dans le paquet, tandis que le runtime décide de ce qui sera effectivement accordé et applique la politique en dehors de l’agent. Docker Sandboxes a été le premier runtime à appliquer la spécification, tandis que Nous Research y a participé en tant que partenaire de lancement avec son agent open source Hermes.
Qu’est-ce qui change en pratique ?
Docker estime que l’isolation de l’exécution ne suffit pas, à elle seule, pour confier des tâches plus importantes aux agents. L’entreprise a présenté l’exemple d’un agent qui a pu lire un secret présent sur l’hôte parce que le socket Docker était connecté au conteneur ; aucune nouvelle vulnérabilité n’a été nécessaire, le résultat découlant des autorisations accordées par la configuration. Lors d’une autre démonstration, une tentative d’accès à l’hôte depuis une microVM a échoué.
Docker a également présenté des politiques qui bloquent par défaut des actions telles que la suppression d’un dépôt GitHub et consignent les décisions de blocage dans des journaux d’audit. L’entreprise a toutefois reconnu les limites de ces contrôles : bloquer une destination réseau non autorisée est différent de détecter qu’un message dont l’envoi est autorisé est adressé au mauvais client. Des autorisations limitées restent donc nécessaires, comme permettre la lecture et la rédaction de messages sans leur envoi, tandis que la vérification de la conformité de l’action avec l’intention de l’utilisateur demeure un défi ouvert.
L’importance de cette annonce tient au fait qu’elle réunit l’isolation de l’agent, la portabilité de son environnement et la description de ses autorisations dans un format ouvert et vérifiable. Les questions auxquelles l’article n’apporte pas de réponse concernent le degré d’adoption de la spécification par d’autres runtimes et la manière d’unifier l’identité de l’agent et les politiques entre les organisations ; Docker a elle-même indiqué que certains de ces points constituent encore des défis pour le secteur.