Infisical Agent Vault : comment un proxy d'identifiants garde les clés API hors des agents IA

La gestion classique des secrets renvoie les identifiants aux applications et services qui les utilisent. Infisical Agent Vault emprunte une autre voie. L'agent ne détient jamais le véritable identifiant.

Ce guide explique comment fonctionne ce modèle de proxy d'identifiants, où il réduit le risque et où il ne le réduit pas. Il s'articule autour d'un modèle à trois couches que nous appelons Substitut / Proxy / Périmètre :

• Substitut : l'agent ne détient qu'une valeur de remplacement, jamais la vraie clé.
• Proxy : un intermédiaire distinct détient le véritable identifiant, applique la politique et l'injecte dans les requêtes approuvées.
• Périmètre : le réseau force chaque appel sortant à passer par cet intermédiaire.

Pourquoi confier des secrets aux agents IA fait voler en éclats l'ancien modèle

La gestion classique des secrets repose sur un contrat simple. Une application que vous avez écrite et relue s'authentifie auprès d'un gestionnaire de secrets, récupère un identifiant et l'utilise.

Les agents rompent ce contrat. Le dépôt d'Agent Vault le dit sans détour : la gestion traditionnelle des secrets renvoie les identifiants aux applications et services, et ce schéma ne tient plus avec les agents IA, qui peuvent être amenés par injection de prompt à divulguer des secrets. Tony Dang, CTO d'Infisical, a avancé le même argument lors du lancement : la gestion des secrets a été conçue pour un monde où les applications récupéraient des identifiants pour les utiliser, et cette hypothèse ne vaut plus pour les agents IA.

Le problème ne tient pas à la malveillance. L'article de lancement d'Infisical reconnaît que, même avec des garde-fous suffisants, rien ne permet de garantir que l'agent ne sera pas manipulé pour divulguer ses secrets.

Les défenses au niveau du modèle ne comblent pas cette lacune. La fiche OWASP consacrée à l'injection de prompt cite Hughes et al. (2024), qui ont rapporté un taux de réussite des attaques de 89% sur GPT-4o et de 78% sur Claude 3.5 Sonnet, avec jusqu'à 10 000 prompts augmentés par requête. Cette étude mesurait la réussite de jailbreaks à l'aide de prompts augmentés de type Best-of-N, et non la fréquence à laquelle l'injection de prompt indirecte exfiltre des secrets. Nous y voyons une raison de ne pas traiter les refus du modèle comme une frontière de sécurité.

Plutôt que de confier une clé à l'agent, vous la tenez entièrement hors de son contexte. C'est la couche Substitut. Les deux autres existent pour la préserver.

Fonctionnement du proxy d'identifiants Agent Vault

Infisical décrit Agent Vault comme un proxy de transfert (forward proxy) qui intercepte le TLS et injecte des identifiants, conçu pour les charges de travail d'agents. Le flux se déroule ainsi :

1. L'agent reçoit une valeur de substitution ou un jeton de session au lieu de la vraie clé API.
2. Son trafic HTTP passe par le proxy, généralement parce que la variable d'environnement HTTPS_PROXY est définie.
3. Le proxy intercepte la connexion TLS, compare l'hôte de destination aux services configurés et insère le véritable identifiant dans la requête sortante.
4. La requête part en amont avec le véritable identifiant, et la réponse revient à l'agent.

Dans le binaire open source, le serveur lance une API de gestion HTTP sur le port 14321 et un proxy HTTP/HTTPS transparent sur le port 14322.

L'API en amont voit une requête authentifiée normale. L'agent, ainsi que tout fournisseur d'inférence qui journalise son contexte, ne voit que le substitut. C'est pourquoi ce modèle répond aussi au risque lié aux journaux des fournisseurs, abordé plus bas dans la section sur la protection.

La confiance dans le certificat est une étape de déploiement

Nous conseillons de traiter la confiance dans le certificat comme une étape de déploiement explicite : avec tout proxy qui intercepte le TLS, prévoyez que chaque environnement d'exécution d'agent fasse confiance à l'autorité de certification qui signe les certificats du proxy. Installez délibérément ce certificat d'AC dans chaque image d'agent et suivez la documentation de votre édition quant à la manière dont il est émis. Ne désactivez jamais la vérification des certificats pour faire fonctionner les connexions.

