Quel est le véritable processus de l'agent qui demande une approbation ?

Une demande d'approbation qui affiche « Terminal » ou « zsh » est généralement trop vague pour permettre une véritable décision. Ces programmes peuvent faire partie du chemin de lancement, mais ils servent souvent d'infrastructure partagée. Le réviseur doit savoir quelle exécution de l'agent a demandé l'action, ce qui l'a lancée et si un élément de cette chaîne lui donne une identité durable.

La difficulté vient du fait qu'un arbre de processus répond à plusieurs questions différentes à la fois. Il peut indiquer qui a créé quel processus. Il peut révéler un exécuteur de tâches que personne n'attendait. Il peut montrer qu'un IDE graphique a démarré le terminal. Mais il ne peut pas, à lui seul, prouver qu'un parent signé a approuvé chaque ligne de code qu'un enfant exécutera. Une bonne conception des approbations utilise l'arbre comme preuve, puis énonce la conclusion limitée qu'il permet réellement de soutenir.

L'approbation concerne un acteur, pas un terminal

L'acteur approuvé par le réviseur est l'exécution du processus qui a demandé l'action, interprétée dans le contexte de sa chaîne de lancement. Une fenêtre de terminal est un endroit où des processus s'exécutent. Ce n'est pas automatiquement le programme responsable.

Cette distinction peut sembler pointilleuse jusqu'à ce qu'une équipe fasse fonctionner plusieurs agents depuis un même shell. Un développeur ouvre un terminal dans iTerm2, lance un agent de programmation interactif dans un onglet, démarre une tâche de dépôt dans un autre et laisse un observateur s'exécuter en arrière-plan dans un troisième. Les trois descendants peuvent avoir la même application de terminal quelque part au-dessus d'eux. Appeler chaque requête « iTerm2 » n'apprend presque rien au réviseur.

L'erreur inverse est tout aussi fréquente. Un réviseur voit node, python ou zsh et suppose que le binaire le plus proche de la requête constitue toute l'identité. Ce binaire peut être l'interpréteur d'un paquet d'agent, un hook de gestionnaire de paquets, un script temporaire généré par une extension d'IDE ou un wrapper ajouté par un outil d'équipe. Le nom est techniquement exact, mais inutile en pratique.

Utilisez trois étiquettes en interne, même si la carte d'approbation n'en affiche que deux :

• Demandeur : le processus qui a réellement demandé à utiliser le canal protégé.
• Chaîne d'exécution : les processus parents pertinents qui expliquent comment le demandeur est arrivé là.
• Autorité reconnaissable : l'ancêtre le plus proche dont l'identité est raisonnablement reconnaissable par un réviseur et dont la signature de code peut être évaluée.

Ces étiquettes résolvent un problème que de nombreux systèmes d'approbation brouillent. Le demandeur répond à « quel processus a effectué cet appel ? ». L'autorité reconnaissable répond à « par quelle personne ou organisation cette exécution est-elle passée ? ». Les deux notions sont liées, mais elles ne sont pas interchangeables.

Par exemple, une requête peut ressembler à ceci :

Code Helper (signed application)
  └─ zsh -l
      └─ npm run agent
          └─ node ./tools/start-agent.mjs
              └─ agent-cli --workspace /Users/maya/src/payments

Si agent-cli effectue une requête HTTP, c'est le demandeur. Le shell et npm expliquent le chemin de lancement. Le processus Code Helper signé peut être la meilleure autorité reconnaissable, à condition qu'il fasse réellement partie de l'ascendance active et qu'il ne soit pas simplement ouvert sur le bureau. Une carte qui indique « agent-cli, lancé depuis Code Helper » est honnête. Une carte qui dit seulement « Code Helper veut accéder à cette ressource » élimine l'information permettant de distinguer cette exécution d'une autre extension ou tâche.

Un arbre de processus est une preuve, pas une déclaration d'intention

Un processus parent prouve qu'il a créé une relation avec un enfant ou qu'il l'a héritée. Il ne prouve pas que le parent comprenait les arguments ultérieurs de l'enfant, son invite, les instructions du dépôt ou la réponse distante.

