Liste de contrôle pour le départ d'un agent IA et une sortie maîtrisée

Le départ d'un employé est l'un des rares moments où le contrôle des accès est mis à l'épreuve par l'urgence. La procédure habituelle de désactivation d'un compte ne suffit pas pour les agents IA, car le travail utile passe souvent par des processus locaux, des tâches sans surveillance, des identifiants API partagés, des éléments SSH et des configurations copiées en dehors de l'identité de la personne sortante.

Considérez le départ comme un transfert contrôlé d'autorité, pas comme une tâche de nettoyage informatique. Vous devez empêcher les nouvelles actions, identifier le travail déjà en cours, remplacer les autorisations partagées et préserver les enregistrements avant que quelqu'un ne supprime les éléments permettant de comprendre ce qui s'est passé.

Une identité désactivée ne révoque pas tous les accès à la production

La désactivation d'un compte d'annuaire ne bloque que les chemins d'accès qui consultent effectivement cet annuaire au moment de l'utilisation. Elle ne révoque pas un jeton API présent dans un fichier de configuration local, une clé privée SSH chargée dans l'espace de travail d'un agent, un jeton d'accès cloud émis auparavant ou un identifiant de service partagé injecté par une tâche CI.

Cette distinction est souvent brouillée parce qu'une personne, un processus d'agent et un identifiant apparaissent parfois sous le même nom d'employé dans un tableau de bord. Ce sont des éléments différents qui demandent des actions différentes :

• Une identité humaine indique qui s'est authentifié.
• Un processus d'agent local indique ce qui peut agir sur la machine de l'employé à cet instant.
• Un identifiant indique ce qu'un service distant acceptera.
• Une session ou une tâche indique ce qui peut déjà être en train de travailler.
• Un enregistrement d'audit indique ce que vous pourrez prouver plus tard.

Une mauvaise distinction entraîne un échec bien connu. Les RH marquent l'employé comme parti à 09:00. L'informatique désactive l'authentification unique à 09:05. À 09:20, une tâche d'agent planifiée s'exécute sur un ordinateur portable qui n'a pas encore été récupéré. Elle utilise un jeton de déploiement partagé stocké dans son environnement et modifie un paramètre de production. Chaque équipe concernée peut dire honnêtement qu'elle a supprimé le compte de l'employé. Aucune n'a supprimé l'autorité utilisée par l'agent.

Commencez le ticket de départ par une question précise : « Quelles actions pourraient encore aboutir si la connexion habituelle de l'employé cessait de fonctionner ? » N'acceptez pas « son compte est désactivé » comme réponse.

Le NIST SP 800-53 répartit les contrôles associés dans des familles distinctes pour une bonne raison. AC-2 couvre la gestion des comptes, IA-5 la gestion des authentifiants et AU-9 la protection des informations d'audit. Les équipes qui réduisent ces trois sujets à une seule case découvrent généralement le travail manquant après un incident.

Gelez les chemins d'action avant de récupérer l'ordinateur portable

Commencez par bloquer l'autorité distante, car la récupération physique peut prendre plusieurs heures et un ordinateur portable allumé peut continuer à fonctionner. La personne qui gère le départ doit prévenir le responsable de la sécurité et les responsables des services, puis suspendre brièvement les actions automatisées attribuables à la personne sortante ou à son poste de travail.

La première vérification doit couvrir les chemins suivants :

1. Révoquez les sessions distantes actives lorsque le fournisseur d'identité, le cloud, l'hébergeur du code source ou le système d'accès privilégié le permet.
2. Désactivez ou isolez les exécuteurs de build enregistrés, les tâches d'agent planifiées et les sessions de développement distantes appartenant à l'employé.
3. Retirez l'appareil des accès liés aux appareils de confiance, au VPN et à la gestion centralisée lorsque votre procédure opérationnelle le permet.
4. Mettez en pause les tâches sans surveillance capables de déployer, de modifier l'infrastructure, d'envoyer des messages ou d'écrire dans des systèmes clients.
5. Récupérez le poste de travail ou placez-le sous des restrictions réseau gérées avant que l'employé n'en perde la supervision.

Ne commencez pas par supprimer les fichiers locaux. Si le départ est contesté, inhabituel ou lié à un problème de sécurité, préservez l'état de l'appareil conformément à votre procédure d'incident. Un effacement précipité détruit l'historique du shell, les transcriptions de l'agent, la configuration locale, les files de tâches et les horodatages qui pourraient indiquer si une action était autorisée.

