Utiliser OpenClaw, c'est comme confier les clés de votre maison numérique à quelqu'un. Ce quelqu'un se trouve être un agent IA disposant d'un accès système, et tous ceux qui frappent à votre porte ne sont pas bienveillants.
Si vous hébergez vous-même OpenClaw (anciennement Moltbot, puis Clawdbot), vous avez probablement constaté une intensification des discussions sur la sécurité. Et pour cause : début 2026, des vulnérabilités (CVE) ont été documentées, notamment des failles d'exécution de code à distance, même sur des instances locales. Les discussions au sein de la communauté font état d'inquiétudes concernant les instances OpenClaw exposées, et des chercheurs ont recensé des skills malveillantes en circulation.
Voilà le point essentiel : OpenClaw n’est pas intrinsèquement dangereux. C’est un outil puissant. Et les outils puissants nécessitent des garde-fous appropriés.
Le modèle de menace réelle
Parlons de ce contre quoi vous vous protégez réellement. OpenClaw fonctionne comme un agent autonome capable d'exécuter des commandes, de lire des fichiers et d'interagir avec votre système. C'est voulu : c'est ce qui rend cet outil si utile.
Les risques liés à la sécurité se répartissent en trois catégories :
- Compromis direct : Les attaquants obtiennent un accès via des passerelles exposées, une authentification faible ou des vulnérabilités connues.
- Injection rapide : Des instructions malveillantes intégrées au contenu traité par l'agent, l'amenant à exécuter des actions non intentionnelles.
- Attaques de la chaîne d'approvisionnement : Compétences, plugins ou extensions compromis contenant du code malveillant
D'après une étude publiée sur arXiv en février 2026, les agents d'IA opérant dans des environnements sociaux sont confrontés à des défis de sécurité spécifiques liés aux illusions de sociabilité et aux interactions multi-agents. Le fonctionnement permanent d'OpenClaw accentue ces problèmes.
Les retours des membres de la communauté confirment ce que les chercheurs en sécurité affirment depuis longtemps : “ Vous devez l’utiliser sur un système qui ne vous intéresse pas ” ou “ Faites-le sur une machine isolée ayant accès à des comptes distincts de vos comptes habituels. ”
Isolement du déploiement : votre première ligne de défense
N'utilisez pas OpenClaw sur votre ordinateur principal. Vraiment pas.
Un utilisateur de Reddit l'a exprimé clairement : “ Lancer openClaw directement sur votre ordinateur principal peut être risqué. Je vous conseille de l'éviter, sauf s'il s'agit d'un ordinateur jetable. ”
Vous disposez de trois approches d'isolation solides :
Route de la machine virtuelle
Une machine virtuelle vous offre une isolation complète. Téléchargez QEMU ou utilisez Windows Hyper-V (intégré à Windows 10/11 Pro). Installez une distribution Linux minimale, configurez-y OpenClaw, et vous aurez créé un périmètre de sécurité.
Un utilisateur a partagé sa configuration Mac : “ Je l’exécute depuis un compte utilisateur distinct avec des règles interdisant l’accès à certains hôtes du réseau privé. ” Sous Ubuntu, il utilise le filtrage iptables qui n’autorise que certains ports vers l’instance OpenClaw.
Déploiement VPS
Un VPS chez des fournisseurs comme DigitalOcean ou Hetzner installe OpenClaw sur le matériel d'un tiers. Liez-le à localhost, désactivez l'authentification par mot de passe, configurez le pare-feu UFW et accédez-y via Tailscale ou un tunnel SSH.
Plusieurs membres de la communauté confirment la fiabilité des déploiements de fournisseurs de cloud. La séparation de vos données personnelles justifie la complexité minimale.
Matériel dédié
Un ancien ordinateur portable ou un Mac Mini dédié à OpenClaw assure l'isolation physique. Combiné à Tailscale pour un accès distant sécurisé, il vous offre un assistant IA local qui ne peut pas interagir avec vos systèmes principaux.
Trois approches d'isolation pour le déploiement d'OpenClaw, classées selon leur efficacité en matière de sécurité et leur cas d'utilisation.
Restriction des outils et sandboxing
OpenClaw est livré avec de puissantes “ compétences ”, c'est-à-dire des outils que l'agent peut utiliser. Certaines sont inoffensives. D'autres peuvent s'avérer dangereuses entre de mauvaises mains (ou en cas de mauvaise incitation).
L'outil d'exécution de nœuds (system.run) permet à OpenClaw d'exécuter des commandes système arbitraires. Les outils d'accès aux fichiers peuvent lire des données sensibles. Le contrôle du navigateur permet d'interagir avec les sessions authentifiées. Les outils réseau peuvent exfiltrer des données.
Voici ce que vous devez configurer :
Désactiver les outils par défaut dangereux
Dans votre configuration OpenClaw, désactivez ou limitez explicitement :
- Exécution de shell (system.run, exec, shell)
- Accès illimité aux fichiers (limité à des répertoires spécifiques)
- Outils réseau sans cas d'utilisation spécifique
- Automatisation du navigateur dans des contextes authentifiés
Les bonnes pratiques de sécurité pour le déploiement d'agents d'IA recommandent d'utiliser une liste blanche plutôt qu'une liste noire pour contrôler l'accès aux outils. N'activez que les outils nécessaires à votre cas d'utilisation spécifique.
Configurer les autorisations au niveau de l'outil
OpenClaw prend en charge un modèle d'autorisation des commandes. Imaginez-le comme un système d'autorisations (sudo) pour votre agent IA. Les opérations critiques doivent nécessiter une autorisation explicite ou être tout simplement désactivées.
Les retours de la communauté indiquent que l'isolation de l'espace de travail fonctionne bien : un utilisateur exécute ClamAV pour analyser tout ce que l'agent touche, créant ainsi une deuxième couche de protection.
Authentification et contrôle d'accès
Les discussions au sein de la communauté indiquent que de nombreuses instances d'OpenClaw présentent des lacunes en matière d'authentification. Évitez d'en faire partie.
Authentification de la passerelle
Si vous exposez OpenClaw via une interface web, mettez en place une authentification préalable. Point final.
Les options comprennent :
- Proxy inverse avec authentification HTTP de base (nginx, Caddy)
- Intégration du proxy OAuth2 pour l'authentification unique (SSO)
- Authentification Tailscale pour l'accès au VPN mesh
N’exposez jamais l’interface utilisateur de contrôle d’OpenClaw via HTTP sans authentification. Les consignes de sécurité mettent explicitement en garde contre les configurations non sécurisées qui désactivent l’authentification.
Isolation de session
Si plusieurs utilisateurs interagissent avec votre instance OpenClaw, activez l'isolation de session. Sans cela, les invites d'un utilisateur peuvent accéder au contexte, aux identifiants et aux données d'un autre utilisateur.
Le modèle d'accès DM prend en charge les modes appariement, liste blanche, ouvert et désactivé. Pour les déploiements multi-utilisateurs, utilisez l'appariement ou la liste blanche. N'utilisez jamais le mode ouvert sur une instance accessible depuis Internet.
Le problème de l'injection rapide
C’est là que les choses se compliquent. Les attaques par injection de prompts intègrent des instructions malveillantes dans le contenu traité par votre agent : courriels, pages Web, fichiers, messages.
Soyons francs : la défense parfaite n’existe pas. Mais on peut la rendre plus difficile.
Validation des entrées
Les tests de sécurité ont démontré que la validation des entrées permet de détecter les tentatives d'injection les plus simples. Ce n'est pas une solution infaillible, mais cela représente un progrès significatif.
Configurez des filtres de contenu qui suppriment ou ignorent les motifs suspects avant qu'ils n'atteignent le modèle de langage. La limitation du débit réduit également les tentatives d'injection par force brute.
Minimisation des privilèges
Moins votre agent est capable de faire de choses, moins une injection peut causer de dégâts. Cela nous ramène aux limitations des outils : si l’agent ne peut pas exécuter de commandes shell, les tentatives d’injection ciblant cette capacité échoueront.
Un membre de la communauté a plaidé pour un “ contrôle d'accès avant le renseignement ”. Il faudrait d'abord limiter les capacités, puis ajouter du renseignement dans ces limites.
| Vecteur d'attaque | Niveau de risque | Atténuation efficace | Difficulté de mise en œuvre |
|---|---|---|---|
| Passerelle exposée (sans authentification) | Critique | Proxy inverse + authentification | Faible |
| Injection rapide | Haut | Restrictions relatives aux outils + validation des entrées | Moyen |
| vulnérabilités d'exécution de code à distance | Critique | Mettez à jour vers la dernière version | Faible |
| compétences malveillantes | Haut | Audit de toutes les compétences, liste blanche uniquement | Moyen |
| exposition des titres de compétences | Haut | Comptes séparés, gestion secrète | Moyen |
| exfiltration de données | Haut | Restrictions réseau, journalisation d'audit | Haut |
Configuration du modèle privé
Voici une vérité dérangeante : si vous utilisez les API Groq, GPT, Claude ou Gemini avec OpenClaw, vos données ne sont pas stockées localement. Ces fournisseurs ont accès à toutes les requêtes envoyées par votre agent.
Pour une confidentialité totale, utilisez Ollama pour exécuter vos modèles locaux. C'est plus lent et moins performant, mais c'est réellement confidentiel.
Une configuration à sécurité renforcée combine :
- Ollama exécuté en local ou sur votre VPS
- Des modèles comme Llama 2, Mistral ou CodeLlama
- Aucun appel d'API externe
Les utilisateurs de la communauté ont constaté des compromis en termes de performances avec les modèles plus grands, mais pour de nombreux cas d'utilisation, un modèle local de 7 ou 13 octets gère parfaitement les tâches sans avoir besoin d'envoyer de données en externe.
Journalisation et surveillance des audits
On ne peut pas sécuriser ce qu'on ne voit pas. Activez la journalisation complète.
Par défaut, OpenClaw enregistre les journaux de session sur disque. Les sessions sont sauvegardées dans des fichiers JSON et JSONL situés dans le répertoire ~/.openclaw/agents/. /sessions/ par défaut.
Configurez votre déploiement comme suit :
- Consignez toutes les invocations d'outils avec horodatage.
- Enregistrement des tentatives d'exécution de commandes (réussies et échouées)
- Suivi des schémas d'accès aux fichiers
- Surveiller les connexions réseau
Les composants de journalisation structurée et de télémétrie des scénarios de sécurité fournissent des pistes d'audit complètes. Acheminez les journaux vers un système distinct afin qu'une compromission de l'instance OpenClaw n'affecte pas votre piste d'audit.
Niveaux de sécurité recommandés pour le déploiement d'OpenClaw en fonction de la tolérance au risque et du cas d'utilisation
Ligne de base renforcée en 60 secondes
Si vous utilisez déjà OpenClaw et que vous devez le sécuriser immédiatement, voici le strict minimum :
- Arrêtez le service OpenClaw
- Modifiez votre fichier de configuration pour désactiver system.run et les outils shell.
- Configurer un proxy inverse avec authentification (nginx + authentification de base)
- Redémarrage d'OpenClaw lié à localhost uniquement
- Accès via le proxy authentifié
Ce n'est pas parfait, mais cela comble les failles les plus évidentes. On peut ensuite ajouter des mesures de sécurité supplémentaires.
Se tenir au courant des CVE
La CISA a publié des résumés des vulnérabilités pour les semaines du 26 janvier et du 2 février 2026.
Se tenir au courant des failles de sécurité nécessite :
- S'abonner aux avis de sécurité d'OpenClaw sur GitHub
- Surveillance de la base de données de vulnérabilités CISA
- Participer aux discussions sur la sécurité communautaire
- Exécution de mises à jour régulières (test préalable en environnement de test)
Les vulnérabilités documentées représentent des problèmes de sécurité découverts. Les mises à jour sont critiques et non facultatives.
Ce qui empêche réellement les attaques
Les tests de sécurité ont démontré que les contrôles multicouches sont plus efficaces que les mécanismes isolés. La limitation du débit permet de réduire les attaques par force brute. La validation des entrées permet de détecter les injections basiques. Cependant, aucun contrôle n'est infaillible.
L'approche efficace consiste à superposer plusieurs contrôles. Un attaquant doit contourner l'isolation, les restrictions des outils, l'authentification et la validation des entrées. Chaque couche augmente la difficulté.
Un principe de sécurité stipule : “ Il est impossible d’empêcher les attaques dans un environnement totalement stochastique. ” C’est probablement vrai. Mais on peut rendre les attaques suffisamment coûteuses pour dissuader les attaquants de s’attaquer à des cibles plus faciles.
Gestion du stockage des identifiants et des secrets
OpenClaw a besoin d'identifiants pour interagir avec les services en votre nom. Ne les intégrez pas directement dans les fichiers de configuration.
Utilisez des variables d'environnement ou un système de gestion des secrets approprié. En cas de compromission de votre instance OpenClaw, vous ne souhaitez certainement pas que vos clés AWS, vos mots de passe de base de données et vos jetons d'API soient divulgués.
Créez des comptes distincts avec des privilèges minimaux pour l'utilisation d'OpenClaw. Si l'agent doit envoyer des courriels, créez un compte de messagerie dédié. Ne communiquez pas vos identifiants Gmail personnels.
Considérations relatives à Docker
L'exécution d'OpenClaw dans un conteneur Docker ajoute une barrière de sécurité au niveau du conteneur. Mais ne croyez pas que Docker vous protège à lui seul.
Configurez votre déploiement Docker avec :
- Utilisateur non root à l'intérieur du conteneur
- Système de fichiers en lecture seule lorsque cela est possible
- Fonctionnalités supprimées (–cap-drop=ALL, ne rajouter que ce qui est nécessaire)
- Isolation réseau (réseau pont personnalisé, et non en mode hôte)
Les guides de sécurité disponibles sur GitHub incluent des configurations de renforcement spécifiques à Docker. Utilisez-les.
Ressources de sécurité communautaire
L'écosystème OpenClaw comprend plusieurs projets axés sur la sécurité :
- manuel de sécurité openclaw : Configurations de sécurité prêtes pour la production
- détection de griffe ouverte : Outils de détection des menaces
- bouclier à griffe ouverte : Validation et filtrage des entrées
- protège-griffes : Surveillance et protection en temps réel
Ces initiatives témoignent des efforts déployés par la communauté pour répondre aux préoccupations en matière de sécurité. Évaluez-les en vue de votre déploiement.
Surveillance visuelle automatisée avec FlyPix AI
Bien que la sécurisation d'un agent autonome local comme OpenClaw exige des efforts techniques considérables, notre équipe est convaincue que l'automatisation à haut risque doit être à la fois puissante et intrinsèquement isolée. En matière d'analyse du monde physique par imagerie satellite et drone, nous avons développé FlyPix AI Notre solution agit comme un agent spécialisé qui automatise la détection d'objets et la surveillance des changements sans compromettre l'intégrité de votre système local. En confiant l'analyse géospatiale à notre plateforme sécurisée dans le cloud, vous pouvez détecter des milliers d'objets en quelques secondes, économisant ainsi jusqu'à 99,71 T³ de temps habituellement consacré à l'annotation manuelle, tout en préservant l'intégrité de votre infrastructure principale.
Notre plateforme constitue un garde-fou essentiel pour les professionnels de la construction, de l'agriculture et du secteur public qui ont besoin d'informations concrètes sans les risques liés aux scripts d'IA hébergés localement. Que vous suiviez l'évolution des infrastructures ou identifiiez des anomalies sur de vastes territoires, notre interface sans code vous permet d'entraîner des modèles personnalisés et de visualiser les résultats grâce à des tableaux de bord intuitifs. Au lieu de vous soucier des vulnérabilités inhérentes aux agents locaux, vous pouvez tirer parti de nos outils préconfigurés pour obtenir, en quelques clics seulement, des données aériennes précises et exploitables.
Aller de l'avant
OpenClaw représente une capacité puissante : des agents d’IA autonomes ayant accès au monde réel. Cette puissance force le respect.
La sécurité n'est pas une simple liste de contrôle à remplir une fois pour toutes. C'est une démarche continue. De nouvelles vulnérabilités apparaîtront. Les techniques d'attaque évolueront. Votre stratégie de sécurité doit s'adapter.
Commencez par les fondamentaux : isolez votre déploiement, limitez l’accès aux outils dangereux, mettez en place une authentification et activez la journalisation. Adaptez ensuite votre stratégie en fonction de votre profil de risque spécifique.
La communauté travaille activement au développement d'outils et de documentation de sécurité. N'hésitez pas à y participer. Partagez vos bonnes pratiques (et celles qui ne fonctionnent pas). Nous apprenons tous ensemble.
Et souvenez-vous : si quelque chose vous semble trop permissif, c’est probablement le cas. Faites confiance à votre intuition. La liberté de tout faire inclut la liberté de faire des dégâts. Concevez en conséquence.
FAQ
Non. OpenClaw possède un accès système et doit être exécuté sur un matériel isolé : une machine virtuelle, un serveur privé virtuel ou un serveur dédié. La communauté déconseille fortement son exécution sur votre ordinateur principal.
Mesures de défense multicouches : restreindre l’accès aux outils, valider les entrées, limiter le débit et minimiser les privilèges des agents. Aucune défense n’est infaillible, mais ces contrôles rendent les attaques beaucoup plus difficiles.
Si la confidentialité est essentielle, utilisez des modèles locaux via Ollama. Les API cloud (GPT, Claude, Gemini) reçoivent toutes vos requêtes. Les modèles locaux sont plus lents et moins performants, mais ils conservent vos données sur votre infrastructure.
Commencez par le niveau 2 : déploiement isolé, authentification via une passerelle, exécution de commandes désactivée, accès aux outils basé sur une liste blanche, règles de pare-feu et identifiants distincts. Cette approche offre un bon compromis entre sécurité et effort de mise en œuvre raisonnable.
Vérifiez les mises à jour chaque semaine. Appliquez les correctifs de sécurité immédiatement après les avoir testés dans un environnement hors production. De nouvelles vulnérabilités apparaissent régulièrement ; il est donc essentiel de rester à jour.
Seule une authentification robuste, le protocole HTTPS, la limitation du débit et une surveillance complète permettent de l'exploiter. Des rapports de la communauté indiquent que de nombreuses instances sont exposées avec une protection insuffisante. Si vous devez l'exposer, traitez-la comme un risque de sécurité critique.
Arrêtez immédiatement le service. Consultez les journaux d'audit pour détecter toute activité suspecte. Modifiez les identifiants de tous les comptes auxquels l'agent a accédé. Recréez le système dans un environnement isolé avec des contrôles de sécurité appropriés avant de le redémarrer.