Vous vous apprêtez à ajouter une commande de nettoyage à un script que l’agent exécutera sans surveillance, et il y a une question à laquelle vous ne pouvez pas répondre en regardant le code : Hermes va-t-il la laisser passer ? Deviner, c’est soit une invite d’approbation en plein milieu de l’exécution à laquelle personne ne répond, soit une commande qui s’est exécutée en silence alors que vous attendiez qu’elle soit bloquée. v0.21.0 livre l’outil évident pour cela : hermes approvals test passe n’importe quelle commande en dry-run contre les vrais garde-fous d’approbation — la blocklist hardline, vos règles approvals.deny, la détection de motifs dangereux, l’allowlist, et même le bypass yolo/off — et imprime le verdict sans rien exécuter, sans demander à personne et sans rien persister.

Le verdict en trois codes de sortie

hermes approvals test -- rm -rf /tmp/x

Le -- compte : il arrête l’analyse des flags pour que les propres flags de la commande (comme -rf) ne soient pas avalés par hermes approvals lui-même. La sortie vous indique le verdict, quelle règle a correspondu, et la trace de commande normalisée — la même normalisation qu’applique la vraie porte. Les scripts obtiennent la réponse via un code de sortie :

• 0 — allow
• 2 — ask-approval (demanderait une approbation)
• 3 — deny (blocklist hardline ou votre propre règle deny)

Vous pouvez donc la brancher dans un contrôle de pré-vol : un script de déploiement qui refuse de continuer si une étape serait bloquée, une tâche cron qui échoue bruyamment avant d’exécuter une commande que la porte aurait de toute façon stoppée, ou une passe d’audit qui grep vos scripts à la recherche de tout ce qui demanderait une approbation dans un contexte sans surveillance.

Ce qu’il évalue réellement

Le dry-run exécute la même chaîne de décision qu’une vraie commande, notamment :

• la blocklist hardline (commandes refusées inconditionnellement),
• vos globs fnmatch approvals.deny (voir notre guide de configuration des smart approvals pour le schéma),
• la détection de motifs dangereux (suppressions récursives, sudo, écritures disque, modifications d’identifiants, …),
• l’allowlist de commandes (les commandes que vous avez déjà bénies),
• et le bypass yolo/off si vous lancez avec ces modes (explication des sept modes yolo).

Deux flags affinent le contrôle : --env-type lui indique quel backend de terminal évaluer (par défaut local ; les backends en conteneur isolé comme docker sautent les garde-fous, donc une commande qui passe en conteneur peut demander une approbation en local — bon à savoir avant d’écrire le script), et --json donne une sortie lisible par machine.

La commande bonus : hermes approvals suggest

hermes approvals test répond à « que se passerait-il ? » ; son frère hermes approvals suggest répond à « que devrais-je autoriser ? ». Il mine vos décisions d’approbation passées dans la base de sessions, classe les motifs récurrents et propose des entrées command_allowlist — rien n’est écrit tant que vous ne les appliquez pas :

hermes approvals suggest                  # passez en revue les propositions numérotées
hermes approvals suggest --apply 1,3,7    # fusionne celles choisies dans config.yaml

Options : --days (jusqu’où remonter dans l’analyse, 90 par défaut), --min-count (nombre minimal d’approbations pour un motif, 2 par défaut), --limit, --db (base de sessions alternative), --json. Les classes destructrices (suppression récursive, sudo, écritures disque, modifications d’identifiants, …) ne sont jamais proposées — l’outil ne suggérera pas d’autoriser ce qu’il existe précisément pour verrouiller. Cela s’associe élégamment aux approbations sans surveillance pour les contextes cron.

Quand vous y aurez recours

Trois moments se détachent. Avant d’écrire de l’automatisation : vérifiez chaque étape risquée une fois, et soit bénissez-la délibérément, soit gérez le chemin d’approbation. L’audit : hermes approvals test -- <cmd> sur une commande suspecte vous dit exactement quelle règle l’attrape — sans essai réel. Apprendre le système : la trace normalisée vous montre comment Hermes voit réellement votre commande, ce qui est le moyen le plus rapide de comprendre pourquoi un one-liner shell que vous croyiez innocent déclenche la porte. v0.21.0 a aussi durci toute la surface d’approbation (les commandes Windows destructrices la déclenchent désormais, les fichiers d’instructions protégés exigent toujours une approbation) — les notes de release couvrent l’ensemble sur /releases/v0-21-0/.