Pour un départ ordinaire planifié, le responsable de la sécurité peut décider que les règles habituelles de restitution et de réinstallation de l'appareil s'appliquent. Cette décision doit apparaître dans le ticket, pas rester dans la mémoire de quelqu'un.

Un point de contrôle utile est la limite du processus de l'agent. Avant d'arrêter un agent exécuté localement, relevez le chemin de l'exécutable, le processus parent, l'identifiant du processus, l'heure de démarrage, le répertoire de travail et l'autorité de signature du code. Sur macOS, un opérateur peut recueillir un aperçu de base du processus ainsi :

ps -axo pid,ppid,user,lstart,command | grep -i '[a]gent'

# Output shape:
# 8421   611 alice  Tue Mar 12 09:14:22 2025 /usr/local/bin/agent-run --task release

La commande ne constitue pas une preuve à elle seule. Elle fournit à l'enquêteur un indice limité dans le temps et évite que l'affirmation vague « un agent était en cours d'exécution » ne devienne l'intégralité du dossier.

Établissez un inventaire des autorités, pas un inventaire des logiciels

La liste des outils d'IA installés ne vous indique pas qui peut modifier un service. Inventoriez tous les chemins d'autorité, y compris les outils que vous ne qualifiez pas d'IA. L'employé a pu utiliser un agent via un terminal, une extension d'éditeur, un exécuteur CI, un script local ou un environnement distant. Le chemin compte davantage que l'étiquette.

Utilisez une ligne par identifiant ou relation d'identité. Si un jeton peut atteindre trois services, indiquez ses trois conséquences dans le champ de portée au lieu de les enfouir dans les notes.

La partie difficile consiste à trouver les autorités partagées. Posez des questions directes aux responsables des services : cet employé connaît-il un jeton qui survit à son compte ? Administrait-il un compte robot ? Son appareil peut-il se connecter avec une clé SSH ? Une tâche s'exécutait-elle avec une identité générique ? Qui recevra les alertes de cette tâche à partir d'aujourd'hui ?

Ne faites pas de la personne sortante la seule source de cet inventaire. Elle peut aider, mais les dépôts, les coffres de secrets, les fichiers authorized_keys, la configuration CI, les registres de propriété des services et les journaux d'audit doivent confirmer la réponse. On oublie facilement un jeton créé pendant une panne. On oublie aussi un exécuteur de test devenu une infrastructure de production deux ans plus tard.

Renouvelez les identifiants partagés dans l'ordre des dépendances

Renouvelez tout identifiant partagé que la personne sortante a pu lire, copier, exporter ou utiliser en dehors d'un chemin de révocation fiable lié à l'identité. Cela comprend les clés API, les mots de passe Basic Auth, les secrets de webhook, les jetons de déploiement, les mots de passe de base de données, les clés SSH, les clés d'accès cloud et les codes de récupération.

La recommandation populaire, mais erronée, consiste à tout renouveler simultanément. Cela semble décisif et produit une liste impressionnante de secrets modifiés. Mais cela casse les dépendances inconnues, rend le dépannage chaotique et pousse les équipes à restaurer l'ancien secret sous la pression. Renouvelez les identifiants selon une séquence qui laisse une voie de remplacement sous la responsabilité de quelqu'un.

Pour chaque identifiant, suivez cet ordre :

1. Nommez le responsable du service et les appelants exacts qui utilisent l'identifiant.
2. Créez un identifiant de remplacement avec la portée la plus limitée prise en charge par le service.
3. Mettez à jour les appelants connus et vérifiez qu'ils fonctionnent avec le remplacement.
4. Révoquez l'ancien identifiant, puis vérifiez qu'il échoue.
5. Notez le responsable du remplacement, sa date de création, sa portée et le résultat de la révocation.

Le test d'échec est important. « Renouvellement terminé » signifie souvent que quelqu'un a créé un nouveau jeton et mis à jour une application. Cela ne signifie pas que l'ancien jeton a cessé de fonctionner. Effectuez une requête authentifiée sans effet de bord que l'ancien identifiant autorisait. Notez la réponse de refus attendue du service, par exemple HTTP 401 ou 403, sans coller de secrets dans le ticket.

Pour les accès SSH, supprimez la clé publique de la personne sortante de toutes les sources authorized_keys des cibles et de tout système central d'accès. Recherchez ensuite les automatisations qui utilisent la même clé privée. Si un agent employait une identité SSH partagée, créez une nouvelle paire de clés, remplacez la partie publique sur les cibles, mettez à jour l'appelant autorisé et retirez l'ancienne clé publique. Supprimer une clé du seul poste de travail ne change rien à une clé copiée.

