Guide complet de sécurité OpenClaw : cinq niveaux de défense, de la sandbox Docker au contrôle des permissions

Conclusion rapide (par ordre de priorité)

Si vous ne faites que trois choses, vous couvrirez déjà la majorité des scénarios à haut risque avec OpenClaw :

1. imposer l’authentification (token/mot de passe) et limiter les points d’entrée ;
2. sandbox conteneur + non-root + moindre privilège ;
3. listes blanches pour les outils sensibles, refus par défaut des commandes dangereuses.
   Une fois ces trois étapes en place, complétez couche par couche l’audit et l’isolation réseau : c’est là que le gain sécurité est le plus fort.

À trois heures du matin, un développeur a posté un appel à l’aide sur Reddit. Il avait installé OpenClaw sur son MacBook, l’avait fait tourner deux semaines en config par défaut, et trouvait ça génial. Jusqu’au jour où il a demandé à OpenClaw de « m’aider à ranger les fichiers récents du projet » — l’IA a lu ~/.ssh/ et ~/.aws/, puis a « gentiment » affiché le contenu de sa clé privée dans la réponse.

Pire encore : cette conversation avait été synchronisée dans son groupe de travail.

Franchement, en lisant ce cas la première fois, j’ai eu un frisson dans le dos. OpenClaw est un assistant IA très puissant : commandes Shell, lecture/écriture de fichiers, contrôle du navigateur — mais cela signifie aussi que, mal configuré, c’est comme laisser entrer un inconnu avec les clés de chez vous.

Vous vous dites peut-être : je suis seul à l’utiliser, ça ira.

Eh bien, c’est justement le piège. Les risques d’OpenClaw ne viennent pas seulement d’attaques externes : injection de prompt (instructions malveillantes glissées dans le chat), erreurs de config (port API exposé par inadvertance), ou même la « zèle excessif » de l’IA (vous demandez de nettoyer des fichiers, elle comprend qu’il faut supprimer des données importantes).

Tout cela est évitable — à condition de bien configurer.

Cet article vous montre pas à pas comment mettre OpenClaw dans une « cage de sécurité » — de l’isolation Docker au contrôle fin des permissions, cinq niveaux de défense pour utiliser cette « bête » en toute sérénité. Avertissement : la config semble un peu lourde, mais comparée à une fuite de données ou un rm -rf sur la base, ce n’est vraiment pas grand-chose.

Guide low-cost « élever la crevette » : ArkClaw démocratise les agents IA

OpenClaw (homard) est populaire mais la config rebute ? ArkClaw de ByteDance Volcano Engine abaisse le seuil au minimum. Sans serveur ni tokens à bricoler : un agent en ligne 24 h/24 qui contrôle le navigateur, exécute des scripts et gère l’agenda en un clic.

Le prix compte : 9,9 ¥/mois ; avec mon code d’invitation ZLKUK54M (inscription ici) seulement 8,9 ¥. Développeur ? Le Coding Plan Pro peut même inclure ArkClaw gratuitement.

Pourquoi une configuration de sécurité ?

Quel est le niveau de permissions d’OpenClaw ?

Commençons par un fait qui remet les idées en place. OpenClaw n’est pas un assistant qui ne fait que discuter — il peut faire à peu près tout ce que vous feriez dans un terminal :

• Exécuter des commandes Shell arbitraires : rm -rf / ? Techniquement possible.
• Lire et écrire sur tout le système de fichiers : clés SSH, identifiants AWS, mots de passe de base de données — s’ils sont sur le disque, il peut y accéder.
• Accéder aux ressources réseau : appeler des API, télécharger des fichiers, scanner des ports du réseau interne.
• Contrôler le navigateur : via Playwright, y compris des sites où vous êtes déjà connecté.
• Lire les variables d’environnement : tout ce qui est dans process.env est visible.

En d’autres termes, donner les permissions par défaut à OpenClaw, c’est comme confier un passe-partout de chez vous à un assistant « très intelligent mais que vous ne connaissez pas bien ».

À quel point la config par défaut est-elle dangereuse ?