Deux règles déterminent si la garantie tient

La première concerne l'emplacement, qui sous-tend la couche Proxy. Selon le dépôt, Agent Vault est censé tourner sur une machine distincte de vos agents IA, afin que ceux-ci ne puissent pas accéder directement aux identifiants qu'il contient. Si l'agent peut lire le stockage du coffre, le modèle ne vous apporte presque rien.

La seconde concerne l'application des règles : c'est la couche Périmètre. Définir HTTPS_PROXY ne garantit pas à lui seul que le trafic passe par le proxy, souligne Infisical, car l'agent peut supprimer cette variable. Elle ne fait que guider les clients conformes. Un déploiement complet verrouille le réseau pour que tout le trafic sortant soit obligé de passer par Agent Vault.

La surface de contrôle : listes d'autorisation, mode refus, sessions et audit

Un proxy qui injecte des identifiants est aussi un endroit naturel pour appliquer une politique.

Correspondance d'hôtes et mode refus. Par défaut, le proxy open source transmet comme du simple trafic proxy les requêtes qui ne correspondent à aucun service configuré. Basculer un coffre en mode refus strict (unmatched_host_policy=deny) rejette ces requêtes avec une erreur HTTP 403.

Nous ferions du mode refus la base de chaque coffre. Avec le passage direct activé, un agent orienté vers un hôte contrôlé par un attaquant peut toujours l'atteindre, simplement sans identifiant fourni par l'intermédiaire. Le mode refus transforme le proxy en liste d'autorisation des flux sortants en plus d'en faire un injecteur d'identifiants. Si votre édition prend en charge des règles par chemin ou par méthode HTTP, vérifiez dans la documentation quelle granularité est réellement appliquée.

Sessions limitées dans le temps. Dans l'édition commerciale d'Agent Vault, chaque session d'agent expire selon un calendrier que vous définissez, et les agents en cours d'exécution perdent l'accès dans les 60 secondes suivant la fin de la session. Des sessions courtes limitent la durée pendant laquelle une exécution détournée peut continuer à utiliser l'accès fourni par l'intermédiaire.

Proxys partagés. Lorsque plusieurs agents partagent un même proxy, ils lui envoient leur jeton de session en HTTP non chiffré, un point que la documentation d'Infisical signale par un avertissement. Gardez cette configuration sur un réseau privé partagé par les agents et le proxy, comme vos propres serveurs, un cluster Kubernetes ou des runners CI auto-hébergés.

Audit. Tout le trafic intermédié passe par un point de passage unique, ce qui donne aux équipes de sécurité un seul endroit pour examiner ce que les agents appellent. Avant de vous en servir comme preuve, déterminez ce que votre édition enregistre et combien de temps elle conserve ces données, puis vérifiez que vous pouvez les exporter. Si vous tracez déjà les exécutions d'agents avec le traçage OpenTelemetry GenAI, mettez en correspondance les enregistrements du proxy avec ces traces au lieu de considérer l'une ou l'autre source comme complète.

Ce contre quoi le modèle protège, et ce qu'il ne couvre pas

D'après la documentation d'Infisical, si une injection de prompt amène l'agent à révéler un identifiant, il n'y a rien à révéler. C'est un vrai progrès par rapport à des secrets stockés dans des variables d'environnement que l'agent peut afficher.

La discussion sur Hacker News autour du lancement a proposé un autre angle. Un commentateur a fait valoir que le modèle ne résout pas le problème des agents hostiles, mais plutôt celui des fournisseurs d'inférence hostiles ou compromis, car on ne veut pas de secrets dans les journaux d'un fournisseur d'IA. Dans les deux cas, des clés qui n'entrent jamais dans les prompts, les complétions ou les sorties d'outils n'atterrissent jamais dans des journaux tiers, que quelqu'un vous attaque ou non.

