Sécurité du changement rapide d'utilisateur pour les actions d'un agent IA local

Un Mac partagé change le sens de l'autorité « locale ». Le changement rapide d'utilisateur permet à plusieurs sessions de rester connectées en même temps. La personne devant le clavier, le processus d'agent, le coffre-fort d'identifiants et la demande d'autorisation peuvent donc appartenir à des contextes de sécurité différents. Les traiter comme une seule identité est la façon dont un simple transfert devient un appel de production non vérifié.

La règle pratique est simple : la propriété du compte, l'accès au coffre-fort et le pouvoir d'autoriser doivent rester liés à la même session utilisateur macOS. Un changement d'utilisateur n'autorise pas la poursuite de la session d'agent de quelqu'un d'autre. C'est un signal qui doit vous faire vérifier quel processus existe encore, quels identifiants il peut demander et qui peut voir ou satisfaire la prochaine demande.

La sécurité du changement rapide d'utilisateur concerne les sessions simultanées

La sécurité du changement rapide d'utilisateur compte parce que macOS peut garder le compte précédent connecté pendant qu'une autre personne utilise le même matériel. Dans le Guide de l'utilisateur macOS, Apple décrit cette fonction comme un moyen de passer d'un compte à l'autre sans déconnecter l'autre utilisateur. C'est tout l'intérêt de la fonction. Cela signifie aussi qu'un changement d'utilisateur ne prouve pas que le travail précédent s'est arrêté.

On imagine souvent un ordinateur portable comme une seule chaise : une personne se lève, une autre s'assoit et le contrôle passe de l'une à l'autre. Un Mac partagé avec le changement rapide d'utilisateur ressemble plutôt à plusieurs pièces dans un même bâtiment. Le bureau visible indique qui contrôle la console à cet instant. Il ne dit pas si un terminal, une extension d'éditeur, un service local ou un lanceur d'agent reste actif dans un autre compte connecté.

Cette distinction devient importante lorsqu'un agent peut appeler une API ou se connecter en SSH. L'agent a peut-être été lancé sous le compte d'Alex avant le déjeuner. Sam passe ensuite sur son propre compte et voit un bureau propre. Le processus d'Alex existe peut-être encore, sa file de tâches contient peut-être toujours du travail et un état d'autorisation peut encore être valide pour cette session. Le Mac n'a pas transféré cette autorité à Sam, mais un logiciel imprudent peut rendre la différence difficile à voir.

Ne confondez pas verrouillage de l'écran, changement d'utilisateur et arrêt des processus. Ces actions répondent à des problèmes différents.

• Le verrouillage de l'écran bloque l'utilisation occasionnelle du bureau actuellement visible.
• Le changement d'utilisateur modifie le compte actif de la console tout en conservant une autre session connectée.
• La déconnexion demande à macOS de fermer la session graphique de cet utilisateur et ses processus.
• La révocation d'une session d'agent retire à cette session l'autorisation d'effectuer d'autres appels externes.

C'est ce dernier point que les équipes oublient. Une session d'agent doit avoir sa propre durée de vie et son propre mécanisme de révocation. Si elle dépend uniquement de la durée de vie d'une fenêtre de terminal ou d'une idée vague de « l'ordinateur du développeur », elle se comportera mal sur un Mac utilisé par plusieurs personnes.

Le changement rapide d'utilisateur n'est pas automatiquement dangereux. Il le devient lorsqu'un système d'actions locales suppose que chaque processus actif et chaque personne susceptible de toucher la machine appartiennent à la même personne. Cette hypothèse ne tient que sur un Mac personnel avec un seul compte actif. Même là, elle échoue dès qu'une autre personne connaît le mot de passe ou utilise un bureau déverrouillé.

L'utilisateur actif de la console ne doit pas hériter de l'autorité d'un autre compte

L'utilisateur actif de la console ne doit contrôler que les identifiants et les autorisations attribués à son propre compte. Un coffre-fort local d'identifiants appartient à une identité, pas à l'ordinateur physique. Si une application rend le coffre-fort accessible à toute la machine, tout utilisateur pouvant atteindre son interface dispose d'un chemin vers l'autorité d'une autre personne.

