Départ d’un collaborateur : que faire de ses agents IA ?
Les agents IA construits par des collaborateurs partis continuent de tourner longtemps après la désactivation de leur compte Okta. Ils ont encore accès. Personne n’en est propriétaire. Voici quoi faire.
ChatGPT
Claude
Mistral
PerplexityRéponse courte
Pour auditer les agents IA après un départ, partez d’un registre qui attribue un propriétaire nommé à chaque agent. Quand ce propriétaire part, chacun de ses agents est signalé et reçoit l’une de trois décisions : réattribution à un nouveau propriétaire, suspension en attendant une revue, ou révocation définitive. La décision est journalisée avec le nom du réviseur et un horodatage, c’est la preuve qu’attend SOC 2 CC6.3. Désactiver le compte Okta ou Entra ID ne suffit pas : les agents tournent en général sur des clés API, des jetons OAuth ou des comptes de service que la désactivation du SSO ne touche pas.
Le problème des agents orphelins
Votre processus de départ attrape l’évident. Compte Okta désactivé. Ordinateur rendu. Slack désactivé. La personne est partie.
Ce qu’il n’attrape pas : les trois agents IA qu’elle a construits dans l’année. L’un lit le CRM et envoie une synthèse hebdomadaire du pipeline. L’un surveille le dépôt GitHub et publie des alertes dans Slack. L’un tourne chaque nuit sur les données de facturation et produit des rapports. Les trois tournent encore le lundi matin. Les trois ont encore accès. Aucun n’apparaît sur la checklist de départ.
C’est le problème des agents orphelins. Il est récent, il grandit, et presque aucun processus de départ standard ne le prend en compte.
Pourquoi un départ standard passe à côté
Le traitement traditionnel des départs a été conçu pour un monde où l’accès signifiait un compte. Désactiver le compte SSO, déprovisionner les applications fédérées, révoquer le VPN. Terminé.
Les agents IA cassent ce modèle de deux façons.
D’abord, les agents s’authentifient en général avec des clés d’API ou des jetons OAuth, pas en SSO. Quand vous désactivez le compte SSO d’une personne, ces identifiants ne sont pas révoqués pour autant. L’agent continue d’appeler les API avec le jeton qu’il a toujours utilisé, avec les mêmes permissions, sans qu’aucun journal n’indique que son propriétaire ne travaille plus là.
Ensuite, les agents ne sont pas dans votre fournisseur d’identité. Il n’y a pas de fiche utilisateur à désactiver, pas d’appartenance de groupe à retirer, pas d’événement SCIM à déclencher. L’agent n’existe tout simplement pas dans les systèmes qui gèrent les départs.
Résultat : un agent construit par une personne partie est fonctionnellement indiscernable d’un agent construit par quelqu’un encore en poste, jusqu’au jour où quelque chose tourne mal.
Trois scénarios aux issues très différentes
La responsable des opérations commerciales part. Elle avait construit un agent qui lit les opportunités HubSpot chaque lundi et envoie une synthèse dans un canal Slack. Personne ne sait qu’elle l’a construit. Il continue de tourner. Six mois plus tard, le canal reçoit un message avec des noms d’opportunités et des montants. Son successeur n’a aucune idée d’où cela vient ni comment l’arrêter.
Le risque n’est pas immédiat, mais il s’accumule. Un agent sans propriétaire, avec un accès vivant à des données métier, sans référent pour l’audit et sans personne sachant le modifier ou l’arrêter, représente une exposition qui grandit tranquillement.
Un développeur avait construit un agent avec son propre jeton OAuth Google pour accéder à Google Drive. Son compte Google est désactivé le dernier jour. Le jeton de l’agent est invalidé. Tous les traitements en aval qui en dépendaient échouent en silence ou se mettent à renvoyer des erreurs. L’IT est saisie, personne ne sait ce que faisait l’agent ni comment il était configuré, et la remise en route prend des jours.
Ce scénario est en réalité le moins mauvais. Au moins, l’accès a disparu. Le problème est la perturbation opérationnelle, pas l’exposition en sécurité.
Un ingénieur avait construit un agent et l’avait provisionné avec un compte de service créé pour l’occasion. Ce compte de service n’est pas rattaché à son identité SSO. Quand il part, son compte SSO est désactivé. Le compte de service persiste. L’agent persiste. Six mois plus tard, on découvre que cet ingénieur a toujours accès aux systèmes de production via ce compte de service, qui n’a jamais figuré dans le périmètre du ticket de départ.
C’est la pire issue. Un accès persistant, aucune trace d’audit de sa propriété, et un incident de sécurité potentiellement en germe.
Que faire au moment du départ
Quand une personne part, la question pour les agents IA n’est pas seulement « désactiver » ou « laisser tourner ». Elle dépend de l’utilité de l’agent pour l’entreprise.
L’étape d’évaluation saute souvent sous la pression du temps. Le réflexe est de tout suspendre immédiatement. C’est le choix sûr côté sécurité, mais il peut casser des flux opérationnels sans prévenir. Une brève fenêtre de revue de 24 à 48 heures avant suspension laisse à l’équipe le temps d’identifier les agents critiques qui méritent une réattribution plutôt qu’un retrait.
Le modèle de propriété qui évite le problème
Les scénarios ci-dessus partagent une cause racine : les agents ont été créés sans fiche de propriété formelle sur laquelle le processus de départ puisse s’appuyer.
Le correctif consiste à traiter la propriété d’un agent comme vous traitez l’attribution d’un rôle à un humain. À son enregistrement, un agent reçoit un propriétaire. Ce propriétaire est une personne nommée dans votre système d’identité, pas une équipe ni un service. Quand cette personne est signalée pour un départ, chacun de ses agents est signalé avec elle.
L’agent billing-reporter affiche un score de risque de 74 parce qu’il a un accès en lecture à Stripe. C’est celui qui demande une attention immédiate. Le résumeur de pipeline et le surveillant de dépôt peuvent sans doute être réattribués avec une revue minimale. Sans un registre qui fait remonter tout cela automatiquement, les trois restent invisibles pour le processus de départ.
Pour chaque agent signalé, la décision se ramène à trois options :
L’agent est encore utile. Un nouveau propriétaire en prend la responsabilité, revoit les rattachements d’accès en place, et confirme que la portée reste adaptée au travail qu’il effectue.
L’agent est peut-être utile mais demande plus d’examen que le temps disponible. Suspendez-le immédiatement pour couper l’accès, puis évaluez dans une fenêtre définie (48 heures est raisonnable).
L’agent était propre à la personne qui part, ou personne n’accepte de le prendre en charge. Révoquez l’accès, documentez la décision, et mettez-le hors service.
Le volet conformité
Le contrôle SOC 2 CC6.3 exige que l’accès soit retiré dès qu’il n’est plus nécessaire. Un agent dont le propriétaire est parti et dont l’accès n’a pas été revu est, par définition, un accès qui n’est peut-être plus nécessaire. Si un auditeur demande « comment vous assurez-vous que l’accès est retiré au départ d’un collaborateur » et que la réponse ne couvre pas les agents IA, c’est une faille dans le contrôle.
Le règlement européen sur l’IA ajoute une couche. Son article 14 impose que les systèmes d’IA à haut risque intègrent des mécanismes permettant à des humains de superviser et d’intervenir. Un agent sans propriétaire et jamais découvert, qui tourne sur des données de production, n’a aucun humain dans la boucle. C’est une faille de responsabilité, pas seulement de sécurité.
L’exigence pratique est simple : chaque agent IA de votre environnement doit avoir un propriétaire nommé dans votre système d’identité. Quand ce propriétaire fait l’objet d’un départ, l’agent est automatiquement signalé pour revue. La décision prise, quelle qu’elle soit, est consignée avec un horodatage et le nom du relecteur. Voilà à quoi ressemble un contrôle défendable.
Ce qui rend l’exercice difficile, c’est l’étape de découverte. Vous ne pouvez signaler les agents d’une personne qui part que si vous savez quels agents existent. Un registre qui capte la création d’un agent dès l’origine est ce qui rend l’étape de départ traitable. Sans lui, vous faites toujours de l’archéologie : chercher les agents après coup, sans registre faisant autorité sur ce qui a été construit.
Les questions qui suivent
Comment auditer les agents IA après le départ d’un collaborateur ?
Listez chaque agent que la personne détenait ou avait créé, vérifiez ce à quoi il accède et si l’activité en a encore besoin, puis réattribuez-le, suspendez-le ou révoquez-le et journalisez la décision. Sans registre d’agents, la première étape devient une recherche manuelle et des agents passent entre les mailles.
Pourquoi les agents IA continuent-ils de tourner après la désactivation du compte Okta ?
Les agents s’authentifient généralement avec des clés API, des jetons OAuth ou un compte de service dédié, pas avec la session SSO du collaborateur. Désactiver le compte SSO ne révoque pas ces identifiants, et l’agent n’est pas un utilisateur de l’IdP : aucun événement SCIM ne l’atteint.
Faut-il suspendre chaque agent dès le départ de son propriétaire ?
La suspension est le réflexe prudent, mais elle peut casser des processus dont l’activité dépend. Une courte fenêtre de revue de 24 à 48 heures permet de réattribuer les agents critiques au lieu de les supprimer, et tout agent que personne ne réclame est révoqué.
Qu’attend un auditeur pour les agents IA lors d’un départ ?
La preuve que les accès sont retirés quand ils ne sont plus nécessaires (SOC 2 CC6.3) s’étend aux agents : pour chaque agent détenu par la personne partie, la décision prise, par qui et quand. Si le contrôle de départ ne couvre pas les agents, c’est une faille du contrôle.
En trente minutes, nous transposons Lutril sur votre stack et vous montrons ce que donne la gouvernance des accès en temps réel pour votre équipe. Sans slides.
Réserver une démo