Propriété d'une session d'agent tmux : autorisations et audits

Les multiplexeurs de terminaux répondent à un vrai problème opérationnel : ils permettent au travail de continuer malgré une connexion SSH interrompue, la mise en veille d'un ordinateur portable ou la fermeture accidentelle d'une fenêtre de terminal. Cette persistance peut toutefois brouiller l'identité du responsable d'un agent IA, la validité de son autorisation et l'identité du processus qui a réellement envoyé une requête authentifiée.

L'erreur consiste à traiter une fenêtre tmux comme une session de sécurité. Ce n'est pas le cas. tmux gère des processus pour des sessions de terminal. Son serveur peut survivre au client du terminal, et ses panneaux peuvent survivre à la personne qui les a créés. GNU screen possède la même propriété fondamentale. Si votre modèle d'autorisation, vos notes d'incident ou votre processus d'audit parlent de « la session tmux » comme s'il s'agissait d'un acteur unique et d'une seule exécution d'agent, vous avez déjà rendu l'enquête plus difficile qu'elle ne devrait l'être.

Le problème est particulièrement important lorsqu'un agent peut accéder à des API ou à des hôtes SSH par l'intermédiaire d'une passerelle contrôlée par un humain. Une personne peut démarrer un agent dans un panneau, se détacher, transmettre le nom de la session à un collègue, se reconnecter depuis une autre machine, puis lancer un deuxième agent dans le même panneau. Pour l'opérateur, chaque événement semble s'inscrire dans la continuité. Dans la table des processus, ce sont des faits distincts.

Une session tmux n'est pas une exécution d'agent

Une session tmux est un ensemble nommé de fenêtres et de panneaux conservé par un serveur tmux qui fonctionne en arrière-plan. Une exécution d'agent est un processus et les enfants qu'il crée, délimités par leur démarrage et leur arrêt. Ce sont deux objets différents. Les confondre produit des périmètres d'autorisation trop larges ou impossibles à expliquer par la suite.

Lorsque vous exécutez tmux new-session -s build, tmux démarre un serveur ou s'y connecte. Le serveur crée un pseudo-terminal pour le panneau initial et lance un shell. Lorsque ce shell lance un agent, l'agent devient un descendant du shell. Le détachement supprime la connexion du client à tmux. Il n'arrête normalement ni le serveur, ni le shell, ni l'agent.

Une chronologie courante peut sembler sans risque :

1. Maya exécute tmux new -s release et lance un agent dans le panneau 0.
2. Maya se détache pour assister à une réunion tandis que l'agent continue son travail.
3. Son collègue se connecte ensuite à release, lit la sortie du panneau et lance une commande complémentaire.
4. Le soir venu, Maya réutilise le panneau 0 pour un autre processus d'agent.

Le nom de la session est resté release. Les entités importantes pour la sécurité, elles, ont changé. Il y a eu au moins deux processus d'agent, deux interactions humaines et potentiellement plusieurs événements d'autorisation. L'historique du terminal ne peut pas transformer ces faits en une identité unique et cohérente.

GNU screen fonctionne de manière similaire. Un serveur screen détaché possède des fenêtres de terminal et des processus enfants. Les commandes exactes diffèrent, mais la conclusion de sécurité reste la même : l'état d'attachement décrit l'accès à un multiplexeur de terminaux, pas la propriété de tous les processus qu'il contient.

Le manuel de tmux décrit un modèle client-serveur et précise que le serveur gère les sessions, les fenêtres et les panneaux. Ce n'est pas un simple détail d'implémentation. Cela indique où se trouve la continuité : dans le serveur, pas dans l'application de terminal que voit une personne. Fondez l'autorisation sur le processus qui demande une action, pas sur le conteneur du multiplexeur qui l'héberge.

L'ascendance des processus répond aux questions auxquelles les noms de panneaux ne répondent pas

Un arbre des processus peut montrer comment un agent a démarré et quel shell et quel serveur tmux sont ses parents. Le titre d'un panneau ne fait qu'afficher une étiquette que quelqu'un peut avoir modifiée, copiée ou laissée obsolète.

Sur macOS ou Linux, commencez l'enquête par une vue limitée des processus tant que le processus est encore actif :

ps -axo pid,ppid,lstart,tty,stat,command | grep -E '[t]mux|[s]creen|[a]gent'