Je sais que beaucoup font simple : npm install -g openclaw, puis openclaw gateway (ou le daemon qui démarre tout seul). Mais savez-vous ce qui se passe par défaut ?

Avant v2026.1.29 :

• Le contrôle d’accès pouvait être auth: none : quiconque obtenait votre URL contrôlait votre OpenClaw.
• Aucune sandbox : l’IA pouvait lire/écrire sur tout le système de fichiers.
• Tous les outils activés par défaut, y compris exec et browser.
• Exécution possible avec des privilèges élevés (voire root).

"v2026.1.29 supprime obligatoirement l’option auth: none ; une authentification par token ou mot de passe est désormais requise"

Après v2026.1.29, c’est un peu mieux : l’option auth: none a été retirée ; token ou mot de passe obligatoire. Mais le reste persiste — sandbox, permissions des outils, accès au système de fichiers : tout cela reste à configurer manuellement.

Franchement, la config par défaut, c’est dormir porte ouverte avec un panneau « bienvenue, visiteurs ».

Trois objectifs de la configuration de sécurité

Pourquoi tant de réglages ? Trois objectifs au fond :

1. Principe du moindre privilège : ne donner à OpenClaw que ce dont il a vraiment besoin. Vous lui demandez d’écrire du code ? Accès lecture/écriture au workspace ; pas besoin du navigateur ? Désactivez l’outil browser.

2. Défense en profondeur : ne pas miser sur une seule barrière. Isolation Docker, utilisateur non privilégié, contrôle d’accès, liste blanche d’outils, isolation réseau — cinq couches ; si l’une cède, les autres tiennent.

3. Rayon d’explosion maîtrisé : au pire — injection de prompt, fuite de token, bug de l’IA — quelle est la perte maximale ? Si OpenClaw n’accède qu’à un workspace isolé, la fuite se limite à ce dossier, pas à tout /home.

En clair : la sécurité ne vise pas à empêcher toute attaque (impossible), mais à rendre l’attaque coûteuse et les dégâts limités.

Cinq niveaux de configuration de sécurité

Passons à la pratique. De la couche basse à la haute, cinq niveaux de défense. Chaque couche : pourquoi, et comment vérifier que c’est en place.

Niveau 1 : isolation sandbox Docker (obligatoire)

Pourquoi Docker ?

Beaucoup voient Docker comme un outil de déploiement. Erreur. Pour une application à privilèges élevés comme OpenClaw, la vraie valeur, c’est l’isolation :

• Isolation du système de fichiers : l’IA ne voit que les fichiers du conteneur ; votre ~/.ssh reste sur l’hôte.
• Isolation réseau : couper l’accès Internet ou n’autoriser que certains domaines.
• Limites de ressources : éviter qu’une boucle infinie fonde le CPU.
• Reprise rapide : problème ? docker rm, reconstruire un conteneur propre en quelques secondes.

On objecte parfois : je tourne en local, faut-il vraiment tout ça ?

Oui. Le local est plus risqué — tokens GitHub, mots de passe de BDD, clés API : autant de cibles pour l’injection de prompt.

Étapes de configuration

1. Créer un Dockerfile sécurisé

Vultr - Serveur cloud NVMe haute performance, 32 emplacements mondiaux, déploiement Docker en un clic

Voir les tarifs →Pub

FROM openclaw/gateway:latest

# Créer un utilisateur non privilégié
RUN adduser --disabled-password --gecos '' clawuser

# Passer à l'utilisateur non privilégié
USER clawuser

# Répertoire de travail
WORKDIR /home/clawuser/openclaw

Le point clé : USER clawuser. Par défaut, le conteneur tourne en root ; OpenClaw aurait alors les privilèges root. Un utilisateur dédié limite les dégâts en cas de fuite du conteneur.

2. Paramètres de sécurité dans Docker Compose

Le cœur du dispositif, ligne par ligne :

