# L'autorité d'un agent après la mise en veille et le réveil d'un Mac

Un processus d'agent approuvé ne devrait pas conserver son autorité simplement parce qu'un Mac s'est réveillé avec les mêmes processus encore en mémoire. La mise en veille, l'extinction de l'écran, le verrouillage, la fermeture du capot et le réveil sont des événements différents du système d'exploitation, mais ils soulèvent tous la même question de sécurité : la personne qui a approuvé cette exécution est-elle toujours présente et en mesure d'intervenir ?

Traitez cette question comme une décision d'autorisation, pas comme un détail de gestion de l'alimentation. Si vous laissez un agent de programmation détenir une autorisation API ou SSH, une approbation obsolète peut transformer une simple pause-café, un trajet ou une interruption nocturne en utilisation de comptes sans surveillance. La solution n'est pas un labyrinthe de règles. Il faut un petit modèle d'état, une politique d'expiration claire et des tests qui imposent les transitions délicates que l'on oublie habituellement.

## La mise en veille n'est pas un événement unique

macOS distingue la mise en veille du système de celle de l'écran. Cette distinction compte, car un écran noir ne prouve pas que votre agent s'est arrêté. Apple fournit des notifications NSWorkspace séparées pour `willSleep`, `didWake`, `screensDidSleep` et `screensDidWake`. Les notifications de mise en veille et de réveil ne contiennent aucune donnée utilisateur indiquant à votre application la raison de la transition.

Un ordinateur portable peut réduire la luminosité ou éteindre son écran tandis qu'une compilation, un transfert réseau ou un processus local continue. Un Mac de bureau peut fonctionner sans écran actif. Un portable branché sur secteur et connecté à des périphériques peut se comporter différemment du même portable sur batterie. Vous ne pouvez pas déduire une décision d'autorité du simple fait que l'écran est devenu noir.

Utilisez quatre faits distincts dans votre conception :

- **L'état de l'écran** indique si l'écran s'est mis en veille ou s'est réveillé.
- **L'état d'alimentation** indique si la machine s'est préparée à se mettre en veille ou si elle en est sortie.
- **L'état de présence de l'utilisateur** indique si la session est active, verrouillée, déconnectée ou remplacée par une autre.
- **L'état du coffre** indique si les secrets peuvent être utilisés ou non.

Les équipes regroupent souvent les trois premiers éléments dans un booléen nommé `isAwake`. Ce raccourci laisse échapper de l'autorité. Un agent peut fonctionner tandis que l'écran est en veille. Une machine peut se réveiller sur l'écran de verrouillage. L'utilisateur peut verrouiller l'écran sans mettre le système en veille. Chaque cas doit avoir son propre résultat attendu.

La bonne valeur par défaut est stricte, mais facile à expliquer : une action protégée nécessite un coffre déverrouillé et une approbation actuelle appartenant à l'époque d'autorité actuelle. Un réveil, un verrouillage, un changement de session utilisateur, une révocation manuelle ou le verrouillage du coffre peuvent faire avancer cette époque. Dès qu'elle avance, les appels de l'ancienne époque échouent.

## Le verrouillage de l'écran doit mettre fin à l'autorité interactive

Le verrouillage de l'écran est le signal le plus clair que l'approbation interactive doit s'arrêter. Le Mac peut continuer à fonctionner et un processus de terminal de longue durée peut conserver ses sockets et sa mémoire, mais l'utilisateur qui a approuvé l'action a quitté la session interactive. Continuer à envoyer des requêtes API ou des commandes SSH sur la base d'un ancien clic est difficile à justifier.

Cela ne signifie pas que chaque agent doit mourir lors du verrouillage. Arrêter le calcul local est une décision distincte. Un modèle peut continuer à lire un dépôt, compiler du code ou préparer une modification si ces actions ne nécessitent pas de passerelle utilisant des identifiants. La frontière est l'action externe. Conservez le travail, retirez l'autorité.

