Installer Agent Zero sur un VPS et sécuriser son Web UI

Ce qu’est Agent Zero et où se situe le danger

Agent Zero est un framework d’agents open source conçu d’abord pour Docker. Un agent principal peut créer des agents subordonnés. Chacun s’exécute dans son propre conteneur Docker isolé et peut exécuter du code, piloter un navigateur et lancer des commandes shell. Vous contrôlez l’ensemble depuis une interface Web. Le système est capable et réellement agréable à utiliser. Il fonctionne sur une machine aussi modeste qu’un VPS à six dollars. Si vous recherchez la forme multi-agent plutôt que le framework, deux sessions Claude Code sur la même machine peuvent s’envoyer directement des messages, ce qui est beaucoup plus léger à exécuter et à sécuriser.

Le danger vient de l’interface Web. Elle sert de panneau de contrôle à un système qui exécute des commandes et écrit des fichiers. Une interface Web exposée et non authentifiée constitue donc un accès distant à ce système. Voici le piège dans lequel la plupart des guides d’installation vous conduisent directement : le docker run standard publie l’interface sur le port 50001, sur toutes les interfaces réseau. Sur un VPS public, elle est donc accessible depuis l’ensemble d’Internet dès le démarrage du conteneur. Corrigez ce point en premier, et non en dernier.

Prérequis

Vous avez besoin d’un VPS avec Docker installé, d’une clé API pour un modèle de langage ou d’un modèle local à utiliser, ainsi que de quelques gigaoctets de RAM pour commencer. Agent Zero fonctionne partout où Docker fonctionne, d’un petit VPS à un serveur équipé d’un GPU. Si Docker est nouveau pour vous, le guide des bases de Docker présente les éléments supposés par les commandes ci-dessous.

Installer avec Docker, en l’attachant à loopback

Le démarrage rapide documenté tient dans un seul docker run. La différence importante avec la version à copier-coller que vous trouverez ailleurs concerne l’adresse publiée. Ne publiez pas le port 50001 sur toutes les interfaces. Publiez-le sur loopback :

docker run -d --name agent-zero \
  -p 127.0.0.1:5080:80 \
  -v a0_usr:/a0/usr \
  agent0ai/agent-zero

-p 127.0.0.1:5080:80 attache l’interface Web à l’adresse loopback du serveur uniquement. Elle n’est donc pas accessible depuis Internet. Accédez-y depuis votre propre machine via un tunnel SSH :

ssh -L 5080:127.0.0.1:5080 you@your-vps

Ouvrez ensuite http://127.0.0.1:5080 en local et configurez votre fournisseur de modèles dans l’interface. Pour une installation permanente destinée à plusieurs utilisateurs, placez plutôt le service derrière un VPN ou un reverse proxy avec authentification. Ne publiez jamais directement l’interface sur Internet. Cette précaution s’applique à tous les autres outils du serveur dont l’interface contrôle un élément sensible. C’est également ainsi qu’il faut accéder à un scanner open source auto-hébergé, via un tunnel vers son interface plutôt qu’au moyen d’un port publié.

Là où les autres guides s’arrêtent, et pourquoi vous ne devriez pas en faire autant

Recherchez comment installer Agent Zero : vous trouverez de nombreux guides, notamment ceux d’hébergeurs, qui vous conduisent jusqu’à une interface Web fonctionnelle sur le port 50001, puis s’arrêtent là. C’est précisément à ce moment que le risque commence, et non qu’il prend fin. Deux mesures permettent de terminer correctement la configuration. Premièrement, gardez l’interface privée, comme indiqué plus haut. Deuxièmement, placez un pare-feu en refus par défaut devant le serveur. Ainsi, un conteneur mal configuré ou une erreur future ne pourra pas exposer un port que vous auriez oublié :

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

Consultez les bases du pare-feu pour avoir une vue d’ensemble. Faites également attention à l’angle mort IPv6, car un service sur :: est accessible via IPv6 même lorsque vos règles IPv4 semblent suffisamment restrictives.

L’isolation des conteneurs protège les agents, pas votre serveur