N'envoyez jamais le remplacement par chat ou par e-mail dans le cadre de la passation. Donnez au nouveau responsable l'autorisation de l'obtenir ou de l'utiliser via le mécanisme de secrets approuvé. Le renouvellement vise à réduire le nombre de copies que vous ne pouvez pas comptabiliser.

Les comptes partagés ont besoin d'un responsable humain nommé

Un compte de service peut être légitime, mais un compte partagé sans opérateur nommé permet de dissimuler un problème de responsabilité. La passation doit nommer une personne qui accepte la responsabilité de l'objectif du compte, de sa portée, de sa facturation, de sa procédure de récupération et du prochain renouvellement de ses identifiants.

Séparez la responsabilité opérationnelle de l'identifiant lui-même. Un robot de mise en production peut devoir continuer à déployer après le départ d'un employé. Cela ne signifie pas que l'employé qui le remplace doit reprendre le jeton personnel de l'ancien ou utiliser sa configuration locale. Donnez au robot sa propre identité lorsque le service le permet, limitez ses permissions à ce dont il a besoin et rendez le nouveau responsable comptable de son usage.

Rédigez une courte fiche de passation qui répond à cinq points :

• Quel service ou processus le compte prend-il en charge ?
• Quels environnements et quelles actions peut-il atteindre ?
• Quels systèmes l'appellent-ils aujourd'hui ?
• Qui peut modifier ses identifiants ou le récupérer ?
• Quand quelqu'un vérifiera-t-il qu'il a toujours besoin de cet accès ?

C'est aussi à ce moment que les équipes découvrent des hypothèses liées aux agents, dissimulées derrière la commodité. Une configuration locale peut demander à un agent d'utiliser une identité de déploiement générique parce que le développeur d'origine n'avait pas le temps d'en configurer une dédiée. Ne conservez pas ce raccourci au nom de la continuité. Remplacez-le par un chemin d'accès attribué à un responsable avant de relancer le travail.

Préservez les enregistrements avant que les tâches de conservation ne les effacent

Conservez les éléments qui permettent de reconstituer les autorités et les actions sans dépendre des explications de la personne sortante. Capturez le ticket de départ, l'inventaire des accès, l'événement de désactivation de l'identité, les révocations de session, les événements de renouvellement, l'historique des tâches CI, les enregistrements d'exécution de l'agent, la décision concernant la collecte du poste et les exports d'audit des services. Indiquez le fuseau horaire et la source de l'horloge si les systèmes diffèrent.

La préservation ne consiste pas à copier quelques captures d'écran. Une capture perd des champs, masque les filtres et peut rarement être vérifiée. Exportez si possible les enregistrements d'origine dans leur format natif, conservez les hachages des fichiers collectés, limitez l'accès au groupe chargé du dossier et documentez les personnes qui ont manipulé chaque copie.

La note de collecte suivante est assez courte pour être utilisée et assez précise pour être auditée :

Case: OFF-2025-041
Collected by: security-operator
Collected at: 2025-03-12T09:37:16Z
Source: build-service job history export
Range: 2025-03-01T00:00:00Z to 2025-03-12T09:37:16Z
File: build-jobs.json
SHA-256: \u003crecorded digest\u003e
Storage: restricted evidence repository
Reason: employee exit and agent authority review

Conservez l'export d'origine sans le modifier. Si un enquêteur le filtre ou l'annote, enregistrez-le comme copie de travail séparée. Cette séparation simple a évité davantage de contestations que des outils médico-légaux complexes : chacun peut examiner l'analyse sans modifier discrètement la source.

Le NIST SP 800-92 décrit la gestion des journaux comme un processus de génération, de transmission, de stockage, d'analyse et de suppression. Lors d'un départ, le point faible est généralement la suppression. Une courte durée de conservation par défaut peut effacer le seul enregistrement nécessaire pour établir si un agent a agi avant ou après la modification des accès. Placez les enregistrements que votre politique vous autorise à conserver sous obligation de conservation, puis levez cette obligation selon la procédure habituelle.

Rendez l'autorisation de l'agent révocable processus par processus

L'approbation donnée par un développeur à un processus d'agent ne doit pas devenir une autorisation générale pour tous les processus susceptibles d'apparaître sur sa machine. Un processus peut être remplacé, relancé depuis un autre répertoire de travail ou invoqué par une extension d'éditeur après le départ de la personne. L'enregistrement d'autorisation doit identifier le processus et prévoir une révocation immédiate.

C'est là qu'une passerelle peut aider, mais uniquement si elle refuse de remettre les identifiants à l'agent. Sallyport conserve les identifiants API et SSH dans un coffre local chiffré, autorise par défaut les nouveaux processus d'agent session par session et enregistre séparément les sessions et les actions individuelles.