Usage abusif d'un accès autorisé. Si un agent peut appeler un point de terminaison de suppression via le proxy, un agent manipulé peut toujours l'appeler, et le proxy y joint le véritable identifiant comme d'habitude. L'intermédiation garde la clé secrète. Elle ne rend pas les actions de l'agent sûres, et c'est particulièrement important pour les outils MCP déclenchés par des événements qui s'exécutent sans revue humaine.

Identifiants dans les réponses. Un critique, dans le même fil Hacker News, a souligné que si l'identifiant est un jeton OAuth2 et que le service dispose d'un point de terminaison de rafraîchissement de jeton, la réponse transporterait un nouveau jeton directement jusqu'à l'agent. Les API d'émission de jetons, de création de clés et de lecture de secrets présentent le même risque. L'intermédiation protège la requête : vous devez donc toujours examiner ce qui revient.

Gestion des jetons MCP. Les bonnes pratiques de sécurité MCP indiquent que les serveurs MCP ne doivent accepter aucun jeton qui n'a pas été explicitement émis pour le serveur MCP. Un proxy d'identifiants ne remplace pas des vérifications d'audience correctes au sein de vos serveurs MCP.

Agent Vault open source ou commercial : ce qui a changé et pourquoi c'est important

Agent Vault est développé par Infisical, qui affirme traiter des milliards de secrets par mois pour des équipes, des pipelines CI/CD et des serveurs.

La revue indépendante de Codeline au moment du lancement relevait environ 800 étoiles, un label Preview et une API explicitement susceptible d'évoluer. Elle décrivait aussi le fonctionnement interne : le mot de passe maître enveloppe une clé de chiffrement des données aléatoire via Argon2id, avec des paramètres par défaut de 3 itérations, 64 MiB de mémoire et 4 threads. Par défaut, le binaire conserve tout son état dans une base SQLite locale qui ne nécessite aucune configuration, et PostgreSQL est l'option prévue pour la production.

En quelques mois, selon un décompte ultérieur d'Infisical, Agent Vault avait dépassé les 2 000 étoiles sur GitHub, avec des dizaines de milliers d'installations et des millions d'exécutions d'agents. Ces chiffres proviennent de l'éditeur et n'ont pas été vérifiés de manière indépendante.

Une remarque sur les noms : Infisical appelle l'édition payante « commercial Agent Vault » lorsqu'il décrit les sessions, et nomme son composant d'intermédiation Agent Proxy lorsqu'il décrit la refonte. Nous employons ici les deux termes de la même manière.

Le changement le plus important est architectural. En revenant sur la première version, Infisical a expliqué avoir regroupé deux concepts distincts en un seul : le magasin de secrets et l'intermédiaire de secrets. Dans l'édition commerciale d'Agent Vault, Agent Proxy les sépare et est livré avec 30+ préréglages pour des services courants, notamment des fournisseurs de LLM comme Anthropic et OpenAI, ainsi que des services comme GitHub, Slack et Datadog. Quant au dépôt open source, l'entreprise indique qu'il reste en ligne et que vous pouvez l'exécuter, mais qu'il n'est pas activement maintenu et n'a jamais été conçu pour une équipe.

Par ailleurs, nos sources ne décrivent la gestion des hôtes non reconnus que pour le dépôt open source, et l'expiration des sessions que pour l'édition commerciale. Consultez la documentation à jour de l'autre édition plutôt que de supposer une parité.

Nous conseillons de considérer le dépôt open source comme un outil d'apprentissage et de prototypage. Pour la production, nous nous tournerions vers l'édition commerciale ou vers un fork interne que vous êtes prêt à maintenir. Évaluez la charge de maintenance comme vous le feriez pour tout composant d'agent en production (consultez notre liste de contrôle pour choisir un runtime d'agents IA durables).

Guide pratique et liste de contrôle avant lancement pour les agents MCP, CLI et SDK

Ces étapes suivent les trois couches et s'appliquent aux deux éditions.

Couche Substitut

1. Inventorier les identifiants. Pour chaque agent, listez chaque identifiant, l'hôte auprès duquel il est utilisé, ainsi que les points de terminaison et méthodes HTTP les plus restreints dont il a besoin.
2. Remplacer par des substituts. Remplacez les vraies clés dans les variables d'environnement et les fichiers de configuration des agents par des valeurs de substitution ou des jetons de session.

