Proxy d'identifiants
Vos agents effectuent des appels API.
Ils ne devraient jamais détenir les clés.
Le proxy Clavitor se situe entre vos agents IA et les API qu'ils appellent. Les identifiants sont injectés au niveau réseau — l'agent ne voit, ne stocke ni n'enregistre jamais le secret réel. Un seul binaire. Une seule variable d'environnement. Zéro modification de code.
Le problème que vous avez déjà
Secrets dans les variables d'environnement
Vos agents lisent OPENAI_API_KEY depuis l'environnement. Cette clé est visible dans /proc, dans les vidages de crash, dans les journaux CI, dans tous les outils que l'agent invoque. Une seule ligne de journal divulguée et la clé est publique.
Secrets dans la mémoire de l'agent
Même si l'agent récupère la clé à l'exécution, il la conserve en mémoire pendant la durée du processus. Une compétence compromise, une injection de prompt, un vidage de débogage — la clé est là, prête à être prise.
Pas d'audit de ce qui a été utilisé
Lorsqu'une clé API est partagée sous forme de chaîne, il n'y a aucune trace de quel agent l'a utilisée, quand, ni pour quoi. Si la clé fuit, vous effectuez une rotation et espérez. Il n'y a aucune piste d'investigation.
Les problèmes que nous espérons que vous n'aurez pas
Clés API dans le code source
Codées en dur dans un fichier de configuration, committées dans git, clonées par chaque développeur et chaque runner CI de l'équipe. Un fork public et elle est sur le tableau de bord de scan de secrets de GitHub — ou pire, elle n'y est pas.
Identifiants dans Slack
« Pouvez-vous m'envoyer la clé Stripe ? » Collée dans un message direct, consultable à jamais, exportée dans chaque archive de conformité. Slack n'est pas un coffre-fort. Ni l'e-mail, ni Google Docs, ni une note autocollante sur un moniteur.
Fichiers .env sur chaque ordinateur portable
Douze développeurs, douze copies des identifiants de production dans des fichiers en clair qui ne font jamais l'objet d'une rotation. Un ordinateur portable volé, une fuite dans ~/.bash_history, un outil de sauvegarde trop zélé — et vous effectuez la rotation de toutes les clés de l'entreprise à 2h du matin.
Retirez les identifiants de l'agent
Le proxy se situe entre l'agent et l'API. L'agent écrit une référence — clavitor://OpenAI/key — là où le secret devrait aller. Le proxy la résout localement, injecte l'identifiant réel dans la requête HTTPS, et la transmet. Les journaux de l'agent affichent le placeholder. L'API reçoit la clé. Rien entre les deux ne la stocke.
Pas de variables d'environnement. Pas de secrets en mémoire. Pas d'identifiants sur la ligne de commande. L'agent ne connaît pas la clé, ne peut pas la divulguer, ne peut pas être trompé pour la révéler.
$ export HTTPS_PROXY=http://127.0.0.1:1983
$ curl -H "Authorization: Bearer clavitor://OpenAI/key" \
https://api.openai.com/v1/chat/completions
# The proxy resolved the placeholder. The agent never saw sk-proj-abc123.
# Neither did the logs, the crash dump, or the conversation history.Fonctionne avec tout agent qui effectue des appels HTTPS : Claude Code, Codex, OpenClaw, CrewAI, LangChain, scripts personnalisés. Définissez une variable d'environnement et les appels API de l'agent passent par le proxy. Pas de SDK, pas de plugin, pas de modifications de code.
Ce qui se passe sous le capot
Déchiffre localement, par requête
Le proxy récupère l'identifiant chiffré du coffre-fort et le déchiffre sur l'appareil. Le texte en clair existe dans la mémoire du processus pour une seule requête HTTP, puis il disparaît. Rien n'est mis en cache. Rien n'est écrit sur le disque. Chaque requête déchiffre à nouveau.
Mappe les champs aux en-têtes
Jetons Bearer, clés API, authentification Basic — le proxy mappe automatiquement les libellés des champs du coffre-fort aux bons en-têtes HTTP. Ou l'agent choisit le champ exact avec une référence clavitor://. Dans tous les cas, l'identifiant atterrit au bon endroit sans que l'agent ne le voie jamais.
Portées, limites de débit, audit
Le coffre-fort applique les limites de portée et de débit. Un agent qui accède à trop d'identifiants distincts est automatiquement bloqué. Chaque accès est enregistré. Incluez un ID d'agent dans le placeholder — clavitor://agentid@Entry/field — pour des journaux d'audit par agent et des limites de débit via un proxy partagé.
Déploiement
Un seul binaire. Sidecar de l'agent. Aucune modification de l'infrastructure réseau.
Hôte à agent unique
Téléchargez le binaire, exécutez clavitor-proxy init avec le jeton d'enregistrement, définissez HTTPS_PROXY sur l'agent. Terminé. Par défaut, le proxy se lie à 127.0.0.1:1983 (sidecar pour un agent) ; définissez CLAVITOR_PROXY_LISTEN pour vous lier ailleurs lorsqu'un proxy dessert plusieurs agents sur un réseau privé.
Hôte multi-agents
Chaque agent obtient sa propre copie du binaire avec son propre fichier de configuration sidecar. Chaque copie a sa propre portée, ses propres limites de débit, son propre journal d'audit. L'agent A ne peut pas voir les identifiants de l'agent B. Isolation par conception.
Chaque proxy d'identifiants qui s'exécute dans le cloud — le vôtre ou celui de quelqu'un d'autre — est une cible. Compromettez le proxy, obtenez les identifiants de chaque client. Ce n'est pas un risque théorique. C'est le modèle économique de chaque service de proxy d'identifiants.
Le proxy de Clavitor s'exécute sur votre infrastructure. Il déchiffre localement. L'identifiant existe dans la mémoire du processus pendant la durée d'une requête. Il n'y a pas de service cloud détenant vos clés en clair. Il n'y a pas de point d'accès API servant vos secrets. Il n'y a rien à compromettre.
Vos agents effectuent déjà des appels API.
Gardez-les dans leur propre voie.
Votre coffre-fort, vos portées, votre journal d'audit. Le proxy ajoute un point d'application au niveau réseau avec zéro modification de code de l'agent.