Check-list de passation des accès d'un agent IA lors d'un changement de poste

Un changement de poste montre si le modèle d'accès d'un agent IA tient vraiment la route ou s'il s'effondre discrètement. Les équipes transfèrent souvent les autorisations d'un dépôt et oublient le chemin d'identification qui permet à un agent d'appeler des API de production, d'ouvrir une session SSH ou de lancer un déploiement. L'agent continue de fonctionner, mais personne ne sait dire qui peut l'autoriser, qui lit ses traces ou qui peut l'arrêter à deux heures du matin.

Une check-list de passation des accès d'un agent IA doit transférer quatre responsabilités distinctes : la garde des identifiants, l'autorité d'autoriser les actions, la responsabilité de l'examen des audits et l'autorité d'agir en cas d'incident. Les confondre sous une notion vague de « propriété » permet à un développeur parti de rester le responsable réel d'un chemin de production longtemps après son changement de poste.

Un changement de poste transfère l'autorité, pas seulement les secrets

L'équipe doit transférer la capacité d'autoriser les actions de l'agent et d'en rendre compte, même lorsque l'identifiant ne quitte jamais son espace de stockage sécurisé. Un secret peut rester dans le même coffre-fort, tandis que son propriétaire, son usage autorisé, son approbateur et son réviseur changent. Ce sont des informations différentes et chacune doit recevoir une réponse consignée.

Commencez par distinguer les personnes que l'on réduit souvent à un seul nom :

• Le dépositaire de l'identifiant peut faire tourner, désactiver ou remplacer le secret.
• Le propriétaire du service décide si l'agent doit conserver son accès à ce système.
• L'approbateur accepte ou refuse une action demandée lorsqu'une autorisation est requise.
• Le réviseur d'audit vérifie ce que l'agent a réellement fait et donne suite aux exceptions.
• La personne habilitée à révoquer en urgence peut couper l'accès lorsque le responsable habituel est indisponible.

Dans les petites équipes, un même ingénieur assume souvent ces cinq responsabilités. Cela peut convenir à un identifiant de développement limité, mais consignez-le clairement et désignez une relève. Sinon, des congés, un départ imprévu ou un désaccord sur les autorisations transforment l'absence d'une personne en dépendance opérationnelle majeure.

Ne confondez pas la propriété d'un dépôt avec l'autorité d'agir. Un développeur peut perdre l'accès en écriture à un dépôt alors qu'un processus d'agent qu'il a configuré continue d'atteindre un outil de suivi, une API cloud ou une machine de production. À l'inverse, un nouveau responsable d'équipe peut posséder le dépôt sans avoir le pouvoir d'autoriser l'agent à utiliser un identifiant de publication. Examinez séparément ces deux aspects.

J'ai vu des passations échouer parce que la personne entrante recevait une liste de noms d'API, mais pas la raison d'être de chaque identifiant. Une fiche qui indique « jeton de déploiement » n'apprend presque rien à un successeur. Précisez le service cible, l'action autorisée, l'environnement, le propriétaire, le mode d'autorisation et la méthode de rotation. Si personne ne peut expliquer en une phrase l'utilité d'un identifiant, désactivez-le jusqu'à ce que ce soit possible.

Gelez les changements avant de transférer la responsabilité

Mettez en pause les nouveaux changements d'accès des agents pendant la passation. Une cible qui bouge produit un document déjà inexact au moment où quelqu'un le signe.

Le gel ne signifie pas qu'il faut arrêter toutes les exécutions d'agents pendant une semaine. Il signifie que personne n'ajoute d'identifiant, n'élargit une portée, ne modifie les paramètres d'autorisation ni n'accorde l'accès à une nouvelle machine sans que les responsables sortant et entrant consignent le changement. Gardez cette période courte et explicite. Pour un changement de poste planifié, commencez dès que la date est connue et terminez avant la perte d'accès de la personne. En cas de départ brutal, révoquez d'abord, puis reconstituez l'inventaire à partir des enregistrements.

Définissez clairement le périmètre. Incluez les processus d'agent exécutés sur les machines des développeurs, les automatisations planifiées, les tâches CI qui invoquent un agent et les environnements de test qui contiennent de vrais identifiants. Les équipes oublient régulièrement les outils locaux parce qu'ils ne sont pas visibles dans la console cloud. Un accès local peut toujours atteindre des systèmes externes.