C'est ici que les équipes confondent deux affirmations différentes. « Le secret n'entre jamais dans l'agent » concerne l'exposition du secret. « Seule la bonne personne peut autoriser l'action » concerne l'autorité. Il faut les deux. Une séparation parfaite des secrets ne sert à rien si un autre utilisateur connecté peut autoriser leur utilisation, ou si une ancienne session reste autorisée après le départ de son propriétaire.

Rendez cette liaison explicite dans votre conception et vos règles de fonctionnement :

1. Stockez les identifiants de chaque personne sous son compte macOS, avec un matériel de coffre-fort distinct et une authentification locale distincte.
2. Exigez que le coffre-fort soit déverrouillé par le compte propriétaire de l'identifiant avant toute action externe.
3. Faites en sorte qu'une autorisation s'applique à un seul processus d'agent dans un seul compte, puis expire lorsque ce processus se termine ou qu'un opérateur la révoque.
4. N'autorisez pas le passage à un autre compte à satisfaire une demande provenant du premier compte.
5. Enregistrez le contexte du compte et le processus à l'origine de chaque autorisation et de chaque appel.

Le cas limite délicat concerne la personne chargée du support qui dispose de droits d'administrateur sur le Mac. Ces droits permettent de modifier de nombreuses conditions locales, mais ils ne doivent pas devenir un moyen d'utiliser facilement les identifiants API d'une autre personne. Demandez-vous si le système impose une nouvelle authentification du propriétaire de l'identifiant et si le journal d'audit rend visible le changement de compte. Si la réponse n'est pas claire, la conception ne l'est pas non plus.

Touch ID rend ce point plus net, pas plus simple. Une autorisation par empreinte doit confirmer la personne autorisée pour le compte actif et pour l'action affichée dans la demande. Elle ne doit pas devenir un simple signal de présence physique qu'une personne inscrite peut utiliser pour dépenser l'autorité d'un autre compte. L'authentification locale appuyée par le matériel ne constitue une barrière solide que si l'application conserve l'identité de l'autre côté de cette barrière.

Ne résolvez pas ce problème par une règle informelle comme « nous ne changeons d'utilisateur que lorsque l'autre personne est absente ». Les machines partagées connaissent les interruptions, la maintenance, les chargeurs prêtés et les transferts précipités. Les contrôles doivent résister au comportement humain normal, car c'est précisément dans ces moments que les règles non écrites sont oubliées.

Un processus invisible peut survivre à la personne devant le bureau

Un changement d'utilisateur peut laisser un agent local actif. Vous devez tester ce comportement exactement de la manière dont votre équipe lance ses agents. Certains processus s'arrêtent lorsque leur terminal parent se ferme. D'autres passent par un éditeur, un exécuteur de tâches, un élément d'ouverture de session ou un mécanisme de lancement en arrière-plan et continuent. Les limites entre comptes macOS restreignent ce à quoi ils peuvent accéder, mais elles ne garantissent pas que chaque processus disparaît lorsqu'un autre utilisateur atteint l'écran de connexion.

Effectuez un petit test avant d'autoriser un travail autonome sur un matériel partagé. Utilisez une tâche d'agent sans danger qui écrit chaque minute un enregistrement local reconnaissable et ne détient aucun identifiant. Lancez-la depuis le même terminal, éditeur ou lanceur que celui utilisé en conditions réelles. Changez d'utilisateur sans vous déconnecter, attendez, revenez à la session initiale, puis vérifiez si la tâche a continué. Recommencez après avoir verrouillé l'écran, puis après vous être déconnecté.

Notez le résultat en termes opérationnels. « L'agent s'arrête » ne suffit pas. Enregistrez le lanceur, le compte, l'événement qui l'a arrêté et le temps nécessaire. Un processus qui continue après un changement d'utilisateur peut être acceptable pour une vérification locale. Il mérite beaucoup plus d'attention s'il peut envoyer une requête qui modifie un environnement hébergé.

