Guide d'installation

Sécurisez vos secrets et clés API

Les clés API sont les clés de votre royaume IA. Une clé divulguée peut être utilisée par n'importe qui pour accumuler des frais ou accéder à vos données. Ce guide couvre les meilleures pratiques de gestion des identifiants pour Hermes Agent.

Prérequis

  • Hermes Agent installé (voir le guide macOS)
  • Au moins une clé API d'un fournisseur de modèle (voir le guide des fournisseurs de modèles)
  • Accès au terminal de la machine exécutant Hermes
  • Environ 10 minutes pour la configuration sécuritaire initiale
La sécurité n'est pas facultative. Les clés API donnent accès à des services payants. Une clé compromise peut entraîner une utilisation non autorisée, des factures imprévues et une exposition potentielle des données. Les étapes ci-dessous prennent quelques minutes — les conséquences de les ignorer peuvent durer beaucoup plus longtemps.

Étape 1 : Stocker les clés dans ~/.hermes/.env avec des permissions strictes

Hermes Agent lit les identifiants à partir de ~/.hermes/.env. Ce fichier ne devrait jamais être lisible par tous. Créez-le avec des permissions restreintes :

# Créer le fichier .env s'il n'existe pas
touch ~/.hermes/.env

# Restreindre les permissions — lecture/écriture du propriétaire seulement (chmod 600)
chmod 600 ~/.hermes/.env

# Vérifier les permissions
ls -la ~/.hermes/.env
# Devrait afficher : -rw-------  1 vous  staff  ...  .env

Ajoutez vos clés API à ce fichier, une par ligne :

# ~/.hermes/.env
# Fournisseurs de modèles
OPENROUTER_API_KEY=sk-or-...xxxx
ANTHROPIC_API_KEY=sk-ant...xxxx
OPENAI_API_KEY=sk-pro...xxxx

# Passerelles (si utilisées)
TELEGRAM_BOT_TOKEN=1234567890:xxxxxxxxxxxxxxxxxxxxxxxxxxxx

Ne collez jamais les clés API directement dans config.yaml ou tout autre fichier qui pourrait être validé dans le contrôle de version. Référencez-les toujours via des variables d'environnement.

Étape 2 : Référencer les clés via des variables d'environnement — ne jamais coder en dur

Dans votre ~/.hermes/config.yaml, utilisez la substitution de variables d'environnement au lieu de valeurs codées en dur :

# ✅ FAITES CECI — référencer les variables d'environnement
provider: openrouter
model: anthropic/claude-sonnet-4

gateway:
  telegram:
    enabled: true
    token: ${TELEGRAM_BOT_TOKEN}
# ❌ NE FAITES PAS CECI — secrets codés en dur dans les fichiers de configuration
provider: openrouter
model: anthropic/claude-sonnet-4
api_key: sk-or-...f456  # NE JAMAIS coder en dur les clés!

La syntaxe ${VARIABLE_NAME} indique à Hermes de lire la valeur à partir de l'environnement (qu'il charge depuis .env). Cela garde les secrets hors de votre fichier de configuration — ce qui est particulièrement important si vous partagez ou sauvegardez un jour votre configuration.

Pourquoi c'est important. Une clé API codée en dur dans un fichier de configuration qui est validée dans un dépôt public, collée dans une conversation ou incluse dans une capture d'écran est un incident de sécurité. Les références de variables d'environnement gardent le secret réel à un seul endroit — votre fichier .env.

Étape 3 : Établir un calendrier de renouvellement des clés

Les clés API doivent être renouvelées régulièrement — traitez-les comme des mots de passe. Un calendrier de renouvellement trimestriel est une bonne base :

  • Tous les 90 jours : Générez une nouvelle clé API depuis le tableau de bord de votre fournisseur
  • Mettez à jour ~/.hermes/.env avec la nouvelle clé
  • Révoquez l'ancienne clé depuis le tableau de bord du fournisseur immédiatement après avoir confirmé que la nouvelle clé fonctionne
  • Testez : Exécutez hermes et envoyez une requête de test pour confirmer que la nouvelle clé est active

Définissez un rappel de calendrier récurrent. De nombreux fournisseurs vous permettent de créer plusieurs clés — vous pouvez générer la nouvelle clé à l'avance, la tester, puis révoquer l'ancienne sans interruption de service.

Renouvelez immédiatement (n'attendez pas le calendrier) si :

  • Un membre de l'équipe qui avait accès quitte l'organisation
  • Vous soupçonnez qu'une clé a pu être exposée (collée dans une conversation, incluse dans une capture d'écran, validée dans un dépôt)
  • Votre machine est perdue, volée ou compromise
  • Un fournisseur vous informe d'un incident de sécurité

Étape 4 : Utiliser 1Password CLI pour les environnements d'équipe

Si vous gérez Hermes sur plusieurs machines ou en équipe, stocker les secrets dans un simple fichier .env n'est pas idéal. 1Password CLI offre une approche plus robuste :

# Installer 1Password CLI
brew install --cask 1password-cli

# Se connecter (nécessite un compte 1Password)
op signin

# Récupérer un secret et l'injecter dans l'environnement
export OPENROUTER_API_KEY=$(op read "op://Privé/OpenRouter/Clé API")

Pour une configuration plus fluide, créez un script d'encapsulation qui récupère les clés au démarrage :

#!/bin/bash
# ~/.hermes/load-secrets.sh
# Sourcez ce script avant d'exécuter Hermes pour peupler les clés API depuis 1Password