Cette distinction évite un choix tout ou rien. Vous n'avez pas à choisir entre un agent figé et un agent sans aucune protection. Laissez l'agent continuer les tâches sûres dans son espace de travail local, puis faites en sorte que l'appel protégé suivant renvoie un refus clair :

```text
authorization_denied
reason: authority_epoch_changed
required: unlock_vault_and_approve_session
```

Un refus utile indique à l'agent ce qui s'est passé sans divulguer de secret ni faire croire que la requête a échoué à cause du réseau. L'agent peut se mettre en pause, enregistrer le blocage et attendre l'utilisateur au lieu de réessayer sans cesse la même commande destructive.

Ne faites pas d'exception parce que le verrouillage vient d'un délai d'inactivité. C'est souvent précisément le cas où l'utilisateur a oublié que l'agent fonctionnait encore. Un verrouillage explicite et un verrouillage automatique correspondent à des intentions humaines différentes, mais aucun ne prouve que la personne reste disponible pour approuver une modification en production.

Il existe un cas limité où conserver l'autorité après un verrouillage peut se justifier : une tâche volontairement sans surveillance à laquelle une capacité distincte et très limitée a été accordée. Il doit s'agir d'un type d'exécution séparé, pas d'une exception cachée à l'approbation interactive. Si votre automatisation nocturne se comporte exactement comme un agent piloté par conversation en journée, vous n'avez pas séparé les risques.

## Un réveil commence une nouvelle époque d'autorité

Le réveil doit invalider l'approbation interactive même si le processus approuvé survit. Un processus peut se mettre en pause avant la veille puis reprendre avec le même PID, les mêmes variables d'environnement et les mêmes descripteurs de fichiers ouverts. Rien de tout cela ne prouve que l'ancienne décision humaine reste valable.

Une époque d'autorité est une valeur monotone qui marque une période continue durant laquelle une autorisation peut être valide. Lorsque le système franchit une frontière qui vous importe, incrémentez l'époque avant de servir une autre action. Le processus ne négocie pas ce changement. Il le découvre à sa prochaine requête.

Un enregistrement d'autorisation minimal peut ressembler à ceci :

```json
{
  "session_nonce": "6a018d62-2e94-4d4a-9e79-1f4e4b5ca501",
  "process_id": 84172,
  "process_start_marker": "2026-07-22T14:03:18Z",
  "signing_authority": "approved-agent-binary",
  "authority_epoch": 27,
  "approved_at": "2026-07-22T14:04:01Z",
  "per_call_approval": false
}
```

L'identifiant du processus n'est qu'un champ parmi d'autres. macOS peut réutiliser un PID après la fin d'un processus. Un simple PID devient donc dangereux si la passerelle oublie un ancien enregistrement et retrouve ensuite le même numéro. Liez l'approbation à un nonce nouveau et à une instance de processus observée. Utilisez l'autorité de signature du code comme signal d'identité de l'exécutable, puis exigez malgré tout une nouvelle approbation de session pour chaque nouvelle exécution du processus.

Lorsque votre gestionnaire d'événements reçoit `willSleep`, enregistrez l'intention de révoquer l'autorité et cessez immédiatement d'accepter de nouveaux appels protégés. Apple indique qu'un observateur peut retarder la mise en veille jusqu'à 30 secondes, mais n'utilisez pas ce délai pour terminer une file d'actions en attente. Refusez-les ou marquez-les comme interrompues. L'utilisateur n'a pas autorisé une dernière rafale d'actions pendant la fermeture du capot.

Lorsque la machine signale le réveil, faites à nouveau avancer l'époque si nécessaire et gardez la porte du coffre fermée jusqu'à ce que l'utilisateur satisfasse à la condition de déverrouillage. Cela gère les ordres d'événements imparfaits. Les événements d'alimentation sont difficiles à interpréter dans les cas limites. Mieux vaut demander une approbation supplémentaire et inoffensive que laisser passer un appel contenant un secret pendant une transition.

