Une reprise de session d'agent doit-elle conserver son ancienne autorisation ?

Une conversation d'agent reprise ne doit jamais hériter d'une autorité simplement parce qu'elle a hérité d'un texte. Le modèle peut toujours avoir le même plan, le même historique d'outils et le même ton assuré. Rien de tout cela ne permet de savoir si le processus qui demande l'accès est celui que vous avez autorisé, si le coffre d'identifiants est disponible ou si la passerelle conserve encore une trace fiable de l'autorisation.

Considérez une reprise comme une affirmation de continuité à vérifier, pas comme un droit que le client peut revendiquer. Si l'identité du processus, l'état du coffre ou l'état de la passerelle ont changé, l'ancienne décision a pris fin. Demandez une nouvelle autorisation avant l'action protégée suivante.

Cela peut sembler strict jusqu'à ce que l'on observe les redémarrages dans le travail réel. Un agent de programmation se met à jour. Un éditeur relance son assistant après un plantage. Un utilisateur arrête un processus bloqué et en démarre un nouveau. Un ordinateur se met en veille pendant que le coffre se verrouille. Une application de barre des menus redémarre après une mise à niveau. La conversation se reconnecte souvent si facilement que l'utilisateur voit un seul fil ininterrompu. Un code de sécurité qui traite ce fil comme une autorité réunira discrètement plusieurs exécutions dans une seule autorisation.

Une conversation reprise ne transporte pas d'autorité

Une conversation fournit un contexte, tandis qu'une autorisation est une décision concernant un acteur présent qui tente une action présente. Ces deux notions doivent rester séparées.

Les systèmes d'agents stockent souvent un identifiant de conversation à longue durée, une transcription et parfois un historique des appels d'outils. Ces éléments sont utiles pour reprendre le travail après une déconnexion. Ils indiquent à l'agent ce qu'il essayait de faire, quels fichiers il a modifiés et quelle requête d'API a échoué en cours de route. Ils n'identifient pas le processus du système d'exploitation actuellement relié aux outils.

Prenons une séquence courante. Un agent prépare une requête de déploiement et reçoit une autorisation de session. La passerelle redémarre avant l'envoi de la requête. Le client de l'agent se reconnecte, charge l'ancienne transcription et affirme reprendre la même exécution. Si la passerelle accepte cette affirmation et restaure l'autorisation précédente, celle-ci couvre désormais un processus que la passerelle n'a pas inspecté depuis son redémarrage.

Le nouveau processus peut être inoffensif. Il peut aussi s'agir d'une version nouvellement installée, d'un exécutable intermédiaire lancé depuis un autre répertoire ou d'un second client d'outil qui a trouvé un jeton de reprise mis en cache. La conversation ne permet pas de distinguer ces cas.

C'est pourquoi « l'utilisateur a déjà autorisé cette tâche » est le mauvais test. Un utilisateur autorise une exécution d'agent identifiable dans des conditions définies. L'autorisation prend fin lorsque ces conditions ne sont plus réunies ou ne peuvent plus être prouvées.

Le Model Context Protocol rend cette distinction plus visible. Sa documentation de transport indique que, pour stdio, le client lance le serveur comme sous-processus et échange des messages JSON-RPC via l'entrée et la sortie standard. Il s'agit d'une relation entre processus actifs, pas d'une autorisation durable stockée dans une transcription. Le journal des modifications de MCP a également supprimé les sessions au niveau du protocole dans les travaux récents sur Streamable HTTP et oriente les serveurs avec état vers des handles explicites générés par le serveur. Cette évolution ne résout pas à elle seule l'autorisation, mais elle évite de faire passer un identifiant de session de transport pour un identifiant d'autorité.

Gardez ces termes distincts dans votre conception :

• Une conversation est un enregistrement applicatif qui peut survivre aux processus.
• Un processus est une instance du système d'exploitation avec une durée de vie limitée.
• Une autorisation de session est une autorisation accordée à un processus identifié pendant cette durée de vie.
• L'utilisation d'un identifiant est une action qui doit respecter les conditions actuelles du coffre et de la passerelle.

Les équipes mélangent ces notions parce qu'une démonstration réussie donne l'impression que les quatre évoluent ensemble. Les redémarrages en production les séparent.

L'identité d'un processus comporte plusieurs éléments

Un identifiant de processus seul est trop faible pour lier durablement une autorisation, car les systèmes d'exploitation peuvent réutiliser les identifiants après la fin d'un processus. Un chemin de processus seul est trop faible, car le fichier situé à ce chemin peut changer. Une signature de code seule est trop faible, car le même programme signé peut s'exécuter à plusieurs endroits en même temps.

