Docker Sandboxes sur un serveur dédié Ubuntu : isoler un agent IA (Claude Code, Codex) dans une microVM

Le 5 novembre 2026, Docker a publié un comparatif entre ses Docker Sandboxes et les conteneurs classiques, avec une formule qui résume la position de l'éditeur : sandboxer l'agent, conteneuriser l'application. Un Docker Sandbox est une microVM dédiée à un agent IA de code : elle embarque son propre noyau Linux, son propre système de fichiers, sa propre pile réseau et son propre moteur Docker. À l'intérieur, Claude Code, Codex, Gemini CLI ou OpenCode dispose de sudo, installe des paquets, construit des images et lance des piles Compose. Mais l'agent ne voit ni le démon Docker de l'hôte, ni les fichiers de l'hôte hors de l'espace de travail que vous lui montez, ni les autres sandboxes de la même machine. Sous Linux, l'outil se nomme sbx, s'installe sur Ubuntu 24.04 ou plus récent avec KVM, et la version courante est la 0.51.0 du 3 novembre 2026.

Ce guide montre l'installation sur un serveur dédié Ubuntu (ou sur un VPS dont l'hébergeur a activé la virtualisation imbriquée), le lancement de Claude Code et de Codex avec sbx run, la gestion du cycle de vie des sandboxes, la politique réseau, les secrets, le fichier sbxenv.yaml, puis les limites de l'isolation. Il complète notre guide installer Hermes Agent sur un VPS : Hermes y tourne dans un conteneur Docker ordinaire, qui partage le noyau de l'hôte. Pour un agent de programmation autonome qui exécute tout ce qu'il décide sans demander, la question de la frontière d'isolation mérite d'être reposée.

Sources : Docker Sandboxes vs. Containers (blog Docker, 5 novembre 2026) ; documentation Docker Sandboxes, pages Install, Get started, Usage, Security model, Policies, Credentials, Environment files, Claude Code, Codex, FAQ, Troubleshooting et Automation ; script get.docker.com ; dépôt docker/sbx-releases.

Sandbox ou conteneur : ce qui change pour celui qui administre la machine

Un conteneur Docker est un processus isolé par les namespaces et les cgroups du noyau de l'hôte. Cette isolation est solide pour une application que vous avez empaquetée vous-même, mais sa frontière est le noyau partagé : s'en échapper demande une faille noyau ou une attaque par canal auxiliaire, et le conteneur reste souvent lancé avec le socket /var/run/docker.sock monté, ce qui revient à donner root sur l'hôte. Le billet de Docker prend précisément cet exemple : un agent qui trouve le socket monté et s'en sert pour atteindre les chemins de l'hôte. Dans un sandbox, la même tentative ne mène nulle part, parce que le socket de l'hôte n'existe pas dans la microVM.

Un Docker Sandbox ajoute une frontière d'hyperviseur autour d'un noyau dédié. Si l'agent sort d'un conteneur qu'il a lui-même lancé, il atterrit dans une microVM jetable, pas sur votre serveur. Deux contrôles sont en plus appliqués hors du processus de l'agent : tout le trafic TCP sortant passe par un proxy côté hôte avec une politique de refus par défaut, et pour les services HTTP connus, ce proxy injecte les identifiants dans les requêtes après leur sortie de la VM. L'agent ne manipule jamais la vraie clé API, seulement une valeur de substitution. Un conteneur ne sait faire ni l'un ni l'autre sans outillage supplémentaire.

Docker recommande de commencer par les conteneurs pour tout ce qui est application, CI ou exécution courte, et de passer aux sandboxes quand l'agent travaille sans surveillance, construit des images, traite du contenu venu d'ailleurs ou a besoin de clés qu'il ne devrait pas pouvoir lire. Les sandboxes exigent plus de mémoire, plus de disque et un hyperviseur supporté : sous Linux, c'est KVM, donc un serveur bare metal ou un VPS avec virtualisation imbriquée. Pour une VM classique pilotée à la main, nos guides Incus sur serveur dédié et Podman ou Docker sur VPS couvrent les autres niveaux d'isolation.

Pourquoi isoler un agent IA maintenant : deux incidents de la semaine

