La sortie de session comme surface de fuite

Quand un agent IA exécute une commande, on imagine la sortie s'afficher dans une console, la lire, et l'oublier. C'est faux. Cette sortie ne reste pas là : elle est capturée dans le transcript de session et renvoyée au fournisseur du modèle via l'API, parce que l'agent en a besoin pour raisonner sur la suite. La console n'est pas le point final du texte — c'est une escale. Un secret qui apparaît dans cette sortie — une clé d'API, un mot de passe, un jeton, une empreinte HMAC, une chaîne de connexion — est donc exposé bien au-delà de l'écran.

Ce texte explique pourquoi cette exposition est structurelle et irréversible, et quelle discipline la neutralise.

Le canal n'est pas privé

L'intuition trompe : « c'est juste ma console, c'est chez moi ». En réalité, dès qu'un agent lit une sortie, cette sortie voyage. Elle est écrite dans un transcript qui persiste, et elle part dans un appel réseau vers un tiers — le fournisseur du modèle — qui peut la journaliser, la mettre en cache, la conserver le temps de ses propres politiques. La frontière de confiance n'est pas où on la place instinctivement. On croit parler à une machine locale ; on publie en fait vers un système distant qu'on ne maîtrise pas. Ce qui traverse la sortie de session a, de fait, quitté le périmètre.

L'irréversibilité

C'est la différence de nature avec une fuite « fichier ». Un secret commité par erreur dans un dépôt, on le retire, on réécrit l'historique, on nettoie. Ici, il n'y a pas de git revert qui sauve : le texte est déjà parti en transcript et en API, dupliqué dans des journaux hors de portée. On ne rattrape pas un secret sorti — la seule réponse sûre est de le considérer comme compromis et de le faire tourner : révocation, régénération, redéploiement de tout ce qui l'utilisait.

Le coût est violemment asymétrique. Quelques caractères affichés une fraction de seconde déclenchent une rotation complète et une chaîne de redéploiements. C'est ce déséquilibre qui rend le sujet sérieux : l'incident est minuscule à produire, coûteux à réparer, et impossible à annuler.

Le renversement : la rigueur devient la faille

Comme pour l'airlock documentaire, ce n'est presque jamais la commande bâclée qui fuit. C'est la plus consciencieuse. Le diff de vérification qu'on lance « pour être sûr que tout est bon ». Le dump de configuration qu'on affiche pour contrôler avant de valider. La variable qu'on imprime pour comprendre pourquoi ça échoue. Le geste de prudence — vérifier, inspecter, débugger — est précisément celui qui pousse un secret dans le canal observé. La rigueur se retourne en fuite.

C'est le même principe que la discipline documentaire, transposé d'une surface à l'autre. L'airlock protège la publication : rien de sensible ne franchit vers l'espace public sans projection. Ici, on protège l'exécution : rien de sensible ne franchit vers la sortie de session. Deux surfaces distinctes, un seul réflexe — le default-deny du sensible : par défaut, le secret ne passe pas.

La discipline : ne jamais laisser transiter le sensible

Le principe tient en une phrase : un secret ne doit jamais avoir à traverser la sortie de session. Trois gestes le mettent en œuvre.

Masquer à la source. L'outil qui manipule le secret ne doit pas le rendre. Une tâche d'automatisation qui utilise <UN_SECRET> peut être configurée pour ne pas le journaliser ni l'imprimer dans son compte-rendu : le secret circule à l'intérieur, il ne ressort pas. C'est à l'outil de se taire, pas à l'humain de penser à ne pas regarder.

Préférer la référence à la valeur. On manipule un nom de variable, un identifiant de secret, un pointeur vers un coffre — jamais la valeur en clair. La sortie montre <UN_SECRET> résolu nulle part, seulement désigné.

Au moindre doute, ne pas lancer. Si une commande peut faire apparaître du sensible et qu'on n'en est pas certain, elle ne se lance pas telle quelle. Le doute tranche vers l'abstention, pas vers l'essai.

Ce que ça n'est pas

Ce n'est pas « ne jamais utiliser de secrets en automatisation » — ce serait renoncer à automatiser. Les secrets circulent, c'est leur rôle : une tâche s'authentifie, une connexion s'ouvre. La règle est plus fine : le secret circule par les canaux prévus pour lui — variables d'environnement, coffres, injection au runtime — et jamais par le canal observé par l'agent. On ne supprime pas le secret du système ; on le tient hors du transcript.