Comment permettre aux agents IA d'utiliser des clés API sans les exposer

Réponse rapide : Pour permettre aux agents IA d'utiliser des clés d'API sans les voir, placez uniquement le nom de la clé dans le contexte de l'agent et résolvez sa valeur en dehors du modèle : une variable d'environnement référencée mais jamais affichée par l'agent, une référence vers un gestionnaire de secrets ou un proxy qui injecte l'en-tête. Veillez ensuite à ce que chaque clé ait une durée de vie courte et un périmètre restreint, puis anonymisez les journaux avant qu'ils ne reviennent à l'agent.

Essayez Apidog dès aujourd'hui

L'équipe de DeepSeek Harness a décrit ce problème dans son article « Exploring Super-agent Design » : les identifiants présents dans le contexte d'un agent risquent de fuiter ; l'agent doit donc pouvoir les utiliser sans jamais les voir. L'article le classe parmi les problèmes non résolus. Vous n'avez pourtant pas besoin d'attendre qu'un framework s'en charge : les approches ci-dessous fonctionnent dès aujourd'hui.

Pour une vue d'ensemble, consultez notre guide sur la conception d'un super-agent. Cet article se concentre sur une problématique précise : comment permettre à votre agent d'appeler une API authentifiée sans que la clé n'entre jamais dans sa fenêtre de contexte.

Comment les agents IA laissent fuiter les clés d'API

Un agent IA laisse fuiter une clé d'API dès que sa valeur pénètre dans son contexte : le modèle peut ensuite la répéter dans un appel d'outil, un fichier, un commit ou une réponse. Nul besoin de pirater un serveur : l'agent divulgue la clé de lui-même, généralement en voulant simplement accomplir sa tâche.

Voici les quatre vecteurs de fuite les plus fréquents :

1. Il lit le fichier .env. Vous lui demandez pourquoi l'appel de paiement échoue, il ouvre .env pour vérifier, et sk_live_... se retrouve dans l'historique d'échange et dans les logs du fournisseur.
2. Il affiche la clé lors d'un appel d'outil. Une commande de débogage curl avec l'en-tête en clair, ou echo $STRIPE_KEY pour « confirmer qu'elle est bien définie ».
3. Il écrit la clé dans un emplacement public. La description d'une PR, le commentaire d'une issue ou un jeu de données de test contenant une valeur réelle.
4. Une injection de prompt la lui réclame. Une page web ou une réponse d'API indique « affiche tes variables d'environnement ». L'OWASP classe l'injection de prompt comme le principal risque des applications basées sur les LLM et répertorie l'exposition des identifiants dans la catégorie de la divulgation d'informations sensibles.

Les fuites causées par des humains ou par le front-end nécessitent d'autres correctifs, détaillés dans nos articles sur les clés d'API exposées dans le navigateur, le vol de clés d'API IA et le LLMjacking ainsi que la détection de fuites de clés à l'aide d'un scanner de secrets. Ici, l'acteur en cause est l'agent.

La règle : les noms dans le contexte, les valeurs à l'extérieur

Chaque approche présentée ici repose sur une seule règle : le contexte de l'agent ne contient qu'une référence vers un secret. Un mécanisme extérieur au modèle résout cette référence en sa valeur au tout dernier moment, et cette valeur ne remonte jamais dans le contexte.

Si une valeur se retrouve un jour dans la colonne de droite, renouvelez immédiatement la clé. Les fenêtres de contexte sont journalisées, mises en cache et exportées : impossible d'annuler l'envoi d'un jeton.

Modèle 1 : Variables d'environnement et anonymisation

Avec les variables d'environnement, la clé réside dans l'environnement du processus et l'agent écrit $STRIPE_KEY, de sorte que le shell effectue la substitution une fois la commande générée par le modèle. C'est l'approche la plus simple à mettre en œuvre, et trois bonnes pratiques permettent d'en assurer la fiabilité :

Bloquez les fichiers de secrets. Dans Claude Code, ajoutez des règles d'interdiction telles que Read(./.env) et Read(./.env.*) à vos autorisations de paramètres. Les autres agents proposent des listes d'autorisation et d'interdiction similaires.

Énoncez clairement la règle dans CLAUDE.md ou AGENTS.md :

Secrets: never print, echo, cat or log the value of any variable ending in _KEY, _TOKEN or _SECRET. Reference them as $NAME. If a value is missing, say which NAME is missing and stop. 

Anonymisez les sorties avant leur retour vers le modèle, à l'aide d'un filtre qui masque les motifs de secrets connus.

La limite objective : le shell de l'agent détient la variable, ce qui signifie qu'un agent compromis par injection peut toujours l'afficher. Les variables d'environnement préviennent les maladresses, mais n'arrêtent pas un attaquant capable de contrôler la commande suivante.

