Pourquoi les secrets sont un risque spécifique avec les agents
Les agents IA manipulent souvent des secrets pour accéder à des services externes : clés API, tokens d'authentification, identifiants de bases de données. La particularité d'un agent est que ces secrets peuvent se retrouver dans le contexte envoyé au modèle, dans les journaux de session ou dans les résultats d'outils, parfois sans que l'utilisateur en soit conscient.
Ce risque est amplifié avec les modèles cloud : si un secret est inclus dans le contexte d'inférence, il est transmis au fournisseur du modèle. Même avec un modèle local, un secret présent dans les journaux représente un risque si ces journaux ne sont pas correctement protégés. La gestion des secrets avec un agent nécessite donc une attention particulière à tous les points où ils peuvent apparaître.
- Les secrets peuvent apparaître dans le contexte envoyé au modèle
- Les journaux de session peuvent capturer des valeurs de secrets
- Les résultats d'outils peuvent contenir des secrets en clair
- Le risque est amplifié avec les modèles cloud
Stockage des secrets
La règle fondamentale est de ne jamais stocker de secrets en clair dans les fichiers de configuration de l'agent, les instructions système ou les fichiers de prompts. Ces fichiers sont souvent versionnés ou partagés, ce qui multiplie les points d'exposition. Les secrets doivent être stockés dans un emplacement dédié et protégé, séparé de la configuration de l'agent.
Les options de stockage vont du simple fichier d'environnement (.env) non versionné à des gestionnaires de secrets dédiés comme HashiCorp Vault, AWS Secrets Manager ou des équivalents. Le choix dépend de la complexité de l'infrastructure et du nombre de secrets à gérer. Dans tous les cas, l'accès au stockage des secrets doit être restreint aux processus qui en ont besoin.
- Ne jamais stocker de secrets dans les fichiers de configuration versionnés
- Utiliser un fichier .env non versionné pour les environnements simples
- Envisager un gestionnaire de secrets dédié pour les environnements complexes
- Restreindre l'accès au stockage des secrets au minimum nécessaire
- Ajouter les fichiers de secrets au .gitignore
Injection des secrets dans Hermes Agent
La méthode recommandée pour fournir des secrets à Hermes Agent est l'injection via des variables d'environnement. Cette approche évite que les valeurs des secrets apparaissent dans les fichiers de configuration ou dans les instructions système. L'agent accède à la valeur via la variable d'environnement sans que cette valeur soit explicitement écrite dans un fichier de configuration.
Il est important de s'assurer que les variables d'environnement contenant des secrets ne sont pas incluses dans le contexte envoyé au modèle. Si l'agent a besoin d'utiliser un secret pour appeler un outil, l'outil doit récupérer la valeur directement depuis l'environnement, sans passer par le contexte de conversation.
- Injecter les secrets via des variables d'environnement
- Ne pas inclure les valeurs de secrets dans les instructions système
- Les outils doivent récupérer les secrets depuis l'environnement, pas depuis le contexte
- Vérifier que les variables d'environnement sensibles ne sont pas journalisées
Exposition dans les journaux et les prompts
Les journaux d'Hermes Agent peuvent capturer les appels d'outils et leurs paramètres. Si un outil reçoit un secret comme paramètre — par exemple une clé API passée directement dans un appel — cette valeur peut apparaître dans les journaux. Il est préférable de concevoir les outils de façon à ce qu'ils récupèrent eux-mêmes les secrets depuis l'environnement plutôt que de les recevoir en paramètre.
De même, les prompts et les instructions système ne doivent jamais contenir de valeurs de secrets, même pour des raisons de commodité. Si le modèle a besoin de savoir qu'une clé API est disponible, il suffit de lui indiquer le nom de la variable d'environnement, pas sa valeur. Cette discipline réduit considérablement le risque d'exposition accidentelle.
- Concevoir les outils pour récupérer les secrets depuis l'environnement
- Ne jamais passer de secrets comme paramètres d'outils en clair
- Exclure les variables d'environnement sensibles de la journalisation
- Ne mentionner que les noms de variables dans les prompts, jamais les valeurs
Rotation des secrets
La rotation régulière des secrets limite la fenêtre d'exposition en cas de compromission non détectée. Un secret qui n'a pas été changé depuis longtemps représente un risque plus élevé qu'un secret récemment renouvelé. La rotation doit être planifiée et documentée, pas seulement réactive.
Hermes Agent lui-même ne gère pas la rotation des secrets : c'est une responsabilité de l'infrastructure. Cependant, la configuration de l'agent doit être conçue pour faciliter la rotation : les secrets injectés via des variables d'environnement peuvent être mis à jour sans modifier la configuration de l'agent, ce qui simplifie le processus.
- Planifier la rotation régulière de chaque secret utilisé
- Documenter la fréquence de rotation pour chaque type de secret
- L'injection via variables d'environnement facilite la rotation sans modifier l'agent
- Tester la rotation en environnement de test avant de l'appliquer en production
Révocation en cas d'incident
Savoir révoquer rapidement un secret compromis est aussi important que de le protéger. Pour chaque secret utilisé par Hermes Agent, il faut connaître la procédure de révocation : où se connecter, quelle action effectuer, et comment vérifier que la révocation est effective. Cette procédure doit être documentée et testée avant d'en avoir besoin.
Après révocation, il faut identifier comment le secret a pu être exposé : journaux non protégés, inclusion dans un prompt, transmission à un modèle cloud. Cette analyse post-incident permet d'améliorer les pratiques et d'éviter la répétition. La révocation sans analyse ne résout que le symptôme immédiat.
- Documenter la procédure de révocation pour chaque secret utilisé
- Tester la procédure de révocation avant d'en avoir besoin
- Après révocation, analyser le vecteur d'exposition
- Mettre à jour les pratiques suite à l'analyse post-incident
Audit et inventaire des secrets
Maintenir un inventaire des secrets utilisés par Hermes Agent — leur nature, leur usage, leur date de création et leur date de dernière rotation — est une bonne pratique souvent négligée. Sans inventaire, il est difficile de savoir quels secrets révoquer en cas d'incident ou lesquels n'ont pas été tournés depuis trop longtemps.
L'inventaire ne doit pas contenir les valeurs des secrets, uniquement leurs métadonnées. Il peut être aussi simple qu'un fichier texte ou une entrée dans un outil de gestion de projet. L'essentiel est qu'il soit maintenu à jour et accessible aux personnes responsables de la sécurité opérationnelle.
- Maintenir un inventaire des secrets avec leurs métadonnées
- Ne jamais inclure les valeurs dans l'inventaire, seulement les métadonnées
- Inclure la date de création et la date de dernière rotation
- Réviser l'inventaire régulièrement et lors de chaque changement d'équipe
Sources et méthode
Cette page est une synthèse éditoriale indépendante. Les capacités et commandes doivent être vérifiées dans les sources officielles avant une utilisation en production.