Une notification de gel utile répond à quatre questions pratiques :

1. Quels identifiants et points d'accès sont concernés par la passation ?
2. Qui peut autoriser une exception pendant le gel ?
3. Où sont conservés l'inventaire actuel et les enregistrements d'actions ?
4. Quand le responsable entrant accepte-t-il la responsabilité ?

N'acceptez pas « nous ferons le ménage plus tard » pour les identifiants qui touchent à la production ou aux données clients. C'est plus tard que l'on découvre qu'un agent possède encore un jeton dont aucun employé ne se souvient. Un gel court coûte moins cher qu'une rotation d'urgence réalisée sans savoir quelles automatisations vont tomber en panne.

Une distinction compte ici : révoquer le compte d'une personne n'est pas la même chose que révoquer l'autorité d'un agent. Un identifiant peut appartenir à un compte de service partagé. Une autorisation peut être attachée à un processus d'agent local. Une clé publique SSH peut autoriser une machine indépendamment du compte du fournisseur d'identité du développeur sortant. La passation doit trouver chaque chemin, pas seulement fermer le compte de l'employé.

Créez un registre qui décrit l'usage, pas les valeurs secrètes

Votre registre de passation doit identifier les identifiants sans copier leur contenu secret dans un tableur ou un ticket. La personne entrante a besoin d'une carte opérationnelle, pas d'un second coffre-fort moins protégé rempli de jetons.

Utilisez un identifiant opaque, une empreinte ou le nom de l'enregistrement dans le coffre-fort. Pour le matériel SSH, consignez l'empreinte de la clé publique et les machines autorisées. Une équipe peut examiner une empreinte publique sans exposer la clé privée :

ssh-keygen -lf ~/.ssh/agent_deploy.pub
256 SHA256:exampleFingerprint agent-deploy (ED25519)

L'empreinte exacte sera différente. L'important est que le registre conserve l'identifiant obtenu, le compte de la machine et la raison d'être de la clé. Ne collez jamais une clé privée ou un jeton bearer dans le document de passation pour le rendre « complet ». Vous créeriez un nouveau point de fuite et rendriez la rotation plus difficile à vérifier.

Copiez cette structure dans la documentation opérationnelle protégée de l'équipe pour chaque identifiant ou chemin d'accès :

access_id: prod-release-api-01
channel: HTTP
service_and_environment: release API / production
allowed_action: create approved release
secret_reference: encrypted-vault record prod-release-api-01
credential_custodian: incoming platform owner
service_owner: release engineering lead
approval_mode: every use
approver_backup: operations manager
audit_reviewer: security duty engineer
emergency_revoker: platform on-call
rotation_method: replace token in service console, then test read-only endpoint
last_verified: 2025-03-08

Les dates et les noms ci-dessus sont des exemples. Remplacez-les par les personnes et les dates réelles, puis protégez le document comme des métadonnées opérationnelles. Il ne contient pas de secret, mais il indique à un attaquant où se trouve l'autorité.

Indiquez la portée, pas seulement une étiquette. « Jeton cloud » peut désigner un accès en lecture à un seul compte de test ou un accès administrateur à plusieurs comptes de production. Demandez au propriétaire du service de confirmer cette portée au lieu de vous fier aux souvenirs du développeur sortant. Les consoles des fournisseurs évoluent, les anciennes intégrations restent en place et le nom donné à un identifiant il y a deux ans correspond souvent peu à ce qu'il peut faire aujourd'hui.

Le registre doit aussi indiquer clairement le sort de chaque accès : conserver, faire tourner, réduire la portée ou révoquer. « Transférer » n'est pas une décision. Si un identifiant n'a plus d'usage actuel, révoquez-le. Les équipes conservent des accès dormants parce qu'une rotation leur paraît risquée. Un accès dormant est plus difficile à surveiller et plus facile à oublier.

Les attentes en matière d'autorisation exigent une décision humaine nommée

Un paramètre d'autorisation ne contrôle réellement une action que lorsque l'équipe s'accorde sur la responsabilité assumée par la personne qui approuve. « Quelqu'un cliquera sur Autoriser » n'est pas une règle. C'est une faille qui attend une personne pressée.