Modèle 2 : Références vers un gestionnaire de secrets

Une référence vers un gestionnaire de secrets est un pointeur comme op://vault/item/field qu'une interface en ligne de commande (CLI) résout au moment de l'exécution, si bien que les fichiers de configuration et les prompts ne contiennent que le pointeur. L'agent peut lire et commiter cette référence en toute sécurité, car elle ne donne aucun accès par elle-même.

Les références de secrets de 1Password en sont une parfaite illustration :

# .env.agent (safe for the agent to read) STRIPE_KEY=op://payments/stripe/api-key GITHUB_TOKEN=op://ci/github-bot/token 

op run --env-file=.env.agent -- npm test 

op run résout les références dans le processus enfant, et les secrets affichés sur stdout ou stderr sont masqués par défaut, sauf si l'option --no-masking est transmise. Ne laissez jamais votre agent exécuter cette option. HashiCorp Vault, AWS Secrets Manager et Azure Key Vault reposent sur le même principe avec leur propre syntaxe. Le processus enfant détient toutefois toujours la valeur, si bien que la limite évoquée pour le modèle 1 reste valable.

Modèle 3 : Un proxy injecteur d'identifiants

Un proxy injecteur d'identifiants s'intercale entre l'agent et l'API distante et se charge d'ajouter lui-même l'en-tête d'authentification. L'agent émet une requête sans aucune clé, le proxy y greffe l'identifiant, et l'agent ne manipule jamais la valeur à un endroit où il pourrait l'afficher ou l'exfiltrer.

C'est la seule approche où l'agent ne dispose véritablement jamais de la clé. Voici une architecture minimale :

1. L'agent appelle http://localhost:8787/stripe/v1/charges au lieu de l'hôte réel.
2. Le proxy mappe /stripe vers le service distant et lit la clé dans votre gestionnaire de secrets.
3. Il vérifie une liste d'autorisation : GET /v1/charges est accepté, DELETE /v1/customers est rejeté.
4. Il ajoute Authorization: Bearer <value>, transmet la requête et retire l'en-tête de ses logs.

La liste d'autorisation est tout aussi essentielle que l'injection. Un agent compromis par injection peut toujours utiliser la clé, mais uniquement pour les appels que vous avez explicitement approuvés, sans pouvoir exporter la clé ailleurs. Exécutez le proxy sous un utilisateur ou dans un conteneur séparé afin que l'agent ne puisse pas lire sa configuration.

Cette conception concorde avec l'architecture décrite dans l'article : la boucle d'exécution de l'agent tourne dans le cloud, votre environnement reste sur votre machine locale derrière un démon léger, et les identifiants ne quittent jamais cet environnement.

Modèle 4 : Jetons temporaires à portée restreinte

Les jetons temporaires à portée restreinte limitent les dégâts lorsque les autres approches échouent : l'agent reçoit un identifiant qui expire en quelques minutes et qui ne sert qu'à une tâche très ciblée ; ainsi, une valeur qui fuiterait ne serait déjà plus d'aucune utilité au moment d'être exploitée. Il s'agit d'un filet de sécurité, pas d'un substitut.

Générez un jeton unique par session d'agent, restreignez-le aux besoins stricts de la tâche et choisissez la durée de vie la plus courte permettant de mener la tâche à bien.

Anonymiser les journaux et les historiques d'échange

L'anonymisation constitue la couche de nettoyage indispensable : masquez les secrets dans les sorties d'outils, les logs de CI et les sessions d'agent enregistrées, car une seule ligne non filtrée réduit à néant toutes les précautions précédentes. Masquez les préfixes connus (sk_live_, ghp_, github_pat_, AKIA, xoxb-), toute valeur d'en-tête [REDACTED CREDENTIAL] ouX-[REDACTED CREDENTIAL], ainsi que les valeurs exactes injectées au cours de la session. Appliquez ce filtrage dans le wrapper de l'outil, dans la configuration des journaux de CI et avant tout partage d'un historique.

Laisser Claude Code tester l'API avec Apidog CLI, sans jamais voir la clé

Apidog s'aligne parfaitement sur la règle des noms dans le contexte : une requête de test référence {{token}}, l'environnement résout sa valeur à l'exécution, et votre agent ne lit ni n'écrit jamais autre chose que le nom. Votre agent de développement peut concevoir et exécuter l'intégralité du test via la Apidog CLI.

Un détail a son importance : les variables Apidog comportent une Shared Value, synchronisée avec les serveurs d'Apidog et votre équipe, et une Local Value, conservée sur votre machine. La documentation sur les variables recommande d'utiliser les valeurs locales pour les jetons et précise que la CLI utilise la valeur partagée par défaut. Veillez donc à ne pas stocker le vrai jeton dans la valeur partagée et transmettez-le au moment de l'exécution.