## La fermeture du capot mérite son propre cas de test

Pour une personne, fermer le capot d'un portable ressemble à une commande de mise en veille. Un logiciel ne doit pourtant pas supposer que ce geste physique correspond proprement à un seul événement du système d'exploitation. La source d'alimentation, les écrans externes, la station d'accueil et les réglages peuvent modifier le comportement de la machine. La seule réponse honnête consiste à tester le matériel et la configuration réellement utilisés par votre équipe.

La politique de sécurité peut rester simple : la fermeture du capot met fin à l'autorité interactive dès que vous observez une frontière associée et fiable. Dans une configuration portable normale, `willSleep` vous donne la possibilité de bloquer rapidement les nouvelles actions. Si une configuration particulière laisse le système actif après la fermeture du capot, utilisez une frontière de session utilisateur ou d'écran comme solution de repli prudente. N'attendez pas une étiquette sémantique parfaite nommée `lidClosed`. Ce qu'il faut empêcher, c'est l'utilisation d'identifiants sans surveillance.

Effectuez cet essai avec un agent qui détient une capacité utilisant des identifiants sans danger, par exemple écrire un marqueur dans une API de test ou exécuter une commande inoffensive sur un hôte SSH temporaire :

1. Démarrez un nouveau processus d'agent et approuvez sa session.
2. Vérifiez qu'un appel protégé réussit, puis laissez l'agent prêt à en effectuer un autre.
3. Fermez le capot assez longtemps pour déclencher le comportement d'alimentation attendu, puis rouvrez-le.
4. Sans déverrouiller ni approuver à nouveau, laissez l'agent réessayer l'appel protégé.
5. Vérifiez que la passerelle refuse la nouvelle tentative et enregistre la transition d'autorité avant le refus.

Répétez le même essai lorsque l'ordinateur est connecté à une station d'accueil, sur batterie et avec un écran externe si ces modes sont utilisés. Gardez le point de terminaison de test inoffensif. Le but est d'observer le comportement de l'autorité, pas de découvrir qu'un déploiement de production peut être interrompu en plein milieu.

Un échec peut ici sembler trompeusement propre : le journal d'actions ne montre aucun appel pendant la veille, puis le premier appel après le réveil réussit. C'est tout de même un échec si l'utilisateur a vu un écran de verrouillage et n'a jamais approuvé la reprise de l'exécution. Le délai écoulé est précisément le sujet du test.

## La mise en veille de l'écran est à elle seule un mauvais déclencheur de révocation

Révoquer l'autorité lors de la mise en veille de l'écran est sûr, mais peut être trop perturbant sur un Mac de bureau dont l'écran se met en veille pendant une utilisation normale. Conserver l'autorité pendant la seule mise en veille de l'écran est pratique, mais il est facile de se tromper lorsque le délai d'affichage sert aussi de signal indiquant que l'utilisateur est absent.

Choisissez une règle et rendez le compromis explicite. Pour les identifiants à fort impact, révoquez lors du verrouillage de l'écran et de la mise en veille du système, pas uniquement lors de la mise en veille de l'écran. Sur une machine où la mise en veille de l'écran précède systématiquement le verrouillage, vous pouvez révoquer dès cette étape comme protection supplémentaire, en acceptant davantage de demandes d'approbation. Le point important est de ne qualifier aucun des deux choix d'« évident ». Tout dépend du déploiement et de ce que les identifiants permettent de faire.

Les notifications séparées d'Apple pour l'écran et le système rappellent utilement qu'elles ne signifient pas la même chose. Surveillez-les toutes les deux, enregistrez-les toutes les deux et testez la politique associée à chacune.

Une matrice pratique évite que ces règles ne deviennent une affaire de tradition :