export OPENROUTER_API_KEY=$(op read "op://Privé/OpenRouter/Clé API" 2>/dev/null)
export ANTHROPIC_API_KEY=$(op read "op://Privé/Anthropic/Clé API" 2>/dev/null)
export OPENAI_API_KEY=$(op read "op://Privé/OpenAI/Clé API" 2>/dev/null)

# Ensuite exécutez : source ~/.hermes/load-secrets.sh && hermes

Avantages de 1Password CLI par rapport à un simple fichier .env :

  • Chiffré au repos : Les secrets sont stockés dans le coffre chiffré de 1Password, pas dans un fichier texte en clair sur le disque
  • Piste d'audit : Suivez qui a accédé à quel identifiant et quand
  • Coffres partagés : Partagez les clés API en toute sécurité avec les membres de l'équipe sans les coller dans Slack ou par courriel
  • Révocation : Retirez l'accès au coffre d'un membre de l'équipe et il perd instantanément l'accès à toutes les clés

Étape 5 : Comprendre les formats de clés spécifiques aux fournisseurs

Chaque fournisseur utilise un format de clé API distinct. Connaître les modèles vous aide à identifier quelle clé va où et à repérer une exposition potentielle :

FournisseurPréfixe de la cléExemple de motif
OpenRoutersk-or-v1-sk-or-v1- + chaîne alphanumérique
Anthropic****** + chaîne alphanumérique
OpenAIsk-proj- ou sk-sk-proj- + chaîne alphanumérique
TelegramID numérique + deux-points1234567890:AA + chaîne alphanumérique

C'est utile pour la détection de fuites basée sur grep — vous pouvez analyser votre code à la recherche de ces motifs pour détecter les clés accidentellement validées.

Liste de vérification de sécurité

Utilisez cette liste pour auditer la sécurité de vos identifiants Hermes. Chaque élément devrait être un « oui » :

  • Ne jamais valider .env : Assurez-vous que ~/.hermes/.env est dans votre .gitignore global (ou mieux, Hermes vit en dehors de tout dépôt git). Si vous versionnez votre configuration Hermes, ajoutez .env à .gitignore immédiatement.
  • Utilisez des clés API restreintes : La plupart des fournisseurs vous permettent de créer des clés avec des limites d'utilisation, des restrictions IP ou un cadrage par projet. Créez une clé Hermes dédiée avec uniquement les permissions dont Hermes a besoin — pas la clé principale de votre compte.
  • Définissez des limites de dépenses : OpenRouter et OpenAI vous permettent de définir des plafonds de dépenses mensuelles par clé API. Définissez une limite raisonnable qui correspond à votre utilisation prévue — c'est votre dernière ligne de défense contre les coûts incontrôlés.
  • Surveillez l'utilisation : Vérifiez le tableau de bord d'utilisation de votre fournisseur au moins une fois par semaine. Des pics inattendus peuvent indiquer une fuite de clé ou une automatisation mal configurée.
  • Renouvelez trimestriellement : Tous les 90 jours, générez de nouvelles clés et révoquez les anciennes. Définissez un rappel de calendrier.
  • Auditez les permissions de .env : Exécutez ls -la ~/.hermes/.env — il doit afficher -rw------- (600). Si c'est autre chose, corrigez avec chmod 600 ~/.hermes/.env.
  • Ne partagez pas les clés en texte clair : Ne collez jamais les clés API dans Slack, par courriel, dans les applications de messagerie ou les messages de validation. Utilisez les coffres partagés 1Password ou un gestionnaire de secrets pour la distribution en équipe.
  • Révoquez les clés inutilisées : Si vous avez expérimenté avec un fournisseur et ne l'utilisez plus, révoquez la clé. Les clés inutilisées sont des clés oubliées — et les clés oubliées sont un passif.
  • Séparez les clés de développement et de production : Si vous exécutez Hermes sur plusieurs machines (portable + serveur), utilisez des clés API différentes. Une clé de portable compromise ne devrait pas affecter vos automatisations de production.
  • Vérifiez les fuites : Exécutez périodiquement grep -r "sk-" ~/.hermes/ --include="*.yaml" --include="*.json" --include="*.md" pour détecter les clés codées en dur qui ne devraient pas être là.

Que faire si une clé est compromise

  1. Révoquez immédiatement : Connectez-vous au tableau de bord du fournisseur et révoquez la clé compromise. C'est l'étape la plus importante — faites-la en premier.
  2. Vérifiez l'historique d'utilisation : Examinez les appels API récents pour évaluer ce à quoi l'attaquant a pu accéder ou ce qu'il a pu dépenser.
  3. Générez une nouvelle clé : Créez une clé de remplacement et mettez à jour votre fichier .env.
  4. Identifiez la fuite : Déterminez comment la clé a été exposée — validation git, collage dans une conversation, capture d'écran, machine volée — et corrigez la cause racine.
  5. Avisez si nécessaire : Si la clé accédait à des renseignements personnels, déterminez si des obligations de notification de violation s'appliquent en vertu de la LPRPDE ou de votre législation provinciale sur la protection des renseignements personnels.

Prochaines étapes

La sécurité est une pratique, pas une case à cocher. Les étapes ci-dessus établissent une base. Révisez régulièrement votre hygiène d'identifiants — surtout à mesure que vous ajoutez plus de fournisseurs, de membres d'équipe et d'automatisations.