Un échec courant semble d'abord anodin. Un développeur démarre une session de programmation autonome capable de créer des commentaires sur des tickets et de mettre à jour un environnement de test. Il autorise le processus pour l'après-midi, puis change de compte afin qu'une autre personne puisse utiliser le Mac. La session de programmation entre dans une boucle de nouvelles tentatives après une erreur temporaire et reprend plus tard. La deuxième personne ne l'a pas démarrée et ignore peut-être même son existence. Pourtant, la session conserve une autorisation valide, car le logiciel a lié l'autorisation au calendrier, à l'appareil ou à une session utilisateur générale plutôt qu'au processus d'origine.

La solution n'est pas simplement de réduire la durée de l'autorisation. Des délais courts interrompent le travail réel et apprennent aux utilisateurs à cliquer rapidement sur les demandes. Liez l'autorisation à une instance de processus. Lorsque ce processus se termine, son droit s'arrête. Lorsqu'un utilisateur transfère volontairement le travail à quelqu'un d'autre, révoquez l'ancienne session et démarrez-en une nouvelle. Le nouveau processus crée un nouvel événement d'autorisation avec un propriétaire identifiable.

Vous devez aussi disposer d'un moyen visible de répondre à la question « qu'est-ce qui fonctionne encore sous mon compte ? ». La réponse ne peut pas dépendre de la mémoire. Donnez aux opérateurs un journal de session qui affiche la session, indique si elle reste autorisée et propose une action directe de révocation. Sur une machine personnelle, c'est pratique. Sur un Mac partagé, cela fait partie de la limite de sécurité.

Les demandes d'autorisation ont besoin de l'identité du processus, pas d'un nom sympathique

Une demande d'autorisation doit afficher assez d'informations pour distinguer l'appelant réel d'une imitation. Une étiquette comme « assistant de programmation » ne sert à rien lorsque deux extensions, deux shells ou un script copié peuvent utiliser le même nom. L'opérateur a besoin du processus à l'origine de la demande et, lorsque macOS le fournit, de son autorité de signature de code.

L'autorité de signature de code répond à une question précise mais importante : quelle identité de développeur a signé ce processus ? Elle ne prouve pas que le processus prendra de bonnes décisions. Elle aide toutefois l'opérateur à repérer une demande provenant d'un outil non signé, d'une version différente ou d'un composant auxiliaire inattendu. C'est préférable à l'autorisation d'une demande anonyme parce qu'elle apparaît pendant un après-midi chargé.

La demande doit aussi nommer l'identifiant ou la catégorie d'action dans des termes qu'une personne peut évaluer. « Utiliser l'identifiant X » oblige à rechercher une information dans sa mémoire. « Envoyer une requête HTTP à l'API de déploiement avec l'identifiant de publication de staging » permet de prendre une décision. Évitez d'intégrer le corps complet de chaque requête dans les demandes. Les demandes volumineuses créent de la lassitude et exposent des données qui n'ont pas leur place dans une notification de bureau. Affichez l'action, la destination, la méthode et l'identité de l'identifiant de façon lisible.

L'autorisation par session et l'autorisation par appel résolvent des problèmes différents. L'autorisation par session signifie : « Je reconnais ce processus d'agent et j'autorise sa session limitée. » L'autorisation par appel signifie : « Je vérifie cette utilisation précise de cet identifiant. » Ne remplacez pas la seconde par la première simplement parce qu'elle interrompt moins le travail.

Utilisez une autorisation par appel lorsque les conséquences sont difficiles à inverser : identifiant capable de modifier des données de production, de supprimer des ressources, de publier à l'extérieur ou d'atteindre une interface d'administration étendue. Une autorisation par appel ajoute de la friction. Cette friction doit apparaître précisément au moment où une personne doit s'arrêter pour réfléchir.

Utilisez une autorisation par session pour les tâches dont le processus est identifiable et dont l'identifiant autorisé a un impact limité. La session doit se terminer avec le processus. Une autorisation générale pour « les agents de ce Mac » est une faille de politique qui porte un nom rassurant.

