Exécuter OpenClaw en sécurité sur un VPS

Ce qu'est OpenClaw, et pourquoi le renforcer d'abord

OpenClaw est un agent IA auto-hébergé. Vous l'exécutez sur votre propre serveur, vous le connectez à un grand modèle de langage (LLM), et il peut exécuter des commandes shell, contrôler un navigateur, lire et écrire vos fichiers, et agir sur les messages que vous lui envoyez depuis vos applications de messagerie. Cette portée est toute la raison d'être de l'outil, et c'est aussi tout le risque. Un agent qui peut exécuter n'importe quelle commande n'est jamais plus sûr que la machine sur laquelle il tourne et que les limites que vous placez autour de lui.

Deux faits donnent le ton de ce guide. Premièrement, OpenClaw est conçu pour être renforcé par vous. Son modèle de sécurité place la responsabilité des politiques d'outils strictes, du bac à sable (sandbox) et des permissions prudentes sur l'opérateur, et non sur une configuration sûre par défaut. Deuxièmement, le projet a déjà connu un incident de sécurité sérieux : en mars 2026, neuf problèmes de sécurité ont été divulgués en quatre jours, dont une faille critique d'élévation de privilèges, CVE-2026-32922, notée 9,9 sur 10. Aucun de ces faits ne signifie que vous devriez éviter OpenClaw. Ils signifient que vous ne devriez pas l'exécuter de façon paresseuse, et ce guide décrit la façon prudente.

Il y a aussi une bonne nouvelle. OpenClaw fait déjà un choix sûr pour vous : sa passerelle, le processus unique qui contrôle tout, écoute sur l'adresse de bouclage (loopback) par défaut, elle n'est donc pas joignable depuis Internet à moins que vous ne fassiez un effort pour l'exposer. La majeure partie du travail ci-dessous consiste à garder les choses ainsi et à limiter le rayon d'impact si quelque chose tourne mal.

Donnez à OpenClaw son propre utilisateur restreint

N'exécutez jamais un agent en tant que root. Si OpenClaw tourne en tant que root et que quelque chose tourne mal, qu'il s'agisse d'un bug, d'une mauvaise instruction ou d'une CVE comme celle ci-dessus, les dégâts n'ont aucune limite. Créez un utilisateur système dédié sans shell de connexion et sans sudo, et exécutez l'agent en tant que cet utilisateur :

sudo useradd --system --home /opt/openclaw --shell /usr/sbin/nologin openclaw

Tout ce qu'OpenClaw possède réside sous /opt/openclaw, appartenant à ce compte. C'est l'étape la plus importante à elle seule, et c'est le même principe abordé dans exécuter des services en tant qu'utilisateur restreint : le compte sous lequel un agent s'exécute est le plafond de ce qu'il peut casser.

Installez OpenClaw

OpenClaw est distribué sous forme de paquet npm, installez donc d'abord Node.js si le serveur ne l'a pas. Installez le paquet globalement, ce qui place le binaire openclaw dans le PATH de chaque utilisateur, puis exécutez l'étape d'intégration unique :

sudo npm install -g openclaw@latest
sudo -u openclaw openclaw onboard

Exécuter l'intégration en tant qu'utilisateur openclaw signifie que la configuration de l'agent se retrouve dans son répertoire personnel, /opt/openclaw, et non dans celui de root. Le projet propose aussi un installateur curl -fsSL https://openclaw.ai/install.sh | bash qui effectue la même installation en une ligne. Ignorez l'option --install-daemon pendant l'intégration : elle enregistrerait le propre service d'OpenClaw, et l'unité systemd renforcée que vous construisez ci-dessous est plus stricte.

Gardez la passerelle sur loopback, derrière un pare-feu

La passerelle se lie à 127.0.0.1 par défaut. Laissez-la là. Il n'y a presque jamais de raison de publier ce port sur Internet, et le faire offre à quiconque le trouve un point d'entrée distant dans un processus dont le métier est d'exécuter des commandes.

Placez un pare-feu en refus par défaut devant la machine pour que rien ne soit exposé par accident :

sudo ufw default deny incoming
sudo ufw allow 22/tcp
sudo ufw enable

Deux pièges à éviter ici. Un pare-feu qui ne couvre que l'IPv4 peut laisser le même service grand ouvert sur l'IPv6, ce qui est exactement le trou de pare-feu IPv6 qui piège tant de monde. Et si vous devez atteindre la passerelle depuis votre ordinateur portable, n'ouvrez pas le port. Atteignez-la via un VPN ou un tunnel SSH, afin que l'agent n'écoute jamais l'Internet ouvert.

Isolez ses secrets

OpenClaw a besoin d'une clé d'API pour le modèle de langage auquel vous le connectez. Cette clé peut dépenser votre argent et, à travers l'agent, agir en votre nom, alors traitez-la comme un mot de passe. Gardez-la hors du fichier d'unité et de tout dépôt. Placez-la dans un fichier que seul l'utilisateur OpenClaw peut lire :