Les agents de code ont changé de nature en un an : ils ne proposent plus un diff à relire, ils exécutent des commandes, installent des dépendances, lancent des serveurs de test et poussent sur Git. Deux affaires récentes illustrent ce que coûte une frontière mal placée. Le 30 octobre 2026, un agent autonome du framework de test d'intrusion ARTEX, lancé par un chercheur dans ce qui devait être un environnement de test, s'est échappé de son bac à sable et a extrait les données d'un outil interne de WorkOS. Ni l'éditeur ni le chercheur n'ont expliqué comment l'agent est sorti ; on sait seulement qu'il a fini par parler à une API publique. Un sandbox avec une politique réseau de refus par défaut n'aurait eu aucun chemin vers cette API.

Le 5 novembre 2026, l'analyse d'Apiiro sur 104 185 fichiers settings.local.json de Claude Code publiés sur GitHub montrait l'autre face du problème : 1 122 d'entre eux contenaient des mots de passe de bases de données, des identifiants SSH ou des clés API, parce que l'agent voit les secrets qu'on lui passe et les enregistre dans ses règles d'autorisation. Dans un Docker Sandbox, la clé Anthropic ou OpenAI ne traverse jamais la frontière de la VM : le proxy de l'hôte la substitue dans l'en-tête HTTP au moment où la requête sort. Ce que l'agent pourrait écrire dans un fichier de configuration, c'est une valeur de substitution sans valeur hors du sandbox.

Dernier point, qui explique l'intérêt soudain pour l'outil : dans un sandbox, Claude Code démarre par défaut avec --dangerously-skip-permissions et Codex avec --dangerously-bypass-approvals-and-sandbox. Docker assume ce choix dans sa FAQ : les couches d'isolation (réseau, identifiants, système de fichiers) remplacent les demandes d'approbation. C'est exactement le mode de fonctionnement que tout le monde réclame pour laisser un agent travailler une heure sans surveillance, et que personne ne devrait activer sur l'hôte qui porte aussi le serveur de jeu, la base MySQL et les sauvegardes. Un serveur dédié avec KVM permet de l'avoir, sans mélanger les deux.

Prérequis : Ubuntu 24.04, KVM et un serveur dédié ou un VPS avec virtualisation imbriquée

La page d'installation de Docker fixe les conditions pour Linux :

• Ubuntu 24.04 ou plus récent, sur processeur 64 bits Intel, AMD ou Arm. Docker ne teste ni ne supporte les dérivés d'Ubuntu comme Linux Mint ou Pop!_OS : le script d'installation peut y configurer un dépôt de paquets incorrect. Les paquets .deb de la version 0.51.0 existent en variantes ubuntu2404 et ubuntu2604, pour amd64 et arm64, plus un .rpm pour Rocky Linux 8 ;
• KVM activé et supporté par le CPU, pour les sandboxes locaux. Le runtime refuse de démarrer sans ;
• votre compte utilisateur dans le groupe kvm ;
• un compte Docker : la connexion avec sbx login est obligatoire, même pour l'usage local, qui reste gratuit, usage commercial compris ;
• du disque : chaque sandbox reçoit par défaut un disque racine de 20 Go et un volume Docker de 10 Go, que l'on peut agrandir à la création. Docker ne publie pas de minimum de RAM ; comptez la mémoire allouée à chaque microVM (le champ memory de sbxenv.yaml accepte par exemple 8g) en plus de ce que consomme déjà l'hôte.

Le point qui décide de tout est KVM. Sur un serveur dédié bare metal, le module est disponible dès que la virtualisation matérielle (Intel VT-x ou AMD-V) est activée dans le BIOS. Sur un VPS, qui est déjà une machine virtuelle, /dev/kvm n'existe que si l'hébergeur a activé la virtualisation imbriquée sur son hyperviseur, ce qui est rarement le cas. Docker le dit explicitement : un sandbox local à l'intérieur d'une VM exige la virtualisation imbriquée, et seuls les sandboxes cloud s'en passent. Vérifiez en une commande avant d'installer quoi que ce soit :

lsmod | grep kvm
# attendu : kvm_intel, kvm_amd, kvm_arm64 ou kvm

sudo apt install -y cpu-checker
kvm-ok
# attendu : KVM acceleration can be used

Si la sortie de lsmod est vide et que kvm-ok signale l'absence de virtualisation matérielle, la machine ne fera pas tourner de sandbox local. Sur un serveur dédié ElypseCloud (2 x Xeon E5-2620 v4 avec 16 cœurs et 32 threads, ou 2 x Xeon Gold 6230 avec 40 cœurs et 80 threads, RAM DDR4 ECC), vous êtes sur du bare metal : le module kvm_intel se charge dès que VT-x est actif dans le BIOS, et lsmod le confirme en une ligne. Notre guide serveur dédié bare metal ou VPS détaille les autres différences. Avant d'ouvrir le serveur à un agent, appliquez aussi les premiers réglages de sécurité d'un serveur dédié : l'isolation du sandbox ne remplace pas celle de l'hôte.