La forme de la sortie compte davantage que le nom exact des commandes :

 8421     1 Tue Mar 12 09:14:03 2025 ??       Ss   tmux new-session -s release
 8430  8421 Tue Mar 12 09:14:04 2025 ttys002  S    -zsh
 9917  8430 Tue Mar 12 10:02:51 2025 ttys002  S+   agent-tool run deploy check

Le PID 9917 est le processus d'agent à examiner. Le PID 8430 est le shell qui l'a lancé. Le PID 8421 est le serveur tmux. La valeur tty peut aider à relier un processus à un panneau tant qu'il existe, mais ne l'utilisez pas comme identité durable. Les pseudo-terminaux peuvent disparaître lorsqu'un processus s'arrête et prendre une autre forme après la recréation du terminal.

Sur macOS, pstree n'est pas installé par défaut. Cette commande fournit une vue exploitable des relations parent-enfant sans ajouter de logiciel :

ps -axo pid,ppid,user,lstart,command | sort -n

Pour un PID précis, examinez plusieurs fois son parent jusqu'à atteindre le serveur tmux ou un service de lancement :

ps -p 9917 -o pid=,ppid=,user=,lstart=,tty=,command=
ps -p 8430 -o pid=,ppid=,user=,lstart=,tty=,command=

Notez ces valeurs avant de supprimer quoi que ce soit. Un opérateur qui exécute d'abord tmux kill-session peut effacer les éléments de preuve actifs les plus utiles : lignes de commande, relations entre parents et enfants et heures de démarrage. Mettre fin à une session peut rester la bonne mesure de confinement, mais prenez un bref instantané avant lorsque la situation le permet.

L'ascendance des processus a ses limites. Un processus peut se transformer en démon, créer un processus enfant ou se rattacher délibérément à un autre parent. Un agent peut aussi demander à un outil externe d'effectuer le travail, ce qui produit un arbre qui s'arrête au niveau de cet outil. Considérez l'ascendance comme une preuve du contexte de lancement, pas comme la preuve de l'intention d'un humain. Vous avez toujours besoin d'enregistrements d'action qui identifient le processus demandeur et l'autorisation qui lui a permis d'agir.

L'autorisation doit suivre le processus de l'agent, pas le terminal connecté

Une autorisation par session devrait s'appliquer à une seule exécution du processus d'agent et prendre fin lorsque ce processus s'arrête. L'attachement, le détachement, le focus d'un panneau et le redémarrage de l'émulateur de terminal ne doivent ni accorder, ni renouveler, ni transférer silencieusement cette autorisation.

L'autorisation par session de Sallyport suit ce principe : le premier appel d'un nouveau processus d'agent demande une autorisation, identifie le processus par son autorité de signature et conserve cette autorisation pour cette seule exécution. L'autorisation ne devient pas une propriété du nom d'une session tmux ni de l'invite d'un shell.

Cette limite résout plusieurs situations déroutantes. Si une personne se détache puis se reconnecte alors que le même processus d'agent continue de fonctionner, le processus n'a pas changé. Son autorisation de session peut rester valable, sous réserve de la passerelle du coffre et de tout identifiant qui exige une autorisation pour chaque appel. Si l'agent s'arrête, qu'un shell du panneau lance un nouvel agent et que le panneau semble inchangé, le nouveau processus doit recevoir une nouvelle décision d'autorisation.

Ne faites pas de l'attachement à tmux l'événement d'autorisation. Cette idée est tentante parce qu'une action humaine, tmux attach, semble être un signal utile. Ce n'est pas le bon signal pour l'utilisation d'un identifiant. Une connexion peut avoir lieu après le démarrage de l'agent, provenir d'une autre personne utilisant le même compte local ou servir uniquement à consulter la sortie. Surtout, un processus peut continuer à agir alors qu'aucun client tmux n'est connecté.

L'erreur inverse existe aussi dans les équipes : considérer chaque commande saisie dans un panneau connecté comme supervisée par un humain. Une personne peut se connecter, s'éloigner et laisser un agent travailler. Un terminal visible ne prouve pas la présence d'un opérateur.

Pour les identifiants sensibles, l'autorisation à chaque utilisation a un autre objectif. Elle ne dit pas qui est responsable du processus. Elle exige une décision humaine au moment où une action particulière sur un identifiant est demandée. Gardez ces idées séparées :

• La passerelle du coffre décide si une action peut être effectuée alors que les secrets restent protégés.
• L'autorisation par processus décide si cette exécution d'agent peut effectuer des appels.
• L'autorisation par identifiant décide si l'utilisation d'un identifiant particulier exige une nouvelle décision humaine.