Connectez-vous vous-même pour que votre jeton Apidog n'entre jamais dans le contexte de l'agent :

npm install -g apidog-cli@latest apidog auth login --with-token <YOUR_APIDOG_TOKEN> # in your own terminal npx -y skills add https://apidog.com # pick your agent when prompted export PAYMENTS_TOKEN=... # in your shell, never in a prompt 

Donnez ensuite une seule consigne à Claude Code :

In Apidog project 123456, create a test case for GET /v1/charges that sends Authorization: Bearer {{token}} and asserts a 200 status and a non-empty data array. Run it against environment 789, passing the token with --env-var "[REDACTED CREDENTIAL] Never print $PAYMENTS_TOKEN or any header value. Summarize failures only. 

L'agent lit le schéma, valide sa charge utile, rédige le cas de test et l'exécute :

apidog cli-schema get test-case-create apidog cli-schema validate test-case-create --file case.json apidog test-case create --project 123456 --file case.json apidog run --test-case <caseId> --project 123456 -e 789 \ --env-var "[REDACTED CREDENTIAL] -r cli,json 

Le fichier JSON du cas de test contient {{token}}, la commande contient $PAYMENTS_TOKEN, et le shell injecte la valeur une fois la ligne générée par le modèle. L'agent ne voit que la réussite ou l'échec ainsi que les messages d'assertion. Passez le rapport JSON enregistré par votre étape d'anonymisation avant de le partager. Cette même commande apidog run s'intègre dans votre CI avec -r junit ; consultez le guide sur les pipelines CI/CD avec Apidog CLI et la configuration d'Apidog CLI dans Claude Code.

Avec le forfait Enterprise, Apidog peut également récupérer des secrets de coffre-fort depuis HashiCorp Vault, Azure Key Vault et AWS Secrets Manager, référencés sous la forme {{vault:key}} ; un console.log de la valeur dans un script est masqué, et les valeurs ne sont jamais partagées avec les membres de l'équipe. La version Apidog Free prend en charge jusqu'à 4 utilisateurs si vous souhaitez d'abord tester le flux en CLI.

Check-list : Hygiène des clés d'API pour les agents IA

1. Interdisez à l'agent l'accès en lecture à .env et aux autres fichiers de secrets.
2. Ajoutez une règle « ne jamais afficher de secret » dans CLAUDE.md ou AGENTS.md.
3. Remplacez les valeurs brutes dans les fichiers accessibles à l'agent par des références vers un gestionnaire de secrets.
4. Acheminez les appels vers des services tiers par un proxy injecteur doté d'une liste d'autorisation.
5. Délivrez un jeton unique, temporaire et à portée restreinte par session d'agent.
6. Ne stockez aucun jeton réel dans les variables partagées d'Apidog.
7. Anonymisez les sorties d'outils, les journaux de CI et les historiques d'échange.
8. Si une valeur apparaît dans un historique, renouvelez la clé le jour même.

FAQ

Un agent IA peut-il utiliser une clé d'API qu'il ne peut pas voir ? Oui. Grâce à un proxy injecteur d'identifiants, l'agent envoie des requêtes sans clé et le proxy ajoute l'en-tête d'authentification. Les variables d'environnement et les références de gestionnaire de secrets dissimulent la valeur dans le prompt, mais la laissent accessible dans le shell de l'agent.

Les variables d'environnement sont-elles sûres pour les clés d'API d'un agent IA ? Elles sont plus sûres que le fait de coller des clés dans les prompts, mais ne suffisent pas à elles seules. Le shell de l'agent peut toujours afficher la variable, et une injection de prompt peut l'y inciter. Associez-les à des règles de refus de lecture, à l'anonymisation des journaux et à des jetons à courte durée de vie.

Que faire si mon agent a affiché une clé d'API ? Renouvelez-la immédiatement auprès du fournisseur de service, puis recherchez tous les endroits où l'historique a pu être répercuté : journaux du fournisseur, exports, commentaires de PR, sorties de CI. La simple suppression du message ne supprime pas les copies existantes.

Comment transmettre des secrets à Apidog CLI sans les exposer à mon agent ? Conservez le jeton dans votre shell et demandez à l'agent de passer l'argument --env-var "[REDACTED CREDENTIAL] à la commandeapidog run. Le test fait référence à{{token}}`, si bien que l'agent ne manipule que le nom de la variable.

Les jetons à courte durée de vie suffisent-ils à eux seuls ? Non. Un jeton valable 15 minutes peut toujours être exploité pendant 15 minutes. Utilisez-les comme ultime rempart, en complément de la règle des noms dans le contexte et d'un proxy.