Installer docker-sbx avec le script get.docker.com

Le script d'installation officiel de Docker connaît depuis peu deux variables d'environnement qui nous intéressent. SBX=1 ajoute le paquet docker-sbx à la liste des paquets installés avec Docker Engine, sur les branches APT (Ubuntu, Debian) comme RPM. REPO_ONLY=1 configure le dépôt de paquets Docker puis s'arrête, sans rien installer ni démarrer de démon. Première option, pour un serveur où vous voulez aussi Docker Engine sur l'hôte :

curl -fsSL https://get.docker.com | sudo SBX=1 sh

Seconde option, recommandée si l'agent est la seule raison d'être de la machine : sbx n'a besoin ni de Docker Desktop ni de Docker Engine sur l'hôte, puisque chaque sandbox embarque son propre moteur. On ajoute le dépôt, puis seulement le paquet docker-sbx :

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

Ajoutez ensuite votre utilisateur au groupe kvm, puis rechargez les groupes sans vous déconnecter :

sudo usermod -aG kvm $USER
newgrp kvm
id -nG | tr ' ' '\n' | grep kvm

Pour vérifier l'installation, sbx diagnose contrôle la présence du binaire, la joignabilité du démon, la cohérence de version entre CLI et démon, les répertoires de stockage et l'authentification. Sur un hôte sans dépôt Docker (autre distribution), le dépôt docker/sbx-releases fournit les paquets pour une installation manuelle avec sudo apt install ./DockerSandboxes-linux-amd64-ubuntu2404.deb, sans garantie de support au-delà d'Ubuntu. Si vous gardez Docker Engine sur l'hôte pour d'autres services, notre guide installer Docker sur un VPS couvre sa configuration et ses pièges de pare-feu.

Se connecter à Docker : obligatoire, même pour un usage local gratuit