Définissez si l'agent a besoin d'une autorisation une fois par exécution ou à chaque utilisation d'un identifiant. Une autorisation de session signifie : « Je reconnais ce processus d'agent et l'autorise à effectuer, pendant cette exécution, la catégorie d'actions qui lui a été attribuée. » Une autorisation par appel signifie : « J'ai examiné maintenant cette tentative d'utilisation précise. » Ces deux options répondent à des risques différents.

Utilisez l'autorisation de session pour un travail délimité lorsque des demandes répétées pousseraient les utilisateurs à approuver machinalement. Par exemple, un agent qui répare une suite de tests peut avoir besoin d'une série d'appels en lecture et en écriture vers un service de développement. L'approbateur doit tout de même savoir quel processus a demandé l'accès et quand l'autorisation prend fin.

Utilisez l'autorisation par appel lorsqu'une action individuelle peut avoir des conséquences importantes : déployer en production, supprimer des données, modifier des autorisations, envoyer des messages hors de l'organisation ou utiliser un identifiant à large portée. La pause supplémentaire est volontaire. Si une action est trop routinière pour justifier une décision humaine, réduisez la portée de l'identifiant ou déplacez l'opération dans une automatisation contrôlée. Ne réglez pas la fatigue liée aux demandes en donnant une autorisation de session étendue à chaque identifiant sensible.

Lors de la passation, consignez ces attentes en langage clair :

• La personne ou le rôle qui peut autoriser chaque catégorie d'action.
• Les situations qui exigent une autorisation par appel.
• Les éléments que l'approbateur doit examiner avant d'autoriser l'action.
• La condition d'expiration d'une autorisation de session.
• L'approbateur de remplacement lorsque le responsable habituel est absent.

Les éléments à examiner peuvent rester simples, mais doivent être concrets : environnement cible, opération demandée, identité de l'identifiant, processus d'agent à l'origine de la demande et résultat attendu. Un approbateur ne peut pas décider correctement à partir d'un message générique indiquant seulement qu'un agent demande un accès.

Une mauvaise recommandation fréquente consiste à désactiver les autorisations une fois que l'équipe « fait confiance » à l'agent. Elle est populaire parce que les demandes interrompent le travail. Elle est erronée parce que la confiance dans la génération de code d'un agent ne lui donne pas le droit d'utiliser chaque identifiant externe. Réduisez les autorisations lorsque le chemin d'action a une portée étroite et de bons tests. Conservez-les lorsque la conséquence exige une personne capable d'expliquer pourquoi elle a autorisé l'action.

L'examen d'audit doit être attribué à une personne et à un calendrier

Les journaux ne créent pas de responsabilité simplement parce qu'ils existent. La passation doit nommer la personne qui examine l'activité de l'agent, préciser ce qu'elle recherche et indiquer ce qu'elle fait lorsqu'une entrée n'est pas cohérente.

La publication spéciale 800-53 du NIST sépare la gestion des comptes dans le contrôle AC-2 de l'examen d'audit dans AU-6. Cette séparation convient bien aux accès des agents. La personne qui gère un identifiant peut être mal placée pour déterminer si son utilisation par un agent correspondait au travail autorisé. Un examen indépendant repère les erreurs comme les suppositions trop commodes.

Fixez une fréquence adaptée à l'accès. Un identifiant de production utilisé pour les publications peut nécessiter un examen après chaque publication et après toute tentative échouée ou refusée. Une intégration de développement à faible impact peut faire l'objet d'un examen planifié. N'écrivez pas « périodiquement ». Ce mot survit à chaque réunion manquée parce qu'il ne promet rien.

Le réviseur doit répondre à quelques questions à partir de l'enregistrement d'action :

• Quel processus d'agent a effectué la demande et qui a autorisé cette exécution ?
• Quel identifiant ou chemin d'accès a-t-il utilisé ?
• Quelle cible a-t-il atteinte et quel résultat a-t-il reçu ?
• La demande correspondait-elle à une tâche nommée ou à un dossier de changement ?
• Une action refusée, répétée ou inattendue nécessitait-elle une enquête ?

Demandez au réviseur de consigner une décision pour les événements inhabituels : attendu, corrigé, transmis ou non résolu. L'équipe n'a pas besoin d'un rapport cérémoniel pour chaque lecture d'API sans risque. Elle doit en revanche rendre visible sa décision lorsqu'un agent atteint la production en dehors d'une fenêtre prévue ou demande à plusieurs reprises un identifiant dont il ne devrait pas avoir besoin.

