Module 07 / 19← Ordre des modules
● Hermes · Mémoire · Garde-fous

Configuration Golden / mémoire / sécurité

Ce module applique la baseline de comportement du Golden Build : mémoire persistante mais bornée, validation des écritures, délégation prudente, identité SOUL et hook de protection des commandes système sensibles. Les secrets restent dans .env et ne doivent jamais être ajoutés aux fichiers de mémoire.

Point de départ

Gateway + API validées

Point d’arrivée

Identité, mémoire et garde-fous Golden

Principe

Écriture contrôlée

Avant de commencer

Prérequis

  • Modules 00 à 06 validés.
  • Hermes fonctionne en CLI et via sa Gateway.
  • Le fichier ~/.hermes/config.yaml existe déjà.
  • Le modèle local reste configuré comme au Module 05.

Ce module protège

  • Les écritures de mémoire.
  • Les créations/modifications de skills.
  • Les commandes système sensibles.
  • La taille de la mémoire persistante.
  • La délégation de sous-agents.
Important : ne remplacez pas aveuglément config.yaml. Ce module modifie uniquement les clés Golden utiles et conserve la configuration du modèle déjà validée.

Légende des commandes

Lecture seuleModificationValidationOptionnel

Installation pas à pas

07.1 · Sauvegarder la configuration Hermes

Modification
cp ~/.hermes/config.yaml ~/.hermes/config.yaml.backup-$(date +%Y%m%d-%H%M%S)
[ -f ~/.hermes/SOUL.md ] && cp ~/.hermes/SOUL.md ~/.hermes/SOUL.md.backup-$(date +%Y%m%d-%H%M%S) || true
Pourquoi : Créer un retour arrière avant les réglages Golden.
Résultat attendu : Les sauvegardes sont présentes sans modifier la configuration active.

07.2 · Activer les deux mémoires intégrées

Modification
hermes config set memory.memory_enabled true
hermes config set memory.user_profile_enabled true
Pourquoi : Activer MEMORY.md pour les faits techniques et USER.md pour les préférences utilisateur.
Résultat attendu : Les deux paramètres sont activés.

07.3 · Appliquer les limites mémoire Golden

Modification
hermes config set memory.memory_char_limit 2200
hermes config set memory.user_char_limit 1375
hermes config set memory.nudge_interval 10
Pourquoi : Éviter qu’une mémoire trop volumineuse consomme inutilement le contexte et dérive dans le temps.
Résultat attendu : Les limites sont enregistrées.

07.4 · Exiger une approbation avant écriture mémoire

Modification
hermes config set memory.write_approval true
Pourquoi : Avec cette barrière, une mémoire proposée doit être validée avant d’être persistée.
Résultat attendu : memory.write_approval vaut true.

07.5 · Protéger les modifications de skills

Modification
hermes config set skills.write_approval true
hermes config set skills.ledger true
Pourquoi : Le Golden Build impose une validation des écritures de skills et conserve un journal de mutations.
Résultat attendu : Les deux paramètres sont activés.

07.6 · Limiter la délégation des sous-agents

Modification
hermes config set delegation.max_concurrent_children 1
hermes config set delegation.max_spawn_depth 1
hermes config set delegation.orchestrator_enabled true
Pourquoi : Conserver une orchestration simple et prévisible sur une machine locale : un enfant à la fois et pas de cascade profonde.
Résultat attendu : La délégation est limitée à un seul enfant et une profondeur de 1.

07.7 · Durcir les approbations de commandes

Modification
hermes config set approvals.mode smart
hermes config set approvals.cron_mode deny
hermes config set approvals.single_query_mode deny
hermes config set approvals.unattended_mode deny
Pourquoi : Empêcher les surfaces sans interaction humaine d’approuver silencieusement une commande dangereuse.
Résultat attendu : Les modes non interactifs sont sur deny.

07.8 · Vérifier la configuration après modifications

Validation
hermes config check
hermes config show | sed -n '1,220p'
Pourquoi : Détecter immédiatement une clé invalide ou une migration de schéma nécessaire.
Résultat attendu : La configuration est valide et les paramètres Golden sont visibles.

07.9 · Créer les fichiers mémoire si nécessaire

Modification
mkdir -p ~/.hermes/memories
touch ~/.hermes/memories/MEMORY.md ~/.hermes/memories/USER.md
chmod 600 ~/.hermes/memories/MEMORY.md ~/.hermes/memories/USER.md
Pourquoi : Hermes stocke sa mémoire persistante dans ces deux fichiers.
Résultat attendu : Les fichiers existent et sont lisibles uniquement par le compte courant.

07.10 · Créer une SOUL minimale et générique

Modification
cat > ~/.hermes/SOUL.md <<'EOF'
# SOUL

Tu es un assistant technique local.
- Réponds dans la langue de l'utilisateur.
- Vérifie l'état réel avant de proposer une modification.
- Utilise les outils lorsque cela apporte une preuve.
- Demande une confirmation avant toute action destructive ou sensible.
- N'affiche jamais les secrets, tokens, mots de passe ou clés privées.
- Préfère les actions en lecture seule pour le diagnostic.
EOF
chmod 600 ~/.hermes/SOUL.md
Pourquoi : Définir l’identité et les règles globales de Jarvis sans y placer de données personnelles.
Résultat attendu : SOUL.md contient uniquement des règles génériques et non sensibles.