Avant le premier sbx run, il faut une session Docker. Dans la FAQ, Docker justifie l'obligation par trois raisons : donner à chaque sandbox une identité vérifiée rattachée à une personne, alimenter les fonctions d'équipe (gouvernance, journaux d'audit, payantes) et authentifier les appels vers ses services. L'adresse e-mail ne sert qu'à l'authentification. La commande sbx login ouvre normalement un navigateur pour l'OAuth Docker, ce qui ne marche pas dans une session SSH sur un serveur sans interface graphique. La méthode que Docker documente pour les scripts et les machines sans navigateur est un jeton d'accès personnel (PAT), créé dans les réglages de votre compte Docker avec au moins la portée Read, passé sur l'entrée standard :

read -rs DOCKER_PAT
echo "$DOCKER_PAT" | sbx login --username votre-identifiant-docker --password-stdin
unset DOCKER_PAT

Deux détails propres aux serveurs headless. D'abord, sans service de trousseau (GNOME Keyring ou équivalent), sbx stocke les secrets dans un fichier sous ~/.config/com.docker.sandboxes, avec des permissions 0700, et l'annonce par un avertissement : quiconque lit ce fichier lit vos clés, donc protégez le compte utilisateur comme vous protégez une clé SSH. Ensuite, le CLI envoie une télémétrie de base (commande lancée, succès ou échec, durée, identifiant Docker), jamais les prompts ni le code ; SBX_NO_TELEMETRY=1 ou sbx settings set telemetry.disabled true la coupe.

sbx run claude : lancer Claude Code ou Codex dans la microVM

Trois étapes avant la première session : stocker la clé du fournisseur de modèle, choisir une politique réseau, lancer. Pour Claude Code avec une clé API Anthropic, la commande demande la valeur de façon interactive, sans la laisser dans l'historique du shell :

sbx secret set anthropic
sbx policy init balanced
mkdir -p ~/projets/site && cd ~/projets/site
sbx run --name site claude

Le premier lancement télécharge l'image de l'agent, les suivants démarrent en quelques secondes. Sans chemin de travail, le répertoire courant est monté en lecture-écriture dans la microVM, au même chemin absolu que sur l'hôte, et l'agent y lit et écrit comme vous ; ses modifications se relisent avec un git diff ordinaire. Si vous avez un abonnement Claude Max, Team ou Enterprise, vous pouvez ne stocker aucune clé et taper /login dans Claude Code : le jeton de session reste sur l'hôte. Pour passer un prompt directement, tout ce qui suit -- est transmis à l'agent :

sbx run --name site claude -- "Ajoute des tests unitaires au module de paiement et lance-les"

Pour Codex, c'est le même schéma avec le service openai. La connexion OAuth (sbx secret set openai --oauth) ouvre un navigateur sur l'hôte, ce qui ramène au problème du serveur headless ; sur un serveur dédié, préférez la clé API :

sbx secret set openai
sbx run --name site-codex codex ~/projets/site

Deux comportements à connaître avant de laisser l'agent seul. Le sandbox n'importe pas la configuration utilisateur de l'hôte (~/.claude, ~/.codex) : seule la configuration de niveau projet, dans le répertoire monté, est visible. Et comme indiqué plus haut, les deux agents démarrent sans demande d'approbation ; dans Claude Code, /permissions permet de réactiver les confirmations pour une session, et /btw de lui demander s'il tourne bien dans un sandbox sans interrompre la tâche en cours.

Sur un serveur, le mode clone est souvent le meilleur choix : au lieu de laisser l'agent écrire dans votre arbre de travail, --clone lui donne un clone Git privé dans la microVM, votre dépôt n'étant monté qu'en lecture seule sous /run/sandbox/source. Les changements restent dans le sandbox jusqu'à ce que vous les récupériez depuis l'hôte via le remote sandbox-<nom> que sbx ajoute à votre dépôt :

sbx run --clone --name site-clone claude .
# plus tard, depuis l'hôte
git fetch sandbox-site-clone
git diff main..sandbox-site-clone/main

Le mode clone se fixe à la création (supprimez et recréez pour en changer), exige que l'espace de travail soit un dépôt Git, et disparaît avec sbx rm : récupérez ou poussez avant de supprimer. Pour une session longue, lancez en mode détaché avec sbx run -d --name site claude ., puis revenez avec sbx run --name site. Attention, un -d sur un sandbox existant le bascule définitivement en mode détaché.

Gérer le cycle de vie des sandboxes : ls, stop, rm, prune, exec

Un sandbox persiste après la fin de l'agent : les paquets installés, les images Docker construites à l'intérieur et la configuration survivent à un stop. Seul rm efface la microVM et tout ce qu'elle contient, clone Git compris ; les fichiers d'un espace de travail monté en direct, eux, vivent sur l'hôte et ne sont pas touchés. Les commandes du quotidien :

Le disque se dimensionne à la création, par variables d'environnement : DOCKER_SANDBOXES_ROOT_SIZE=40g sbx run claude pour le disque racine (20 Go par défaut), DOCKER_SANDBOXES_DOCKER_SIZE=20g pour le volume des images Docker (10 Go par défaut, réglable durablement avec sbx settings set sandbox.disk.dockerVolume 20g), et DOCKER_SANDBOXES_CLONED_WORKSPACE_SIZE=100g pour un clone volumineux. Les sandboxes ne partagent ni images ni couches entre eux : sur un serveur qui en héberge plusieurs, l'usage disque croît avec chacun, d'où l'intérêt de prune. L'état vit sous ~/.local/state/sandboxes/, ~/.cache/sandboxes/ et ~/.config/sandboxes/. Évitez un espace de travail sur stockage réseau : chaque lecture et écriture traverserait le réseau.

Pour travailler depuis votre poste dans un sandbox qui tourne sur le serveur, sbx setup ssh écrit un bloc géré dans ~/.ssh/config de l'hôte, qui route les noms *.sbx vers le démon ; ssh site.sbx ouvre alors une session dans la microVM, et VS Code ou Cursor s'y connectent en Remote SSH avec le nom site.sbx. Depuis un ordinateur portable, enchaînez avec un saut SSH vers le serveur dédié, que vous aurez au préalable durci.

Politique réseau et secrets : ce qui a le droit de sortir de la microVM

Tout le TCP sortant d'un sandbox passe par le proxy de l'hôte : HTTP et HTTPS par un forward proxy, le reste du TCP en transparent, les deux soumis à la politique. L'UDP est bloqué sauf fonction expérimentale, l'ICMP toujours bloqué (un ping depuis le sandbox échoue, c'est normal). Trois préréglages existent :

Les règles acceptent un nom d'hôte, une adresse IP ou un bloc CIDR, un couple hôte:port pour le TCP non HTTP (SSH, bases de données), et pour HTTP une méthode, un chemin et des paramètres, ce qui permet de n'ouvrir qu'une partie d'une API. Une règle de refus l'emporte toujours sur une règle d'autorisation, et les règles d'un kit s'appliquent sous tous les préréglages. Les commandes utiles sur un serveur :

sbx policy ls                                   # règles actives, à relire après avoir choisi Balanced
sbx policy allow network registry.npmjs.org     # un hôte
sbx policy allow network "git.exemple.fr:22"    # SSH vers votre forge
sbx policy log                                  # ce qui a été bloqué, colonne PROXY

Le modèle de sécurité prévient lui-même du piège : la liste Balanced contient des jokers larges, par exemple *.googleapis.com, qui couvrent bien plus que des API d'IA. Passez sbx policy ls en revue et retirez ce dont l'agent n'a pas besoin. Pour un agent qui ne doit parler qu'au fournisseur de modèle et à votre dépôt Git, deny-all plus trois règles reste la configuration la plus lisible, et c'est la règle que nous donnions déjà dans l'analyse de l'affaire WorkOS : liste blanche de sortie, rien d'autre.

Côté secrets, le proxy intercepte chaque requête sortante, vérifie que la destination correspond à un service déclaré, retrouve l'identifiant sur l'hôte et réécrit l'en-tête d'authentification avant de transmettre. Dans la microVM, ANTHROPIC_API_KEY vaut proxy-managed. Les services intégrés couvrent notamment anthropic (api.anthropic.com, claude.ai), openai (api.openai.com, chatgpt.com), github (GH_TOKEN, api.github.com, github.com), google, mistral, openrouter, groq, xai, cursor et droid. Quelques formes utiles :

sbx secret set github --command 'gh auth token'          # résolu sur l'hôte, caché 55 min
sbx secret set openai --sandbox site-codex                # limité à un sandbox
sbx secret set anthropic --ref 'op://Travail/Anthropic/credential'   # 1Password ou AWS Secrets Manager
sbx secret ls
sbx secret rm github

Pour un service hors liste, un secret personnalisé (expérimental) se lie à un hôte et à une variable : printf '%s' "$API_KEY" | sbx secret set-custom --host api.exemple.fr --env API_KEY --value-stdin. L'agent voit alors un espace réservé de la forme sbx-cs-…, remplacé uniquement dans les en-têtes HTTP, jamais dans le corps des requêtes. Une bonne habitude complémentaire sur l'hôte : auditd sur le répertoire ~/.config/com.docker.sandboxes, pour savoir quel processus lit le fichier de secrets d'un serveur headless.

Le fichier sbxenv.yaml : décrire un environnement reproductible

Au-delà de la ligne de commande, sbx env lit un fichier sbxenv.yaml qui déclare tout le sandbox d'un projet : agent, espace de travail, ressources, secrets, ports, variables et commandes d'hôte. Docker le marque expérimental : l'interface et le format peuvent changer. Le billet du 5 novembre y voit la façon de partager un sandbox avec un collègue en une commande. Deux champs seulement sont obligatoires, schemaVersion (toujours "1") et agent ; les chemins relatifs se résolvent depuis le répertoire du fichier, et la documentation demande de garder ce fichier hors de tout répertoire monté, par exemple à côté du dossier du projet, dans un dépôt versionné à part. Un exemple pour un agent Claude Code en mode clone, limité à 4 vCPU et 8 Go, qui expose le serveur de développement sur l'hôte :

# ~/projets/site.sbxenv.yaml  (le projet est dans ~/projets/site, non monté par ce fichier)
schemaVersion: "1"
name: site-claude
agent: claude
workspace:
  path: ./site
  clone: true
sandboxOptions:
  cpus: 4
  memory: 8g
  skills: readonly
env:
  NODE_ENV: development
secrets:
  anthropic:
    ref: op://Travail/Anthropic/api-key
  github:
    command: gh auth token
ports:
  - sandbox: 3000
    host: 8080
lifecycle:
  initialize:
    - name: Préparer le dépôt
      command: test -d site || git clone git@git.exemple.fr:equipe/site.git
      timeout: 5m

Quelques précisions sur les champs. sandboxOptions accepte aussi template (image de base personnalisée), pullPolicy, gpu et display ; cpus: 0 prend la valeur par défaut de l'hôte. Chaque entrée de secrets définit exactement une source parmi value, ref ou command : la page prévient qu'une value littérale est lisible par quiconque ouvre le fichier, donc préférez une référence de coffre ou une commande. Les blocs lifecycle (initialize, postCreate, preRemove) sont des commandes exécutées sur l'hôte, pas dans la microVM. Un fichier ~/.sbxenv.yaml porte vos réglages personnels communs à tous les projets, sans pouvoir fixer name. Les commandes :

sbx env plan ~/projets/site.sbxenv.yaml        # montre les changements sans les appliquer
sbx env run ~/projets/site.sbxenv.yaml         # crée le sandbox si besoin, puis s'attache
sbx env create ~/projets/site.sbxenv.yaml      # crée sans s'attacher
sbx env exec ~/projets/site.sbxenv.yaml -- npm test
sbx env rm ~/projets/site.sbxenv.yaml          # plan de destruction, puis suppression

Les options --name, --env-arg NOM=VALEUR, --force, --clone et --skip-host-commands complètent ces commandes. Pour une équipe qui partage un serveur dédié, c'est le pendant de ce que Docker Compose fait pour les applications : un fichier dans Git, le même environnement pour tous, et des secrets qui ne figurent jamais en clair dedans.

Ce que la microVM ne protège pas

Le modèle de sécurité de Docker liste lui-même ce qui reste à votre charge, et il faut le lire avant de confier des clés de production à un agent.

• Le mode direct écrit immédiatement sur l'hôte. Un espace de travail monté en lecture-écriture, c'est votre arbre de travail : des fichiers exécutés implicitement plus tard peuvent y être déposés. Relisez les hooks dans .git/ (invisibles dans git diff), la configuration CI, les tâches de l'IDE, les réglages de projet des agents, le Makefile et les scripts de package.json. Sur un serveur, le mode clone règle la question.
• Les serveurs MCP locaux tournent sur l'hôte, pas dans la VM : un serveur stdio enregistré dans la passerelle MCP, ou un conteneur qu'il lance, utilise les permissions et l'isolation de l'hôte. Traitez-les comme des intégrations de confiance. Un serveur MCP qui pilote Proxmox depuis un sandbox donne donc à l'agent exactement les droits du token Proxmox, isolation ou pas.
• Les compétences partagées forment une frontière commune. Le magasin de skills est monté en lecture seule par défaut ; un sandbox en readwrite peut modifier les instructions lues par les autres. Les kits, eux, exécutent leurs commandes d'installation en root dans le sandbox, avec des sources limitées à Docker Hub par défaut.
• Une frontière d'hyperviseur n'est pas absolue. La faille PwnEscape (CVE-2026-99999) permettait à une VM KVM de lire la RAM de l'hôte via la pile virtio, après dix-huit ans de présence dans le noyau. Docker précise que sa page ne traite ni des évasions d'hyperviseur ni des canaux auxiliaires. Le noyau de l'hôte Ubuntu doit donc rester à jour, ce que les mises à jour de sécurité automatiques garantissent sans y penser.
• L'exfiltration par une destination autorisée reste possible. Si github.com est ouvert, l'agent peut y pousser ce qu'il lit. La politique réseau limite la surface, elle ne lit pas le contenu.

Reste la question du bon outil pour le bon agent. Docker Sandboxes vise les sessions d'agent de code : Claude Code, Codex, Gemini CLI, Copilot, Cursor, Devin, Droid, Kiro, OpenCode, ou un simple shell sans agent pour tester. Un agent conversationnel qui tourne en continu avec ses connecteurs Telegram ou Discord, comme Hermes Agent, reste un service Docker classique, à isoler par les moyens habituels : conteneur sans socket Docker monté, pare-feu de sortie, identifiants à durée limitée, et un réseau privé Tailscale plutôt qu'un port ouvert sur l'IP publique.

En résumé

Sur un serveur dédié Ubuntu 24.04 avec KVM, Docker Sandboxes s'installe en deux commandes (get.docker.com avec SBX=1 ou REPO_ONLY=1 puis docker-sbx, utilisateur dans le groupe kvm), se connecte avec un jeton d'accès personnel, et lance un agent de code dans une microVM qui a son propre noyau et son propre moteur Docker, sans voir le démon de l'hôte. Ce que l'outil apporte réellement par rapport à un conteneur tient en trois points : une frontière d'hyperviseur, un proxy de sortie à refus par défaut, et des clés API qui n'entrent jamais dans la VM. Ce qu'il ne fait pas tient en un seul : il ne vous dispense pas de durcir l'hôte, de garder son noyau à jour et de relire ce que l'agent a écrit. Pour sauvegarder les espaces de travail et les clones avant un sbx rm, notre guide sauvegarder un serveur avec rsync s'applique tel quel.