Ces contrôles répondent à des questions différentes. Une équipe qui utilise une seule autorisation étendue pour une session de terminal de longue durée privilégie la commodité au détriment d'une limite défendable.

Une fenêtre réutilisée peut prolonger la confusion entre les exécutions

Le problème commence souvent par une session persistante appelée « work », devenue un tiroir partagé pour les commandes inachevées. Quelqu'un démarre un agent, se détache, revient quelques heures plus tard, l'arrête, puis lance un autre agent dans le même shell. Le panneau contient toujours la transcription précédente, les variables d'environnement et l'invite. Les utilisateurs déduisent une continuité que le système d'exploitation ne reconnaît pas.

Prenons un incident au cours duquel une API reçoit une requête destructive à 16:43. L'enregistrement d'activité identifie un processus d'agent. L'équipe ouvre tmux et trouve un panneau appelé prod-fix, dont la sortie commence à 09:00. Elle suppose que l'ingénieur qui a créé prod-fix a autorisé la requête. Cette conclusion peut être fausse de plusieurs façons :

• L'agent initial peut s'être arrêté à 10:15 et un autre processus avoir démarré à 16:40.
• Un deuxième ingénieur peut s'être connecté et avoir lancé la nouvelle commande.
• Le titre du panneau peut provenir d'une tâche précédente.
• Un fichier de démarrage du shell peut avoir exporté des identifiants ou un environnement cible qui ne correspondent plus au travail actuel.
• Le processus peut avoir démarré hors de tmux et écrit sa sortie dans le panneau par un autre mécanisme.

La bonne question est plus précise : quel processus exécutable a demandé l'action à 16:43, qui a autorisé ce processus et quelle autorité de signature l'interface d'autorisation affichait-elle ? Demandez ensuite comment ce processus est entré dans l'arbre des processus de la machine.

Ne réagissez pas en interdisant tmux. Une session nouvelle et nommée avec précision peut faciliter le travail d'incident en fournissant un espace visible et en conservant la sortie pendant une connexion instable. Le risque vient de la réutilisation d'une session générale comme conteneur pour des exécutions d'agents sans rapport.

Utilisez des noms qui indiquent un objectif et un identifiant d'exécution de courte durée, comme deploy-4812 plutôt que work ou main. Le nom aide les humains, mais ne doit pas servir d'entrée à l'autorisation. Mettez fin à la session lorsque l'exécution est terminée.

Le travail détaché exige un responsable et une date d'expiration

Une session tmux ou screen détachée ne peut fonctionner sans risque que lorsque quelqu'un a explicitement accepté qu'elle continue sans terminal connecté. « Je pensais que c'était arrêté » n'est pas un modèle de responsabilité.

Avant de détacher un agent capable d'effectuer des actions authentifiées, notez quatre faits dans le ticket, la note d'incident ou le document de transmission : le PID du processus d'agent, le nom de la session tmux, la tâche déclarée et la personne responsable de son arrêt. Ajoutez une heure à laquelle quelqu'un devra vérifier s'il doit continuer. Ce travail est simple et évite davantage de problèmes que des conventions complexes de nommage des panneaux.

Un modèle de lancement utile crée un nouvel espace de sockets pour une exécution au lieu d'ajouter une fenêtre à un serveur personnel durable :

tmux -L agent-4812 new-session -d -s agent-4812 \\
  'exec agent-tool run "verify deployment 4812"'

tmux -L agent-4812 display-message -p \\
  '#{session_name} #{session_created} #{pane_pid} #{pane_tty}'

La première commande lance une session détachée. exec est important, car il remplace le processus du shell par la commande de l'agent et fait du PID du panneau un point de départ plus direct pour l'enquête. Sans exec, le panneau appartient d'abord à un shell qui crée ensuite l'agent comme processus enfant. Cela reste gérable, mais ajoute un niveau à examiner.

La deuxième commande affiche des métadonnées dont la forme ressemble à ceci :

agent-4812 1731000000 9917 /dev/ttys002

Enregistrez cette sortie avec le suivi de la tâche. Le processus peut ensuite créer des enfants ou s'arrêter, ce qui ne constitue pas un audit complet. Ces données fournissent un premier repère lorsque les intervenants doivent comparer les informations sur les processus aux journaux d'actions.