La recommandation souvent faite de désactiver les autorisations sur une machine locale de développement de confiance ne convient pas aux Mac partagés. Elle est populaire parce que les demandes interrompent le travail et que les développeurs considèrent les processus locaux comme privés. Le changement rapide d'utilisateur supprime cette hypothèse. Une machine locale peut contenir plusieurs contextes utilisateur actifs et un processus familier peut continuer longtemps après le départ de son propriétaire.

Les Mac partagés ont besoin d'une procédure de transfert qui met fin à l'autorité

Un véritable transfert met fin à l'autorité de l'ancienne personne avant de commencer le travail de la suivante. Transmettre un onglet de terminal, une description de tâche ou un message de discussion ne transfère pas la responsabilité. La personne qui arrive a besoin d'un nouveau processus et de sa propre autorisation pour utiliser un identifiant.

Appliquez cette procédure lorsqu'une autre personne doit reprendre une tâche d'agent local :

1. Arrêtez l'agent actuel s'il prend encore des décisions. Laissez-le écrire ses fichiers de travail ordinaires, mais empêchez-le de continuer à appeler des systèmes externes pendant le transfert.
2. Révoquez l'ancienne session d'agent dans son enregistrement de session. Vérifiez que la révocation modifie bien l'état de la session avant le départ de l'utilisateur initial.
3. Verrouillez le coffre-fort de l'utilisateur initial ou déconnectez ce compte si la machine doit rester longtemps avec la personne suivante.
4. Demandez à la personne qui arrive de passer sur son propre compte macOS et d'y démarrer un nouveau processus d'agent.
5. Exigez une nouvelle autorisation identifiant le nouveau processus, puis vérifiez l'état de la tâche avant d'autoriser les actions externes.

Cette procédure semble stricte jusqu'au premier transfert ambigu qui déclenche une requête. Le coût du redémarrage d'un agent est faible par rapport au travail nécessaire pour déterminer qui a autorisé une modification. Si un flux de travail ne tolère pas un redémarrage, il lui faut une conception multiutilisateur réfléchie, pas un transfert accidentel via un bureau partagé.

Évitez de partager un compte pour accélérer les transferts. Un identifiant partagé détruit les éléments dont vous aurez besoin plus tard. Vous ne pourrez pas savoir qui a déverrouillé le coffre-fort, quel terminal a démarré le processus ni qui a jugé l'appel acceptable. Des comptes macOS séparés ne résolvent pas tous les problèmes, mais ils préservent une limite utile et un historique exploitable.

Les équipes ont aussi besoin d'une règle pour les propriétaires absents. Si un processus d'agent fonctionne sous le compte d'une personne indisponible, personne ne doit le maintenir actif en cliquant dans sa session. Arrêtez-le, révoquez-le et redémarrez-le sous le compte d'un propriétaire présent. Le travail peut attendre. Une autorisation sans surveillance permettant de modifier des systèmes externes ne le doit pas.

Le verrouillage du coffre-fort doit arrêter les actions avant l'affichage des demandes

Une barrière de coffre-fort doit refuser toute action lorsqu'il est verrouillé, même si un processus d'agent a déjà reçu une autorisation de session. C'est la différence entre l'autorisation d'exécuter une session et la permission actuelle d'utiliser un identifiant. La première établit quel processus la personne reconnaît. La seconde demande si le magasin d'identifiants est disponible maintenant.

Sallyport applique volontairement cet ordre : sa barrière de coffre-fort est absolue et, sur macOS, elle utilise Secure Enclave et Touch ID, tandis que les actions sont refusées lorsque le coffre-fort est verrouillé. Cet ordre empêche une ancienne autorisation d'agent de remplacer l'accès au coffre-fort après le verrouillage de la session par un utilisateur.

Gardez ces contrôles séparés dans votre modèle mental. La barrière du coffre-fort protège l'accès aux identifiants. L'autorisation de session reconnaît une session d'agent précise. L'autorisation par appel ajoute une vérification directe pour certains identifiants. Lorsqu'un contrôle prend la place d'un autre, les opérateurs ne peuvent plus comprendre clairement la raison d'un refus.

