Docker Sandboxes 0.39 rend les environnements d’agents IA déclaratifs avec .sbxenv.yaml

19 août 2026. 0.39.0. Un fichier YAML. Docker vient de donner aux environnements d’agents IA ce que le Dockerfile a donné aux conteneurs il y a une décennie : une forme déclarative, versionnée et reproductible. La version 0.39.0 de Docker Sandboxes, publiée le 19 août 2026, introduit les sandbox environments : un fichier .sbxenv.yaml décrit l’agent, l’espace de travail, les kits, les variables d’environnement, les secrets, les ports et les limites de ressources, puis sbx env run reproduit l’environnement à l’identique.

L’enjeu n’est pas cosmétique. Aujourd’hui, un développeur qui lance un agent Claude Code dans une sandbox reconstruit son environnement à la main — ou pire, le laisse évoluer sans trace. Le fichier .sbxenv.yaml transforme cet état implicite en artefact de code, auditable et diffable comme le reste du dépôt.

Un Dockerfile pour l’agent, pas pour l’image

La mécanique est simple à lire. Un fichier .sbxenv.yaml déclare l’ensemble de ce qui constitue l’environnement : l’agent utilisé, l’espace de travail monté, les kits à installer, les variables d’environnement, les secrets, les identifiants de registre, les ports exposés et les plafonds de ressources. Une fois le fichier commité dans le projet, n’importe quel contributeur lance sbx env run et obtient la même sandbox, sans reconstituer la configuration de mémoire.

Le cycle de vie se pilote par des commandes dédiées : sbx env create, sbx env exec et sbx env rm. Deux propriétés le distinguent d’un simple script de setup. D’abord, les fichiers se combinent : un fichier partagé peut porter la configuration commune, surchargée localement par un second fichier. Ensuite, les valeurs peuvent référencer des variables d’environnement de l’hôte, ce qui évite de coder en dur des chemins ou des identifiants propres à chaque machine.

La fonctionnalité est marquée expérimentale. C’est le signal habituel chez Docker : le format bougera encore, mais la direction — rendre l’environnement d’agent aussi reproductible que le build d’une image — est assumée.

La chaîne d’approvisionnement devient un vrai sujet

Le point le plus structurant de la sortie n’est pas le YAML. C’est que la sandbox devient un objet qu’on signe, qu’on gouverne et qu’on audite.

Trois briques le montrent. Les kits se signent. Depuis la 0.39.0, un kit peut être signé et vérifié avec des signatures Sigstore compatibles cosign, via sbx kit sign et sbx kit verify, avec une politique de vérification optionnelle au chargement. Les secrets deviennent dynamiques. sbx secret set peut désormais résoudre une valeur depuis une référence ou une commande, avec contrôle du rafraîchissement, de la vérification et des erreurs. Les images se redirigent. Le paramètre platform.images.registryMirror renvoie les images de modèles et de kits vers le miroir de registre de l’organisation.

Ce trio répond à une vraie inquiétude : si l’environnement d’un agent contient des secrets, des identifiants de registre et des kits tiers, il devient lui-même un vecteur de supply chain. La 0.38.0, publiée le 6 août 2026, avait déjà posé la première pierre avec le MCP gateway : des serveurs MCP enregistrés une fois, réutilisés entre agents, les identifiants OAuth restant sur l’hôte, et une gouvernance par politiques Cedar.

Le reste de la 0.39.0

La sortie accumule des améliorations qui dessinent un produit en voie de maturité. Le passage USB devient possible en expérimental (--usb, Linux x86_64/ARM64 uniquement), derrière le flag DOCKER_SANDBOXES_FEATURE_SANDBOX_USB. Le backend Ollama se sélectionne par --provider ollama plutôt que par un préfixe dans le nom du modèle. Les sandboxes arrêtées se nettoient en masse avec sbx prune. Chaque sandbox s’identifie via les variables SANDBOX_NAME et SANDBOX_ID, l’ancien SANDBOX_VM_ID étant déprécié. Et le /remote-control de Claude Code fonctionne désormais dans une sandbox via sbx settings set claude.remoteControl true.

Deux correctifs méritent l’attention. D’abord, les kits déclarant un volume persistant sans taille reçoivent maintenant 512 Mo au lieu de 50 Go, ce qui réduit fortement l’empreinte disque sur l’hôte. Ensuite, les sandboxes Claude consomment environ 3,9 Go de moins sur la machine hôte. Pour un parc de postes ou de runners, ces deux détails changent la facture réelle.

