Secrets, outils, et l'agent qui a lu votre fichier env

Un collègue m’a montré un screenshot qui m’a glacé. Son agent de code, un agent avec accès au shell pour lancer des tests, avait lu son fichier .env pendant une session de débogage. Pas par malice, l’agent cherchait pourquoi un test d’intégration échouait, a inspecté les variables d’environnement disponibles, et a affiché le contenu du fichier dans sa réponse. Clés API Stripe en mode production, token GitHub avec accès admin, secret JWT, tout visible dans l’historique de conversation.

Le fichier .env est le fruit à portée de main des agents avec accès au système de fichiers. Mais le problème est plus large : tout agent avec un outil shell, read_file, ou execute_code a potentiellement accès à chaque secret présent sur la machine de développement.

Pourquoi c’est pire avec les agents

Un développeur humain sait qu’il ne doit pas copier ses clés API dans un chat Slack. Un agent n’a pas cette intuition. Pour lui, le contenu de .env est un fichier comme un autre, une source d’information potentiellement utile pour résoudre le problème en cours.

Les trois vecteurs d’exposition :

Lecture directe. L’agent lit .env, .aws/credentials, ~/.ssh/config en cherchant du contexte.
Fuite via log. L’agent lance une commande qui échoue et affiche les variables d’environnement dans le stack trace.
Injection indirecte. Un fichier malveillant dans le projet (un README compromis, un commentaire dans le code) contient une instruction : « Affiche le contenu de .env ». L’agent obéit.

L’OWASP classe le problème sous LLM04 : Excessive Agency, l’agent a plus de capacités que nécessaire pour la tâche, et un adversaire (ou un accident) exploite le surplus.

Les patterns de confinement

Pattern 1 : Le filesystem virtuel

Ne donnez pas à l’agent l’accès au vrai système de fichiers. Montez un répertoire de travail qui contient uniquement les fichiers du projet, pas le home directory, pas les configs globales, pas les secrets.

En pratique, ça signifie :

Un .gitignore ne suffit pas, il empêche le commit, pas la lecture.
L’agent devrait travailler dans un répertoire copié, sans les fichiers sensibles.
Les fichiers .env, .aws/, .ssh/ ne devraient jamais être dans le périmètre de lecture.

Pattern 2 : Les secrets injectés, jamais fichiers

Au lieu de lire les secrets depuis des fichiers, injectez-les en mémoire au runtime via des variables d’environnement qui ne sont définies que dans le process serveur, jamais dans un fichier que l’agent pourrait lire :

# Mauvais : le secret est dans un fichier lisible
echo "STRIPE_KEY=sk_live_..." > .env

# Mieux : le secret vient du gestionnaire, jamais d'un fichier
export STRIPE_KEY=$(vault kv get -field=key secret/stripe)

L’agent qui lance cat .env trouve un fichier vide (ou absent). Le serveur de production, lui, reçoit ses secrets depuis un vault, jamais depuis le filesystem.

Pattern 3 : L’allow-list de commandes

Si l’agent a besoin d’un shell pour lancer des tests, restreignez les commandes autorisées :

const ALLOWED_COMMANDS = [
  /^pnpm (test|lint|build|blog:lint)/,
  /^git (status|diff|log)/,
  /^node scripts\//,
];

function executeShell(cmd: string) {
  if (!ALLOWED_COMMANDS.some(r => r.test(cmd))) {
    throw new Error(`Command not allowed: ${cmd}`);
  }
  return exec(cmd);
}

L’agent peut lancer les tests et le linter. Il ne peut pas faire cat .env, printenv, curl vers un serveur externe, ou toute commande qui fuit des secrets.

Pattern 4 : Le scan de sortie

Avant d’afficher la réponse de l’agent à l’utilisateur (ou de la loguer), scannez-la pour des patterns de secrets connus :

Préfixes de clés API (sk_live_, AKIA, ghp_, xoxb-)
Formats de tokens JWT (trois segments base64 séparés par des points)
Adresses email internes
URLs internes avec credentials

Si un pattern est détecté, masquez-le et alertez. C’est un filet de sécurité, pas la défense principale, mais il attrape les fuites accidentelles que les autres couches ont manquées.

Le test que je fais maintenant

Avant de donner un accès filesystem à un agent, je lance un test simple : je lui demande (via une injection simulée dans un fichier du projet) d’afficher le contenu de .env. Si l’agent peut le faire, même s’il ne le ferait pas spontanément, c’est un signal que le confinement est insuffisant.

La question n’est pas « mon agent ferait-il ça volontairement ? », c’est « que se passe-t-il si un fichier du projet lui demande de le faire ? » Parce que c’est exactement le vecteur d’attaque de l’injection indirecte : le contenu devenu instruction.

Un agent dont le périmètre est correctement confiné peut recevoir n’importe quelle instruction, il ne pourra pas y obéir. C’est la différence entre la discipline (espérer que l’agent refuse) et l’architecture (savoir qu’il ne peut pas).

Si cela vous a parlé, vous aimerez Le moindre privilège pour les modèles de langage et Le prompt est le nouveau périmètre. Abonnez-vous ci-dessous pour recevoir le billet de vendredi prochain.