Construisez l'identité que vous affichez et à laquelle vous liez l'autorisation à partir de plusieurs éléments recueillis au moment de l'autorisation. Sur macOS, le meilleur point de départ est le processus en cours, l'identité de son exécutable et son autorité de signature du code. Apple décrit les designated requirements comme l'exigence de code qui identifie un code signé. Elle est souvent construite à partir de l'autorité de signature et de l'identifiant intégré lorsque l'application n'en a pas fourni explicitement. L'utilisateur dispose ainsi de quelque chose de plus utile qu'un simple PID à examiner.

Ne transformez toutefois pas une autorité de signature en réponse magique. Deux processus distincts ayant la même designated requirement restent deux processus distincts. Un agent signé peut lancer un assistant non signé. Un binaire de développement compilé localement peut avoir une signature ad hoc. Un attaquant qui prend le contrôle du processus autorisé après l'autorisation ne devient pas fiable parce que la signature d'origine semblait correcte.

Utilisez une liaison de processus fondée sur des éléments qui ont un sens ensemble :

approval_subject = {
  process_id: 48192,
  process_start_time: "2026-07-22T14:18:03Z",
  executable_file_id: "volume:.../inode:...",
  executable_hash: "sha256:...",
  signing_requirement: "anchor ... and identifier ...",
  parent_process_id: 48001,
  launch_nonce: "random-128-bit-value"
}

Les champs exacts varient selon la plateforme. La règle, elle, ne change pas : la passerelle doit disposer de suffisamment de preuves pour refuser une ancienne autorisation lorsque son ancien sujet n'existe plus. Le nonce de lancement est important, car il est fourni par la passerelle après inspection du nouveau processus. Un client ne peut pas le restaurer de manière fiable depuis un cache local et appeler cela de la continuité.

Il n'est pas nécessaire d'afficher tous les champs à l'utilisateur. En pratique, cela rend généralement la carte d'autorisation moins claire. Affichez l'autorité de signature, le nom de l'exécutable et une description claire du canal d'action. Conservez la liaison complète dans le journal pour un examen ultérieur.

Il existe une limite importante qu'il faut énoncer clairement. Si votre passerelle ne peut pas voir ni attester le processus qui effectue la requête, elle ne peut pas accorder une autorisation spécifique à ce processus. Elle peut encore accorder une autorisation plus limitée liée à un autre sujet digne de confiance, mais elle ne doit pas prétendre avoir vérifié le processus. Appeler « identité » un nom de processus fourni par le client est la manière dont les conceptions fragiles se donnent des appellations officielles.

Un redémarrage du processus met fin à l'autorisation de session

Une autorisation de session doit prendre fin lorsque son processus se termine, même si le processus de remplacement possède un code, des arguments et un historique de conversation identiques.

Cette règle permet de gérer des cas qui semblent anodins jusqu'à ce qu'ils causent des dégâts. Supposons qu'un agent fonctionne sous une extension d'éditeur. L'extension plante, son superviseur en démarre une nouvelle et celle-ci recharge l'ancien état de la tâche. Le nouveau processus utilise le même répertoire de projet et probablement le même compte utilisateur. Il ne possède pas l'autorité accordée au processus qui a planté.

Il en va de même lorsqu'un agent crée un processus fils. Un processus parent peut recevoir une autorisation, puis lancer un assistant pour exécuter des commandes shell ou effectuer des appels réseau. Si l'autorisation ne s'applique qu'au parent, l'assistant doit soit agir par l'intermédiaire du parent dans le cadre d'une délégation contrôlée, soit demander sa propre autorisation. Transmettre un jeton bearer dans l'arbre des processus rend l'autorisation portable, exactement ce que vous cherchez à éviter.

Ne tentez pas de corriger cela avec une longue durée d'expiration. Une autorisation de cinq minutes que n'importe quel processus de remplacement peut reprendre n'est pas une autorisation de session de cinq minutes. C'est un identifiant bearer valable cinq minutes, avec une appellation rassurante.

Une meilleure règle est simple :

if current.process_id != approved.process_id:
    deny("approval belongs to a different process")

if current.process_start_time != approved.process_start_time:
    deny("process lifetime changed")

if current.launch_nonce != approved.launch_nonce:
    deny("gateway has not bound this run")