Cette limite compte lorsque l'on parle de signature de manière imprécise. Apple décrit l'exigence désignée comme le mécanisme utilisé par macOS pour déterminer si un code reste le même au fil des versions. Elle intègre généralement un identifiant et une autorité de signature. Apple précise aussi la limite : le code non signé ne possède pas d'exigence désignée durable, et les signatures locales ad hoc ne fournissent pas une identité stable d'une version à l'autre.

C'est une preuve utile pour une approbation. Ce n'est pas une validation de l'action. Un IDE signé peut démarrer un script de dépôt non signé. Un terminal signé peut exécuter un binaire téléchargé. Un exécuteur de tâches signé peut transmettre des variables d'environnement malveillantes à un interpréteur parfaitement ordinaire. La signature permet au réviseur de reconnaître l'éditeur du code. Elle ne rend pas sûre la chaîne qui se trouve en dessous.

Traitez les affirmations suivantes différemment :

La conséquence est pratique. Ne réduisez pas ces quatre affirmations à une icône d'application conviviale et une seule phrase. Le réviseur doit pouvoir voir quelle affirmation il accepte.

Lorsque la chaîne est ambiguë, dites-le. « Démarré par un script non signé depuis une session de terminal » est une meilleure étiquette d'approbation que d'attribuer la requête à l'application de terminal comme si celle-ci en était l'auteur. Une fausse précision apprend aux utilisateurs à ignorer la carte.

Inspecter la chaîne active avant de concevoir la carte d'approbation

Le moyen le plus rapide de trouver le bon acteur consiste à inspecter une exécution réelle pendant qu'elle est active. Faites-le avec une opération inoffensive, car la chaîne peut changer lorsque le travail passe du démarrage à un exécuteur de tâches ou à un assistant enfant.

Sur macOS, commencez par le PID du demandeur si votre passerelle l'enregistre. Cette commande affiche le processus, son PID parent, l'heure de démarrage, le nom de l'exécutable et les arguments :

ps -p "$PID" -o pid=,ppid=,lstart=,user=,comm=,args=

Un résultat représentatif a cette forme :

81234 80991 Tue Jul 21 14:08:31 2026 maya /usr/local/bin/agent-cli agent-cli --workspace /Users/maya/src/payments

Remontez ensuite la chaîne. ps ne le fait pas récursivement, mais une petite fonction shell rend l'inspection reproductible :

ancestry() {
  local pid="$1"
  while [ "$pid" -gt 1 ] 2>/dev/null; do
    ps -p "$pid" -o pid=,ppid=,user=,comm=,args=
    pid=$(ps -p "$pid" -o ppid= | tr -d ' ')
  done
}

ancestry "$PID"

La sortie reste volontairement simple. Cherchez les changements de nature : exécutable d'agent vers interpréteur, interpréteur vers gestionnaire de paquets, gestionnaire de paquets vers shell, shell vers terminal ou assistant d'IDE. Ne vous arrêtez pas parce qu'un nom vous est familier. Continuez jusqu'à atteindre un processus qui fournit une provenance utile au réviseur, ou jusqu'à la fin de la chaîne locale.

Pour obtenir une vue d'ensemble lorsque plusieurs descendants existent, cette commande est utile :

ps -ax -o pid=,ppid=,user=,lstart=,comm=,args= | sort -n

Utilisez-la pour l'analyse, pas pour une demande d'approbation. Une liste complète des processus contient trop de détails sans rapport et trop peu de structure. Votre implémentation doit la recueillir si nécessaire, puis la réduire au demandeur, au parent immédiat, à l'autorité reconnaissable et aux étapes intermédiaires qui expliquent un lancement surprenant.

Deux pièges temporels sont à prendre en compte. D'abord, les identifiants de processus peuvent être réutilisés après la fin d'un processus. Enregistrez l'heure de démarrage avec le PID et résolvez la chaîne au moment de la requête au lieu de faire confiance à un échantillon antérieur. Ensuite, un exécuteur de tâches peut créer un worker puis se terminer avant l'appel protégé. Si le parent a déjà disparu, conservez la chaîne observée lors de la création du processus ou signalez le lien manquant. Ne le remplacez pas par un parent supposé.

