La croissance d’OpenClaw en 2026 attire les attaquants de supply chain : extensions, serveurs MCP, modèles et commandes copiées. La bonne réponse n’est pas la panique, mais la réduction du rayon d’explosion.
Cette checklist s’adresse aux utilisateurs OpenClaw qui veulent des mesures concrètes. Office Claws n’est pas un runtime OpenClaw natif ; c’est un gestionnaire desktop orienté Codex pour exécuter des agents de code sur des VPS isolés. Cette nuance est importante.
Le schéma d’attaque
Un cheval de Troie typique n’a pas besoin de zero-day. Il entre par une extension ou un script de confiance, s’exécute avec accès fichier et réseau, lit .env, historique shell ou tokens, puis utilise les outils de l’agent pour persister, exfiltrer ou consommer des crédits.
L’atténuation OpenClaw est donc surtout une affaire d’architecture.
Checklist
| Contrôle | Minimum | Mieux |
|---|---|---|
| Isolation | Un projet par workspace | Un VPS jetable par run risqué |
| Secrets | Pas de clés longues dans .env | Keychain ou tokens courts |
| Extensions | Versions épinglées | Diff relu et permissions limitées |
| Réseau | Journaliser l’egress | Allowlist par tâche |
| Dépenses | Plafonds provider | Budget quotidien par agent |
| Reprise | Branche propre | Rebuild depuis snapshot |
1. Placez l’agent sur un hôte supprimable
Un malware est moins grave sur un hôte sans cookies, clés SSH personnelles ni dépôts sans rapport. Pour du code sérieux, utilisez un conteneur ou un petit VPS. Si le runner semble suspect, détruisez-le, faites tourner les tokens et repartez d’un snapshot.
2. Gardez les clés hors du runner
Le pire défaut est une clé API puissante dans .env. Déplacez-la vers le trousseau du système ou un broker local avec tokens courts. Pour les migrations Codex, Office Claws for OpenClaw users aide à garder une frontière nette entre desktop et runner.
3. Traitez les extensions comme des dépendances de production
Épinglez les versions, évitez l’auto-update et lisez les diffs. Bloquez les extensions avec accès fichiers trop large, domaines inattendus ou scripts qui téléchargent des binaires.
4. Rendez l’egress visible
Beaucoup de chevaux de Troie finissent par appeler l’extérieur. Des logs DNS ou firewall suffisent pour commencer. Mieux : autoriser uniquement Git, registres de paquets, fournisseurs de modèles et votre control plane.
5. Les plafonds de dépenses sont obligatoires
Une clé volée sans plafond est un chèque en blanc. Configurez des limites quotidiennes et surveillez les tokens par runner. Notre OpenClaw cost comparison explique pourquoi Codex par abonnement peut être plus prévisible, mais la visibilité reste nécessaire.
6. Conservez l’audit hors de l’agent
Le processus compromis ne doit pas être la seule source de vérité. Prompts, appels d’outils, commandes et diffs doivent être persistés hors du runner.
Quand passer à Codex sur VPS
Pour explorer OpenClaw, gardez un sandbox étroit. Pour du code centré dépôt, de longs tests et plusieurs branches, Codex sur VPS isolé est souvent plus propre. Lisez la OpenClaw vs Codex comparison. Office Claws apporte provisioning, monitoring et visibilité multi-agent sans prétendre exécuter OpenClaw nativement.
Plan en 15 minutes
- Retirer les clés de
.env. - Mettre un plafond quotidien provider.
- Épingler les extensions et désactiver l’auto-update.
- Utiliser une branche neuve et un workspace étroit.
- Lancer les tâches longues sur un hôte jetable.
- Sauvegarder logs et diffs hors runner.
L’atténuation n’est pas un scanner magique. Ce sont des frontières ennuyeuses : pas de secrets durables sur le runner, pas de dépenses illimitées, pas de réseau invisible, et aucun hôte que vous craignez de supprimer.