Par exemple, ne faites pas des demandes par appel la seule protection d'un identifiant étendu. Une personne peut autoriser par erreur la mauvaise requête après être revenue sur un bureau chargé. Le coffre-fort verrouillé doit déjà avoir refusé l'action jusqu'à ce que le propriétaire de l'identifiant s'authentifie localement. La demande par appel peut alors poser une question plus précise : cette utilisation mérite-t-elle une autorisation ?

De même, ne laissez pas le coffre-fort déverrouillé en permanence parce qu'une longue tâche de programmation pourrait en avoir besoin plus tard. Cette décision transforme un bref moment d'inattention en une période durant laquelle un ancien processus peut agir. Déverrouillez-le pour le travail supervisé, puis verrouillez-le lorsque le propriétaire s'éloigne ou confie le Mac à quelqu'un d'autre. Si la tâche exige réellement une autorité sans surveillance, déplacez-la dans un environnement conçu pour les identités de service, les identifiants limités et une responsabilité opérationnelle explicite. Une session personnelle partagée n'est pas le bon endroit pour imiter un serveur.

L'expression « humain dans la boucle » cache souvent la question de l'identité. Quel humain ? Sous quel compte ? Pour quel processus l'autorisation est-elle donnée ? Une demande qui ne peut pas répondre à ces questions ne fournit pas un contrôle significatif. Elle enregistre seulement que quelqu'un a cliqué sur un bouton.

Les journaux d'audit établissent la chronologie, pas la décision d'autorisation

Une piste d'audit infalsifiable permet de reconstituer une session d'agent après une action contestée, mais elle ne peut pas empêcher une mauvaise autorisation au moment où elle se produit. Utilisez le journal pour établir la séquence et la responsabilité, puis corrigez le contrôle qui a permis l'action. Ne vous présentez pas l'historique d'audit comme un remplacement d'un coffre-fort verrouillé ou d'une limite d'autorisation claire.

Le journal doit proposer deux vues, car les opérateurs posent deux questions différentes. Un journal de session répond à « quelle session d'agent a été autorisée et puis-je la révoquer ? ». Un journal d'activité répond à « quel appel a eu lieu, sur quel canal et à quel moment ? ». Ces enregistrements doivent provenir d'une même source append only, plutôt que de deux bases de données sans lien qui peuvent finir par diverger.

Sallyport produit ces deux journaux à partir d'un journal d'audit chiffré, chaîné par hachage et en écriture aveugle, afin que l'historique des activités et celui des sessions partagent une même source de référence. Sa vérification hors ligne s'effectue avec cette commande :

sp audit verify

Lancez cette vérification lorsque vous archivez une machine, examinez un transfert contesté ou recevez un magasin d'audit exporté. Le vérificateur contrôle la chaîne sur le texte chiffré et n'a pas besoin de l'identifiant de déchiffrement. Cette propriété compte sur les Mac partagés : un enquêteur peut vérifier que les enregistrements forment toujours un historique valide sans recevoir les jetons API ou le matériel SSH concernés par cet historique.

La vérification indique si la chaîne est restée cohérente en interne. Elle ne prouve pas que chaque événement était judicieux, qu'une personne a compris chaque demande ou que l'appareil n'a subi aucune compromission. Soyez précis dans votre affirmation. Une chaîne vérifiée rend plus difficile la dissimulation d'une modification silencieuse des anciens enregistrements. Elle ne transforme pas un compte partagé dangereux en compte sûr.

Pendant une enquête, comparez le contexte du compte, l'identité du processus, l'heure d'autorisation de la session, l'événement de déverrouillage du coffre-fort et l'ordre des appels individuels. Une question utile n'est pas seulement « un agent a-t-il fait cela ? ». Demandez si le même compte possédait le coffre-fort, le processus d'agent et l'autorisation. Si ces éléments diffèrent, vous avez trouvé une limite qui mérite votre attention.

