Tes secrets vivent dans le trousseau du système,
pas dans un prompt ni dans ton dépôt
AgentsRoom stocke tes clés d'API, tes tokens et tes mots de passe de base de données dans un coffre local à la machine, chiffré par le trousseau de ton système d'exploitation. Tu les références par leur nom, et l'app résout la valeur au démarrage d'une commande ou d'un agent.
Arrête de coller un token dans un prompt parce que c'était le plus rapide pour débloquer un agent. Nomme le secret une fois, utilise {{secret:NAME}} partout ailleurs, et laisse la valeur là où elle doit rester.
Comment AgentsRoom garde un secret utilisable par tes commandes et illisible pour l'agent qui le demande.
Chaque projet finit avec une poignée de valeurs qui ne doivent pas circuler : une clé de paiement, un mot de passe de base de données, un token de déploiement, une clé d'API pour l'environnement de staging. Dès que les agents IA de code entrent en jeu, ces valeurs se mettent à bouger de la pire façon possible. On les colle dans un prompt pour débloquer un agent, on les écrit en dur dans un script que l'agent vient de produire, ou on les dépose dans un fichier qu'un commit ramasse trois commits plus tard.
Le gestionnaire de secrets d'AgentsRoom leur donne un seul endroit où vivre. Un secret, c'est un nom et une valeur : tu l'ajoutes une fois, et AgentsRoom le chiffre via le trousseau de ton système d'exploitation avant même qu'il touche le disque. Tout le coffre tient dans un seul fichier de ton dossier personnel, écrit avec des permissions réservées au propriétaire, et il ne quitte jamais la machine sur laquelle il a été créé.
À partir de là, tu ne manipules plus jamais la valeur. Tu écris {{secret:NAME}} dans une commande de dev ou dans l'environnement d'un agent, et AgentsRoom substitue la vraie valeur au démarrage de cette commande ou de cet agent. Tes agents peuvent lister les noms et demander qu'un secret soit injecté, ce qui leur suffit pour travailler, et ils n'obtiennent jamais la valeur elle-même.
Un coffre pensé pour une machine pleine d'agents IA
Chiffré par le système d'exploitation, référencé par son nom, résolu au dernier moment possible.
Chiffré par le trousseau de ton système
Chaque valeur est chiffrée via Electron safeStorage : la clé de chiffrement est détenue par le trousseau de ton système d'exploitation, pas par AgentsRoom. L'app stocke du chiffré et demande au système de le déchiffrer, exactement comme les autres applications auxquelles tu confies déjà des identifiants.
Un seul fichier de coffre, propriétaire uniquement
Tous tes secrets vivent dans un coffre unique, ~/.agentsroom/secrets.json, écrit avec des permissions réservées au propriétaire (0600) et remplacé de façon atomique à chaque modification. Pas de fichier à moitié écrit après un crash, et aucun autre compte utilisateur de la machine ne peut l'ouvrir.
Référence par nom, jamais par valeur
Un secret enregistré s'utilise sous la forme {{secret:NAME}} : dans la ligne de commande d'un terminal de dev, dans l'environnement donné à un agent, partout où tu aurais sinon tapé l'identifiant. Ce que tu lis à l'écran, et ce que tu pourrais montrer à un collègue, c'est le nom.
Résolu au lancement, dans le processus principal
La substitution a lieu au démarrage du processus, à l'intérieur du processus principal Electron. La valeur résolue part dans l'environnement de la commande lancée et nulle part ailleurs : pas dans un log, pas dans l'interface, pas dans un fichier sur le disque.
Les agents voient des noms, pas des valeurs
Un agent IA peut lister les noms de tes secrets et demander qu'un secret soit injecté dans ce qu'il s'apprête à lancer. Aucun chemin de code ne renvoie une valeur à un agent, à la couche interface ou via MCP. L'agent travaille avec la référence, l'app travaille avec le secret.
Pas de trousseau, pas de stockage
Si la machine ne peut pas fournir un trousseau système fonctionnel, AgentsRoom refuse d'enregistrer le secret plutôt que de retomber sur du texte en clair. Un coffre qui se dégrade en silence en simple fichier est pire que pas de coffre du tout, donc ce repli n'existe tout simplement pas.
Local à la machine par conception, pas par réglage par défaut
Tes secrets ne sont jamais envoyés aux serveurs d'AgentsRoom. Il n'y a pas d'interrupteur de synchronisation à vérifier, pas de coffre cloud à désactiver, et aucune sauvegarde de tes clés ailleurs que sur ton propre disque. Le coffre est créé sur la machine, chiffré avec une clé que le trousseau du système garde pour cette machine, et il y reste. Une copie du fichier, prise seule, n'est pas quelque chose qu'une autre machine peut ouvrir.
La séparation entre utiliser un secret et lire un secret est appliquée dans le code, pas par une consigne écrite dans un prompt. La couche interface, les outils MCP et tous les agents parlent des secrets par leur nom. Seul le processus principal Electron transforme une référence en valeur, et uniquement pendant qu'il construit l'environnement d'un processus que tu lui as demandé de démarrer. Dire à un agent de faire attention aux identifiants, c'est un espoir. Ne pas avoir de fonction qui renvoie l'identifiant, c'est une garantie.
C'est ce qui rend raisonnable de laisser un agent travailler sur une API payante ou une vraie base de données. L'agent sait qu'il existe un secret nommé STRIPE_SECRET_KEY et peut demander qu'il soit injecté dans la commande qu'il veut lancer. Il ne peut pas l'afficher, pas le copier dans un fichier qu'il écrit, et pas le laisser fuiter dans une conversation stockée ailleurs.
D'un token collé à un secret nommé
Trois étapes, et la valeur ne réapparaît plus jamais.
Ajoute le secret une fois
Donne-lui un nom et colle la valeur une dernière fois. AgentsRoom la chiffre via le trousseau du système et l'écrit dans le coffre ~/.agentsroom/secrets.json, réservé au propriétaire et de façon atomique. Si la machine n'a pas de trousseau utilisable, l'app le dit et refuse plutôt que d'écrire du texte en clair.
Référence-le avec {{secret:NAME}}
Utilise la référence là où allait la valeur : la commande qui démarre ton serveur de dev, ou l'environnement d'un agent qui a besoin d'un token d'API. Ce qui est stocké dans tes réglages, c'est la référence, et on peut la regarder sans risque.
Laisse AgentsRoom la résoudre au lancement
Au démarrage de la commande ou de l'agent, le processus principal échange la référence contre la vraie valeur dans l'environnement de ce processus. Ton outillage reçoit ce qu'il lui faut, et l'agent qui le pilote n'aura connu que le nom.
Quand un gestionnaire de secrets cesse d'être optionnel
Les situations où un identifiant collé se transforme en vrai incident.
Des serveurs de dev qui ont besoin de vraies clés
Ton serveur de dev ne démarre pas sans une clé de paiement et un mot de passe de base de données. Mets {{secret:NAME}} dans la commande de lancement à la place de l'identifiant, et la commande devient quelque chose que tu peux laisser à l'écran pendant un appel sans un moment de panique.
Des agents qui appellent une API payante
Un agent a besoin d'un token pour joindre une API tierce pendant qu'il travaille. Ajoute le secret à son environnement par son nom : l'agent obtient un environnement fonctionnel, et le token n'est ni dans le prompt, ni dans la conversation, ni dans ce que l'agent écrit ensuite.
Des clés qui n'atterrissent plus dans le dépôt
L'accident habituel, c'est un identifiant écrit dans un fichier de config qu'un commit ultérieur ramasse. Référencer les secrets par leur nom veut dire que le fichier suivi dans le dépôt contient un nom, donc il n'y a rien à faire fuiter quand la branche est poussée.
Une machine, plein de projets
Un coffre unique, protégé par le trousseau de ton système et lisible par ton seul compte utilisateur, sert tous les projets que tu ouvres. Chaque projet référence les noms dont il a besoin, et aucun ne garde sa propre copie éparpillée d'un identifiant.
Comment un agent peut-il utiliser un secret qu'il ne peut pas lire ?
Parce qu'utiliser un identifiant et lire un identifiant sont deux opérations différentes, et AgentsRoom n'implémente que la première pour les agents. Le coffre est exposé via MCP par exactement un outil, secrets_list, et il renvoie des noms. À partir de là, l'agent écrit {{secret:NAME}} dans la commande ou l'environnement dont il a besoin, et la substitution est exécutée par l'app, pas par l'agent.
Ce qui manque volontairement, c'est l'autre sens. Aucun outil MCP ne renvoie la valeur d'un secret, la couche interface n'en reçoit jamais, et rien ne la réaffiche dans une conversation. Transformer une référence en valeur réelle se passe à l'intérieur du processus principal Electron, au moment où un processus est lancé, et le résultat part dans l'environnement de ce processus et nulle part ailleurs.
L'effet concret, c'est qu'un agent peut lancer ta suite de tests sur une vraie base de données, appeler une API payante ou déployer en staging sans qu'un seul identifiant entre dans son contexte. Rien à caviarder après coup, puisque rien n'a jamais été exposé.
Découvrir AgentsRoom MCPFAQ
Où sont stockés mes secrets ?
Dans un fichier de coffre unique, ~/.agentsroom/secrets.json, dans ton dossier personnel. Chaque valeur est chiffrée via Electron safeStorage, donc la clé de chiffrement est détenue par le trousseau de ton système d'exploitation. Le fichier est écrit avec des permissions réservées au propriétaire (0600) et remplacé de façon atomique, donc un crash ne le laisse jamais à moitié écrit.
Mon agent IA peut-il lire mes secrets ?
Non. Un agent peut lister les noms de tes secrets et demander qu'un secret soit injecté dans une commande ou un environnement, ce qui lui suffit pour faire le travail. Aucun chemin de code ne renvoie une valeur à un agent, à la couche interface ou via MCP. La résolution a lieu dans le processus principal Electron uniquement.
Mes secrets sont-ils synchronisés vers les serveurs d'AgentsRoom ?
Jamais. Le coffre est local à la machine par conception. Les secrets ne sont pas envoyés aux serveurs d'AgentsRoom, pas sauvegardés dans un cloud et pas relayés vers l'application mobile. Ils sont créés sur ta machine, chiffrés pour ta machine, et ils y restent.
Comment j'utilise un secret dans une commande ?
Écris {{secret:NAME}} là où la valeur serait allée : dans la commande d'un terminal de dev, ou dans l'environnement d'un agent. AgentsRoom substitue la vraie valeur au lancement de ce processus, et c'est la référence qui reste dans tes réglages.
Que se passe-t-il si ma machine n'a pas de trousseau système ?
AgentsRoom refuse de stocker le secret. Il n'existe volontairement aucun repli qui écrirait la valeur en clair sur le disque, parce qu'un coffre qui se dégrade en silence en simple fichier te donne la confiance du chiffrement sans le chiffrement.
Est-ce que ça remplace les fichiers d'environnement de mon projet ?
Ça règle la partie du problème qui fait mal dès que des agents IA sont impliqués : garder l'identifiant hors des fichiers, des prompts et des conversations. Ton projet garde ce dont il a besoin à l'exécution, et la valeur elle-même vit dans le coffre et est injectée au lancement au lieu de dormir dans un fichier qu'un agent peut lire et qu'un commit peut ramasser.
Si quelqu'un copie le fichier du coffre, peut-il le lire ?
Pas sur une autre machine. Les valeurs sont chiffrées avec une clé que le trousseau de ton système d'exploitation détient, donc le fichier pris seul n'est que du chiffré. En plus de ça, le coffre est écrit avec des permissions réservées au propriétaire, donc un autre compte utilisateur de la même machine ne peut pas l'ouvrir non plus.
Quel outil MCP mes agents utilisent-ils pour les secrets ?
secrets_list, et c'est le seul. Il renvoie les noms des secrets stockés sur cette machine, donc un agent peut découvrir ce qui existe puis en référencer un sous la forme {{secret:NAME}} dans une commande de dev ou dans l'environnement d'un processus qu'il démarre. Aucun outil ne renvoie de valeur, donc il n'y a rien qu'un agent puisse afficher, copier dans un fichier qu'il écrit ou laisser fuiter dans une conversation. Quand un secret dont il a besoin manque, il te demande de l'ajouter dans l'app plutôt que de te demander de le coller dans le chat.
Tu pourrais aussi aimer
Connexions bases de données
Enregistre tes connexions MySQL et MariaDB, atteins une base dans un sous-réseau privé via un tunnel SSH ou une session AWS SSM, et laisse tes agents IA la requêter via MCP. Lecture seule par défaut, une seule instruction par appel, résultats plafonnés, et le mot de passe n'arrive jamais jusqu'à l'agent.
Connexions SSH
Enregistre tes connexions SSH, ouvre un terminal SSH intégré et lance Claude Code, Codex ou Antigravity CLI directement sur ton serveur distant ou ton VPS. Authentification par clé ou mot de passe, profils de connexion par projet, sans client SSH séparé.
Terminaux de dev
Gestionnaire de terminaux et lanceur de process par projet. Démarre backend, frontend et workers en un clic, avec tes secrets injectés au lancement au lieu d'être tapés à la main.
AgentsRoom MCP
Le serveur MCP qui laisse tes agents piloter AgentsRoom lui-même : projets, terminaux, backlog et connexions, avec les garde-fous qui vont avec.
Donne à tes agents l'accès, pas tes clés
Télécharge AgentsRoom, déplace tes clés d'API et tes mots de passe dans un coffre chiffré par le trousseau de ton système, et référence-les par leur nom partout ailleurs.
App companion : suivez vos agents en déplacement
Utilisez Claude, Codex, Antigravity CLI ou un autre fournisseur IA.
Remontez bugs et demandes directement dans votre backlog public.
Aperçu d'AgentsRoom en action.