07.11 · Préparer le répertoire des hooks

Modification
mkdir -p ~/.hermes/agent-hooks
chmod 700 ~/.hermes/agent-hooks
Pourquoi : Isoler les scripts de sécurité dans l’emplacement conventionnel Hermes.
Résultat attendu : Le répertoire existe avec des droits restrictifs.

07.12 · Créer le hook de protection système

Modification
cat > ~/.hermes/agent-hooks/protect-system-actions.py <<'PY'
#!/usr/bin/env python3
import json, re, sys
try:
    payload = json.load(sys.stdin)
except Exception:
    print('{}')
    raise SystemExit(0)
if payload.get('tool_name') != 'terminal':
    print('{}')
    raise SystemExit(0)
args = payload.get('args') or payload.get('tool_input') or {}
cmd = str(args.get('command',''))
patterns = [
    r'\bsystemctl\b.*\b(restart|stop|disable|mask)\b',
    r'\bhermes\s+gateway\s+(restart|stop)\b',
    r'\b(reboot|shutdown|poweroff|halt)\b',
    r'\bdocker\b.*\b(restart|stop|rm|prune)\b',
    r'\bumount\b', r'\bmount\b',
]
if any(re.search(p, cmd, re.I) for p in patterns):
    print(json.dumps({
        'action':'approve',
        'message':'Action système sensible : confirmation explicite requise.',
        'rule_key':'jarvis-sensitive-system-action'
    }))
else:
    print('{}')
PY
chmod 700 ~/.hermes/agent-hooks/protect-system-actions.py
Pourquoi : Ajouter une seconde barrière pour les opérations système qui peuvent interrompre des services ou modifier les montages.
Résultat attendu : Le script est créé et exécutable.

07.13 · Déclarer le hook dans config.yaml

Modification
nano ~/.hermes/config.yaml

# Ajouter ou fusionner ce bloc :
hooks:
  pre_tool_call:
    - matcher: '^terminal$'
      command: 'METTRE_VOTRE_CHEMIN_HOME/.hermes/agent-hooks/protect-system-actions.py'
      timeout: 5
      fail_closed: true
Pourquoi : Les shell hooks doivent être déclarés dans la configuration Hermes. Le chemin doit être absolu car le hook est exécuté sans expansion shell.
Résultat attendu : Le bloc hooks existe une seule fois et pointe vers votre chemin HOME réel.

07.14 · Valider et accepter le hook en mode interactif

Validation
hermes config check
hermes --accept-hooks chat -q "Réponds uniquement par : HOOKS OK"
hermes hooks list
hermes hooks doctor
Pourquoi : Le consentement d’un shell hook est enregistré lors de sa première utilisation. L’option --accept-hooks évite qu’un service non interactif ignore un nouveau hook.
Résultat attendu : hooks list indique le hook autorisé et hooks doctor ne signale pas d’erreur critique.

07.15 · Tester le hook sans redémarrer réellement un service

Validation
printf '%s\n' '{"tool_name":"terminal","tool_input":{"command":"systemctl --user restart service-de-test"}}' | ~/.hermes/agent-hooks/protect-system-actions.py
Pourquoi : Tester le JSON produit par le script de façon inoffensive.
Résultat attendu : La sortie JSON contient action=approve.

07.16 · Redémarrer la Gateway après configuration

Modification
hermes gateway restart
hermes gateway status
Pourquoi : Les changements de configuration et les hooks doivent être repris par le service Gateway.
Résultat attendu : La Gateway redémarre et reste active.

07.17 · Contrôler les fichiers de mémoire

Validation
ls -l ~/.hermes/memories/
wc -c ~/.hermes/memories/MEMORY.md ~/.hermes/memories/USER.md
Pourquoi : Vérifier que la mémoire démarre proprement et reste dans les limites prévues.
Résultat attendu : Les deux fichiers existent et leurs tailles sont cohérentes avec les limites Golden.

Que mettre dans SOUL, USER et MEMORY ?

SOUL.md

L’identité générale : ton, prudence, règles de fonctionnement et principes de sécurité. Ne pas y placer de secrets.

USER.md

Préférences de communication et attentes durables. Le fichier est géré par la mémoire Hermes et reste privé au profil.

MEMORY.md

Faits techniques stables réellement utiles : conventions, architecture, chemins génériques, décisions durables. Éviter les tokens et mots de passe.

Écritures approuvées

Avec write_approval=true, utilisez /memory pending, /memory approve et les commandes équivalentes des skills pour contrôler ce qui devient persistant.

Validation du Module 07

Ne passez au module suivant que lorsque tous les points applicables sont validés.

config.yaml a été sauvegardé avant modification.
MEMORY et USER sont activés.
Les limites 2200 / 1375 sont appliquées.
Les écritures mémoire nécessitent une approbation.
Les écritures de skills nécessitent une approbation.
Le ledger des skills est activé.
La délégation est limitée à un enfant et une profondeur de 1.
Les surfaces non interactives refusent les commandes dangereuses par défaut.
SOUL.md ne contient aucun secret.
Le hook de protection système est déclaré, autorisé et valide.
Le test du hook retourne action=approve.
La Gateway fonctionne après redémarrage.

STOP — Module 07 validé

Si tous les contrôles sont corrects, ce module est terminé. En cas d’écart, restez sur ce module et diagnostiquez la dernière étape en erreur avant de poursuivre.