La passerelle doit effectuer cette vérification avant de décider si une requête peut bénéficier de l'autorisation de session. Ne la faites pas uniquement lors de la reconnexion de l'agent. Un processus peut changer dans une architecture client qui multiplexe le travail, et un objet d'autorisation obsolète peut rester plus longtemps que prévu en mémoire.

Un utilisateur peut objecter que le processus de remplacement est manifestement le même agent. Il demande généralement une carte d'autorisation plus fluide, pas une raison d'effacer la limite. Expliquez que l'agent a redémarré et affichez le nouveau signataire. Un clic volontaire coûte moins cher qu'une enquête sur un appel de production inattendu provenant d'un processus non inspecté.

Un changement d'état du coffre supprime le droit d'agir

L'état du coffre n'est pas un détail secondaire. Lorsqu'un coffre se verrouille, toute décision précédente qui dépendait de sa disponibilité doit cesser d'accorder l'autorisation pour les actions nécessitant des identifiants.

Deux échecs doivent être évités. Le premier est évident : une passerelle continue d'utiliser un identifiant déchiffré après le verrouillage du coffre. Le second est plus discret : la passerelle met en file une action nécessitant un identifiant alors que le coffre est verrouillé, puis l'exécute automatiquement lorsqu'il est déverrouillé parce qu'une ancienne autorisation de session existe encore. Ce deuxième échec transforme un déverrouillage humain ultérieur en autorisation accidentelle d'une requête antérieure.

La documentation d'Apple sur le Keychain définit clairement cette limite. Les contrôles d'accès peuvent exiger la présence de l'utilisateur lorsqu'une application tente de récupérer un élément, et Apple recommande de choisir le réglage d'accessibilité le plus restrictif compatible avec l'application. Le Secure Enclave peut contrôler des opérations cryptographiques sans exposer les données biométriques sous-jacentes aux logiciels de l'espace utilisateur. Ces mécanismes sont utiles, mais ils ne définissent pas la sémantique de votre passerelle. Votre application doit décider ce qui arrive aux exécutions d'agents déjà autorisées lorsque cette barrière se ferme.

La réponse la plus sûre consiste à maintenir une époque du coffre. Incrémentez-la chaque fois que le coffre se verrouille, se déverrouille, est réinitialisé ou perd sa session protégée. Ajoutez cette époque à chaque enregistrement d'autorisation. Une différence signifie que l'enregistrement ne peut pas autoriser une action nécessitant un identifiant.

approved_vault_epoch = 17
current_vault_epoch = 18

if approved_vault_epoch != current_vault_epoch:
    require_new_session_approval()

Cela ne signifie pas que chaque déverrouillage doit déclencher une cérémonie agaçante. Si l'agent n'a aucune session active, rien ne se passe. Si une requête nécessite un identifiant après le déverrouillage, la passerelle peut afficher une nouvelle carte d'autorisation indiquant la raison : l'état du coffre a changé après l'autorisation précédente. Pour les identifiants qui nécessitent une autorisation à chaque utilisation, conservez également la vérification par appel. L'autorisation de session et l'autorisation par appel répondent à des questions différentes.

L'autorisation de session demande si ce processus identifié peut utiliser ce canal pendant son exécution actuelle. L'autorisation par appel demande si l'utilisateur veut cette utilisation précise maintenant. Traiter l'autorisation de session comme un remplacement de la décision par appel annule l'intérêt de marquer un identifiant de cette manière.

Le redémarrage d'une passerelle efface le souvenir de l'autorisation

Un redémarrage de passerelle doit invalider les autorisations de session conservées en mémoire, car la passerelle redémarrée ne peut pas prouver que son ancien enregistrement d'autorisation possède encore une liaison complète et intacte avec le monde réel.

Certaines équipes conservent les jetons d'autorisation et les rechargent après un redémarrage. La motivation est compréhensible : l'utilisateur n'a cliqué qu'une fois, l'agent travaille toujours et un redémarrage ne devrait pas faire échouer le flux. Mais un jeton persistant devient souvent un identifiant réutilisable. Le client le renvoie après reconnexion, la passerelle le reconnaît et l'ancienne autorisation revient sans nouvelle inspection du processus.

Cette conception rend aussi la récupération ambiguë. La passerelle a-t-elle planté avant l'envoi de l'action ? A-t-elle envoyé l'action puis planté avant d'enregistrer la réponse ? Le service distant a-t-il reçu deux fois la requête après une nouvelle tentative ? Restaurer l'autorisation et réessayer la requête comme une seule opération mélange la récupération de l'identité et la récupération de la livraison. Ces deux problèmes nécessitent des contrôles différents.

