Le mode YOLO sans confier mon ordinateur à un agent IA

Un conteneur de développement classique est pratique pour encapsuler les dépendances, mais il ne constitue pas automatiquement une frontière de sécurité robuste.

Le raccourci habituel consiste à monter le socket Docker de l’hôte afin qu’un outil exécuté dans le conteneur puisse construire et lancer d’autres conteneurs. Cette technique lui donne en pratique le contrôle du daemon Docker de l’hôte. Dans le cas d’un agent autonome, elle compromet une grande partie de l’isolation recherchée.

Docker propose une autre approche avec Docker Sandboxes. Chaque sandbox s’exécute dans une microVM qui possède son propre environnement Linux, son propre système de fichiers, son propre réseau et son propre Docker Engine.

Dans cet environnement, l’agent peut :

• installer des paquets avec sudo
• construire des images
• démarrer des conteneurs
• exécuter Docker Compose
• modifier son environnement de développement

Et tout cela sans donner à l’agent accès au daemon Docker de l’hôte ni aux fichiers situés en dehors de l’espace de travail que je choisis expressément de partager.

L’objectif n’est pas d’empêcher l’agent de causer le moindre dommage. Il est de limiter les dégâts potentiels et de mieux comprendre jusqu’où ils peuvent s’étendre.

Docker Sandboxes propose deux modes de partage particulièrement utiles.

Mode direct

Le projet est monté en lecture-écriture. Les modifications apportées par l’agent apparaissent immédiatement dans ma copie de travail locale. J’utilise ce mode pour le développement courant, car l’agent et moi pouvons intervenir sur les mêmes fichiers.

La contrepartie est claire : le dépôt reste exposé aux erreurs de l’agent.

Mode clone

Pour tester des agents que je connais mal, mener des expériences potentiellement destructrices ou travailler en parallèle, le mode clone offre une frontière plus robuste. Le dépôt de l’hôte est monté en lecture seule, tandis que l’agent travaille dans un clone privé au sein de la sandbox. Les modifications ne sont répercutées dans ma copie de travail locale qu’après avoir été explicitement importées.

Le mode clone empêche de modifier le dépôt, mais pas d’en consulter le contenu. Les fichiers du dépôt, y compris ceux que Git ignore, peuvent rester accessibles par l’intermédiaire du montage en lecture seule. Les secrets doivent donc rester en dehors de l’espace de travail.

Une sandbox vide résout le problème de l’isolation, pas celui de la configuration.

Je ne voulais pas devoir réexpliquer, au début de chaque session, quelles bibliothèques natives sont requises par le projet, quelles versions des outils sont nécessaires à la compilation, ni comment configurer l’environnement des modèles locaux.

Avec Docker Sandboxes, il est possible de créer des configurations de projet réutilisables appelées kits. Le kit de mon projet décrit les outils et l’environnement dont l’agent a besoin, notamment :

• les dépendances natives requises pour la compilation
• les outils de développement Rust
• les dépendances nécessaires aux tests de navigateur
• les variables d’environnement
• les accès réseau requis pendant la configuration initiale

Le détail de la configuration compte moins que le principe : les connaissances nécessaires pour préparer l’environnement sont consignées avec le projet plutôt que reconstituées de mémoire.

Un agent IA peut ébaucher un fichier spec.yaml propre au projet en inspectant le dépôt, puis poser des questions sur les éléments qu’il ne peut pas déduire : paquets système, commandes de compilation et de test, services d’arrière-plan, accès réseau, ports et identifiants d’accès gérés par l’hôte.

Pour une application web, le kit peut par exemple inclure Playwright et un navigateur sans interface graphique dans la sandbox. L’agent peut alors effectuer le rendu des pages, exécuter des tests de bout en bout et prendre des captures d’écran afin de contrôler visuellement le résultat. Si l’agent et le modèle retenus acceptent les images en entrée, l’agent peut aussi analyser lui-même ces captures. Le fichier généré doit néanmoins être relu, puis validé avec sbx kit validate.

Le kit sert aussi de carnet de dépannage

La première version du kit était beaucoup plus sommaire. Il s’est enrichi chaque fois que la réalité a démenti l’une de mes hypothèses.

Dans une version, la variable PATH était remplacée au lieu d’être complétée. Les chemins ajoutés par l’environnement d’exécution de la sandbox disparaissaient alors, ce qui empêchait l’agent de programmation de démarrer correctement.

Dans une autre version, la variable RUSTFLAGS était définie de manière globale. Ce réglage remplaçait par inadvertance une option propre au projet, utilisée en CI pour exclure les tests qui effectuent de véritables requêtes auprès des fournisseurs de modèles.

Ces problèmes auraient pu rester enfouis dans l’historique du shell ou dans des notes personnelles. Leurs correctifs sont aujourd’hui consignés avec la configuration qu’ils documentent.