La conception d’Agent Zero est réellement efficace pour un type d’isolation : les agents secondaires s’exécutent dans des conteneurs distincts et sont donc isolés les uns des autres. Cette isolation est utile. Mais il est facile d’en déduire que « le service est dans un bac à sable, donc je ne risque rien », puis de s’arrêter là. L’isolation des conteneurs protège les agents les uns des autres. Elle ne protège pas votre serveur contre Internet et n’empêche pas une interface Web exposée de donner le contrôle à un tiers. Ces protections relèvent de votre responsabilité, sur l’hôte. Déterminez à l’avance ce qu’un agent est autorisé à faire lorsque personne ne le surveille. C’est le même choix que pour les modes d’autorisation de Claude Code : un serveur sans surveillance doit utiliser un réglage plus restrictif que l’ordinateur portable placé devant vous.

Secrets, utilisateurs et hôte

Conservez la clé API du modèle et les autres identifiants dans la configuration d’Agent Zero ou dans un fichier d’environnement que seul le compte concerné peut lire. Ne les laissez pas dans l’historique de votre shell ni dans un dépôt. La même règle s’applique aux autres éléments de la machine qui protègent des secrets. En effet, le durcissement de Vaultwarden concerne surtout son jeton d’administration et son fichier de sauvegarde, plutôt que le chiffrement que l’application gère déjà correctement. Administrez la machine avec un utilisateur non privilégié plutôt qu’avec root, conformément au principe des utilisateurs disposant du moindre privilège, et configurez SSH pour n’autoriser que l’authentification par clé, comme dans le durcissement de SSH. Suivez ensuite la checklist ci-dessous afin de ne rien oublier.

Si vous comparez plusieurs agents, il s’agit de la même posture de sécurité que celle adoptée par le guide de durcissement d’OpenClaw et le guide d’OpenHands : gardez la surface de contrôle privée, exécutez les services avec un utilisateur non privilégié, activez le firewall par défaut et considérez l’hôte comme une machine qui exécute du code qu’elle n’a pas écrit. Pour une comparaison côte à côte des cinq agents, consultez les meilleurs agents IA auto-hébergés en 2026.

Les concepts communs à ces solutions sont présentés dans créer votre propre agent IA sur un VPS, et Dify est une autre plateforme auto-hébergeable à comparer.

FAQ

Agent Zero est-il sûr à auto-héberger ?

Oui, si vous gardez son interface Web privée et si vous sécurisez l’hôte. Agent Zero exécute du code, utilise un navigateur et un shell. Vous le contrôlez depuis une interface Web publiée par défaut sur le port 50001. Le risque vient donc d’une interface exposée, pas du framework lui-même. Liez l’interface à la boucle locale et accédez-y via SSH ou un VPN. Placez un pare-feu en refus par défaut devant l’interface et exécutez Agent Zero avec un utilisateur non privilégié.

Agent Zero expose-t-il une interface Web sur Internet par défaut ?

La configuration standard docker run publie l’interface sur le port 50001 de chaque interface réseau. Sur un VPS public, elle est donc accessible depuis Internet dès que le conteneur démarre. Remplacez l’adresse publiée par 127.0.0.1 afin que l’interface écoute uniquement sur la boucle locale. Accédez-y ensuite par un tunnel SSH ou un VPN.

Agent Zero peut-il fonctionner sur un petit VPS ?

Oui. Agent Zero fonctionne partout où Docker fonctionne, y compris sur un petit VPS peu coûteux. Les tâches plus lourdes et les modèles locaux plus volumineux nécessitent toutefois davantage de mémoire. Si vous utilisez un modèle auto-hébergé plutôt qu’une API hébergée, dimensionnez le serveur en fonction du modèle, et pas seulement d’Agent Zero.

Quelle est la différence entre Agent Zero, OpenClaw et Hermes ?

Ces outils se recoupent, mais leurs objectifs diffèrent. Agent Zero est un framework conçu d’abord pour Docker. Il s’appuie sur un agent principal qui lance des agents secondaires dans des conteneurs isolés, depuis une interface Web. OpenClaw et Hermes sont des assistants personnels accessibles depuis des applications de chat. Leur posture de sécurité est la même : gardez la surface de contrôle privée et sécurisez l’hôte.