version: '3.8'
services:
  openclaw-gateway:
    build: .
    container_name: openclaw-safe

    # Sécurité
    security_opt:
      - no-new-privileges:true  # Empêche l'élévation de privilèges dans le conteneur
    cap_drop:
      - ALL  # Retire toutes les Linux capabilities
    cap_add:
      - NET_BIND_SERVICE  # N'ajoute que la capacité de lier un port

    # Système de fichiers racine en lecture seule
    read_only: true

    # Répertoires temporaires (écriture)
    tmpfs:
      - /tmp
      - /home/clawuser/openclaw/temp

    # Limites de ressources
    deploy:
      resources:
        limits:
          cpus: '2.0'
          memory: 4G
        reservations:
          cpus: '1.0'
          memory: 2G

    # Isolation réseau
    networks:
      - openclaw-isolated

    # Volumes (moindre privilège)
    volumes:
      # Workspace (lecture/écriture)
      - ./workspace:/home/clawuser/workspace
      # Config (lecture seule)
      - ./config:/home/clawuser/openclaw/config:ro
      # Logs (écriture seule)
      - ./logs:/home/clawuser/openclaw/logs

networks:
  openclaw-isolated:
    driver: bridge
    internal: true  # Pas d'accès réseau externe

Pourquoi cette config ?

• no-new-privileges:true : bloque sudo et setuid ; même avec une faille, pas d’élévation de privilèges.
• cap_drop: ALL : les capabilities Linux sont granulaires ; tout retirer, ne remettre que le nécessaire (ex. lier un port) réduit la surface d’attaque.
• read_only: true : racine en lecture seule ; pas de backdoor ni de modification système. L’écriture passe par tmpfs (/tmp, etc.).
• internal: true : pas de réseau externe. Si OpenClaw n’a pas besoin du web (fichiers locaux uniquement), cela limite l’exfiltration.

3. Activer le mode sandbox d’OpenClaw

La config principale au runtime se trouve en général dans ~/.openclaw/openclaw.json (JSON). Le YAML ci-dessous est une analogie de structure ; noms de champs et imbrication : voir la doc officielle Gateway. Un dépôt GitOps maison peut utiliser config/config.yaml — ce n’est pas le nom par défaut upstream.

sandbox:
  mode: "non-main"  # Tous les chats de groupe tournent dans des conteneurs isolés
  docker:
    enabled: true
    network: "none"  # Désactive le réseau des conteneurs sandbox

Fonction sandbox propre à OpenClaw. mode: "non-main" : hors de votre fenêtre principale, chaque conversation tourne dans un conteneur Docker dédié. Une injection de prompt dans un fil de groupe ne peut agir que dans sa petite sandbox.

Vérification

Ne vous précipitez pas ; vérifiez d’abord :

# Vérifier que le conteneur n'est pas root
docker exec openclaw-safe whoami
# Attendu : clawuser

# Vérifier le système de fichiers en lecture seule
docker exec openclaw-safe touch /test.txt
# Attendu : Read-only file system

# Vérifier l'isolation réseau
docker exec openclaw-safe ping 8.8.8.8
# Attendu : Network is unreachable

Si les trois tests passent, le premier niveau est en place.

Niveau 2 : exécution avec utilisateur non privilégié (obligatoire)

Non-root dans le conteneur, d’accord — mais qui lance le conteneur ? Si vous faites docker-compose up en root sur l’hôte, une évasion Docker peut encore donner root.

Solution : utilisateur dédié à faibles privilèges sur l’hôte

Configuration sur l’hôte :

# Créer groupe et utilisateur dédiés
sudo groupadd -r openclaw
sudo useradd -r -g openclaw -d /opt/openclaw -s /bin/bash clawuser

# Structure de répertoires
sudo mkdir -p /opt/openclaw/{workspace,config,logs,temp}

# Permissions
sudo chown -R clawuser:openclaw /opt/openclaw
sudo chmod 700 /opt/openclaw/config  # Config : owner seulement
sudo chmod 755 /opt/openclaw/workspace  # Workspace
sudo chmod 750 /opt/openclaw/logs  # Logs

# Limiter les privilèges utilisateur
sudo usermod -L clawuser  # Verrouiller connexion par mot de passe ; su uniquement

Pourquoi chmod 700 ?