Conservez les enregistrements avant une rotation ou une révocation si un incident est possible. La rotation corrige l'exposition future, mais n'explique pas les actions passées. Vérifiez que le réviseur entrant connaît l'emplacement de conservation, les personnes qui peuvent exporter les enregistrements et la façon de vérifier leur intégrité. Une piste d'audit qu'un seul ingénieur sortant sait interpréter est un journal privé, pas un enregistrement opérationnel.

Répétez la révocation avant la date de départ

Un plan de révocation reste incomplet tant que l'équipe ne l'a pas testé avec une demande sans risque. La première tentative ne doit pas avoir lieu pendant un incident, lorsque chacun essaie de deviner si un refus signifie que le contrôle fonctionne ou que le service est en panne.

Examinez un échec courant. Un développeur change d'équipe et perd l'accès au contrôle de version. Son ancienne configuration d'agent continue de fonctionner sur un ordinateur portable géré avec un identifiant de déploiement partagé. L'identifiant reste valide parce qu'il appartient au compte de service des publications, pas au développeur. Un collègue demande à l'agent de « vérifier l'état de la publication », et l'agent peut toujours appeler le point d'accès de production. L'équipe croyait avoir effectué le départ parce que le compte de l'employé avait été désactivé. Le chemin partagé n'était pourtant pas fermé.

Testez plutôt le chemin réel. Le propriétaire du service peut organiser une demande sans effet de bord, par exemple une lecture d'état vers une cible de test, avec l'autorisation sortante. Révoquez ensuite l'ancienne autorisation, désactivez l'identifiant ou supprimez le chemin autorisé selon les besoins de la passation. Répétez la demande et confirmez trois faits : l'accès échoue, l'échec a la raison attendue et l'enregistrement d'audit identifie la tentative.

Ce test permet de trouver plus qu'un identifiant oublié. Il révèle une configuration locale obsolète, une seconde copie d'une autorisation SSH, une automatisation utilisant un compte de service inattendu et un réviseur incapable de retrouver l'enregistrement correspondant.

Gardez le test limité. Il n'est pas nécessaire d'exécuter des opérations destructrices pour prouver une révocation. Un appel d'état refusé ou une tentative de connexion rejetée fournit assez de preuves si la passerelle d'accès l'enregistre correctement. Documentez la commande ou la requête utilisée, le résultat attendu, le résultat réel et la personne qui a assisté au test.

Si le test échoue, ne clôturez pas la passation avec la promesse d'enquêter. Traitez cet identifiant comme actif, avec une responsabilité incertaine. Alertez la personne habilitée à révoquer en urgence, limitez le chemin d'accès et identifiez tous les endroits où l'autorisation a été mise en cache ou réutilisée. Le test raté remplit son rôle en révélant le chemin alors que la personne sortante peut encore répondre aux questions.

Les contacts d'urgence doivent avoir une autorité et un moyen réel d'agir

Les contacts d'urgence ne sont pas un simple champ d'annuaire. Ce sont les personnes qui peuvent prendre une décision urgente lorsqu'un agent tente une action dangereuse ou lorsque le responsable habituel ne répond pas.

Désignez un contact principal et un remplaçant pour chaque groupe d'accès sensible. Indiquez le moyen de les joindre pendant un incident, l'étendue de leurs pouvoirs de révocation et le propriétaire du service qui décidera d'une éventuelle restauration. Ne faites pas d'une boîte aux lettres d'équipe le seul contact d'urgence. Les boîtes aux lettres recueillent les messages, elles n'assument pas la responsabilité.

Définissez les conditions de déclenchement en termes opérationnels. Il peut s'agir d'une action d'agent en dehors d'un changement autorisé, d'autorisations échouées à répétition, d'un nouveau processus d'agent inattendu demandant un identifiant de production ou d'un enregistrement d'audit impossible à relier à un travail. Le contact doit savoir s'il faut suspendre toutes les actions d'agent, révoquer un seul identifiant, désactiver un compte sur une machine ou appeler le propriétaire du service.