Attribuez à chaque durée de vie de passerelle un identifiant de démarrage qui n'existe que dans sa mémoire actuelle. Ajoutez-le à chaque enregistrement d'autorisation. Après un redémarrage, l'identifiant actuel diffère, donc aucun ancien enregistrement de session ne peut correspondre.

approval = {
  gateway_boot_id: "b7f9...",
  process_binding: "...",
  vault_epoch: 17,
  approved_at: "2026-07-22T14:20:11Z"
}

if approval.gateway_boot_id != gateway.current_boot_id:
    require_new_session_approval()

La passerelle peut conserver un événement d'audit indiquant qu'une autorisation a eu lieu. Elle ne doit pas recharger cet événement comme une autorisation active. L'historique d'audit explique ce qui s'est passé, mais ne recrée pas une relation d'autorité active.

Sallyport suit cette logique en conservant le coffre dans l'application signée de la barre des menus et en refusant les actions lorsque le coffre est verrouillé. Son autorisation par session est liée à un nouveau processus d'agent, et l'utilisateur peut révoquer immédiatement une exécution enregistrée. Ces limites ne sont utiles que si un redémarrage ou un verrouillage ne peut pas rattacher discrètement une ancienne exécution à une nouvelle décision.

Liez l'autorisation à des preuves que le client ne peut pas rejouer

L'enregistrement d'autorisation a besoin de preuves actuelles créées par le serveur. Un jeton de reprise fourni par le client peut aider la passerelle à retrouver une conversation ou à afficher un libellé utile, mais il ne peut pas prouver que l'autorisation reste valide.

Le modèle pratique le plus simple utilise quatre valeurs qui changent :

1. La passerelle crée un identifiant de démarrage aléatoire au lancement.
2. La passerelle crée un nonce d'exécution aléatoire après avoir identifié un processus nouvellement connecté.
3. Le coffre maintient une époque qui change chaque fois que sa disponibilité protégée change.
4. La passerelle crée un identifiant d'autorisation uniquement après que l'utilisateur a autorisé l'exécution identifiée.

La passerelle évalue ensuite chaque action par rapport à toutes les valeurs qu'elle possède. Le client peut demander une action, mais il ne peut pas fabriquer une autorisation qui corresponde à un nouvel identifiant de démarrage ou à un nouveau nonce d'exécution.

Voici un modèle d'état compact que les équipes peuvent adapter. Il conserve volontairement la référence de conversation comme contexte d'affichage, jamais comme champ d'autorisation.

{
  "run": {
    "conversation_ref": "worktree-cleanup-42",
    "process": {
      "pid": 48192,
      "started_at": "2026-07-22T14:18:03Z",
      "signing_requirement": "recorded-at-approval",
      "launch_nonce": "gateway-generated"
    }
  },
  "approval": {
    "id": "gateway-generated",
    "gateway_boot_id": "gateway-generated",
    "vault_epoch": 17,
    "expires_when_process_exits": true
  }
}

Remarquez ce qui manque : aucun indicateur réutilisable resume_authorized ni horodatage d'expiration qui pourrait transformer un processus mort en sujet actif. Vous pouvez conserver un délai court comme limite supplémentaire, mais le délai n'est pas une identité.

Lorsque l'agent se reconnecte, demandez-lui de répéter l'initialisation et l'enregistrement du processus. La passerelle doit alors renvoyer l'un des résultats suivants :

REAUTH_REQUIRED process_changed
REAUTH_REQUIRED gateway_restarted
REAUTH_REQUIRED vault_state_changed
RETRY_SAFE previous_action_not_started
STATUS_UNKNOWN inspect_activity_journal

La distinction entre RETRY_SAFE et STATUS_UNKNOWN est importante. Une passerelle ne peut dire qu'une action n'a pas commencé que si elle dispose de preuves durables qu'elle n'a pas commencé. Si elle a perdu l'alimentation après avoir remis une requête HTTP à la pile réseau, la réponse honnête peut être inconnue. L'agent doit examiner la destination ou le journal avant de tenter une action en double.

Réessayer une action est différent de restaurer une autorisation

Un protocole de reconnexion doit d'abord restaurer la communication, établir ensuite une nouvelle autorité, puis décider s'il faut réessayer. Combiner ces étapes produit des requêtes en double et des autorisations héritées.

Utilisez cette séquence pour une action protégée dont la connexion est perdue :

