En quelques jours, OpenClaw est devenu un phénomène viral dans les équipes techniques. Des milliers d’instances sont désormais accessibles en ligne, parfois sans protection adéquate. Dans les environnements professionnels, certains collaborateurs l’installent en une seule commande, en lui accordant un accès complet au shell, au système de fichiers et aux jetons OAuth d’outils stratégiques. Tester l’outil localement peut alors créer le risque même que l’on cherche à évaluer.
Une adoption fulgurante qui inquiète les équipes sécurité
Les chiffres donnent le vertige. Des analyses réseau ont montré qu’OpenClaw est passé d’environ 1 000 instances publiques à plus de 21 000 en moins d’une semaine. Dans les entreprises, des solutions de cybersécurité ont observé des déploiements directs sur des postes professionnels, souvent via une simple ligne d’installation.
Cette pratique expose immédiatement des ressources sensibles : accès au terminal, lecture et écriture sur le disque, connexions à Slack, Gmail ou SharePoint via OAuth. En clair, l’agent fonctionne avec les mêmes privilèges que son utilisateur.
Plus grave encore, plusieurs failles critiques ont été identifiées :
- CVE-2026-25253, une vulnérabilité d’exécution de code à distance notée 8.8 sur l’échelle CVSS, permettant le vol de jetons d’authentification via un simple lien malveillant.
- CVE-2026-25157, une faille d’injection de commandes affectant le gestionnaire SSH sous macOS.
Une analyse de 3 984 extensions publiées sur la marketplace ClawHub a révélé que 283 d’entre elles, soit environ 7,1 %, contenaient des failles critiques exposant des identifiants en clair. Un audit distinct a même montré qu’environ 17 % des extensions présentaient des comportements directement malveillants.
Le problème dépasse OpenClaw lui-même. Des chercheurs ont découvert qu’un réseau social d’agents basé sur cette infrastructure avait laissé sa base Supabase entièrement accessible, sans règle de sécurité au niveau des lignes. Résultat : 1,5 million de jetons API exposés, 35 000 adresses email et des messages privés contenant des clés OpenAI en clair.
Pourquoi tester en local crée un risque majeur
OpenClaw fonctionne avec l’ensemble des privilèges de l’utilisateur hôte. Il peut exécuter des commandes, modifier des fichiers et utiliser toutes les connexions configurées.
Le chercheur en sécurité Simon Willison parle d’un « trio létal » pour les agents IA :
- accès à des données privées,
- exposition à des contenus non fiables,
- capacité de communication externe.
OpenClaw réunit ces trois éléments par conception.
Un simple prompt injection dissimulé dans une page web résumée ou dans un email transféré peut déclencher une exfiltration de données qui ressemble à une activité normale. Les pare-feux voient une requête HTTP valide. Les outils EDR surveillent le comportement des processus, pas le sens sémantique des instructions.
Autre point critique : la passerelle OpenClaw écoute par défaut sur 0.0.0.0:18789, exposant son API complète sur toutes les interfaces réseau. Les connexions localhost sont authentifiées automatiquement. Placé derrière un proxy inversé mal configuré, le système peut considérer du trafic externe comme interne.
Les conteneurs éphémères : une isolation qui change tout
Pour évaluer OpenClaw sans exposer une machine d’entreprise, une approche consiste à isoler totalement l’agent dans un environnement temporaire.
Le framework open source Moltworker, publié par Cloudflare, repose sur une architecture en quatre couches :
- Un Cloudflare Worker gère le routage.
- L’agent s’exécute dans un conteneur sandboxé basé sur Ubuntu 24.04 avec Node.js.
- Le stockage R2 assure une persistance chiffrée facultative.
- Cloudflare Access applique une authentification Zero Trust sur chaque route d’administration.
L’élément clé est l’isolation. Si un agent est compromis par une injection malveillante, il reste confiné dans un micro-environnement temporaire. À la fin de la tâche, le conteneur disparaît. Aucun fichier sensible sur un ordinateur portable, aucun identifiant stocké dans un répertoire local.
Déployer un environnement sécurisé en quatre étapes
Mettre en place une instance d’évaluation prend quelques heures.
Première étape : configurer le stockage et la facturation.
Un plan Workers payant à environ 5 dollars par mois suffit, associé au stockage R2. Pour un test purement sécurisé, il est même possible de désactiver toute persistance : chaque redémarrage efface les données.
Deuxième étape : générer les jetons et déployer.
Il faut définir trois secrets : une clé API Anthropic, un jeton de passerelle généré aléatoirement et, si besoin, une configuration AI Gateway. Une commande de déploiement initialise ensuite le conteneur, avec un démarrage à froid d’une à deux minutes.
Troisième étape : activer l’authentification Zero Trust.
C’est ici que l’approche diffère radicalement des tutoriels classiques. L’interface d’administration est protégée via Cloudflare Access et reliée à votre fournisseur d’identité. Les panneaux ouverts et les jetons visibles dans l’URL disparaissent.
Quatrième étape : connecter un canal de test.
Un compte Telegram dédié suffit pour commencer. L’agent devient accessible via ce canal, dans un environnement isolé et authentifié.
Le coût total d’une instance active en permanence se situe entre 7 et 10 dollars par mois. À comparer avec un Mac Mini connecté au réseau interne, contenant des identifiants en clair.
Mettre en place un stress test de 30 jours
Durant le premier mois, aucune donnée réelle ne doit être utilisée.
Créez un bot Telegram dédié. Configurez un calendrier fictif. Si l’email est nécessaire, ouvrez un compte vierge sans contacts ni règles de transfert. L’objectif est d’observer le comportement de l’agent sur la planification, les résumés ou la recherche web, sans exposer d’informations sensibles.
Surveillez particulièrement la gestion des identifiants. OpenClaw stocke par défaut certaines configurations en Markdown et en JSON en clair. Ces formats sont précisément ciblés par des infostealers comme RedLine, Lumma ou Vidar. Dans un conteneur isolé, le risque reste circonscrit. Sur un poste d’entreprise, ces fichiers deviennent des cibles immédiates.
Plusieurs tests offensifs peuvent être menés :
- Envoyer des liens contenant des injections de prompt dissimulées.
- Vérifier si l’agent ajoute des instructions malveillantes dans ses propres fichiers internes.
- Limiter les permissions d’outils et observer s’il tente d’élargir son périmètre.
- Contrôler les connexions sortantes vers des domaines non autorisés.
- Installer des extensions ClawHub et analyser leur comportement avant et après activation.
L’environnement sandbox permet d’effectuer ces essais sans impact sur la production.
Enfin, validez la frontière de sécurité. Tentez d’accéder à des ressources externes au conteneur. Confirmez que l’arrêt du conteneur coupe toutes les connexions actives. Vérifiez que la persistance R2 ne conserve aucune donnée qui aurait dû rester temporaire.
Construire une méthode durable pour l’IA agentique
L’enjeu dépasse OpenClaw. Le véritable avantage consiste à bâtir un cadre d’évaluation reproductible : exécution isolée, intégrations progressives et validation structurée avant toute ouverture vers des systèmes réels.
Mettre en place cette discipline dès maintenant permet d’anticiper la prochaine vague d’agents viraux. La manière dont une organisation teste ces outils aujourd’hui déterminera si elle en tire un gain de productivité… ou si elle signe sa prochaine fuite de données.