Lorsque la tâche est terminée, arrêtez explicitement la socket nommée :

tmux -L agent-4812 kill-session -t agent-4812

Vérifiez ensuite que le PID de l'agent attendu s'est bien arrêté. Ne supposez pas que kill-session a supprimé tous les descendants. Les programmes qui créent leurs propres sessions ou des outils d'arrière-plan peuvent survivre à leur pseudo-terminal d'origine. Examinez de nouveau la liste des processus et utilisez la passerelle d'actions pour révoquer l'exécution active de l'agent si ses enregistrements montrent qu'elle reste autorisée.

Screen présente le même piège d'identité, avec moins d'indices

GNU screen crée une session détachée qui peut être reprise plus tard. Ses identifiants numériques familiers peuvent sembler plus précis qu'ils ne le sont. Ils identifient une instance de serveur screen, pas un processus d'agent précis ni une autorisation humaine.

Le manuel de GNU screen documente les sessions détachées et les commandes telles que screen -ls et screen -r. Ces commandes indiquent si un serveur screen est disponible pour une connexion. Elles ne permettent pas de savoir si le processus de la fenêtre est le même que celui qui fonctionnait plus tôt, ni si l'opérateur actuel est la personne qui a pris la décision d'autorisation initiale.

Commencez par ces vérifications lorsque screen intervient dans un incident :

screen -ls
ps -axo pid,ppid,lstart,tty,stat,command | grep -E '[s]creen|[a]gent'

Un résultat comme 12345.build (Detached) identifie une session screen à examiner. Comparez-la aux heures de démarrage et aux terminaux avant de vous connecter. La connexion peut modifier ce que voit l'utilisateur, déclencher des hooks du shell ou inciter un programme interactif à continuer. Lors d'un incident sensible, préservez d'abord les éléments de preuve et laissez l'intervenant désigné décider si une interaction est nécessaire.

Le mode multiutilisateur de screen appelle une prudence supplémentaire. Il peut donner à d'autres utilisateurs locaux accès à une session de terminal partagée. Cela peut convenir sur une machine contrôlée, mais affaiblit toute affirmation informelle selon laquelle « la personne qui s'est connectée » serait responsable des processus. L'autorisation doit toujours identifier le processus d'agent demandeur et exiger une décision de la personne qui contrôle localement la passerelle des identifiants.

Les enregistrements d'audit ont besoin d'un point de rapprochement en dehors de tmux

Une enquête défendable rapproche trois types d'enregistrements : celui des processus du système d'exploitation, celui des autorisations et celui de chaque action. La sortie de tmux ou de screen peut compléter ces éléments de preuve, mais ne peut en remplacer aucun.

Pour chaque action sur un identifiant examinée, établissez la séquence suivante :

1. Identifiez dans l'enregistrement d'activité l'heure, la destination, la méthode et le résultat de l'action.
2. Identifiez l'exécution de l'agent qui l'a demandée et la décision d'autorisation associée.
3. Comparez les détails du processus et l'heure de démarrage de l'exécution à l'arbre des processus actif ou capturé.
4. Utilisez les métadonnées de la session tmux ou screen uniquement pour reconstituer l'espace de travail et les transmissions entre opérateurs.
5. Vérifiez que l'enregistrement d'audit n'a pas changé depuis sa capture.

La différence entre un journal d'actions et l'historique du terminal est nette. L'historique peut omettre une sortie, être renouvelé, contenir du texte collé depuis un autre processus ou être modifié par un utilisateur ayant accès à la session. Un journal d'actions doit indiquer l'opération tentée et son résultat. S'il fournit des preuves de modification, les enquêteurs peuvent vérifier que l'ensemble des enregistrements est resté intact sans faire confiance au terminal qui les affichait.

Sallyport enregistre les exécutions d'agents et les appels individuels dans un journal d'audit chiffré et chaîné par hachage. sp audit verify peut vérifier cette chaîne hors ligne sans clé du coffre. Cette vérification prouve l'intégrité de la séquence enregistrée, pas qu'un titre tmux identifie correctement la personne qui a saisi une commande. Faites clairement la distinction dans les rapports d'incident.

Une note d'incident utile évite une formulation comme « la session tmux de release l'a fait ». Écrivez plutôt : « À 16:43, l'exécution d'agent [identifiant] a demandé [action]. La demande provenait du processus [identifiant], démarré à [heure]. Au moment de la capture, le processus était un descendant de [shell ou service] associé au serveur tmux [PID]. [Personne] a autorisé l'exécution après examen de l'autorité de signature affichée. » Ne renseignez que les faits que vous pouvez étayer.