1. L'agent se reconnecte et initialise une nouvelle relation avec la passerelle.
2. La passerelle identifie le processus actuel et le compare à tout enregistrement d'exécution existant.
3. La passerelle vérifie son identifiant de démarrage et l'époque actuelle du coffre.
4. Si un élément d'autorité a changé, la passerelle demande une nouvelle autorisation de session avant d'utiliser les identifiants.
5. La passerelle indique si elle sait que l'action précédente n'a pas commencé, qu'elle est terminée ou que son état est inconnu.

L'ordre compte. Ne demandez pas à l'agent de renvoyer la requête d'origine avant d'avoir établi l'autorisation actuelle. Vous donneriez ainsi à un client en reconnexion l'occasion de faire pression autour d'une ancienne requête : « J'étais déjà autorisé, terminez-la simplement. » Un humain voit souvent les mêmes mots et suppose qu'il s'agit d'une continuation sans risque. La passerelle doit rendre la condition modifiée visible avant de présenter l'action.

Pour les API HTTP, utilisez une clé d'idempotence lorsque la destination la prend en charge. Générez la clé pour l'action métier logique, enregistrez-la durablement avant l'envoi et réutilisez-la uniquement après avoir rétabli l'autorisation pour la nouvelle tentative. Une clé d'idempotence aide le service distant à détecter une livraison en double. Elle n'autorise pas la nouvelle tentative.

Pour SSH, les nouvelles tentatives demandent davantage de prudence, car une commande distante peut avoir partiellement modifié une machine avant la rupture de connexion. Préférez les opérations qui écrivent un marqueur explicite ou interrogent l'état existant avant de le modifier à nouveau. Une commande comme mkdir peut être rendue plus sûre avec une vérification du répertoire attendu. Une commande qui fait tourner un identifiant ou redémarre un service doit généralement signaler un état inconnu après une défaillance du transport, jusqu'à ce que l'agent lise l'état distant.

Ne masquez pas cette incertitude derrière un langage optimiste. Un agent qui affirme « déploiement terminé » après avoir perdu la réponse fabrique une certitude. Le journal doit indiquer que le résultat de l'action n'a pas été observé, et l'agent doit enquêter.

Les échecs difficiles révèlent la bonne limite

Le test le plus révélateur n'est pas une reconnexion propre. C'est un redémarrage au milieu d'une action, suivi d'un agent qui tente résolument de continuer.

Imaginez un agent qui dispose d'une autorisation de session pour mettre à jour un outil de suivi des problèmes via une API HTTP. Il prépare une requête, reçoit l'autorisation et appelle la passerelle. La passerelle injecte l'identifiant et commence à envoyer la requête. À cet instant, l'application de la passerelle redémarre. L'agent se reconnecte avec son ancienne référence de conversation et l'état local mis en cache de son outil.

Une conception fragile accepte l'ancienne référence, restaure l'autorisation et réessaie la requête. Le problème peut recevoir deux commentaires. Pire encore, l'autorisation s'applique au processus qui fournit maintenant l'état mis en cache, quel qu'il soit.

Une conception rigoureuse produit un résultat moins spectaculaire. La passerelle redémarrée crée un nouvel identifiant de démarrage. Elle refuse l'ancienne autorisation de session. Elle demande l'autorisation du processus actuellement connecté. Elle vérifie le journal d'activité. Si le journal indique qu'une requête est terminée, elle en renvoie le résultat. S'il indique qu'aucune requête n'a quitté la passerelle, elle autorise une nouvelle tentative approuvée. Si l'action a franchi la limite de livraison mais que le résultat a été perdu, elle signale un état inconnu. L'agent lit le problème avant de décider si une autre écriture est nécessaire.

Cela demande plus de travail que de faire confiance au jeton de reprise. C'est aussi ce qui distingue un système d'actions traçable d'un système qui dissimule l'ambiguïté jusqu'à ce qu'un utilisateur découvre des modifications en double.

Testez au moins les cas suivants avant de considérer votre comportement de reprise comme sûr :

• Tuez l'agent après l'autorisation, puis démarrez un remplacement qui présente la même référence de conversation.
• Redémarrez la passerelle alors qu'un agent autorisé reste actif et tente un autre appel nécessitant un identifiant.
• Verrouillez puis déverrouillez le coffre pendant qu'un agent autorisé attend une nouvelle tentative.
• Démarrez deux processus d'agent signés identiques et vérifiez que l'autorisation de l'un ne couvre pas l'autre.
• Supprimez la réponse réseau après le début d'une requête externe par la passerelle, puis vérifiez que le chemin de nouvelle tentative signale l'incertitude de livraison.

