Agent IA et secrets : injection runtime, pas stockage

L'erreur la plus répandue dans les déploiements d'agents IA en 2026, c'est d'exposer les secrets via des variables d'environnement ou des fichiers de config. Le pattern est partout, parce que c'est ce que les exemples de documentation montrent, parce que c'est ce qui marche le plus vite. Et c'est aussi ce qui transforme un agent compromis en exfiltration immédiate de credentials.

La bonne posture en 2026 : injection runtime via broker, jamais stockage long-terme dans l'environnement de l'agent.

Le problème en clair

Un agent qui peut exécuter du code (et la plupart des agents 2026 le peuvent, directement ou via des outils) a accès à os.environ, à ~/.config, au filesystem entier. Si vous y avez mis :

• OPENAI_API_KEY=sk-xxx
• AWS_ACCESS_KEY_ID=AKIA...
• DATABASE_URL=postgres://user:pass@...
• GITHUB_TOKEN=ghp_...

…un attaquant qui compromet l'agent (par prompt injection ou autre) lit tout ça en une commande. Souvent il les exfiltre dans la même session, sans que vous le voyiez tout de suite.

Le pattern broker : 3 composants

1. Le broker

Service séparé qui détient les secrets et expose une API authentifiée. Au choix :

• HashiCorp Vault.
• AWS Secrets Manager.
• GCP Secret Manager.
• Azure Key Vault.
• Doppler, 1Password Connect, Infisical pour les stacks plus petites.

Le broker est la seule source de vérité des secrets en clair. Personne d'autre ne les détient.

2. L'identité de l'agent

L'agent prouve son identité au broker via :

• OIDC fédéré : le runtime de l'agent (Kubernetes, Lambda, container ECS) prouve son identité au broker via un token OIDC signé par le cluster. Pas de credentials long-terme.
• Ou, dans un environnement plus modeste, un token court rotaté toutes les 15-60 minutes.

3. La demande just-in-time

Quand l'agent veut appeler un outil qui nécessite un secret :

`` agent → broker (identité OIDC + scope demandé) → broker vérifie autorisation + politique → broker retourne un token éphémère (15 minutes, scopé à l'opération) → agent appelle l'outil avec ce token → token expire ``

Le secret n'est jamais persistant dans la mémoire de l'agent. Si l'agent est compromis, l'attaquant n'obtient au pire que le token éphémère, valable 15 minutes, scopé à une opération précise.

Les variantes pratiques

Variante minimaliste pour démarrer

Si Vault ou équivalent n'est pas envisageable tout de suite, le dégradé acceptable est :

• Secrets stockés chiffrés côté serveur.
• Récupérés à l'init de l'agent par un appel authentifié.
• Tenus uniquement en mémoire (pas dans os.environ, pas dans un fichier).
• L'agent ne peut pas exécuter de code utilisateur arbitraire dans le même process que les secrets.

Ce n'est pas parfait, mais c'est mieux que OPENAI_API_KEY en variable d'env.

Variante avancée : secrets jamais en mémoire de l'agent

Pour les actions à très fort impact (paiement, signature) :

• L'agent ne reçoit jamais le secret.
• L'agent appelle un endpoint interne qui sait "effectuer le paiement".
• L'endpoint, lui, a accès au secret via le broker.
• L'endpoint applique sa propre politique (validation, limites, audit) avant d'agir.

L'agent travaille en aveugle sur ce que sont les credentials. Il dispose d'une primitive métier, pas d'une primitive technique. C'est l'architecture la plus défensive pour les fonctions sensibles.

Le cas particulier des agents en dev local

Un dev qui itère sur un agent localement a besoin de credentials. Le réflexe est de coller un .env dans le projet. À éviter :

• Tooling comme direnv + 1Password CLI : récupère les secrets à la volée quand le shell entre dans le dossier, les détruit en sortant.
• Tokens dédiés au dev, scopés à la sandbox, avec rotation forcée toutes les semaines.
• Pas d'accès aux ressources de prod depuis le compte du dev — staging seulement.

Ce qui marche moins bien qu'on ne le pense

Le chiffrement at-rest seul

"Mes secrets sont chiffrés sur le disque" — oui, mais ils sont déchiffrés au démarrage de l'agent et tenus en mémoire en clair. Un dump de la mémoire de l'agent les expose. Le chiffrement at-rest seul est une protection contre le vol physique du disque, pas contre une compromission applicative.

Les permissions filesystem

"Le fichier .env est en chmod 600" — oui, mais l'agent qui tourne sous le même user a accès. Et la majorité des agents sont compromis via du code qu'ils exécutent eux-mêmes, pas via une élévation de privilège système.

Le scrubbing des logs

Beaucoup d'équipes ont des scrubbers qui retirent les secrets des logs avant export. Bonne pratique. Mais si l'attaquant a exécuté du code dans l'agent, il n'a pas besoin de passer par les logs — il lit les secrets directement.

Le test simple

Trois questions à se poser avant un go-live :

1. Si je fais un dump de la mémoire de mon agent en plein milieu d'une session, combien de secrets long-terme je trouve ?
2. Si un attaquant compromet l'agent et exécute du code arbitraire pendant 60 secondes, quelles actions à fort impact peut-il déclencher ?
3. Mes secrets en prod ont-ils été vus en clair par plus d'un humain depuis qu'ils existent ?

L'objectif est respectivement : 0, aucune, et idéalement aucun humain. C'est la cible. Les écarts sont des dettes documentées.

Pour la rotation automatique des secrets, Vault + Terraform + ArgoCD. Pour le confinement runtime général, Confinement d'un agent.