Docker Sandboxes : sécuriser les agents IA en production

Docker Sandboxes : sécuriser les agents IA en production

Donner de l'autonomie aux agents sans leur offrir les clés de la machine hôte : c'est exactement le problème que Docker Sandboxes résout pour les équipes qui livrent avec Claude Code, Copilot CLI ou Codex.

Les Docker Sandboxes changent la posture de sécurité des agents de coding. Au lieu de choisir entre vitesse (mode permissif) et prudence (validation manuelle à chaque commande), vous isolez l'agent dans une microVM jetable. Votre poste, votre daemon Docker hôte et votre réseau local restent hors de portée — sauf ce que vous montez explicitement.

Pour une PME ou une agence d'automatisation, l'enjeu n'est pas théorique. Les agents écrivent du code, touchent aux workflows n8n, installent des dépendances et appellent des APIs. Cet article explique ce que propose Docker (faits issus de la page produit et de la documentation officielle), comment installer sbx, quelle checklist appliquer avant le YOLO mode, et comment articuler cette isolation avec la gouvernance des agents n8n en livraison.

---

Le problème : des agents trop utiles pour rester sans murs

Claude Code, Copilot CLI, Codex, OpenCode, Kiro et Gemini CLI savent exécuter des commandes, modifier des configs et lancer des conteneurs. C'est leur valeur. C'est aussi leur surface de risque.

Sans isolation :

• un rm mal ciblé touche le disque hôte ;
• un package compromis s'installe dans votre environnement quotidien ;
• un accès au socket Docker hôte expose tous vos conteneurs locaux ;
• les secrets présents dans le shell ou les fichiers non suivis deviennent lisibles.

La doc Docker décrit ce besoin clairement : les agents font leur meilleur travail avec de la liberté, mais la liberté sans frontière n'est pas tenable en équipe. Docker Sandboxes répond par une frontière dure — la microVM — plutôt que par une succession de prompts « Allow / Deny ».

Sur la page produit, Gavriel Cohen (créateur de NanoClaw) résume la logique ainsi : on ne fait pas confiance aux agents pour la sécurité ; on construit des murs autour d'eux. Ben Navetta (Engineering Lead, Warp) insiste sur le même point côté productivité : les sandboxes permettent des tâches longues sans sacrifier la sûreté, avec un environnement cohérent en local comme dans le cloud.

---

Ce que sont Docker Sandboxes (faits produit)

D'après docker.com/products/docker-sandboxes et la documentation docs.docker.com/ai/sandboxes :

1. Sandboxes jetables et isolées pour agents de coding.
2. Agents supportés : Claude Code, Copilot CLI, Codex, OpenCode, Kiro, Gemini CLI (et possibilité d'en ajouter).
3. Isolation microVM : frontière forte avec l'hôte ; chaque sandbox a son propre filesystem, réseau et daemon Docker.
4. Autonomie réelle à l'intérieur : installer des paquets, modifier des configs, lancer Docker dans la sandbox.
5. YOLO / --dangerously-skip-permissions : mode permissif par défaut dans la sandbox — sûr parce que confiné.
6. Pas besoin de Docker Desktop pour utiliser les sandboxes.
7. Docker AI Governance (offre séparée) pour politiques réseau, filesystem et MCP à l'échelle de l'organisation.

L'agent travaille dans une microVM : workspace monté, proxy réseau, Docker Engine privé — l'hôte reste hors périmètre

Couches d'isolation utiles à connaître

La documentation sécurité Docker détaille plusieurs couches. Pour une PME, retenez surtout :

Point d'attention documenté : même en mode clone, le dépôt peut rester visible en lecture (y compris fichiers non suivis). Un .env local n'est pas « invisible » par magie. Traitez les secrets comme un sujet séparé (sbx secret, coffre, variables CI).

---

Installation rapide (macOS, Windows, Linux)

Les commandes ci-dessous reprennent la page produit Docker Sandboxes. Adaptez selon votre OS.

macOS (Apple silicon, Sonoma+ selon la doc get-started) :

brew trust docker/tap
brew install docker/tap/sbx
sbx login

Windows 11 (x86_64, Hypervisor Platform activée) :

winget install Docker.sbx
# ou : winget install -h Docker.sbx
sbx login

Linux Ubuntu (24.04+, KVM requis) :

curl -fsSL https://get.docker.com | sudo REPO_ONLY=1 sh
sudo apt-get install docker-sbx
sbx login

sbx login ouvre l'OAuth Docker. La CLI sbx est indiquée comme utilisable gratuitement, y compris pour un usage commercial ; la gouvernance organisationnelle est un abonnement séparé.

Premier run

cd ~/mon-projet
sbx run --name mon-sandbox claude

Au premier lancement, Docker propose un preset réseau :

• Open — tout autorisé ;
• Balanced — deny par défaut + sites de dev courants (bon point de départ) ;
• Locked Down — tout bloqué sauf ce que vous autorisez.

Ensuite :

sbx ls
sbx policy ls
sbx policy allow network registry.npmjs.org
sbx stop mon-sandbox
sbx rm mon-sandbox

Retirer une sandbox efface paquets, images et état interne. Les fichiers du working tree hôte ne sont pas supprimés avec sbx rm.

---

Checklist avant d'activer le YOLO mode

Le YOLO mode accélère les sessions longues. Il ne remplace pas une discipline d'équipe. Utilisez cette checklist avant de généraliser --dangerously-skip-permissions (ou l'équivalent activé par défaut dans la sandbox).