VS Code modifie le chemin de lancement sans devenir le demandeur

Le terminal intégré de VS Code peut injecter des arguments ou des variables d'environnement lorsqu'il lance des shells pris en charge pour activer l'intégration au shell. Sa documentation précise aussi que l'injection automatique ne couvre pas toutes les configurations, notamment certains sous-shells, connexions SSH et shells complexes. C'est un bon rappel : les métadonnées de l'interface du terminal et la parenté Unix sont deux sources de preuve distinctes.

Dans un cas simple, la chaîne ressemble à ceci :

Visual Studio Code
  └─ terminal helper
      └─ login shell
          └─ agent-cli

L'assistant de terminal existe parce que l'IDE doit gérer un pseudo-terminal et son shell enfant. Le shell de connexion peut charger un profil qui modifie PATH, active un environnement de langage, installe des hooks shell ou démarre un script propre au projet. Ces détails expliquent pourquoi la même commande se comporte différemment dans un terminal autonome et dans le terminal d'un IDE.

La décision d'approbation ne doit pas faire comme si ces détails n'existaient pas. Affichez l'exécutable de l'agent comme demandeur. Présentez VS Code comme autorité de lancement uniquement lorsqu'il figure dans l'ascendance actuelle. Incluez le shell et la commande de tâche dans un chemin dépliable lorsqu'ils distinguent réellement l'exécution.

Un échec fréquent ressemble à ceci :

Visual Studio Code
  └─ zsh
      └─ make test-agent
          └─ sh -c ./scripts/bootstrap-agent
              └─ python3 tools/agent.py

Une implémentation naïve voit zsh et étiquette la requête « terminal VS Code ». Une autre voit python3 et l'étiquette « Python ». Aucune n'aide le réviseur à déterminer s'il s'agit de la tâche connue du dépôt ou d'un processus arbitraire lancé depuis le même shell.

La formulation utile est plutôt :

Requester: python3 tools/agent.py
Run path: make test-agent > scripts/bootstrap-agent
Launched from: Visual Studio Code integrated terminal

Cette étiquette a un coût : elle révèle que la requête vient d'un code contrôlé par le dépôt. C'est normal. Si un réviseur fait confiance à un éditeur signé, mais pas à la copie actuelle du dépôt, la carte doit lui laisser la possibilité de porter ce jugement.

N'inférez pas que VS Code est propriétaire à partir de séquences d'échappement du terminal, de variables d'environnement ou d'un simple titre de fenêtre. Ces éléments peuvent être hérités, copiés ou obsolètes. La parenté active constitue une preuve plus solide. Le contexte fourni par l'IDE peut enrichir l'affichage une fois cette ascendance établie, mais il ne doit pas la remplacer.

Un terminal autonome fournit du contexte, pas une autorité générale

iTerm2, Terminal et les applications comparables offrent à l'utilisateur un point d'entrée délibéré. Si un développeur ouvre un terminal propre, saisit une commande d'agent et reçoit immédiatement une demande d'approbation, l'identification de l'application de terminal constitue un contexte utile. Elle indique où l'exécution a commencé.

Elle ne justifie toujours pas une approbation générale pour chaque enfant qui partage cette session. Les shells sont conçus pour créer des enfants, et les onglets de longue durée survivent souvent à la raison pour laquelle ils ont été ouverts. Une commande lancée à 9 h dans un onglet peut laisser un worker actif jusqu'au déjeuner, après un cd, un changement de branche, une modification d'environnement et trois commandes sans rapport.

Rendez la distinction visible :

Requester: agent-cli --workspace /Users/maya/src/payments
Parent: zsh -l
Interactive origin: signed terminal application
Session started: Tue Jul 21 14:08:31 2026

L'origine interactive est un contexte complémentaire. La session appartient à l'exécution réelle du processus. Si le processus se termine, révoquez l'approbation de la session même si l'onglet du terminal reste ouvert. Un nouvel agent lancé dans le même onglet constitue une nouvelle exécution, avec de nouveaux arguments et éventuellement un autre exécutable trouvé dans PATH.

