Docker Sandboxes peut donner sudo à un agent, lui laisser installer des paquets et démarrer son propre Docker. C’est justement l’idée.

Tout cela se passe dans une microVM séparée. Le noyau, le daemon Docker, le système de fichiers interne et le réseau de l’agent sont isolés du host.

Puis Docker fait un choix beaucoup moins spectaculaire : par défaut, le dossier du projet reste monté en lecture-écriture.

Donc oui, l’agent est sandboxé. Et oui, il peut encore modifier votre package.json, votre configuration CI ou vos hooks Git. Les deux phrases sont vraies en même temps.

C’est ce qui rend le modèle intéressant : il oblige à arrêter de parler de « sandbox » comme s’il existait une seule frontière magique.

La microVM protège le host, pas automatiquement le travail

Docker décrit la microVM comme sa frontière de confiance principale.

À l’intérieur, l’agent a les pleins pouvoirs. Il peut utiliser sudo, installer des logiciels, lancer des conteneurs et utiliser un daemon Docker privé. Il ne partage pas le noyau ni la mémoire du host.

Le host Docker daemon n’est pas exposé directement. Le réseau local et localhost du host ne sont pas accessibles comme s’ils appartenaient à la VM. Les requêtes sortantes passent par une couche de contrôle réseau.

C’est une différence importante avec l’agent lancé directement dans un terminal utilisateur. Un paquet douteux installé dans la microVM reste dans cette microVM au lieu de venir décorer votre machine principale de dépendances surprises.

Mais le projet sur lequel l’agent travaille constitue volontairement un canal entre les deux mondes.

En mode direct, Docker monte ce workspace en lecture-écriture. Les changements apparaissent immédiatement dans le working tree du host.

Autrement dit, le système protège très bien /etc sans empêcher l’agent d’écrire dans le fichier que vous allez exécuter dans trente secondes.

Le risque ne tient pas seulement dans le diff

La documentation Docker insiste sur un détail particulièrement utile.

Dans le workspace, l’agent peut modifier des fichiers qui s’exécutent implicitement : scripts package.json, configuration CI, tâches d’IDE, Makefile, configuration d’agents et autres fichiers de build.

Les hooks Git méritent encore plus d’attention. Ils vivent dans .git/ et ne sont pas forcément visibles dans un git diff ordinaire.

Docker recommande donc de traiter les modifications produites par l’agent comme une pull request non fiable avant d’exécuter le code modifié.

C’est une formulation plus honnête que « l’agent tourne dans une VM, donc tout va bien ».

Une isolation système peut empêcher un processus de lire vos photos personnelles tout en lui permettant d’ajouter une commande assez créative à npm test. La sécurité dépend de ce qu’on autorise à traverser la frontière, pas du nom donné à la boîte.

Le mode clone déplace la frontière

Docker propose une deuxième configuration avec --clone.

Cette fois, le dépôt du host est monté en lecture seule et l’agent travaille dans une copie privée à l’intérieur de la sandbox. Ses modifications ne touchent plus directement le working tree local.

Pour plusieurs agents lancés en parallèle, ou pour tester un agent qu’on connaît mal, cette différence est beaucoup plus importante que le logo de l’hyperviseur.

Le mode direct optimise la fluidité : le fichier changé est immédiatement chez vous.

Le mode clone optimise l’isolation du travail : il faut explicitement récupérer ou intégrer ce que l’agent a produit.

Aucun des deux n’est universellement meilleur. Ils répondent à deux niveaux de confiance différents.

Les secrets peuvent rester hors de la VM

La même logique apparaît avec les credentials.

Docker peut conserver les secrets côté host et injecter les informations d’authentification dans les requêtes HTTP via un proxy. Dans ce mode, la valeur brute du credential n’entre pas dans la microVM.

Ça réduit un risque classique : donner une clé API à un agent, puis découvrir qu’un processus qu’il a installé peut lire la même variable d’environnement.

Le réseau est également médié. Docker documente une politique de sortie contrôlée et le blocage des protocoles non HTTP dans le modèle par défaut.

Là encore, ce n’est pas une garantie absolue. Autoriser un domaine reste autoriser un canal vers ce domaine. Docker signale même que certains wildcards par défaut peuvent couvrir beaucoup plus de services qu’on ne l’imagine.

Même les skills deviennent une frontière partagée

Les versions récentes de Docker Sandboxes savent aussi importer des skills d’agents dans un stockage persistant partagé entre plusieurs sandboxes.

C’est pratique. C’est aussi, explicitement dans la documentation, une exception à l’isolation entre sandboxes.

Le store est monté en lecture-écriture. Une sandbox participante peut donc modifier une instruction ou un script qu’une autre sandbox utilisera plus tard. L’option --no-share-skills permet d’en sortir.

Le petit fichier Markdown qui apprend à l’agent comment travailler devient donc lui-même une surface de confiance. L’humanité a réussi à réinventer les dépendances partagées, mais avec davantage de prose.

“Sandboxé” ne répond pas à la bonne question

Docker Sandboxes apporte une isolation sérieuse là où les agents en ont besoin : processus, noyau, Docker, réseau et secrets peuvent être séparés du host.

Mais la documentation montre aussi pourquoi il faut poser une question plus précise : qu’est-ce que l’agent est encore autorisé à modifier ou à faire sortir de la boîte ?

Si le workspace est partagé, ce sont les fichiers du projet. Si le réseau autorise un service, c’est un canal. Si les skills sont partagés, c’est une mémoire exécutable commune.

Une sandbox ne transforme pas un agent en processus digne de confiance.

Elle permet de choisir plus proprement où on accepte de ne pas lui faire confiance.