Lancer OpenClaw ne se résume pas à démarrer un assistant dans une fenêtre de chat. Très vite, l’agent lit des fichiers, exécute des commandes, interagit avec des services externes et agit de façon autonome. À ce moment précis, une question devient centrale : jusqu’où peut-il accéder ? Le texte source montre que la réponse dépend largement d’un réglage précis, souvent activé dès les premières minutes : le mode sandbox « all ».
Éviter que l’agent agisse sur le système principal
L’usage décrit commence par une décision simple : ne pas installer OpenClaw directement sur la machine principale. L’agent est exécuté dans un environnement isolé, le plus souvent via Docker. Le lancement se fait depuis le terminal, avec des options de sécurité visibles dans la commande elle-même.
Les paramètres --read-only, --security-opt=no-new-privileges et --cap-drop=ALL sont ajoutés pour empêcher l’écriture hors des répertoires autorisés et bloquer toute élévation de privilèges.
Aucune de ces protections n’est implicite. Si un flag manque, l’agent dispose immédiatement de droits plus larges que prévu.
Restreindre concrètement l’accès aux fichiers
Le montage des volumes apparaît comme l’un des points les plus sensibles. Une configuration trop large donne accès à des éléments très concrets : clés SSH, fichiers personnels, configurations de clusters ou photos.
La pratique recommandée consiste à créer un dossier de travail dédié, monté explicitement dans le conteneur, et rien d’autre.
Ce choix détermine ce que l’agent peut réellement voir, lire ou modifier. Il n’existe pas de garde-fou automatique : une mauvaise ligne de montage suffit à exposer tout un répertoire.
Activer le mode sandbox « all » pour cloisonner les sessions
OpenClaw propose plusieurs modes de sandboxing. Le mode « all » force chaque session à s’exécuter dans son propre conteneur. Concrètement, une tâche ne partage pas son environnement avec la suivante.
À ce réglage s’ajoute le paramètre workspace_access, qui définit le niveau d’accès aux fichiers :
"none": aucun accès"ro": lecture seule"rw": lecture et écriture
Le texte source décrit une approche prudente : commencer avec les accès les plus limités, puis les ouvrir uniquement si une tâche précise l’exige.
Des risques observés lors de tests réels
Les restrictions ne sont pas présentées comme théoriques. Des tests de sécurité montrent des attaques par prompt injection réussies, notamment via des e-mails contenant des instructions dissimulées. Dans ces cas, l’agent exécute des actions avec les autorisations qui lui ont été accordées.
Des plugins modifiés ont également circulé via des chaînes de dépendances, parfois téléchargés massivement avant d’être détectés.
Ces exemples expliquent pourquoi plusieurs experts déconseillent explicitement toute installation d’OpenClaw sur une machine principale non isolée.
Changer d’environnement pour réduire encore les accès
Lorsque Docker ne suffit pas, d’autres options sont décrites : exécuter OpenClaw sur un VPS cloud, sur un Mac Mini dédié ou via Cloudflare Workers. Chaque choix modifie les accès possibles :
sur un VPS, aucune donnée personnelle locale ; sur un Mac Mini, accès au réseau domestique ; avec les Workers, aucune exécution de code local.
Le coût, le temps de mise en place et le niveau d’isolement varient, mais l’objectif reste identique : limiter ce que l’agent peut atteindre.
Accepter une mise en place plus lente pour garder le contrôle
La configuration décrite demande du temps : réglage des permissions, suppression des identifiants inutiles, activation de la journalisation et vérifications régulières. Rien n’est instantané.
Cette lenteur initiale conditionne l’usage quotidien.
Dans le cadre présenté, le mode sandbox « all » n’est pas un détail technique : c’est le réglage qui définit concrètement jusqu’où OpenClaw peut aller, et surtout ce à quoi il n’a jamais accès.
Passionné de téléphones mobiles, de maison intelligente et d’intelligence artificielle. Pendant mon temps libre, j’aime nager, faire du vélo et programmer de nouvelles applications.