Seul le propriétaire (clawuser) lit/écrit/exécute ; les autres n’ont même pas la liste. Tokens et mots de passe dans la config : à protéger absolument.

Permissions des fichiers d’identifiants (crucial !)

Pour WhatsApp ou autres services connectés à OpenClaw :

# Fichiers d'identifiants en 600 (owner lecture/écriture seulement)
chmod 600 ~/.openclaw/credentials/whatsapp/*/creds.json
chmod 700 ~/.openclaw

J’ai vu des 644 (lisibles par tous) sur un serveur partagé — identifiants volés par un autre utilisateur. Ne commettez pas cette erreur basique.

Vérification

# Utilisateur du processus OpenClaw
ps aux | grep openclaw
# Attendu : clawuser, pas root

# Permissions des fichiers
ls -la /opt/openclaw/config
# Attendu : drwx------ clawuser openclaw

Pourquoi ce niveau compte

Au pire : conteneur compromis, sandbox OpenClaw contournée, code arbitraire — l’attaquant reste clawuser :

• Pas d’accès aux fichiers des autres utilisateurs
• Pas d’installation système (pas de sudo)
• Pas de modification de /etc
• Pas de lecture de /root

C’est la défense en profondeur : une couche tombe, la suivante tient.

Niveau 3 : contrôle d’accès et authentification (obligatoire)

Les deux premiers niveaux limitent ce qu’OpenClaw peut faire ; celui-ci limite qui peut l’utiliser.

Changement majeur v2026.1.29

Avant, auth: none (aucune vérification) était possible — un désastre. v2026.1.29 l’a supprimé ; token ou mot de passe obligatoire.

Configurer l’authentification par token Gateway

Avantage du token vs mot de passe : un token par personne/application, permissions distinctes ; fuite d’un token → révocation sans impacter les autres.

Toujours dans la section Gateway de ~/.openclaw/openclaw.json (ne pas confondre avec config/config.yaml d’un dépôt maison ; YAML indicatif) :

gateway:
  # Authentification par token obligatoire
  auth: token

  # Configuration des tokens
  tokens:
    - name: "admin-token"
      value: "${OPENCLAW_ADMIN_TOKEN}"  # Variable d'environnement, pas en dur !
      permissions:
        - "admin"  # Permissions complètes

    - name: "readonly-token"
      value: "${OPENCLAW_READONLY_TOKEN}"
      permissions:
        - "chat"  # Chat uniquement
        - "read"  # Lecture fichiers
      # Sans exec, browser, etc.

Générer des tokens robustes

Pas de 123456 ou mytoken. Token aléatoire 256 bits :

# Générer un token aléatoire
openssl rand -base64 32

# Variables d'environnement (pas dans le fichier de config !)
export OPENCLAW_ADMIN_TOKEN="votre token généré"
export OPENCLAW_READONLY_TOKEN="un autre token"

Pourquoi pas en dur ? Le fichier de config peut finir dans Git, les logs ou une sauvegarde cloud. Les variables d’environnement sont relativement plus sûres.

Liste blanche d’accès

Le token répond à « qui peut accéder », mais vous voulez peut-être limiter à certains utilisateurs ou groupes WhatsApp :

# Politique DM (messages privés)
dmPolicy: allowlist  # Mode liste blanche
allowFrom:
  - "user_id_1"
  - "user_id_2"

# Politique groupe
groupPolicy: allowlist
allowFrom:
  - "group_id_1"

# Mention gating (réponse aux @ uniquement en groupe)
mentionGating: true

# Pas d'accès public
publicAccess: false

mentionGating: true est très utile. OpenClaw dans un groupe de 100 personnes sans ça : chaque message est traité (coût + surface d’attaque par prompt). Avec : réponse seulement quand on le @.

Vérification

# Accès non autorisé (doit échouer)
curl -X POST http://localhost:3000/api/chat \
  -H "Content-Type: application/json" \
  -d '{"message":"hello"}'
# Attendu : 401 Unauthorized

# Token valide
curl -X POST http://localhost:3000/api/chat \
  -H "Authorization: Bearer ${OPENCLAW_ADMIN_TOKEN}" \
  -H "Content-Type: application/json" \
  -d '{"message":"hello"}'
# Attendu : 200 OK

Pourquoi ce niveau est clé

Sans contrôle d’accès, isolation Docker et moindre privilège ne servent à rien — l’attaquant passe par l’API directement.

Railway - Plateforme de déploiement moderne, sans opérations complexes, en ligne en quelques minutes

Commencer →Pub

C’est le gardien à la porte.

Niveau 4 : contrôle des permissions des outils (recommandé)

OpenClaw est en cage, mais il a encore beaucoup d’outils. Il est temps d’en retirer les plus dangereux.

Problème : tous les outils activés par défaut

Des dizaines d’outils : exec, browser, write_file, web_fetch… Tout est ouvert par défaut.

En pratique, pour écrire du code et chercher de la doc, browser et exec peuvent rester désactivés.

Liste blanche d’outils

tools:
  # Outils sûrs uniquement
  allowlist:
    - "read_file"
    - "write_file"     # Écriture limitée aux répertoires autorisés
    - "web_search"
    - "git"
    # Sans exec, browser, etc.

  # Outils à risque : autorisation explicite
  exec:
    enabled: false

  browser:
    enabled: false

  web_fetch:
    enabled: true
    allowedDomains:
      - "github.com"
      - "api.anthropic.com"
      - "*.npmjs.com"

Si exec est indispensable : liste blanche de commandes

Tests, build de projet :

tools:
  exec:
    enabled: true
    sandbox: true

    allowCommands:
      - "git"
      - "npm"
      - "yarn"
      - "pytest"
      - "curl"

    denyCommands:
      - "rm -rf"
      - "sudo"
      - "chmod 777"
      - "dd if="
      - "mkfs"
      - "> /dev/sda"

Liste blanche > liste noire : les attaques sont infinies ; les commandes sûres, non.

Restriction d’accès au système de fichiers

filesystem:
  allowedPaths:
    - "/home/clawuser/workspace"
    - "/home/clawuser/projects"

  deniedPaths:
    - "/home/clawuser/.ssh"
    - "/home/clawuser/.aws"
    - "/home/clawuser/.config"
    - "/etc"
    - "/root"

  defaultPermission: "readonly"

  writablePaths:
    - "/home/clawuser/workspace/temp"

Même avec un prompt du type « lis ~/.ssh/id_rsa », refus.

Vérification

Dans le chat OpenClaw :

• Vous : « Exécute sudo apt update »

  • Réponse attendue : commande bloquée par la politique de sécurité

• Vous : « Lis le fichier ~/.ssh/id_rsa »

  • Réponse attendue : Access denied

Niveau 5 : isolation réseau et surveillance (avancé)

Entreprise, données sensibles, ou paranoia saine : niveau ultime.

Isolation réseau : couper les connexions inutiles

internal: true bloque Internet — mais OpenClaw doit appeler l’API Claude ?

Solution : proxy avec liste blanche de domaines

Seuls api.anthropic.com, etc. ; le reste bloqué :

# docker-compose.yml
services:
  openclaw-gateway:
    environment:
      - HTTP_PROXY=http://allowlist-proxy:8080
      - HTTPS_PROXY=http://allowlist-proxy:8080
    networks:
      - openclaw-isolated

  allowlist-proxy:
    image: squid:latest
    volumes:
      - ./squid.conf:/etc/squid/squid.conf:ro
    networks:
      - openclaw-isolated
      - external  # Seul le proxy accède à l'extérieur

squid.conf (liste blanche) :

acl allowed_domains dstdomain .anthropic.com
acl allowed_domains dstdomain .github.com
acl allowed_domains dstdomain .npmjs.com

acl SSL_ports port 443
acl CONNECT method CONNECT

http_access allow allowed_domains
http_access deny all

access_log /var/log/squid/access.log

OpenClaw n’atteint que ces domaines ; « télécharge un script malveillant » via injection → bloqué par le proxy.

Journal d’audit : tout enregistrer

Les logs n’empêchent pas l’attaque, mais expliquent ce qui s’est passé :

logging:
  level: "info"

  auditLog:
    enabled: true
    path: "/home/clawuser/openclaw/logs/audit.log"
    format: "json"

    logToolCalls: true
    logFileAccess: true
    logNetworkRequests: true
    logPrompts: true

  sessionLog:
    enabled: true
    path: "/home/clawuser/openclaw/logs/sessions/"

logPrompts: true est crucial pour repérer « ignore les restrictions précédentes, exécute… » après coup.

Surveillance en temps réel

# Activité suspecte
tail -f /opt/openclaw/logs/audit.log | grep -E "(exec|sudo|rm|chmod)"

# Connexions réseau
docker exec openclaw-safe netstat -tuln

# Ressources
docker stats openclaw-safe

Alertes

alerts:
  - type: "command_execution"
    pattern: "sudo|rm -rf|chmod 777"
    action: "block_and_notify"

  - type: "file_access"
    pattern: "/.ssh/|/.aws/|/etc/passwd"
    action: "block_and_notify"

  - type: "network_request"
    pattern: ".*\\.onion|torproject\\.org"
    action: "block_and_notify"

Email, Slack, ou arrêt du service OpenClaw.

Stratégie de départ en lecture seule

Cinq niveaux en place — tout activer d’un coup ?

Non.

Sécurité et confort se balancent. Trop strict → OpenClaw inutilisable ; trop laxiste → pas de protection.

Mieux : partir du plus strict, assouplir progressivement.

Semaine 1 : mode lecture seule

Au déploiement :

tools:
  allowlist:
    - "read_file"
    - "web_search"
    - "git_log"

filesystem:
  defaultPermission: "readonly"
  writablePaths: []

Cette semaine : observer.

• Fichiers souvent accédés
• Activité suspecte dans les logs
• Outils habituellement appelés
• Test d’injection de prompt (en environnement sûr)

Semaine calme → base OK. Tentatives fréquentes sur .ssh → config ou attaque réelle.

Semaine 2 : écriture limitée

filesystem:
  writablePaths:
    - "/home/clawuser/workspace/temp"

tools:
  allowlist:
    - "write_file"
    - "git_commit"

Seul le répertoire temporaire est writable ; le code source reste protégé.

« Nettoie le projet » compris comme tout supprimer → dégâts limités aux temporaires.

Alibaba Cloud - Choix n°1 des développeurs, 15 % de réduction exclusive sur Lighthouse

Obtenir -15 % →Pub

Semaine 3 et au-delà : outils à la demande

tools:
  exec:
    enabled: true
    sandbox: true
    allowCommands:
      - "git"
      - "npm test"

Principes :

• Un seul levier à la fois
• 24 h d’observation après chaque assouplissement (logs d’audit)
• Rollback immédiat si comportement suspect

Cas réel : mon évolution de config

Au début j’ai voulu tout d’un coup, doc « sécurité complète » — OpenClaw ne pouvait même plus compléter du code (write_file désactivé).

J’ai appris :

• Semaine 1 : lecture seule, doc et explication de code. RAS.
• Semaine 2 : écriture dans workspace/drafts. OK.
• Semaine 3 : git pour commits — oubli de config Git user, erreurs ; corrigé, OK.
• Semaine 4 : npm test. Suffisant au quotidien.

browser et exec sans limite ? Jamais activés, jamais nécessaires.

Leçon : ne configurez pas des permissions « rassurantes » mais inutiles. Mieux vaut assouplir au besoin.

Checklist de sécurité

Comment vérifier qu’il ne manque rien ? Cette liste évite ~90 % des erreurs bêtes avant déploiement.

Avant déploiement (tout cocher)

Sécurité conteneur :

• ☐ Utilisateur non privilégié (pas root dans le conteneur)
• ☐ no-new-privileges:true
• ☐ cap_drop: ALL
• ☐ Racine en lecture seule (read_only: true)
• ☐ Limites CPU/mémoire
• ☐ Mode sandbox OpenClaw activé

Authentification :

• ☐ Token fort (pas auth: none)
• ☐ Token ≥32 caractères, aléatoire
• ☐ Token en variable d’environnement, pas dans le code
• ☐ Liste blanche DM/groupe
• ☐ Sur VPS : liste blanche IP si applicable

Contrôle des permissions :

• ☐ Liste blanche d’outils
• ☐ Outils à risque désactivés ou liste blanche de commandes
• ☐ Restrictions système de fichiers
• ☐ .ssh, .aws, etc. en liste d’interdiction
• ☐ Fichiers d’identifiants en 600

Audit et surveillance :

• ☐ Journal d’audit activé
• ☐ Journal de session activé
• ☐ Espace disque suffisant pour les logs
• ☐ Vous savez lire et analyser les logs

En production (régulier)

Hebdomadaire :

• ☐ Parcourir le journal d’audit
• ☐ CPU, mémoire, disque
• ☐ Tentatives d’accès non autorisé
• ☐ Sauvegarder la config

Mensuel :

• ☐ Mettre à jour OpenClaw
• ☐ Rotation des tokens (services longue durée)
• ☐ docker scan sur l’image
• ☐ Retirer les permissions devenues inutiles

Préparation à l’urgence

Script d’arrêt d’urgence :

#!/bin/bash
# emergency-stop.sh

echo "Arrêt d'urgence OpenClaw..."

docker stop openclaw-safe

# Révoquer tous les tokens (si système dynamique)
# curl -X DELETE https://your-auth-server/tokens/revoke-all

curl -X POST https://your-webhook-url \
  -H "Content-Type: application/json" \
  -d '{"text":"OpenClaw arrêté en urgence"}'

echo "Arrêté. Consultez les logs : /opt/openclaw/logs/audit.log"

Fuite de token :

1. Révoquer immédiatement le token
2. Audit : usages du token
3. Nouveau token, informer les utilisateurs légitimes
4. Fuite de données → plan d’incident

Activité suspecte :

1. Ne pas couper tout de suite (alerte l’attaquant)
2. Sauvegarder logs et snapshot conteneur
3. Analyser vecteur et impact
4. Isoler, redémarrer ou reconstruire

Conclusion

En une phrase : OpenClaw est puissant, mais ce n’est une « bête » utile que dans une cage sécurisée.

Les cinq niveaux :

1. Sandbox Docker : conteneur, fichiers et réseau limités
2. Utilisateur non privilégié : dégâts limités même en cas d’intrusion
3. Contrôle d’accès : token + listes blanches
4. Permissions des outils : outils dangereux désactivés ou restreints
5. Réseau et surveillance : connexions filtrées, tout tracé

Les trois premiers sont obligatoires ; les deux derniers recommandés pour données sensibles ou déploiement entreprise.

Oui, c’est un peu lourd. « Je joue seul, faut-il vraiment ? »

Oui.

Pas parce qu’OpenClaw est mal conçu — ses capacités sont juste énormes. « Range les fichiers du projet » peut devenir « supprime les temporaires » incluant une draft non sauvegardée. « Historique Git récent » peut lire les identifiants dans .git/config.

Ce n’est pas malveillant, juste trop zélé — les conséquences peuvent être identiques.

La sécurité ne vise pas à empêcher OpenClaw de « mal faire », mais à limiter le rayon d’une erreur.

Trois actions :

1. Vérifiez votre config maintenant — config par défaut : stoppez et mettez au moins les trois premiers niveaux.
2. Strict d’abord, assouplir ensuite — une semaine en lecture seule avant d’ouvrir les permissions.
3. Logs d’audit chaque semaine — 5 minutes pour repérer l’anormal tôt.

OpenClaw est un excellent outil. Comme l’énergie nucléaire : bien maîtrisée, utile ; mal configurée, catastrophe.

La config est pénible — moins qu’une fuite, un rm -rf ou un post Reddit à trois heures du matin.

Non ?

Prochaines lectures

• 5 paramètres de sécurité à ne pas négliger dans la configuration initiale d’OpenClaw
• Configuration OpenClaw en détail : guide complet de openclaw.json
• Guide d’installation OpenClaw 2026 : déployer votre assistant IA personnel