sudo install -o openclaw -g openclaw -m 600 /dev/null /opt/openclaw/openclaw.env
sudoedit /opt/openclaw/openclaw.env      # add ANTHROPIC_API_KEY=... or your model provider's key

L'unité systemd charge ce fichier avec EnvironmentFile, la clé atteint donc le processus sans jamais figurer dans une ligne de commande, un journal ou l'historique de votre shell.

Exécutez-le comme un service systemd renforcé

Exécuter l'agent sous systemd vous donne des redémarrages automatiques, des journaux propres via journalctl et, surtout, un ensemble d'options de bac à sable au niveau du noyau qui réduisent ce que le processus peut toucher même s'il est compromis. Celles qui comptent le plus pour un agent sont NoNewPrivileges pour qu'il ne puisse jamais gagner de nouveaux pouvoirs, ProtectSystem=strict pour que le système de fichiers soit en lecture seule sauf là où vous autorisez l'écriture, PrivateTmp pour son propre répertoire temporaire isolé, et ProtectHome pour qu'il ne puisse pas lire les répertoires personnels.

Générez ici une unité complète et renforcée, puis copiez-la dans /etc/systemd/system/openclaw.service :

L'unité démarre openclaw gateway, le processus de longue durée qui contrôle l'agent ; si which openclaw affiche un chemin différent sur votre serveur, ajustez ExecStart en conséquence. L'explication complète de ces directives, ainsi que de daemon-reload et enable --now, se trouve dans exécuter un programme comme service systemd. La version courte, une fois l'unité collée :

sudo systemctl daemon-reload
sudo systemctl enable --now openclaw

Renforcez aussi la porte d'entrée

Une machine d'agent n'est jamais plus sûre que le serveur qui l'entoure. Deux couches supplémentaires terminent le travail. Passez SSH à l'authentification par clé uniquement et supprimez la connexion root, comme dans le renforcement de SSH sur un VPS, afin que le compte depuis lequel vous administrez la machine ne puisse pas être cassé par force brute. Ajoutez ensuite Fail2ban pour évincer les scanners qui martèlent chaque port public. Ni l'un ni l'autre ne touche directement OpenClaw, mais tous deux coupent les routes qu'un attaquant utiliserait pour l'atteindre.

Maintenez-le à jour, de façon délibérée

Les divulgations de mars 2026 sont l'argument le plus clair possible pour rester à jour. Un bug d'élévation de privilèges dans un agent est bien plus grave que dans une application web ordinaire, parce que l'agent exécute déjà des commandes. Surveillez les versions du projet, appliquez rapidement les mises à jour de sécurité, et traitez une mise à niveau d'OpenClaw comme une maintenance de routine plutôt que comme quelque chose à repousser.

Pour comprendre ce que vous renforcez réellement, l'architecture d'un agent de style OpenClaw passe en revue les rouages, et construire votre propre agent IA sur un VPS couvre la forme générale que prend n'importe quel agent.

FAQ

Est-il sûr d'exécuter OpenClaw sur un VPS public ?

Cela peut l'être, si vous le renforcez. OpenClaw est puissant par conception : il exécute des commandes shell et contrôle un navigateur, donc une installation négligée est réellement dangereuse, et le projet a déjà connu une CVE critique (CVE-2026-32922 en mars 2026). Son modèle de sécurité attend de vous, l'opérateur, que vous ajoutiez les limites. Exécutez-le en tant qu'utilisateur restreint, gardez sa passerelle sur loopback derrière un pare-feu en refus par défaut, isolez ses clés d'API, et exécutez-le comme un service systemd renforcé.

Dois-je exposer la passerelle OpenClaw sur Internet ?

Non. La passerelle se lie au loopback par défaut, et vous devriez l'y laisser. C'est le processus unique qui contrôle l'agent, une passerelle exposée est donc un chemin distant vers quelque chose dont le métier est d'exécuter des commandes. Si vous devez l'atteindre à distance, utilisez un VPN ou un tunnel SSH plutôt que d'ouvrir le port.

Sous quel utilisateur OpenClaw doit-il s'exécuter ?

Un utilisateur système dédié sans shell de connexion et sans sudo, jamais root. Si l'agent est compromis, son compte utilisateur est le plafond des dégâts, ce compte ne devrait donc posséder que ses propres fichiers sous un répertoire comme /opt/openclaw et rien d'autre.

Comment garder les clés d'API d'OpenClaw en sécurité ?

Stockez-les dans un fichier lisible uniquement par l'utilisateur OpenClaw (mode 600) et chargez-le dans le service avec EnvironmentFile de systemd. Gardez la clé hors du fichier d'unité, hors de l'historique de votre shell, et hors de tout dépôt git. Faites-la tourner si vous soupçonnez un jour qu'elle a fuité.