| Transition | Travail local de l'agent | Approbation de session existante | Action utilisant le coffre |\n| --- | --- | --- | --- |\n| L'écran se met en veille | Peut continuer | Selon la politique définie | Généralement suspendue, ou limitée aux usages à faible risque |\n| L'écran se verrouille | Peut continuer | Prend fin | Refusée jusqu'à une nouvelle approbation |\n| Le système commence sa mise en veille | Se met naturellement en pause | Prend fin immédiatement | Aucun nouvel appel accepté |\n| Le système se réveille sur l'écran verrouillé | Peut reprendre localement | Reste terminée | Refusée jusqu'au déverrouillage et à une nouvelle approbation |\n| L'utilisateur déverrouille | Peut continuer | Reste terminée | Une nouvelle approbation de session est nécessaire |\n
L'utilisateur déverrouille le Mac pour retrouver son bureau. Cette action ne doit pas restaurer discrètement l'ancienne autorité de l'agent. Déverrouiller un ordinateur et approuver une action externe sont liés, mais répondent à deux questions différentes.

## Les exécutions nocturnes nécessitent un contrat distinct

Une exécution nocturne ne doit pas hériter des permissions d'une session interactive de l'après-midi. Les personnes approuvent le travail interactif en regardant la différence, le terminal ou une carte de demande. Le travail nocturne est une décision explicite de laisser quelque chose avancer sans cette surveillance immédiate.

Rendez le contrat de la tâche assez limité pour pouvoir l'expliquer en une phrase. « Exécuter les tests et préparer une pull request » est compréhensible. « Faire tout ce qui est nécessaire pour terminer la tâche » n'est pas un contrat, c'est un blanc-seing.

Pour le travail sans surveillance, séparez les actions locales des actions externes. Autorisez les premières lorsqu'elles restent contenues : analyse du dépôt, modifications sur une branche, exécution des tests et génération d'artefacts. Exigez une nouvelle approbation humaine pour les effets externes sensibles, notamment une mutation d'API de production, un déploiement, la publication d'un paquet, l'écriture dans une base de données partagée ou l'accès SSH à une machine importante.

Dans certains cas, une exécution nocturne doit appeler un service externe. Utilisez alors un identifiant dédié ou un environnement de test dont le rayon d'action correspond à la tâche. Ne réutilisez pas un identifiant administrateur simplement parce qu'il existe déjà dans le coffre. L'argument courant consiste à dire que la personne a approuvé l'agent plus tôt dans la soirée. Cette approbation couvrait une exécution visible et interactive. Elle ne couvre pas ce qui reste après son endormissement.

Utilisez un budget d'actions limité si la tâche possède un objectif externe récurrent et légitime. Limitez-le par destination, méthode et effet, plutôt que par de vagues scores de confiance. Par exemple, une tâche de test sans surveillance peut être autorisée à envoyer une requête fixe vers un seul point de terminaison de préproduction, sans pouvoir changer d'hôte, de méthode HTTP ou utiliser SSH. Si la tâche a besoin de davantage, elle attend.

L'autorisation par session de Sallyport donne à chaque nouveau processus d'agent sa propre frontière d'approbation. Gardez le travail nocturne dans un processus nouvellement démarré et soumettez ses actions protégées au même contrôle que toute autre exécution sans surveillance.

## Les journaux doivent prouver le refus, pas seulement l'activité

Un enregistrement indiquant que « le Mac s'est réveillé » ne prouve pas que l'autorité a pris fin. Vous avez besoin d'éléments des deux côtés de la frontière : l'événement du système d'exploitation qui a déclenché la transition de politique et l'action protégée suivante que la passerelle a refusée.

macOS fournit un bon point de départ pour examiner l'alimentation :

```sh
pmset -g log | grep -E 'Sleep|Wake|DarkWake|Display'
```

Les lignes exactes varient selon le matériel et la version de macOS, mais la sortie doit afficher des enregistrements horodatés contenant des noms comme `Sleep`, `Wake`, `DarkWake` ou des transitions d'écran. Conservez la période correspondante de chaque essai. N'en faites pas la source de vérité pour l'autorisation, car ce journal ne connaît ni votre coffre ni l'identité de votre agent.