Une bonne passation prévoit aussi le cas délicat où la personne habilitée à révoquer en urgence est celle qui change de poste. Transférez ce pouvoir avant que le changement ne prenne effet, puis testez la capacité du remplaçant à agir. Évitez de faire circuler dans une conversation un secret d'urgence partagé. Vous perdriez la traçabilité et le secret resterait généralement dans l'historique de quelqu'un longtemps après la fin de l'urgence.

Écrivez également la règle de restauration. La révocation d'urgence doit être simple. La restauration doit exiger que le propriétaire du service confirme la portée, que le réviseur d'audit examine l'événement et que le nouveau dépositaire accepte l'identifiant. Les équipes qui ignorent cette règle rétablissent souvent un accès trop large uniquement pour débloquer une tâche.

Une passerelle doit rendre la passation visible

Une passerelle d'action locale peut réduire le nombre d'endroits où cette passation échoue, mais elle ne remplace pas les décisions de responsabilité. Sallyport conserve les identifiants dans un coffre-fort chiffré, exige que le coffre-fort soit ouvert avant l'exécution des actions et enregistre à la fois les exécutions d'agents et les appels individuels. Le réviseur de la passation dispose ainsi de points concrets à examiner.

La distinction entre autorisation de session et autorisation par appel est utile pour rédiger les attentes précédentes. Le responsable entrant doit décider quels identifiants nécessitent une nouvelle décision humaine à chaque utilisation, au lieu de reprendre le réglage pratique choisi par le développeur sortant.

Pour vérifier hors ligne son enregistrement d'audit chiffré et chaîné par hachage, le réviseur entrant peut exécuter cette commande :

sp audit verify

Un résultat réussi doit indiquer que la vérification s'est terminée correctement. Un résultat négatif doit signaler l'échec de la vérification au lieu de considérer silencieusement l'enregistrement comme fiable. Exécutez cette commande dans le cadre des preuves de passation et conservez le résultat avec le dossier. La commande vérifie la chaîne sur le texte chiffré et n'a pas besoin de la clé du coffre-fort, ce qui est utile lorsque le réviseur doit vérifier les enregistrements sans recevoir l'accès aux identifiants.

Ne transformez pas une passerelle en vaste projet de gouvernance. Un long document de règles avec une exception pour chaque équipe vieillira mal et compliquera les passations. Gardez les points de décision compréhensibles : le coffre-fort peut-il autoriser une action, cette exécution d'agent dispose-t-elle d'une autorisation et cet identifiant exige-t-il une personne à chaque utilisation ? Assurez-vous ensuite que des personnes nommées assument ces réponses.

La validation finale doit prouver que l'équipe peut fonctionner sans la personne sortante

Ne clôturez la passation qu'après que l'équipe entrante a démontré qu'elle maîtrise chaque chemin actif. Un document signé sans test de révocation, réviseur nommé et voie d'escalade fonctionnelle n'est que de la paperasse, pas une preuve.

Utilisez cette check-list de clôture pour chaque groupe d'identifiants concerné :

1. Le registre identifie le service, la portée, le dépositaire, l'approbateur, le réviseur, la relève et la personne habilitée à révoquer en urgence.
2. Le propriétaire du service a choisi de conserver, faire tourner, réduire la portée ou révoquer l'accès, et l'équipe a consigné le résultat.
3. L'approbateur entrant a accepté par écrit les règles d'autorisation de session et par appel.
4. Le réviseur d'audit a retrouvé des enregistrements d'action récents et vérifié le contrôle d'intégrité lorsqu'il est disponible.
5. L'équipe a testé la révocation ou le refus avec une demande sans risque et consigné le résultat.

Demandez au développeur sortant de signer uniquement pour confirmer l'exactitude de ce qu'il a déclaré, pas pour les actions futures après la fin de son rôle. Demandez au nouveau dépositaire et au propriétaire du service d'accepter séparément leurs responsabilités. Cette séparation compte lorsqu'un incident ultérieur révèle un chemin d'accès obsolète : l'équipe peut déterminer si l'échec vient d'un identifiant non déclaré, d'une rotation non effectuée ou d'un responsable qui n'a jamais accepté la tâche.

Le test final est simple. Demandez aux personnes entrantes de répondre sans appeler le développeur sortant : quel agent peut atteindre ce service, qui peut l'autoriser, qui lit l'enregistrement et qui peut l'arrêter ce soir ? Si une réponse reste vague, la passation n'est pas terminée.