Lors d'un départ, exportez ou préservez les enregistrements de session et d'activité pertinents, révoquez les sessions actives et verrouillez le coffre avant le transfert de l'appareil. Cet ordre crée une limite claire : l'agent ne peut plus effectuer de nouvel appel externe, tandis que l'historique de ses appels précédents reste disponible pour examen.

Ne confondez pas l'approbation par session avec l'approbation de chaque action importante. Un agent peut avoir légitimement besoin d'une session pour lire un dépôt, alors que chaque identifiant permettant de modifier la production doit demander une confirmation à chaque utilisation. Appliquez le contrôle le plus strict aux identifiants dont l'utilisation abusive déclencherait une réponse à incident, pas aux appels de lecture sans risque qui entraîneraient une lassitude face aux approbations.

La lassitude face aux approbations est un défaut de conception. Si les utilisateurs reçoivent une demande pour chaque requête habituelle, ils cessent de les lire. Si une seule demande couvre silencieusement l'accès à des systèmes de production sans rapport entre eux, elle est trop large. Une bonne autorisation crée une limite claire qu'un opérateur peut expliquer après coup.

Inspectez le travail en cours et les déclencheurs différés

La révocation d'un compte n'arrête pas de manière fiable un travail déjà accepté par un service distant. Vérifiez les builds en file d'attente, les shells distants, les calendriers d'automatisation, les déclenchements de workflows de dépôt, les tâches de publication de paquets, les plans d'infrastructure et les files de messages susceptibles de lancer une action plus tard.

Pour chaque élément en cours ou en file d'attente, décidez s'il faut l'annuler, le laisser se terminer sous surveillance ou le transférer à un nouveau responsable. La décision doit dépendre de l'action, de son impact potentiel et de la possibilité de reproduire la tâche. Un déploiement associé à une modification connue peut être autorisé à se terminer. Une tâche qui peut modifier les contrôles d'accès ou déplacer des données doit normalement s'arrêter jusqu'à ce que son responsable confirme l'intention.

Relevez les identifiants avant l'annulation. Une simple URL de tâche constitue une preuve médiocre si le service supprime les détails après une période de conservation. Stockez l'identifiant de la tâche, l'identité qui l'a déclenchée, la référence du commit ou de la tâche, les heures de début et de fin, les permissions utilisées et le résultat. Si la tâche a échoué pendant le départ, indiquez si l'échec venait de votre révocation. Sinon, un enquêteur pourrait prendre un succès du contrôle d'accès pour une défaillance opérationnelle.

Inspectez aussi l'exécution différée. Les entrées cron, les launch agents, les calendriers CI, les règles d'événements cloud et les workflows de dépôt peuvent reprendre leur activité après que l'équipe pense le départ terminé. Une tâche récurrente doit être transférée à un responsable géré ou désactivée. La laisser active sous un compte abandonné rend la prochaine panne prévisible et difficile à diagnostiquer.

Ne clôturez que lorsqu'une personne indépendante peut vérifier le résultat

La personne qui effectue les modifications ne doit pas être la seule à déclarer le départ terminé. Demandez à un collègue de la sécurité, au responsable du service ou au manager de vérifier les points essentiels : l'ancienne identité ne peut plus se connecter, les anciens identifiants partagés échouent, aucune tâche d'agent planifiée ne reste sous l'ancien responsable et la collecte des preuves est lisible et protégée.

Utilisez une déclaration de clôture qui indique des faits testés plutôt qu'une formulation vague :

Former identity: disabled and active sessions revoked
Shared credentials: 6 inventoried, 6 replacement paths tested, 6 prior credentials revoked
Agent work: 2 scheduled jobs transferred, 1 queued job canceled
Evidence: exports and collection hashes stored under case OFF-2025-041
Exceptions: none
Verified by: service owner and security reviewer

Si un identifiant ne peut pas être renouvelé immédiatement, gardez le ticket ouvert et consignez la restriction compensatoire, le responsable et la date limite. « Nous le ferons plus tard » n'est pas un contrôle. Une restriction du pare-feu, un workflow désactivé ou une suspension temporaire du service peut constituer un contrôle si quelqu'un le vérifie et sait quand il expire.

Le premier changement utile est simple : ajoutez un inventaire des autorités et une décision de conservation des preuves au ticket RH de départ existant. Ces deux champs imposent la bonne discussion avant qu'un ordinateur portable ne disparaisse, qu'un jeton ne survive ou qu'une tâche de conservation des journaux ne supprime le seul enregistrement d'une action de l'agent.