C'est là que l'identité reconnaissable par le réviseur devient délicate. L'application de terminal peut être signée par un éditeur connu, tandis que agent-cli est un exécutable non signé installé dans un répertoire de projet. La carte honnête doit mentionner ces deux faits. Ne transférez pas la signature du terminal à l'enfant non signé comme si le terminal s'en était porté garant.

Le même problème se présente avec les fonctions shell et les alias. Une commande qui ressemble à agent peut se développer en une fonction qui change de répertoire, charge un fichier d'environnement, lance un script de paquet, puis démarre un autre binaire. Votre collecteur de processus ne verra que les enfants qui en résultent. Si vous voulez afficher la commande saisie comme contexte facultatif, capturez-la via l'intégration au shell ou un hook shell et étiquetez-la comme historique de commande saisie par l'utilisateur, pas comme identité du processus.

Les scripts et les exécuteurs de tâches créent les chaînes les plus trompeuses

Les exécuteurs de tâches sont appréciés parce qu'ils transforment une configuration locale complexe en une commande facile à retenir. Cette commodité donne souvent à leur chaîne de processus une apparence de fiabilité supérieure à la réalité.

Considérez ce lancement ordinaire :

zsh -l
  └─ just agent
      └─ /bin/sh -cu 'npm run agent -- --mode write'
          └─ npm run agent -- --mode write
              └─ sh -c node ./scripts/launch-agent.js --mode write
                  └─ node ./scripts/launch-agent.js --mode write
                      └─ agent-cli --mode write

Chaque processus intermédiaire a une fonction légitime. just sélectionne une recette. /bin/sh interprète son contenu. npm sélectionne un script de paquet et démarre un shell. Node évalue le script de lancement. Pourtant, aucun de ces noms n'indique au réviseur si la requête protégée vient d'une exécution connue de l'agent ou d'une autre commande qui utilise par hasard le même environnement d'exécution.

Ne supprimez pas les couches intermédiaires du journal d'audit. C'est précisément là qu'une analyse trouvera un script de paquet modifié, un hook de cycle de vie pre ou post inattendu, un PATH altéré ou un script de dépôt qui a remplacé un autre exécutable. Réduisez-les dans l'affichage d'approbation uniquement après les avoir conservées dans un enregistrement d'événement immuable.

Une règle d'affichage raisonnable consiste à :

1. Placer en premier l'exécutable du demandeur et ses arguments.
2. Afficher le lanceur direct lorsqu'il modifie l'interprétation, par exemple npm run deploy-agent ou make migration-bot.
3. Nommer le premier ancêtre signé reconnaissable comme autorité de lancement.
4. Garder l'ascendance observée complète accessible dans le détail de l'événement.

Cette règle évite deux mauvaises habitudes. La première consiste à masquer tous les wrappers, ce qui rend invisible une tâche modifiée. La seconde consiste à afficher un arbre de sept lignes avant que le réviseur ait pu comprendre la requête. Face à des cartes d'approbation illisibles, les utilisateurs approuvent la forme de la carte, pas l'action.

Je rejette une recommandation fréquente : approuver l'exécuteur de tâches plutôt que l'agent parce que le nom de la tâche est plus facile à reconnaître. Les noms de tâches sont souvent du texte provenant du dépôt. Toute personne capable de modifier la copie de travail peut peut-être modifier le comportement de la tâche. Utilisez le nom de la tâche comme contexte, mais liez la session d'approbation à l'exécution observée du processus de l'agent et réévaluez-la lorsqu'une nouvelle exécution commence.

Choisir soigneusement la limite signée

L'ancêtre signé le plus proche est généralement la meilleure autorité reconnaissable, mais « le plus proche » demande du discernement. Un shell système ou un interpréteur signé peut se trouver directement au-dessus d'un script non signé. Appeler ce shell l'autorité produit une étiquette techniquement signée qui ne dit rien de la personne ayant fourni le code.

Les recommandations d'Apple sur la signature du code distinguent l'identifiant d'un exécutable de son identité de signature et utilisent une exigence désignée pour établir l'identité du code. L'outil codesign peut afficher cette exigence. Utilisez sa sortie pour identifier une application ou un assistant signé, mais ne considérez pas une chaîne d'identifiant seule comme la preuve d'une relation avec un éditeur.