Les appels HTTP et SSH présentent des risques différents dans une session partagée

Les actions HTTP et SSH dépensent toutes deux de l'autorité, mais elles laissent des traces opérationnelles différentes et échouent de manière différente. Les identifiants HTTP donnent souvent accès à un service distant doté d'une large portée API. Les identifiants SSH peuvent fournir un shell sur un hôte distant, où une seule connexion acceptée peut exécuter plusieurs commandes. Ne leur appliquez pas le même traitement d'autorisation simplement parce qu'ils proviennent du même agent local.

Pour HTTP, examinez la destination, la méthode et la portée de l'identifiant. Une requête de lecture vers une API de développement limitée ne mérite pas la même règle qu'une requête d'écriture vers un point d'accès de gestion d'environnement. L'agent doit demander l'action à une passerelle locale qui injecte elle-même l'identifiant, afin que l'agent reçoive le résultat plutôt que le jeton porteur. Cela limite l'exposition du secret, mais ne réduit pas l'impact d'une requête destructive autorisée.

Pour SSH, concentrez-vous sur l'identité de l'hôte, l'identité du compte et l'intention de la commande. Une connexion à un hôte de développement avec un compte limité est très différente d'une connexion à un compte de production partagé. Si l'identifiant fournit un shell interactif, traitez-le comme une permission à fort impact, même si la première commande semble inoffensive. La suivante peut ne pas l'être.

Le changement rapide d'utilisateur ajoute une condition locale aux deux canaux. Un processus d'agent actif sous un compte ne doit pas continuer à envoyer des requêtes HTTP ou à ouvrir des sessions SSH simplement parce qu'un autre utilisateur a rendu le Mac actif. La passerelle doit associer la requête au processus d'origine et exiger que le propriétaire du coffre-fort satisfasse la barrière. L'écran du deuxième utilisateur ne doit pas devenir une surface d'autorisation pour la session du premier.

Conservez des identifiants distincts pour les différentes personnes lorsque la responsabilité compte. Un jeton de déploiement partagé rend difficile la distinction entre un problème de processus et un problème de transfert humain. Des identifiants individuels et des entrées de coffre-fort associées à chaque compte rendent l'historique d'audit utile lorsque vous devez retrouver le véritable responsable.

Certaines charges de travail n'ont pas leur place sur un poste partagé

Un Mac partagé peut convenir au développement local supervisé avec des identifiants limités et des autorisations réfléchies. Il convient mal à un agent autonome de longue durée ayant le pouvoir de modifier des systèmes de production, d'accéder à de larges API d'administration ou de maintenir des shells distants sans personne présente.

La limite ne dépend pas de l'intelligence de l'agent. Elle dépend de sa capacité à continuer d'agir après le départ de son propriétaire responsable de la console. Si c'est possible, utilisez un environnement conçu pour cette tâche. Donnez à la charge de travail une identité de service dédiée, un propriétaire défini, des identifiants limités et des enregistrements que l'équipe opérationnelle peut consulter sans emprunter la session de bureau de quelqu'un.

Ne confondez pas une conception serveur avec une conception d'application locale. Un serveur possède un modèle de menace différent, des contrôles de cycle de vie différents et des attentes différentes concernant l'exécution sans surveillance. Une application de barre des menus Mac peut donner à un développeur un contrôle humain étroit sur les actions locales. Elle ne doit pas prétendre être un système d'automatisation sans interface simplement parce que quelqu'un souhaite laisser une tâche fonctionner toute la nuit.

Pour le Mac partagé que vous utilisez déjà, rendez la première règle concrète : aucun agent ne conserve une autorité externe lors d'un transfert sans propriétaire. Testez ce qui survit à un changement d'utilisateur, imposez le verrouillage du coffre-fort lorsque le propriétaire de l'identifiant s'en va et révoquez les anciennes sessions au lieu d'espérer que la personne suivante les remarquera. C'est à ce moment que le changement rapide d'utilisateur cesse d'être une simple commodité de bureau et reçoit le traitement de sécurité qu'il exige.