Votre propre journal doit répondre à une autre série de questions :

```text
14:20:16.402 session_approved process=84172 epoch=27 authority=approved-agent-binary
14:22:04.118 power_will_sleep epoch=27
14:22:04.119 authority_revoked old_epoch=27 new_epoch=28 reason=system_sleep
14:25:38.771 power_did_wake epoch=28
14:25:44.025 action_denied process=84172 request=ssh.exec reason=authority_epoch_changed
```

L'ordre compte. Si l'action apparaît avant l'entrée de révocation, vous avez découvert une condition de concurrence. Si aucune action refusée n'apparaît parce que l'agent de test s'est discrètement arrêté, vous n'avez rien prouvé au sujet d'un processus persistant. Organisez l'essai pour que le même processus de longue durée tente un appel protégé après chaque transition.

Une piste d'audit résistante à la falsification offre un second avantage : elle permet de vérifier après coup que la séquence des événements et des actions n'a pas été modifiée pour produire un récit plus présentable. Sallyport construit ses journaux Sessions et Activity à partir d'un journal d'audit chiffré, chaîné par hachage et insensible à l'écriture, et `sp audit verify` vérifie cette chaîne hors ligne sur le texte chiffré. C'est utile pour ce test, car une vérification réussie indique que la séquence enregistrée n'a pas été réécrite discrètement. Elle ne compense pas une politique de révocation faible.

## Les conditions de concurrence apparaissent aux frontières

Le problème dangereux est généralement une requête déjà en cours lorsque le Mac commence sa mise en veille ou que l'utilisateur verrouille l'écran. Une passerelle qui vérifie l'approbation uniquement lorsqu'elle accepte une connexion peut laisser une tâche en file s'exécuter après la transition d'autorité. Une passerelle qui ne vérifie qu'après avoir injecté un identifiant peut transmettre celui-ci à un utilitaire avant de constater la révocation.

Vérifiez l'autorité immédiatement avant l'opération privilégiée. Cela signifie avant l'injection d'un identifiant, avant l'ouverture d'un utilitaire SSH avec une clé utilisable et avant l'envoi de la requête HTTP. Si une opération comporte plusieurs phases privilégiées, vérifiez à nouveau à chaque phase où le système pourrait autrement franchir une frontière d'autorité.

Une structure simple ressemble à ceci :

```text
receive request
identify process and session nonce
read current authority epoch
compare request grant epoch to current epoch
check vault gate
check per-call approval when required
inject credential and execute action
append result to audit log
```

Gardez la lecture de l'époque et l'engagement à exécuter l'opération privilégiée aussi proches que possible dans votre implémentation. Une fois que des octets ont quitté le Mac, vous ne pouvez pas rendre une action HTTP distribuée parfaitement réversible. Vous pouvez empêcher une autorisation obsolète de la démarrer.

N'essayez pas de résoudre chaque cas limite en retardant la mise en veille. La notification `willSleep` permet un court délai de traitement, mais empêcher un portable de se mettre en veille pour terminer les actions de l'agent inverse les priorités. La machine quitte un état interactif. Révoquez l'accès, enregistrez l'interruption et laissez l'utilisateur décider de la reprise.

L'approbation par appel est la réponse claire pour les clés susceptibles d'avoir des effets coûteux ou irréversibles. Elle rend la mise en veille et le réveil moins critiques, puisque chaque utilisation demande déjà l'accord de l'utilisateur au moment de l'action. Ce n'est pas une raison pour ignorer la révocation de session. C'est une seconde barrière pour un groupe plus restreint d'identifiants.

## Testez les transitions que les utilisateurs effectuent réellement

Un bon plan de test ne commence pas par les tests unitaires d'un gestionnaire de notifications. Ces tests sont utiles, mais les défaillances apparaissent lors de vraies transitions d'alimentation, sur de vrais écrans de verrouillage et avec des processus d'agent qui survivent à une fenêtre de terminal.