Pour une application intégrée, inspectez l'exécutable ou le bundle d'application qui apparaît dans l'ascendance :

codesign --display --verbose=4 --requirements - "/Applications/Example.app" 2>&1 \
  | sed -n '/Identifier=/p;/TeamIdentifier=/p;/Authority=/p;/designated =>/p'

Un résultat typique contient des champs de cette forme :

Identifier=com.example.editor
TeamIdentifier=AB12CDE345
Authority=Developer ID Application: Example Software (AB12CDE345)
designated => anchor apple generic and identifier "com.example.editor" and certificate leaf[subject.OU] = "AB12CDE345"

Les champs exacts varient selon la signature et le mode de distribution. L'essentiel est que votre système d'approbation enregistre une identité de code stable lorsque macOS peut en fournir une, puis affiche une version compréhensible par le réviseur sans masquer les preuves brutes.

Suivez ces règles pour choisir l'autorité affichée :

• Préférez une application graphique signée ou un assistant signé dédié qui fait réellement partie de l'ascendance du demandeur.
• N'utilisez pas un interpréteur générique signé pour remplacer le script non signé qu'il a exécuté.
• Ne déduisez pas l'autorité à partir du répertoire de l'exécutable, du nom du dépôt ou de l'invite du shell.
• Signalez clairement les étapes non signées et signées ad hoc au lieu de les enfouir sous un parent reconnaissable.
• Si aucune autorité signée reconnaissable n'existe, indiquez que l'exécution ne possède pas d'identité d'éditeur local vérifiée.

Un processus peut avoir plusieurs signatures au sens conceptuel : celle du bundle d'application, celle d'un assistant imbriqué et celle d'un interpréteur. Examinez l'exécutable qui apparaît réellement dans la liste des processus. Une application signée peut lancer un assistant signé séparément. Un assistant peut lancer un binaire installé par l'utilisateur. Chacun constitue une question d'identité distincte.

Certaines chaînes de lancement doivent réduire la confiance

Une chaîne parent-enfant propre n'est pas toujours disponible, et les cas manquants ne sont pas anecdotiques. C'est là que les systèmes d'approbation commettent généralement leurs plus graves erreurs d'attribution.

L'exécution distante rompt l'ascendance locale

Si un agent local invoque SSH, votre Mac peut identifier le client SSH local et ses parents. La commande distante possède un arbre de processus distinct sur un autre hôte. N'affirmez pas qu'un agent-cli distant a été lancé par un IDE local sans recueillir et vérifier des preuves sur cette machine distante.

La carte d'approbation locale peut malgré tout être utile. Elle peut nommer le demandeur local, la destination, le compte distant s'il est connu et la commande exacte transmise à SSH. Cela suffit pour décider si l'agent local peut ouvrir la connexion. Cela ne suffit pas pour établir l'identité du processus distant.

Le travail détaché exige une nouvelle décision d'identité

Un enfant peut appeler setsid, effectuer un double fork ou demander à un superviseur de poursuivre le travail après la fin de son lanceur initial. Dans ce cas, une approbation liée uniquement au terminal ou au shell initial devient fictive. Le worker détaché a besoin de son propre enregistrement de processus, de sa propre heure de démarrage et d'une nouvelle portée d'approbation, sauf si vous avez conçu une relation de supervision explicite que les réviseurs peuvent inspecter.

L'héritage de l'environnement peut changer l'acteur sans modifier l'arbre

Le même chemin node peut charger un autre paquet d'agent parce que PATH, NODE_OPTIONS, les chemins de modules propres au langage, les paramètres de proxy ou le répertoire de travail ont changé. L'ascendance des processus n'affiche pas toutes les valeurs héritées. Pour l'analyse, capturez une empreinte de contexte limitée : chemin de l'exécutable, arguments, répertoire courant, noms et valeurs sélectionnés de l'environnement après masquage et condensat de l'exécutable lorsque cela correspond à votre modèle.

