Docker Sandboxes (sbx) a changé de nature en 2026 : l'outil n'isole plus un agent de code dans un conteneur qui partage le noyau de l'hôte, mais dans une microVM avec son propre noyau et son propre moteur Docker. C'est un changement de frontière de confiance. Cette évaluation s'appuie sur la documentation officielle Docker et sur la vérification des prérequis d'installation : rien n'a été exécuté.
à retenir
Docker Sandboxes (sbx) isole un agent de code IA dans une microVM, avec son propre noyau, pas dans un conteneur partagé. UDP et ICMP sont bloqués au niveau réseau, non déblocables par policy : ping et les requêtes DNS directes ne fonctionnent pas dans un sandbox. Une faille de sécurité, CVE-2026-17106, a été corrigée en version 0.38.0. Évaluation basée sur la documentation officielle, sans exécution réelle.
Qu'est-ce que Docker Sandboxes ?
Docker Sandboxes est un outil de Docker Inc. qui exécute un agent de code IA (Claude Code, ou tout autre outil qui invoque des commandes shell et modifie des fichiers) dans un environnement isolé, séparé du système hôte. Depuis sa forme actuelle, cet environnement est une microVM : elle embarque son propre noyau et son propre moteur Docker, distincts de ceux de la machine hôte. Le CLI qui pilote cet outil s'appelle sbx. Il fonctionne seul, sans exiger Docker Desktop ni Docker Engine installés sur la machine hôte.
Ce changement d'enveloppe se lit directement dans la façon dont l'agent démarre. Sur Claude Code, la documentation de l'intégration indique que sbx lance par défaut claude --dangerously-skip-permissions, l'option qui supprime les demandes de confirmation avant chaque action de l'agent. La page documente ce comportement sans en exposer la motivation. Concrètement, un agent lancé de cette manière n'attend plus d'accord humain pour écrire un fichier ou exécuter une commande : ce qui l'arrête devient la paroi de la microVM, et rien d'autre.
C'est une différence structurante par rapport à la génération précédente : l'ancienne sous-commande docker sandbox, intégrée à Docker Desktop avant la bascule vers la microVM, isolait l'agent par conteneur, une technique qui partage le noyau de l'hôte. sbx change de mécanisme d'isolation, pas seulement de nom.
Pourquoi le conteneur ne suffisait pas ?
Un agent de code autonome exécute des commandes shell, modifie des fichiers, installe des dépendances : c'est exactement le type de charge que l'isolation par conteneur protège le moins bien, pour deux raisons que Docker détaille dans sa documentation sur l'isolation.
Le daemon partagé
Un conteneur Docker classique s'exécute via un daemon partagé avec l'hôte. Le processus de l'agent tourne dans un namespace isolé, mais il communique avec le même daemon Docker que tous les autres conteneurs de la machine. Une faille dans ce daemon, ou un abus de son API, expose potentiellement l'ensemble des conteneurs qui y sont rattachés, y compris ceux qui n'ont rien à voir avec l'agent IA.
Le noyau partagé
Le second point de friction est plus profond : le conteneur partage le noyau Linux de la machine hôte. Un agent qui exécute des commandes arbitraires interagit, via ce noyau partagé, avec la même surface système que le reste de la machine. Docker Sandboxes répond à ce double problème en changeant de mécanisme : d'après la documentation de sécurité officielle, la microVM embarque un noyau séparé et un moteur Docker propre à la VM, pilotée par un hyperviseur (le logiciel qui virtualise et isole les ressources matérielles entre plusieurs machines virtuelles). Le sandbox n'est plus un voisin de palier du système hôte, il est dans un autre bâtiment.
Que garantit la microVM ?
Une microVM est une machine virtuelle légère, avec son propre noyau et son propre moteur Docker, entièrement séparée du système hôte. C'est la garantie de base documentée par Docker : chaque sandbox tourne dans cet environnement, pas dans un conteneur qui partage le noyau de la machine qui l'héberge. Le système de fichiers, le réseau et la gestion des identifiants en découlent directement, chacun avec sa propre limite.
Système de fichiers
sbx propose 12 variantes de templates (docker/sandbox-templates:*), toutes basées sur Ubuntu, avec un utilisateur par défaut nommé agent. Des variantes -docker embarquent en plus un moteur Docker complet à l'intérieur de la microVM, avec un volume de 10 Go en mode sparse. Chaque sandbox démarre depuis ce template, isolé du système de fichiers de l'hôte par défaut.
Réseau
Le réseau sortant d'un sandbox suit un des trois préréglages documentés : Open, Balanced, ou Locked Down. Une règle peut autoriser une connexion TCP non-HTTP explicite, par exemple SSH via une règle de la forme myhost:22. Mais deux protocoles sont bloqués au niveau réseau, sans exception possible par policy : UDP et ICMP. Concrètement, ping ne fonctionne pas dans un sandbox, et les requêtes DNS directes non plus, puisque la résolution DNS classique passe par UDP.
Credentials
La documentation sur la configuration des credentials précise que l'agent forwarding SSH est activé dès qu'un agent SSH tourne sur le poste hôte (variable SSH_AUTH_SOCK), et que la clé privée SSH n'entre jamais dans la microVM. Les secrets destinés aux services modélisés (clé API, jeton OAuth) sont injectés en en-tête HTTP par un proxy qui tourne côté hôte, avec une sentinelle proxy-managed qui signale leur origine. Pour un credential hors de ce modèle de service, la commande sbx secret set-custom permet de déclarer un couple domaine et variable d'environnement.
Que ne garantit pas la microVM ?
La microVM déplace la frontière de confiance, elle ne l'efface pas. Avant d'accorder un accès large à un agent, trois limites documentées comptent : l'agent reste root à l'intérieur de la sandbox, le poste de travail de l'utilisateur n'est pas importé par défaut, et un secret déjà présent sur le disque au moment de la sauvegarde suit le disque, pas la politique de sécurité.
L'agent est root
L'utilisateur par défaut des templates, agent, est non-root mais dispose du sudo : il peut devenir root à tout moment dans la microVM. Les variantes -docker vont plus loin : le conteneur d'agent créé depuis ces templates tourne en mode privilégié, pour héberger le Docker Engine embarqué, à l'intérieur de la microVM. Toute barrière d'approbation construite sur l'ownership Unix côté hôte (ce fichier appartient à tel utilisateur, l'agent ne peut pas le toucher) ne survit pas au passage en sandbox. Elle est déplacée à l'intérieur de la VM, pas résolue.
Le poste de travail n'est pas importé
Par défaut, ~/.claude n'est pas importé dans le sandbox, et les liens symboliques qui pointent vers l'hôte ne sont pas suivis. Pour faire entrer des skills ou une configuration spécifique, sbx skills import existe comme mécanisme explicite. Une exception documentée : le store de skills partagé est monté en lecture-écriture pour tous les sandboxes, ce qui casse l'isolation stricte entre deux sandboxes qui partagent ce store.
Les secrets sur disque
La commande sbx template save capture l'intégralité du système de fichiers du sandbox au moment où elle est exécutée, secrets compris. Un token ou une clé laissée sur le disque, même temporairement, entre dans le template sauvegardé et y reste.
Un angle mort qui ne dépend d'aucun préréglage réseau
Les serveurs MCP (Model Context Protocol, le protocole que Claude Code et d'autres agents utilisent pour appeler des outils externes) locaux, qui communiquent en stdio, tournent sur l'hôte et jamais dans la microVM. Un serveur MCP stdio n'est donc pas isolé par le sandbox, quel que soit le préréglage réseau Open, Balanced ou Locked Down choisi.
Sur quels systèmes tourne sbx ?
sbx s'installe sur trois familles de systèmes, chacune avec ses propres prérequis documentés :
| Système | Prérequis documentés |
|---|---|
| macOS | macOS 14 ou supérieur, puce Apple Silicon |
| Windows | Windows 11, Hypervisor Platform activé |
| Linux | Ubuntu 24.04 ou supérieur, KVM, utilisateur dans le groupe kvm |
Sur Linux, KVM (le module de virtualisation intégré au noyau Linux) est ce qui permet à sbx de lancer une microVM sur Ubuntu. Un compte Docker est obligatoire pour utiliser sbx. Le CLI envoie de la télémétrie d'usage, désactivable via la variable SBX_NO_TELEMETRY=1 ; les prompts et le code source en sont explicitement exclus.
Vérification de prérequis (aucun test d'usage)
Sur un poste Ubuntu 24.04.4 exécuté sous WSL2, le module kvm_amd est chargé et /dev/kvm est présent, mais l'utilisateur n'est pas dans le groupe kvm (corrigible), sbx n'est pas installé, et surtout, WSL2 n'apparaît pas dans la liste des systèmes supportés déclarée par Docker. Ce relevé documente un état de prérequis, à un instant donné, sur une machine donnée. Il ne vaut ni benchmark ni retour d'usage : sbx n'a pas été installé, rien n'a été exécuté.
Combien ça coûte ?
La page de présentation de Docker Sandboxes est explicite : faire tourner des sandboxes sur sa propre machine, y compris pour un usage professionnel, n'entre dans aucune grille tarifaire. Trois briques se facturent différemment.
| Brique | Modèle | Ce que ça couvre |
|---|---|---|
CLI sbx et compute local |
Gratuit, usage commercial inclus | Lancer des sandboxes sur sa propre machine, y compris en contexte professionnel |
Exécution en cloud (sbx --cloud) |
Facturé à l'usage mesuré | Faire tourner la sandbox ailleurs que sur le poste de travail |
| Gouvernance organisation | Plan payant | Poser des politiques réseau et des règles de credentials à l'échelle d'une équipe |
Le CLI seul, sur une machine individuelle, reste donc dans la case gratuite.
Faut-il l'adopter ?
Les notes de version publiées par Docker, complétées par l'historique des releases GitHub pour les versions antérieures à 0.38, montrent un rythme de changement soutenu, avec des évolutions de sécurité notables à chaque sortie depuis la version 0.35.0. Comme tout outil de sécurité jeune, cet historique de versions donne des indices sur sa maturité, sans valoir verdict.
| Version | Date | Changement notable |
|---|---|---|
0.35.0 |
2026-07-10 | Fin de l'authentification par variables d'environnement de l'hôte ; refonte de sbx policy ; transport SOCKS5 |
0.37.0 |
2026-07-24 | Accès SSH aux sandboxes (expérimental) ; skills partagées |
0.37.1 |
2026-07-29 | SSH ne transmet plus ANTHROPIC_API_KEY, OPENAI_API_KEY, GH_TOKEN par défaut |
0.38.0 |
2026-08-06 | Kit spec v2 ; gestion MCP de première classe via une passerelle intégrée ; --deny-network ; correction de CVE-2026-17106 (échappement de destination dans le copy-out de sbx cp, sens sandbox vers hôte) |
0.39.0 / 0.42.0 |
— | Ajout de -e/--env ; ajout de sbx --cloud |
CVE-2026-17106 : une faille corrigée
Un outil de sécurité qui documente ses failles corrigées, plutôt que de les taire, est un signal de maturité normale à ce stade. CVE-2026-17106 a été corrigée en version 0.38.0 : c'est un fait à connaître avant d'accorder une confiance large à l'outil.
Cinq questions déterminent si l'isolation par microVM répond au problème de sécurité que vous cherchez à résoudre, ou si elle en déplace seulement une partie :
- Réseau : votre agent a-t-il besoin d'accès sortant restreint, ou dépend-il de
pinget de la résolution DNS directe pour ses propres diagnostics ? - Menace visée : empêcher l'exécution de code arbitraire par l'agent et empêcher la fuite d'un secret déjà posé sur le disque ne demandent pas la même priorité.
- Plateforme : macOS 14+, Windows 11 et Ubuntu 24.04+ sont documentés ; WSL2 ne l'est pas.
- Gouvernance : un usage individuel suffit, ou bien il faut des politiques réseau et de credentials centralisées au niveau organisation.
- Sauvegarde : pouvez-vous accepter qu'un
sbx template savecapture les secrets présents sur le disque au moment de l'exécution ?
Points clés
La frontière a changé de nature
Ce n'est plus le namespace qui isole l'agent, mais l'hyperviseur : la microVM embarque son propre noyau et son propre moteur Docker.
La confiance est déplacée, pas résolue
L'agent reste root dans la microVM (sudo par défaut, variantes -docker privilégiées). Une barrière fondée sur l'ownership Unix hôte ne survit pas au passage en sandbox.
Trois angles morts opérationnels
UDP et ICMP bloqués (ping et DNS direct hors service), configuration hôte non importée par défaut, et secrets sur disque capturés par sbx template save.
Une évaluation, pas un retour d'usage
Cet article s'appuie sur la documentation officielle et une vérification de prérequis (WSL2 non supporté sur le poste testé). Rien n'a été exécuté.
Questions fréquentes
Qu'est-ce que Docker Sandboxes (sbx) ?
Docker Sandboxes est un outil de Docker Inc. qui exécute un agent de code IA dans une microVM isolée, avec son propre noyau et son propre moteur Docker, distincts de la machine hôte. Le CLI qui le pilote s'appelle sbx et fonctionne seul, sans Docker Desktop ni Docker Engine installés sur l'hôte.
Un sandbox Docker est-il un conteneur ?
Non, plus depuis la version actuelle. L'ancienne sous-commande docker sandbox de Docker Desktop, avant la bascule vers la microVM, isolait l'agent par conteneur, une technique qui partage le noyau de l'hôte. Le CLI autonome sbx isole désormais par microVM, avec un noyau et un moteur Docker séparés.
Docker Sandboxes est-il gratuit ?
Le CLI sbx et le compute local sont gratuits, usage commercial inclus. L'exécution en cloud (sbx --cloud) est facturée à l'usage mesuré, et la gouvernance au niveau organisation est un plan payant.
Peut-on lancer Claude Code sans les demandes de permission ?
Oui. La documentation de l'intégration Claude Code indique que le lancement par défaut dans un sandbox utilise l'option claude --dangerously-skip-permissions. La page documente ce comportement par défaut sans en exposer la motivation.
Un agent dans un sandbox peut-il accéder à mes fichiers ?
Par défaut, non : ~/.claude n'est pas importé et les liens symboliques vers l'hôte ne sont pas suivis. Une exception documentée existe : le store de skills partagé est monté en lecture-écriture pour tous les sandboxes.
sbx fonctionne-t-il sous Linux ? Sous WSL2 ?
Linux est supporté sur Ubuntu 24.04 ou supérieur, avec KVM et l'utilisateur dans le groupe kvm. WSL2 n'apparaît pas dans la liste des systèmes supportés déclarée par Docker, ce qu'une vérification de prérequis sur un poste Ubuntu 24.04.4 sous WSL2 a confirmé, sans installer ni exécuter sbx.
Mes clés d'API entrent-elles dans le sandbox ?
Pas directement : les secrets des services modélisés sont injectés en en-tête HTTP par un proxy hôte, avec une sentinelle proxy-managed. Mais tout secret déjà présent sur le disque est capturé, secrets compris, si le template est sauvegardé via sbx template save.
Peut-on utiliser SSH depuis un sandbox ?
Oui. Une règle réseau explicite de la forme myhost:22 peut autoriser une connexion TCP non-HTTP comme SSH. L'agent forwarding SSH est activé par défaut, et la clé privée SSH n'entre jamais dans la microVM.
Pourquoi ping et les requêtes DNS directes ne fonctionnent-ils pas dans un sandbox ?
UDP et ICMP sont bloqués au niveau réseau, sans exception possible par policy, quel que soit le préréglage choisi. ping repose sur ICMP et la résolution DNS classique passe par UDP : aucun des deux ne fonctionne dans un sandbox.
Ma configuration Claude Code est-elle reprise dans le sandbox ?
Non, pas automatiquement : ~/.claude n'est pas importé par défaut. La commande sbx skills import existe comme mécanisme explicite pour faire entrer des skills spécifiques, distinct d'un import automatique du reste de la configuration hôte.
Suivre les prochaines évaluations d'outils pour agents IA
Cet article sera mis à jour si Docker fait évoluer sbx de façon significative. D'autres évaluations du même type suivront sur les outils d'isolation pour agents de code.
Suivre sur LinkedIn