Quatre garde-fous : workspace propre, politique réseau, secrets via sbx, revue Git avant merge

Checklist opérationnelle

1. Inventaire secrets — pas de .env production dans le workspace monté, ou basculez en clone mode.
2. Politique réseau — préférez Balanced ou Locked Down ; ajoutez les hosts nécessaires (sbx policy allow network …).
3. Secrets agents — utilisez sbx secret set (ex. token GitHub) plutôt que d'exporterer des clés en clair dans la VM.
4. Périmètre Git — branche dédiée, commits atomiques, PR obligatoire ; l'agent écrit, l'humain merge.
5. Pas de socket Docker hôte — vérifiez que les builds passent par le Docker Engine de la sandbox.
6. Données client — dumps, exports CRM, exports n8n : hors workspace ou anonymisés.
7. Durée de vie — sandbox jetable par ticket / feature ; sbx rm en fin de mission.
8. Alignement équipe — si plusieurs postes : documenter le preset réseau et, si besoin, Docker AI Governance.

Sans ces huit points, YOLO reste rapide — mais votre dette de risque croît à chaque session.

---

Angle PME : pourquoi ce n'est pas « trop enterprise »

Les tutos concurrentiels s'arrêtent souvent à « installer sbx et lancer Claude ». Pour une PME, la question utile est : quel risque résiduel acceptons-nous pour accélérer la livraison ?

Trois cas concrets :

1. Refactor d'un workflow n8n sensible.
L'agent peut modifier des JSON de workflow, installer des CLI et lancer des tests. La sandbox limite le blast radius si un script tourne mal. La mise en production reste soumise à votre pipeline et à la gouvernance n8n.

2. Spike technique client (48 h).
Vous montez uniquement le dépôt du spike. Pas de VPN client, pas de secrets de prod. À la fin : sbx rm, diff Git, démo. Le poste consultant reste propre pour le client suivant.

3. Onboarding junior + agent.
Le junior active YOLO dans la sandbox, pas sur sa machine. Vous réduisez le coût de supervision sans ouvrir le parc entier.

Docker AI Governance devient pertinent dès que vous standardisez ces règles sur 3+ postes (politiques réseau, filesystem, MCP). Ce n'est pas obligatoire pour démarrer ; c'est l'étape « équipe » après le premier gain individuel.

---

Relier Docker Sandboxes et agents n8n en livraison agence

L'isolation locale ne remplace pas la gouvernance runtime des agents métier. Chez BOVO Digital, nous traitons deux plans distincts — et complémentaires.

Du coding agent isolé jusqu'aux workflows n8n avec HITL, guardrails et RBAC

Plan A — Développement (Docker Sandboxes)

• Claude Code / Copilot CLI dans sbx ;
• génération et correction de workflows, scripts, tests ;
• YOLO confiné + revue PR.

Plan B — Production (n8n AI Agent Governance)

• RBAC, human-in-the-loop, guardrails runtime, sanitization des sorties, observabilité ;
• décisions de gouvernance dans le workflow, pas seulement dans un PDF de politique.

Notre article détaillé sur n8n AI Agent Governance en production couvre les cinq piliers. Docker Sandboxes se place en amont : sécuriser la façon dont l'équipe fabrique les agents et workflows. n8n se place en aval : sécuriser la façon dont ils s'exécutent chez le client.

Pour une mission d'automatisation PME ou une livraison via notre agence automatisation n8n, la combinaison type est :

1. Cadrage périmètre données et outils MCP autorisés.
2. Développement agent / workflow sous sandbox.
3. Revue humaine + tests (évaluations n8n si agent autonome).
4. Déploiement avec HITL sur les actions à fort impact (paiements, emails massifs, écritures CRM).
5. Monitoring et rétrospective incident.

Quatre piliers complémentaires pour une PME ou une agence qui livre des agents IA

---

Limites et pièges à éviter

Soyez précis sur ce que les sandboxes ne font pas :

• Elles n'empêchent pas un agent de modifier le workspace monté en mode direct (c'est voulu).
• Elles ne remplacent pas la revue de code ni les tests.
• Elles ne chiffrent pas magiquement les secrets déjà présents dans le dépôt.
• Elles ne gouvernent pas seules les outils MCP métier côté n8n / cloud client.
• Nested virtualization est requise si vous lancez sbx dans une VM (VDI) — sinon le démarrage échoue (doc get-started).

Aucun numéro de CVE inventé ici : suivez les advisories Docker et celles de vos agents (Claude Code, Copilot, etc.) via leurs canaux officiels.

---

Conclusion — une frontière concrète pour accélérer sans naïveté

Docker Sandboxes apporte une réponse infrastructure claire : microVM + workspace contrôlé + proxy réseau + Docker Engine privé. Le YOLO mode devient un levier de productivité, pas un pari sur la sagesse de l'agent.

Pour les PME et les agences qui livrent avec Claude Code et n8n, la suite logique est en deux temps : isoler le coding agent localement, gouverner l'agent métier en production. Si vous voulez structurer cette chaîne sur vos postes et vos workflows clients, contactez-nous via Automatisation ou Agence automatisation n8n.

Action concrète cette semaine : installer sbx, lancer un agent sur un dépôt non critique en preset Balanced, appliquer la checklist YOLO, puis comparer le diff Git à une session non sandboxed. Vous verrez immédiatement ce que l'isolation change — et ce qu'elle ne remplace pas.