Un Coffre de Secrets Simple pour les Agents CLI

Ce que j'ai construit et où se situe la frontière de sécurité

En septembre 2026, j'avais créé un coffre de secrets rudimentaire pour mes propres agents CLI. Dans mon article Medium consacré à la création d'un gestionnaire de secrets, j'ai décrit le projet et la raison de son existence. Il ne cherche pas à remplacer des solutions matures, mais à répondre concrètement à une question inconfortable : que reçoit exactement un agent lorsqu'il accède à un jeton ?

Le principe de base est simple : un secret ne doit jamais se retrouver dans le prompt, les instructions ou le dépôt. Si l'agent voit une clé API comme du texte ordinaire, une injection de prompt ou un appel d'outil défaillant peut transformer l'automatisation locale en canal d'exfiltration. Il est plus sûr de stocker une référence opaque et de n'injecter la valeur réelle que pendant l'exécution d'une commande.

Pour une CLI locale, le magasin sécurisé du système d'exploitation constitue une base raisonnable. La documentation de Keeper Secrets Manager CLI décrit l'enregistrement de la configuration via macOS Keychain, Windows Credential Manager et Linux Secret Service. La bibliothèque Python keyring fournit une interface unifiée vers ces mécanismes ; un coffre maison n'a donc pas besoin de réinventer le stockage des clés.

En production, il est plus logique de séparer totalement la CLI des secrets persistants. Google Secret Manager et AWS Secrets Manager documentent le stockage et la récupération de clés API, mots de passe et autres valeurs sensibles, tandis qu'AWS documente aussi la rotation. Dans ce modèle, la CLI devient un intermédiaire plutôt que le coffre-fort.

Mais un coffre ne résout que le stockage. La couche suivante doit émettre des identifiants de courte durée pour une tâche ou une session, limiter l'accès de l'agent aux fichiers et au réseau, et journaliser les requêtes au niveau des outils. Sinon, nous aurons seulement mieux caché une clé trop puissante.

Pourquoi un coffre seul ne suffit pas

Le principal gain n'est pas un nouveau format de stockage, mais la séparation entre le modèle et le secret. L'agent peut conserver le droit de demander une opération sans voir la valeur qui la signe ou l'autorise.

Pour des essais locaux, même un coffre rudimentaire vaut mieux qu'un jeton dans un fichier à côté du projet. Pour des agents autonomes, cela reste insuffisant : privilèges minimaux, sandbox, révocation d'accès, rotation et journal des actions sont nécessaires. Le modèle le plus faible reste une clé universelle permanente dans les variables d'environnement de chaque processus.

Je vérifierais d'abord non pas le chiffrement du stockage, mais le trajet du secret après son extraction. Les arguments de ligne de commande, les journaux, les dumps d'erreur et le contexte du modèle sont particulièrement dangereux. Sans contrôle du dernier kilomètre, même un backend solide devient une manière coûteuse d'envoyer un secret au mauvais endroit.

Mon coffre rudimentaire est donc surtout intéressant comme point de départ d'une architecture saine. La véritable frontière de sécurité n'entoure pas un fichier de clés : elle encadre chaque opération que l'agent peut effectuer au nom de l'utilisateur.

Nous avons déjà étudié comment Secret Storage dans Obsidian influence la sécurité des plugins et de l'automatisation IA. Ces principes sont également utiles pour concevoir un coffre de secrets auquel les agents accèdent.