Cette formulation fait aussi apparaître les lacunes. Si personne n'a capturé la chaîne des parents avant le confinement, dites-le. Si le système ne conserve pas l'identité de processus nécessaire, ne remplacez pas cette information manquante par un nom de panneau.

L'identité de signature et celle du compte local répondent à des problèmes différents

Un compte macOS local identifie un utilisateur du système d'exploitation. L'autorité de signature identifie le signataire d'un exécutable. Une session tmux identifie un serveur de terminal. Aucun de ces identifiants n'a le même sens, et chacun permet de repérer une défaillance différente.

L'identité du compte local aide à déterminer quel compte possède le processus. Elle ne dit pas si un binaire provient de l'éditeur attendu ni si une autre personne a utilisé un compte déverrouillé. L'autorité de signature aide l'utilisateur à reconnaître l'exécutable qui demande l'accès. Elle ne dit pas si le processus a été lancé dans le bon panneau tmux ni si la tâche était appropriée.

C'est pourquoi une carte d'autorisation qui présente en premier l'autorité de signature est utile lorsqu'un nouveau processus d'agent demande à agir. Elle fournit un signal stable qui résiste au changement de nom des panneaux, à la copie d'une configuration tmux et au redémarrage de l'émulateur de terminal. Elle rend aussi visibles les exécutables inattendus, non signés ou signés différemment, au moment décisif.

Ne transformez pas cela en règle aveugle du type « même signataire, donc sans danger ». Un signataire fiable peut publier une version défectueuse, un wrapper local peut appeler un binaire approuvé dans un contexte dangereux et un processus signé peut recevoir des instructions risquées. L'identité du processus resserre la cible de l'autorisation. L'autorisation par appel pour certains identifiants et un historique complet des actions prennent en charge les risques que cette identité ne peut pas résoudre seule.

Pour les investigations sur macOS, vous pouvez examiner les informations de signature d'un binaire avec codesign :

codesign -dv --verbose=4 "$(command -v agent-tool)" 2>&1 | \\
  grep -E 'Identifier=|TeamIdentifier=|Authority='

La sortie contient normalement des lignes comme Identifier=, TeamIdentifier= et une ou plusieurs entrées Authority=. Capturez-la lorsque vous devez expliquer pourquoi une interface d'autorisation a reconnu un processus. Ne remplacez pas les preuves de signature par un chemin comme /usr/local/bin/agent-tool. Les chemins peuvent facilement être masqués, remplacés ou redirigés par un lien symbolique.

Cessez d'utiliser des sessions partagées permanentes pour les agents privilégiés

Un serveur tmux permanent appelé dev, main ou shared est un mauvais endroit pour exécuter des agents pouvant accéder aux identifiants de production. Il facilite le travail actif, mais mélange les personnes, les tâches, l'historique du shell, l'état de l'environnement et la durée de vie des processus, jusqu'à ce que personne ne puisse dire où une exécution s'est terminée.

Séparez le multiplexage interactif personnel de l'exécution des agents. Donnez à chaque exécution son propre socket ou sa propre session. Lancez-la à partir d'une commande enregistrée, capturez son PID et son heure de démarrage, puis désignez un responsable avant le détachement. Si un autre ingénieur doit poursuivre la tâche, il doit démarrer un nouveau processus d'agent et recevoir une nouvelle décision d'autorisation, plutôt que d'hériter par convention d'une ancienne fenêtre.

Les équipes résistent parfois à cette pratique parce que la réutilisation d'une session semble efficace. Elle l'est jusqu'au moment où un agent envoie une requête après la fin de la tâche initiale et où l'équipe d'intervention passe une heure à lire l'historique du terminal. Créer des limites de processus claires ne prend que quelques secondes. Reconstituer une limite confuse prend beaucoup plus de temps et conduit souvent à une supposition plutôt qu'à une réponse.

Le premier changement opérationnel est simple : interdisez les sessions tmux et screen anonymes de longue durée pour les agents disposant d'un accès authentifié. Créez une session éphémère par exécution, enregistrez l'identité de lancement et fermez-la lorsque l'exécution est terminée. Cette règle donne aux systèmes d'autorisation et aux enquêteurs une véritable limite sur laquelle s'appuyer.