Ces tests détectent une erreur particulièrement fréquente : les ingénieurs vérifient seulement que le client légitime peut récupérer son état. Ils ne vérifient pas qu'un autre client peut emprunter le chemin de récupération.

Les journaux doivent expliquer pourquoi l'autorité a pris fin

Un journal d'audit doit enregistrer les changements d'autorité comme des événements à part entière, au lieu de laisser l'enquêteur les déduire des écarts entre les appels d'outils.

Enregistrez l'autorisation de session avec les éléments d'identité du processus utilisés, l'identifiant de démarrage de la passerelle, l'époque du coffre et le sujet visible par l'utilisateur. Enregistrez l'événement de fin avec une raison précise : processus terminé, différence d'identité du processus, passerelle redémarrée, coffre verrouillé, révocation manuelle ou autorisation expirée. Enregistrez séparément une action refusée et une action absente. Ce sont deux faits différents.

Une séquence d'activité utile ressemble à ceci :

14:20:11 session_approved run=R31 signer="Example Developer ID" boot=B8 vault=17
14:23:04 gateway_restarted previous_boot=B8 current_boot=C2
14:23:06 action_denied run=R31 reason=gateway_restarted
14:23:09 session_approved run=R32 signer="Example Developer ID" boot=C2 vault=17
14:23:12 http_action_started run=R32 request=Q44
14:23:13 http_action_result run=R32 request=Q44 status=201

L'objectif n'est pas d'exposer les secrets ni le contenu complet des requêtes dans chaque entrée du journal. Il est de préserver la chaîne causale : qui a demandé, quelle autorité s'est appliquée, quel état a changé et si la passerelle a réellement effectué l'action.

Les preuves d'altération sont importantes, car un historique d'autorisations n'est utile que si quelqu'un peut détecter une réécriture ultérieure. Sallyport produit ses journaux Sessions et Activity à partir d'un journal d'audit chiffré, chaîné par hachage et inscriptible sans possibilité de lecture, et sp audit verify peut vérifier cette chaîne hors ligne sur le texte chiffré, sans clé de coffre. Un examinateur peut ainsi vérifier la séquence sans ouvrir les secrets qui ont servi aux actions.

Ne demandez pas à un journal d'audit de faire le travail de prévention. Un enregistrement parfait indiquant qu'une ancienne autorisation a été réutilisée est la preuve d'une mauvaise décision, pas sa correction. La passerelle active doit refuser l'action avant l'injection des identifiants lorsque sa liaison ne correspond plus.

Une nouvelle autorisation doit être assez précise pour justifier l'interruption

Une nouvelle autorisation après un changement important d'état est justifiée, mais un prompt vague apprend aux utilisateurs à cliquer machinalement. La carte d'autorisation doit indiquer ce qui a changé et qui demande l'accès maintenant.

Évitez un message générique comme « Session expirée. Autoriser à nouveau ? » Cette formulation pousse l'utilisateur à considérer l'événement comme un simple délai. Montrez plutôt la condition qui a rompu la continuité : « La passerelle a redémarré. Autorisez ce processus nouvellement connecté à utiliser l'API d'hébergement Git pour cette exécution. » Si l'identité du processus a changé, affichez la nouvelle autorité de signature ou indiquez que le programme n'est pas signé. Si le coffre s'est verrouillé, précisez que son déverrouillage n'a pas restauré l'autorisation précédente de l'agent.

C'est également le moment de décider si l'autorisation de session est trop large pour un canal. Si un agent repris veut modifier une machine de production via SSH, une autorisation par appel peut être le choix raisonnable, même après une nouvelle décision de session. Le fait que la session ait franchi toutes les vérifications ne rend pas chaque commande aussi sûre.

N'essayez pas de réduire la fatigue décisionnelle en rendant les autorisations transférables. Réduisez-la en limitant les changements inutiles, en affichant une identité de processus stable lorsqu'elle existe et en gardant la portée de chaque décision compréhensible. L'utilisateur peut autoriser une demande concrète. Il ne peut pas autoriser en toute sécurité la promesse que n'importe quel futur processus disposant d'une ancienne transcription pourra agir.

La règle d'implémentation tient sur un pense-bête : conservez le contexte lors d'une reprise, mais reconstruisez l'autorité à partir de preuves réelles. Lorsque le processus, le coffre ou la passerelle change, l'ancienne autorisation appartient à l'exécution précédente.