Sécurisez votre passerelle OpenClaw
Appliquez la configuration de base sécurisée recommandée dans la documentation OpenClaw : loopback et authentification par token, sandbox, approbation stricte des commandes exec et contrôle rigoureux des personnes autorisées à envoyer des messages à l’agent.
Certains paramètres par défaut sont permissifs : la sandbox est désactivée et exec.security est réglé sur full sur les hôtes de passerelle. Sauvegardez ~/.openclaw/openclaw.json avant de le modifier.
Lancez l’audit de sécurité
L’audit standard vérifie votre configuration ; --deep ajoute des vérifications approfondies et --fix applique les corrections qu’il peut effectuer automatiquement. Ajoutez --json pour obtenir une sortie analysable par des scripts. Relancez l’audit après chacune des étapes ci-dessous.
shell openclaw security audit openclaw security audit --deep openclaw security audit --fixGénérez un token robuste
L’assistant de configuration crée déjà un token. Si vous en définissez un vous-même, utilisez au moins 24 caractères : l’audit signale tout token plus court. Cette commande affiche 64 caractères hexadécimaux aléatoires.
shell openssl rand -hex 32Utilisez loopback avec l’authentification par token
Dans openclaw.json, définissez gateway.mode sur local, gateway.bind sur loopback et gateway.auth.mode sur token, puis renseignez dans gateway.auth.token le token de l’étape 2. L’authentification de la passerelle échoue de manière sécurisée : les requêtes sans token valide sont refusées. N’utilisez pas lan, custom ou auto sur un hôte exposé à Internet.
Placez les outils en sandbox et limitez l’accès aux fichiers
La sandbox est désactivée par défaut. Activez-la avec l’un des backends pris en charge (Docker, Podman, SSH, OpenShell ou Crabbox), puis vérifiez le résultat avec openclaw sandbox explain. Définissez ensuite tools.profile sur messaging et tools.fs.workspaceOnly sur true, puis ajoutez à tools.deny les groupes d’outils que vous n’utilisez pas, comme group:automation et group:runtime.
Verrouillez les commandes shell
Définissez tools.exec.security sur deny pour empêcher l’agent d’exécuter des commandes. Si un workflow en nécessite quelques-unes, passez à allowlist et laissez tools.exec.ask sur always afin que chaque commande attende votre approbation ; askFallback est réglé par défaut sur deny si personne ne répond. Laissez tools.elevated.enabled sur false.
Contrôlez qui peut contacter l’agent
Laissez dmPolicy sur pairing, définissez requireMention sur true pour les groupes et réglez session.dmScope sur per-channel-peer afin que les expéditeurs ne partagent jamais une session. Les skills s’exécutent avec les privilèges de l’agent et OpenClaw ne bloque pas le code dangereux lors de l’installation. Vérifiez donc le statut d’audit de chaque skill ClawHub avant de l’installer et définissez security.installPolicy. En février 2026, des chercheurs ont découvert des centaines de skills malveillantes sur ClawHub.
La documentation considère chaque passerelle comme une frontière de confiance unique, et non comme un environnement hostile multi-tenant. Exécutez des passerelles distinctes pour différentes personnes ou différents domaines de confiance.