C’est là tout l’intérêt du kit. Il ne se contente pas d’installer des logiciels. Il transforme les connaissances liées à l’environnement en code intégré au projet, que l’on peut relire, versionner et améliorer.

Pour travailler au quotidien, je crée une sandbox nommée et configurée avec le kit du projet :

# D’autres agents sont également pris en charge, notamment claude, gemini et opencode.
sbx run codex \
  --name aitopus \
  --kit ./sandbox/aitopus/

Cette commande utilise le montage direct du projet : les modifications de l’agent apparaissent dans mon arbre de travail.

Lorsque j’ai besoin d’une frontière plus robuste, je peux créer à la place une sandbox distincte en mode clone :

sbx run --clone --no-share-skills codex \
  --name aitopus-review \
  --kit ./sandbox/aitopus/

La mise en place initiale peut prendre du temps, car l’environnement comprend des chaînes d’outils natives, des navigateurs et des dépendances de compilation. L’avantage est que l’état de la sandbox et les caches de compilation persistent d’une session à l’autre.

Une fois cette première mise en place terminée, je peux me reconnecter à la sandbox nommée plutôt que de reconstruire entièrement l’environnement.

Un agent de programmation a tout de même besoin d’Internet. Il peut devoir accéder aux services de son fournisseur de modèles, à des registres de paquets, à des dépôts de code source ou à des archives de versions.

Pour les sessions plus sensibles, je commence par appliquer une politique réseau restrictive, puis je n’autorise que les services indispensables à l’agent et à la compilation.

Le proxy d’identifiants proposé par Docker Sandboxes permet de conserver sur l’hôte les identifiants pris en charge et de ne les ajouter qu’aux requêtes autorisées. Cela évite de copier dans la sandbox une clé API à longue durée de vie, puis d’oublier où elle se trouve.

Le contrôle du réseau a malgré tout ses limites. Un service autorisé peut toujours recevoir les informations que l’agent lui transmet. Restreindre les destinations réduit l’exposition ; cela ne rend pas pour autant légitime chaque requête sortante.

Une sandbox limite les accès ; elle ne garantit pas que le code produit soit correct. Je traite le travail de l’agent comme une pull request provenant d’une source non fiable.

• Qualité du code. L’agent peut toujours ajouter une dépendance vulnérable, mal comprendre une exigence ou produire du code qui passe les tests tout en allant à l’encontre de la conception prévue.
• Effets de bord sur l’hôte. En mode direct, l’agent peut modifier bien plus que les fichiers source habituels. Les hooks Git, workflows de CI, tâches de l’IDE, scripts de compilation et fichiers de configuration de l’agent sont tous susceptibles d’exécuter ultérieurement du code sur l’hôte.
• Modifications du dépôt. Le mode clone empêche toute écriture directe dans la copie de travail de l’hôte, mais tout ce qui y est réimporté doit encore être relu.
• Plateformes cibles. Une sandbox Linux offre un environnement de travail plus sûr et plus cohérent ; elle ne prouve pas que l’application finale fonctionne correctement sur toutes les plateformes visées.

Les demandes d’autorisation sont utiles lorsqu’aucune frontière plus robuste n’existe. Elles ne remplacent toutefois pas une isolation conçue en amont.

Dans une microVM dédiée, l’agent peut travailler avec une grande latitude. Il peut installer des compilateurs, modifier les paquets installés, construire des conteneurs et mener un cycle complet de débogage sans devoir attendre une approbation après chaque commande.

Je lui donne délibérément accès au dépôt du projet. En revanche, il n’a accès ni au daemon Docker de l’hôte ni aux fichiers sans rapport avec le projet. Il ne dispose pas non plus d’un accès sans restriction au reste de ma machine.

Cette approche n’est pas seulement plus sûre. Elle me rend aussi plus productif.

Je passe moins de temps à approuver les opérations courantes et à réparer mes chaînes d’outils locales. Mes prompts sont aussi plus concis, puisque je n’ai plus à y décrire l’environnement de développement en détail. L’agent dispose de suffisamment de liberté pour avancer ; de mon côté, je garde la maîtrise d’un périmètre clairement défini.

Il en va de même pour l’IA locale : choisir où s’effectuent les calculs, décider quelles informations peuvent franchir la frontière et conserver le reste sous contrôle local.

C’est cette version du mode YOLO qui me convient :

non pas une confiance aveugle dans l’agent, mais la certitude d’avoir choisi le périmètre dans lequel ses erreurs resteront confinées.

Remarque : les kits de Docker Sandboxes sont encore expérimentaux. Consultez la documentation la plus récente avant d’utiliser en production une commande ou un champ de configuration spécifique.