Créez un agent de test capable d'attendre, de recevoir un signal, puis de demander une action protégée sans danger. Donnez à chaque essai un nouvel identifiant d'exécution. Notez l'attente avant de lancer le test, car sinon un résultat surprenant devient après coup un « comportement probablement normal ».

Testez au moins les cas suivants sur chaque configuration Mac prise en charge :

- Verrouillez l'écran pendant que l'agent est inactif, puis réessayez une action approuvée avant et après le déverrouillage.
- Mettez le système en veille depuis le menu Apple, réveillez-le sur un écran verrouillé, puis réessayez avec le processus d'origine.
- Laissez l'écran se mettre en veille tandis que le système reste actif, puis vérifiez que le comportement correspond à votre politique d'affichage.
- Fermez et rouvrez le capot d'un portable, sur batterie comme dans la configuration de bureau utilisée par les personnes concernées.
- Laissez une exécution d'agent volontairement longue fonctionner toute la nuit, puis examinez le journal d'alimentation, le journal d'actions et le premier appel protégé après le retour.

Utilisez une petite fiche de résultat pour chaque exécution : époque attendue, événements d'alimentation observés, survie ou non du processus d'origine, état de verrouillage du coffre et refus ou non du premier appel protégé. Cette fiche révèle une erreur fréquente : les équipes vérifient que l'application a vu l'événement, mais ne vérifient jamais que la couche d'action a refusé un appel ensuite.

Testez aussi les mauvais timings. Lancez une action protégée, verrouillez l'écran pendant qu'elle attend une réponse réseau, puis vérifiez si une nouvelle tentative ou une action de suivi s'exécute avec l'ancienne autorisation. Lancez une action juste avant la mise en veille. Déconnectez et reconnectez une station d'accueil. Redémarrez le processus d'agent après le réveil et assurez-vous qu'il ne peut pas emprunter l'enregistrement d'approbation de l'ancien processus.

Vous n'avez pas besoin d'un gigantesque moteur de politiques pour réussir ces tests. Il vous faut une porte de coffre stricte, un enregistrement d'approbation par processus, une époque révocable et un chemin d'action qui les vérifie immédiatement avant d'utiliser un identifiant.

## Écrivez la politique en termes de résultats, puis appliquez-la

Une bonne politique d'autorité tient sur une page, car elle décrit des résultats observables et non une collection d'étiquettes supposées du système d'exploitation. Indiquez ce qui arrive aux actions protégées après un verrouillage, une mise en veille, un réveil, une fermeture du capot, une déconnexion et une révocation manuelle. Précisez si le travail local peut continuer et ce que l'utilisateur doit faire pour reprendre.

Pour la plupart des agents de programmation IA interactifs, la politique devrait être formulée ainsi :

> Une action protégée nécessite un coffre déverrouillé et une approbation pour le processus actuel dans l'époque d'autorité actuelle. Le verrouillage, la mise en veille, la perte de la session utilisateur, le verrouillage du coffre et la révocation manuelle mettent fin à cette approbation. Le réveil et le déverrouillage ne la restaurent pas. L'agent doit demander une nouvelle approbation avant toute autre action protégée.

Cette règle a un coût : les utilisateurs doivent approuver à nouveau les actions lorsqu'ils reviennent sur leur Mac. Acceptez ce coût. L'alternative oblige l'utilisateur à se souvenir de chaque processus d'agent actif avant la fermeture d'un capot, puis à lui faire confiance lorsqu'il se réveille plusieurs heures plus tard.

Lancez les tests avant de déclarer qu'une configuration d'agent peut fonctionner sans surveillance. Si une requête réussit après un verrouillage ou un réveil sans nouvelle décision de l'utilisateur, vous avez trouvé une autorité qui a survécu au moment où elle a été accordée.