Couche Proxy

1. Isoler le proxy. Exécutez-le sur une machine distincte ou de l'autre côté d'une frontière réseau par rapport aux agents. Le magasin d'identifiants ne se trouve jamais dans l'environnement d'exécution de l'agent.
2. Refuser par défaut. Activez le mode refus pour les hôtes non reconnus et ajoutez des entrées à la liste d'autorisation par agent, et non par équipe.
3. Examiner ce qui revient. Repérez les points de terminaison autorisés dont les réponses peuvent renvoyer un identifiant ou un secret, comme les API de rafraîchissement OAuth, d'émission de jetons, de création de clés et de lecture de secrets. Tenez-les à l'écart de l'agent, sauf si vous pouvez justifier cette exposition.
4. Restreindre la portée des jetons MCP. Les clés API en amont de chaque serveur MCP résident dans l'intermédiaire, pas dans sa configuration. Rejetez les jetons clients qui n'ont pas été explicitement émis pour le serveur MCP, et ne les transmettez jamais en aval.

Couche Périmètre

1. Forcer les flux sortants. Utilisez des règles de pare-feu, des network policies Kubernetes ou des règles de runner CI pour que le proxy soit la seule voie de sortie de l'agent. Définissez ensuite HTTPS_PROXY comme indication pour les clients conformes.
2. Installer la confiance dans l'AC. Ajoutez le certificat d'AC du proxy au magasin de confiance de chaque environnement d'exécution d'agent, en laissant la vérification activée.
3. Vérifier les clients HTTP. Tous les environnements d'exécution ne respectent pas les variables de proxy. La documentation d'Infisical indique que le fetch intégré de Node.js ne lit pas HTTPS_PROXY par défaut : il vous faut donc --use-env-proxy ou NODE_USE_ENV_PROXY=1 sur Node 24 ou version ultérieure. Nous vous conseillons de confirmer la prise en charge de cette option pour la version exacte du runtime que vous déployez avant de vous y fier.

Le prouver

1. Tester la révocation et l'injection. Définissez des durées de session courtes, mettez fin à une session en cours d'exécution et vérifiez que l'accès s'arrête. Lancez ensuite un test canari d'injection de prompt demandant à l'agent d'afficher ses clés, et vérifiez que seuls des substituts en sortent.

Agents CLI comme Claude Code

Infisical cite Claude Code parmi les agents qui fonctionnent via Agent Vault. Pour les agents CLI, la configuration fiable est un conteneur ou une VM dont les règles réseau n'autorisent les connexions sortantes que vers le proxy, avec des substituts partout où l'agent attend des clés API. Un agent CLI peut exécuter des commandes shell : partez donc du principe qu'il peut supprimer des variables d'environnement, et laissez le réseau imposer le chemin.

Agents SDK personnalisés

Auditez chaque client HTTP de l'arbre de dépendances. Une bibliothèque qui ignore les paramètres de proxy doit échouer en mode fermé au niveau réseau, et non se connecter discrètement en direct.

Lire la liste d'autorisation comme le ferait un attaquant

Une fois les clés sorties du contexte de l'agent, la liste d'autorisation devient la principale chose qu'une injection réussie peut exploiter : examinez-la donc sous cet angle avant le déploiement. Pour chaque entrée, demandez-vous ce que pourrait faire la pire séquence d'appels autorisés si quelqu'un d'autre les choisissait. Les points de terminaison de suppression, de transfert, de création de clés et de rafraîchissement de jetons devraient exiger une approbation humaine ou rester totalement hors de la liste d'autorisation. L'identifiant en amont derrière chaque entrée devrait porter les portées les plus restreintes que propose le fournisseur, afin que même un appel approuvé puisse faire le moins possible.

Le proxy fonctionne en complément de vos contrôles existants contre l'injection de prompt, comme le filtrage des entrées, les vérifications des sorties et une conception des outils fondée sur le moindre privilège. Il n'en remplace aucun.