Je construis sur le VPS Hestia un dispositif simple à formuler et difficile à tenir : laisser Hermes Agent travailler seul plusieurs heures, administrer des services et reprendre une mission après une coupure de chat, sans lui céder une puissance root permanente.
La question n’est pas de savoir si un modèle peut lancer une commande. Il le peut. La vraie question est celle de la responsabilité : quelle fin a été déléguée, quels moyens sont autorisés, quel livrable doit rester après l’exécution et quelle décision doit encore appartenir à l’humain ?
État au 23 août 2026. Le socle Hestia est installé et ses contrôles automatisés sont verts : compte non-root, courtier root borné, sockets privés et validateur TOTP one-shot. La nouvelle identité Tailscale et le premier canari TOTP restent une gate humaine. L’ancien gateway Telegram demeure actif jusqu’à cette bascule. Ce texte distingue donc ce qui est installé de ce qui est déjà activé.
« Maître du VPS » ne veut pas dire propriétaire de root
Un agent utile finit par demander de l’administration. Installer un paquet. Redémarrer un service. Relancer un conteneur. Suivre un job long. Parfois arrêter ou supprimer.
Lui remettre root une fois pour toutes serait commode. Ce serait aussi confondre l’autonomie avec l’abandon du contrôle. Une commande root libre peut installer une clé, modifier un service, créer un nouvel utilisateur ou préparer une persistance qui contournera toutes les validations suivantes.
Chez Ambactos, un agent répond d’une fin déléguée. Le mandat agentique nomme cette fin, le livrable, le périmètre, les interdits et les escalades. Hermes peut devenir le maître opérationnel du VPS dans ce cadre : il conduit le travail, mais ne réécrit pas lui-même la constitution de son pouvoir.
Le root existe toujours. Il est porté par un courtier minimal, possédé par le système, qui accepte des requêtes structurées plutôt qu’une chaîne shell arbitraire. Une action agentique demeure ainsi l’exécution d’un mandat, pas l’initiative sans limite d’un modèle.
Ce que Hermes Agent apporte déjà
Hermes Agent est le runtime open-source de Nous Research. La version vérifiée pour ce déploiement est la release v2026.8.19, annoncée comme v0.20.5, publiée le 21 août 2026 et épinglée par digest immuable.
Sa documentation Security décrit un plancher utile : approbation des commandes dangereuses, hardline blocklist toujours active, règles de refus, restrictions d’écriture, allowlists d’utilisateurs, pairing des messages privés, protection SSRF et isolation de conteneur.
Les guides Telegram et WhatsApp confirment les deux canaux visés. Telegram fonctionne ici en long polling sortant, donc sans port entrant public pour le bot. WhatsApp viendra plus tard.
Ces protections natives ne prouvent pas qu’un agent est inviolable. Une blocklist freine un agent honnête qui se trompe ; elle ne remplace ni une frontière de privilège, ni une identité réseau, ni une policy root possédée par l’humain. Le TOTP exact décrit plus bas est une extension Hestia, pas une fonction native d’Hermes.
Une mission longue, sans mot de passe toutes les cinq minutes
Imaginons une mission de six heures.
Je demande depuis Telegram : « Prépare le dossier concurrentiel du client Y. Utilise des sources publiques. Rends une note structurée et une liste d’URL. Tu peux redémarrer le service de collecte nommé s’il bloque. Tu ne publies rien et tu ne touches pas aux autres services. »
Le mandat fixe une durée, un budget d’actions, des familles autorisées et des cibles exactes. Hermes lit, collecte et écrit dans son espace. Mon téléphone peut disparaître du réseau : les jobs longs vivent dans des unités persistantes, leurs journaux restent consultables et le livrable partiel ne dépend pas de la survie de la conversation.
Trois heures plus tard, le service de collecte nommé se bloque. Son redémarrage est réversible et prévu par le mandat. Hermes le redémarre sans me demander un code. C’est précisément le but : beaucoup d’autonomie là où le périmètre est écrit, peu de friction pour les opérations réversibles déjà confiées.
Si Hermes veut ensuite redémarrer un service absent du mandat, il s’arrête. Une opération réversible hors périmètre appelle une extension du mandat, pas un TOTP automatique. Le second facteur ne doit pas devenir un moyen de contourner une mauvaise définition du scope.
Si la prochaine action consiste à supprimer durablement un répertoire, arrêter une ressource critique ou redémarrer le VPS, la nature du geste change. La mission prépare alors une demande exacte et attend une action humaine forte.
L’architecture Hestia en cinq frontières
1. Une identité Linux non-root
Hermes rejoint le VPS comme un utilisateur dédié. Ce compte n’appartient ni au groupe sudo, ni au groupe Docker. Son mot de passe est verrouillé. Il travaille dans son propre home et peut appeler un protocole local borné.
2. Une identité Tailscale distincte
Le bot n’emprunte pas mon identité personnelle. Son appareil reçoit une identité de service et une règle one-way : joindre le VPS sur SSH, ouvrir une session seulement comme l’utilisateur non-root prévu, ne pas rejoindre les autres ports ni les autres machines du réseau privé.
3. Aucun raccourci Docker ou système hôte
Le conteneur Hermes ne reçoit ni le socket Docker, ni un montage global du type/:/host. Son système de fichiers racine est en lecture seule, ses capabilities Linux sont supprimées et seuls ses espaces dédiés restent en écriture. Donner le socket Docker reviendrait presque à donner root sur l’hôte ; monter tout l’hôte offrirait à l’agent le territoire que l’on prétend borner.
4. Un courtier root structuré
Le courtier reçoit des objets : mission, famille d’action, cible, budget et expiration. Il connaît des verbes limités, par exemple afficher l’état d’un service autorisé, le redémarrer, installer un paquet présent dans une allowlist ou suivre un job de la mission. Il ne connaît pas bash -c et n’évalue pas une commande libre.
5. Un journal avant l’action
Chaque tentative, acceptée ou refusée, possède une mission, une empreinte, une cible et un résultat. Si l’audit ne peut pas être écrit, l’action échoue fermée. Un interrupteur root permet par ailleurs de suspendre toutes les actions host sans arrêter la lecture ou la rédaction non-root.
Trois niveaux d’autorisation, pas une pluie de mots de passe
Niveau 1 : travail ordinaire autonome
Lire, analyser, écrire dans le workspace, utiliser Git, appeler une API permise, lancer un test et produire le livrable ne demandent aucun mot de passe. Les jobs longs s’exécutent sous l’identité non-root avec leur propre journal.
Niveau 2 : mandat temporaire borné
La mission ajoute, pour quelques heures, des moyens administratifs réversibles sur des cibles nommées. État, démarrage, redémarrage ou reload d’une unité permise, redémarrage d’un conteneur autorisé, rafraîchissement APT, installation de paquets autorisés, suivi et annulation de jobs : Hermes peut les enchaîner sans intervention tant qu’il reste dans le budget et avant l’expiration.
Cette autonomie n’est pas un blanc-seing. Les services de contrôle, le pare-feu, Tailscale, SSH, Docker et les courtiers eux-mêmes restent hors périmètre. Hermes ne peut pas augmenter son plafond ni réécrire sa policy.
Niveau 3 : opération massive, irréversible ou destructive
Là seulement intervient le TOTP exact one-shot. Arrêter une ressource, supprimer durablement un chemin ou redémarrer le VPS exige une validation extérieure au chat. Telegram peut me prévenir. Telegram ne signe pas root.
Ce que TOTP veut dire dans ce dispositif
TOTP signifie Time-based One-Time Password : un code court calculé à partir d’un secret partagé avec une application d’authentification et d’un pas de temps. Le code change régulièrement. Mais un code TOTP, pris seul, ne sait rien de l’opération que l’on approuve.
Hestia ajoute donc un lien explicite entre le geste humain et la demande exacte :
- le courtier normalise la mission, l’action et la cible ;
- il calcule une empreinte et crée une demande à durée courte ;
- je me connecte comme root par Tailscale SSH depuis mon mobile ou mon PC ;
- le terminal affiche le résumé exact et exige une confirmation textuelle ;
- je lis le code dans mon application TOTP et le saisis au terminal masqué ;
- le courtier vérifie de nouveau la cible, consomme l’autorisation une fois et exécute uniquement cet acte.
Le code n’apparaît ni dans Telegram, ni dans les arguments d’une commande, ni dans l’historique du shell. Un rejeu, un changement de cible, un code déjà consommé, cinq erreurs successives ou une panne du journal produisent un refus.
Le premier canari est volontairement sans effet : il vérifie l’approbation, la consommation unique et le refus du rejeu sans supprimer ni arrêter quoi que ce soit. Ce canari ne transforme pas une opération réversible en opération destructive ; il teste la gate réservée au niveau 3.
Accès administratif, tailnet, Serve et Funnel
Un accès administratif est la capacité de modifier le système, d’élever des privilèges, d’arrêter une ressource ou de publier une surface. Parler au bot n’est pas, à lui seul, un accès administratif.
Le tailnet est le réseau privé chiffré de Tailscale. Les règles associent des identités humaines ou de service à des destinations et à des utilisateurs SSH. La documentation Tailscale SSH et le policy file décrivent ces deux couches : autorisation réseau, puis autorisation de session.
Tailscale Serve expose un service local au tailnet. Tailscale Funnel publie une ressource ciblée sur Internet. Ils ne sont pas interchangeables. Le déploiement Hestia ne touche pas aux configurations Serve ou Funnel déjà présentes et n’ouvre lui-même aucun port public.
Une proposition d’intégration native de Serve dans Hermes existe dans la PR #9295. Elle est fermée comme non planifiée. Serve et Funnel restent donc des briques Tailscale autour d’Hermes, pas une capacité native promise par le runtime.
Ce qui est installé, ce qui attend encore l’humain
Le staging a déjà produit et vérifié les éléments suivants :
- un compte Hermes non-root, sans sudo ni groupe Docker ;
- deux sockets privés séparant contrôle host et approbation destructive ;
- un courtier root à actions structurées, missions temporaires et budgets ;
- un validateur TOTP lié au consommateur, exact et one-shot ;
- un conteneur sans port public, sans socket Docker et sans montage global ;
- des tests de refus, de rejeu, de concurrence, de symlink et de changement de cible ;
- une procédure de bascule Telegram avec retour automatique vers l’ancien bot.
Il reste deux gestes que l’agent ne doit pas s’attribuer. D’abord, appliquer la policy Tailscale et attribuer l’identité de service depuis le compte humain. Ensuite, saisir le premier TOTP depuis une session root Tailscale conservée ouverte. La bascule du gateway Telegram ne part qu’après ces canaris positifs et négatifs.
Les risques qui demeurent
Cette architecture réduit une surface. Elle ne fabrique pas le risque zéro.
- un mauvais mandat peut autoriser une mauvaise action parfaitement conforme ;
- un paquet pourtant autorisé peut introduire une compromission de supply chain ;
- un processus déjà compromis ailleurs sur le VPS reste un autre problème ;
- une règle Tailscale trop large peut annuler l’isolation attendue ;
- un Funnel oublié reste une ressource publique ;
- l’humain peut encore confirmer trop vite une demande exacte.
Le résultat n’est donc pas « la protection la plus dure de X ». Nous n’avons ni classement exhaustif, ni audit comparatif de tous les déploiements. C’est une architecture plus stricte que les configurations publiques courantes que nous avons trouvées, surtout par l’identité dédiée, l’absence de root permanent et la liaison TOTP à un acte one-shot.
La responsabilité précède l’outil
La sécurité utile n’est pas une collection de refus. C’est une manière de rendre l’autonomie possible. Les actions ordinaires sont fluides. Les opérations réversibles prévues sont exécutées sans surveillance constante. Les gestes qui changent durablement le territoire reviennent à l’action humaine.
C’est le prolongement concret de notre manifeste et de notre constitution : les moyens peuvent être délégués, les fins restent humaines. Un agent durable ne se définit pas par son modèle, mais par son mandat, son livrable et la responsabilité dont il répond.
FAQ
Comment laisser Hermes travailler plusieurs heures sans lui donner root ?
En le laissant non-root pour le travail ordinaire, puis en ouvrant une mission temporaire qui autorise seulement des actions structurées, réversibles et ciblées. Les opérations massives, irréversibles ou destructives passent par un TOTP exact one-shot. La mission, les logs et les jobs survivent au chat.
Telegram peut-il servir de second facteur root ?
Non. Telegram transporte la demande et la notification. Le TOTP est saisi depuis une session root Tailscale SSH, dans un terminal interactif, après affichage de l’opération exacte.
Serve et Funnel, est-ce la même chose ?
Non. Serve expose au tailnet privé. Funnel publie une ressource ciblée sur Internet. Aucun des deux ne remplace le mandat ni le courtier root.
Sources officielles
- Dépôt Hermes Agent et release v2026.8.19
- Documentation Security et Messaging
- Tailscale SSH, Serve, Funnel et policy file