L’isolation par microVM, pas par conteneur

La promesse de sécurité des sandboxes repose sur un choix d’architecture assumé : chaque sandbox tourne dans une microVM, pas dans un simple conteneur. L’espace de travail est monté depuis l’hôte, la mise en réseau est propre à la sandbox, et les identifiants — notamment les jetons OAuth des serveurs MCP — restent sur l’hôte, jamais copiés dans l’environnement.

C’est ce qui rend acceptable l’exécution de code produit par un agent tiers. Un agent qui corrige du code et ouvre une pull request exécute des opérations que personne n’a relues une à une : la microVM borne l’impact d’une dérive, et les politiques réseau, comme le flag --deny-network HOST introduit en 0.38.0, empêchent l’exfiltration. La sandbox devient un périmètre de confiance traçable, pas un conteneur de plus dans le pipeline.

Le corollaire est une charge de gouvernance. À mesure que les kits se signent, que les secrets deviennent dynamiques et que les serveurs MCP se centralisent dans le gateway sbx mcp, l’équipe sécurité dispose enfin des points de contrôle qui lui manquaient : une politique Cedar peut refuser l’enregistrement d’un serveur MCP ou l’appel d’un outil précis, sans toucher au code des agents.

Pourquoi la CI est le vrai terrain de jeu

Le billet d’accompagnement de Docker, Running AI agents in GitHub Actions with Docker Sandboxes, donne le cas d’usage canonique : un agent isolé qui exécute des tests Testcontainers, corrige du code et ouvre une pull request en brouillon. C’est là que le .sbxenv.yaml prend tout son sens. En CI, l’environnement de l’agent doit être identique à chaque exécution, auditable après coup et reproductible par n’importe quel reviewer. Un fichier versionné répond aux trois exigences, là où une sandbox créée interactivement ne répond à aucune.

La contrepartie est une surface d’attaque et de gouvernance élargie : chaque kit tiers, chaque serveur MCP et chaque secret dynamique devient un composant de la chaîne. La signature Sigstore et les politiques Cedar ne sont pas des options confort — ce sont les contrôles minimaux si l’agent touche au code de production.

Le flux de travail au quotidien

Pour mesurer ce que change la 0.39.0, il suffit de dérouler une journée type. Le développeur démarre par sbx env run : la sandbox se crée depuis le .sbxenv.yaml du dépôt, installe les kits déclarés et ouvre une session interactive. Le changement de modèle ne passe plus par un préfixe dans le nom — sbx run --model sélectionne désormais le backend Ollama via --provider ollama. Les secrets sensibles ne sont plus saisis à la main : sbx secret set les résout depuis une référence ou une commande, avec rafraîchissement contrôlé.

La maintenance s’aligne sur celle d’un parc de conteneurs. sbx prune nettoie les sandboxes arrêtées en masse, sans jamais toucher une sandbox en cours d’exécution, et filtre sur l’ancienneté de l’arrêt. sbx diagnose signale l’espace disque disponible et détecte une configuration SSH cassée ou masquée. Et quand le poste ne fournit pas d’hyperviseur — par exemple une machine virtuelle sans virtualisation imbriquée — le message d’erreur le dit clairement au lieu d’échouer après trente secondes.

C’est ce maillage de petites commandes qui transforme la sandbox d’un gadget en outil d’équipe : chaque étape est scriptable, chaque état est inspectable, et chaque incident a un diagnostic.

Verdict

Si vos agents IA tournent en CI ou sur des runners partagés, adoptez .sbxenv.yaml maintenant : la reproductibilité et la traçabilité qu’il apporte dépassent largement son statut expérimental. Verrouillez en même temps la vérification de signature des kits au chargement et la gouvernance des serveurs MCP par politiques, avant qu’un kit tiers non signé ne devienne la porte d’entrée.

Si vous n’utilisez des sandboxes que ponctuellement, en local, attendez une version qui stabilise le format YAML, mais observez la direction : l’environnement d’agent devient un artefact de code comme les autres. Les équipes qui l’auront intégré tôt auront une longueur d’avance quand Docker sortira le flag de stable.

Références

• Docker Sandboxes release notes — 0.39.0, 19 août 2026
• Sandbox environments — Docker Docs, consulté le 23 août 2026
• Running AI agents in GitHub Actions with Docker Sandboxes — Docker Blog, consulté le 23 août 2026
• docker/sbx-releases — version 0.39.0, 19 août 2026