Ne versez pas tout l'environnement dans une carte d'approbation ou un journal. Les environnements contiennent souvent des jetons, des points de terminaison et des chemins personnels. L'objectif est de distinguer les exécutions, pas de créer un second coffre de secrets dans les journaux.

Le réviseur a besoin d'une conclusion courte et de preuves consultables

Une demande d'approbation ne dispose que de quelques secondes pour retenir l'attention. Placez en haut la conclusion pertinente pour la décision, puis donnez au réviseur un moyen d'inspecter la raison pour laquelle le système l'a formulée.

Une carte pratique peut afficher :

Agent process requests an HTTP call

Requester
agent-cli --workspace /Users/maya/src/payments
PID 81234, started 14:08:31

Launched through
npm run agent > node scripts/launch-agent.js
from a signed editor process

Destination
api.example.internal / POST /deployments

C'est assez compact pour être lu et assez précis pour être contesté. Un réviseur peut le refuser parce que l'espace de travail est incorrect, que l'exécuteur de tâches est inattendu, que la destination surprend ou que la requête vient d'une étape non signée. Ce sont de vraies raisons d'arrêter l'action.

Conservez toutes les preuves derrière la carte. Préservez le PID et l'heure de démarrage du demandeur, le chemin de l'exécutable, les arguments, la chaîne de parents, les éléments de signature de l'autorité choisie et la décision d'approbation. Si le même agent effectue ensuite une autre requête dans l'exécution approuvée, l'enregistrement doit montrer clairement que la décision de session s'appliquait à la durée de vie de ce processus, et non à un nom d'application détaché de tout processus.

L'autorisation par session de Sallyport repose sur cette limite pratique : le premier appel d'un nouveau processus d'agent demande une approbation, qui ne dure que jusqu'à la fin de ce processus. Sa carte d'approbation commence par l'autorité de signature du code du processus. Elle fournit ainsi au réviseur un point de départ reconnaissable sans prétendre que la signature explique chaque commande enfant.

Révoquer selon la durée de vie du processus, puis expliciter les exceptions

Une approbation de session doit suivre la durée de vie du processus de l'agent, puisque c'est lui qui a effectué la requête. Réutiliser une approbation parce qu'un terminal reste ouvert, qu'une fenêtre d'IDE reste visible ou qu'une tâche porte le même nom crée une portée d'approbation que personne ne peut inspecter honnêtement.

Cette règle crée effectivement des frictions pour les wrappers de courte durée. Un gestionnaire de paquets peut démarrer un nouveau processus d'agent pour chaque sous-commande. Ne corrigez pas cela en élargissant discrètement l'approbation à tous les futurs enfants de npm ou à tous les processus du terminal. Déterminez si le workflow a besoin d'un hôte d'agent stable et signé, d'un processus de plus longue durée exposant une identité claire ou d'une confirmation à chaque appel pour l'identifiant sensible.

L'approbation par appel est adaptée lorsque le risque se situe dans chaque utilisation plutôt que dans l'identité de lancement. Un jeton de déploiement de production, une clé privée SSH donnant accès à un hôte sensible ou une API d'administration capable d'écrire peuvent justifier une décision humaine à chaque utilisation, même lorsque l'identité du processus est familière. Reconnaître le processus réduit la confusion. Cela ne remplace pas le jugement.

Le test d'implémentation est simple : arrêtez le processus approuvé, relancez la même commande et vérifiez que la seconde exécution demande sa propre approbation. Lancez ensuite une commande différente dans le même onglet de terminal et vérifiez qu'elle ne peut pas hériter de la décision de la première exécution. Si l'un des tests échoue, le système a approuvé un emplacement ou une étiquette au lieu d'un acteur.

Le réviseur ne devrait jamais avoir à considérer le nom d'un terminal comme un substitut à l'identité d'un processus. Conservez la chaîne, identifiez l'exécution qui a effectué la requête, affichez l'autorité reconnaissable la plus solide que vous puissiez défendre et laissez les preuves manquantes rester visibles. C'est moins séduisant qu'une règle générale d'« IDE de confiance ». C'est aussi ce qui résiste lorsqu'un script de tâche, un wrapper shell ou un saut distant se révèle être l'élément qui comptait.