Coffre de secrets pour agents

Donnez des credentials à vos agents. Sans jamais les exposer.

Vos agents IA ont besoin de clés d'API, de tokens et de mots de passe pour agir. Les coller dans le prompt, le contexte du modèle ou un fichier .env les expose — au LLM, aux logs, à l'historique. Tramya inverse le flux : l'agent demande l'usage d'un secret, vous approuvez en local, l'agent reçoit le résultat — jamais la valeur.

Démarrer Voir le modèle de sécurité

Le problème

Un secret dans un prompt est un secret compromis.

Tout ce qui entre dans le contexte d'un modèle peut être répété, mis en cache côté fournisseur, ou fuité par une injection de prompt.

Quand un agent doit déployer, appeler une API payante ou pousser du code, il lui faut un credential. Les approches courantes le rendent visible bien au-delà de l'usage :

  • Dans le prompt : la valeur part chez le fournisseur du modèle, reste dans l'historique de conversation et peut ressortir dans une réponse.
  • Dans le contexte / la mémoire de l'agent : elle est ré-injectée à chaque tour, multipliant les points de fuite.
  • Dans un fichier .env ou de config : elle traîne en clair sur le disque, finit dans un commit ou une capture d'écran.

Le risque n'est pas théorique : une seule injection de prompt bien placée peut convaincre un agent de recracher tout ce qu'il a en contexte.

Le flux

L'agent demande, vous approuvez, il reçoit le résultat.

Trois outils MCP, une règle simple : la valeur en clair reste entre le coffre local et l'action.

1 — L'agent demande l'usage

L'agent appelle request_secret_use avec l'identifiant du secret et l'action voulue (ex. « utiliser STRIPE_KEY pour créer un remboursement »). Il ne demande pas la valeur : il demande une exécution.

2 — Vous approuvez en local

Une fenêtre locale affiche qui demande quoi, pour quelle action. Vous approuvez ou refusez. Rien ne part sur le réseau pour cette décision — le moteur local (port 4317) orchestre tout.

3 — Le secret est injecté à l'exécution

Sur approbation, la valeur est déchiffrée en mémoire et injectée uniquement dans la commande ou l'appel réel. Elle n'est jamais rendue à l'agent sous forme de texte.

4 — L'agent récupère le résultat

Via get_secret_use_result, l'agent obtient la sortie de l'action (statut, réponse de l'API, jeton éphémère selon la politique) — de quoi continuer sa tâche sans jamais avoir vu le credential.

Et pour enregistrer un secret ? Symétrique : l'agent appelle request_secret_store pour déclarer un besoin (nom, usage), mais c'est vous qui saisissez la valeur dans la fenêtre locale et qui validez. L'agent obtient une référence, jamais la valeur.

Local-first

Pas un broker cloud. Un coffre sur votre machine.

La différence de fond avec les brokers de credentials d'entreprise.

La clé reste locale

La clé de chiffrement du coffre est dérivée et gardée sur votre appareil. Aucun serveur tiers ne peut déchiffrer vos secrets, parce qu'aucun serveur tiers ne détient la clé.

Sans compte Business

Un broker cloud exige un plan entreprise, un annuaire d'équipe et une confiance dans son infrastructure. Ici, un poste de dev seul suffit : le flux d'approbation tourne en local.

Audit sans exposition

Chaque demande d'usage est explicite, horodatée et journalisée localement. Vous savez qui a demandé quoi, quand — sans que la valeur du secret apparaisse nulle part.

Questions fréquentes

L'agent voit-il la valeur du secret ?

Non. L'agent appelle request_secret_use avec un identifiant de secret et une action. La valeur est injectée localement au moment de l'exécution approuvée ; l'agent ne reçoit qu'un résultat (statut, sortie de la commande, ou jeton à durée de vie courte selon la politique). La valeur en clair n'entre jamais dans le prompt, le contexte du LLM ni les logs de la conversation.

Faut-il un compte Business ou un cloud pour utiliser le coffre ?

Non. Le coffre Tramya est 100% local-first : la clé de chiffrement et les secrets restent sur votre machine. Contrairement à un broker de credentials cloud, aucun compte Business ni serveur tiers n'est requis pour approuver un accès. Le moteur local sur le port 4317 orchestre la demande, l'approbation et l'injection sans sortie réseau.

Comment un secret arrive-t-il dans le coffre sans que l'agent le lise ?

Via request_secret_store : l'agent déclare qu'il a besoin d'un secret (nom, usage), mais c'est vous qui saisissez la valeur dans une fenêtre locale et qui approuvez. Le secret est chiffré au repos avec AES-256-GCM. L'agent obtient une référence, jamais la valeur.

Que se passe-t-il si je refuse une demande d'accès ?

L'action est bloquée et l'agent reçoit un statut de refus. Chaque demande request_secret_use est explicite, horodatée et journalisée localement, ce qui vous donne une piste d'audit des accès sans jamais exposer les valeurs.

Vos agents peuvent agir sans que vous exposiez vos clés.

Démarrer Modèle de sécurité Mémoire IA locale Connecter un agent