Un agent pilote peut être « arrêté » dans son interface et conserver malgré tout un accès ailleurs : cela dépend des connecteurs, des identités et des tâches qui l’entourent. La bonne question avant le premier essai n’est donc pas seulement « que peut-il faire ? », mais « qui pourra constater, système par système, qu’il ne peut plus le faire ? »
Pour chaque accès, consignez une tâche, un propriétaire, un périmètre, une échéance et une preuve de retrait attendue. À la fermeture du pilote, demandez la vérification au responsable du système concerné. Une capture d’écran du bouton « pause » ne tient pas lieu de réponse.
Valider un brouillon ne retire aucun droit
La validation humaine d’une réponse concerne une action. La permission d’un connecteur détermine ce que l’agent, ou le service qui agit pour lui, peut demander au système. On peut interdire l’envoi d’un message dans un workflow tout en laissant au connecteur un droit d’écriture inutile. Inversement, un prompt qui dit « lecture seule » ne fait pas office de contrôle d’autorisation.
OWASP distingue les fonctionnalités, permissions et autonomie excessives ; il recommande de faire appliquer les autorisations dans les systèmes en aval, plutôt que de compter sur les décisions du modèle (LLM06:2025 Excessive Agency, consulté le 25/09/2026). Si vous décidez encore où placer l’approbation d’une action, notre article sur la validation humaine dans un workflow IA couvre cette autre décision.
Écrire la fiche avant d’ouvrir le premier connecteur
Prenons un exemple entièrement fictif : dans un bac d’essai sans dossier client, un agent trie des demandes factices et prépare un brouillon interne. Il n’envoie aucun message et n’a aucun compte administrateur. La fiche ci-dessous décrit le résultat voulu, pas une configuration à copier telle quelle.
| Tâche | Ressource et action | Propriétaire | Fin prévue | Preuve de retrait attendue |
|---|---|---|---|---|
| Trier des demandes d’essai | Sous-ensemble de demandes factices ; lecture | Responsable du bac d’essai | Fin du pilote ou changement de propriétaire | Autorisation supprimée côté outil et nouvelle lecture refusée sur une ressource factice |
| Préparer un brouillon interne | Espace de brouillons du test ; création sans envoi | Responsable de l’outil de brouillons | Même échéance, revue si la tâche change | Droit de création retiré et nouveau brouillon-test refusé |
Ce schéma résume le contrôle, sans remplacer les propriétaires et les preuves attendues détaillés dans la fiche ci-dessus. Exemple fictif, pas une trace de révocation réelle.
La colonne « propriétaire » nomme la personne habilitée à demander et vérifier le retrait ; elle ne prétend pas que l’agent possède une identité indépendante dans tous les produits. Ajoutez à la vraie fiche le mode d’identité utilisé, le responsable métier qui autorise le pilote, la personne qui administre chaque connecteur et le moyen de la joindre. Si ces rôles se confondent, notez-le. Ne mettez jamais de secret, d’identifiant sensible ou de contenu métier dans la fiche.
Microsoft recommande une identité d’agent suivie dans le temps, avec un propriétaire humain identifié, des rôles liés à la tâche et des droits délimités par ressource, donnée et opération. La limitation dans le temps peut porter sur le droit ou l’approbation, sans recréer une identité à chaque tâche (Microsoft Security, 16/07/2026). C’est un cadre d’architecture, pas la preuve que vos outils disposent tous d’une expiration automatique.
La date de fin doit appartenir à quelqu’un
Inscrivez avant activation la condition de fin : date prévue, tâche abandonnée, changement de propriétaire ou élargissement du périmètre. Nommez la personne qui déclenche la revue avant cette échéance et celle qui peut retirer effectivement chaque droit. Si l’outil ne sait pas faire expirer l’autorisation, prévoyez une action manuelle et un contrôle ; ne présentez pas une simple date dans un tableur comme une expiration technique.
L’automatisation est possible dans certains produits. Okta Identity Governance décrit, pour les demandes d’accès aux applications liées aux agents IA dans son propre périmètre, une durée d’accès après laquelle l’accès est révoqué automatiquement (documentation Okta Identity Engine, consultée le 25/09/2026). Ce comportement ne vaut ni pour tous les connecteurs ni pour toutes les identités d’agent.
Le renouvellement n’est pas un silence qui prolonge tout. À l’échéance, le propriétaire confirme la tâche encore utile, revoit les ressources et opérations réellement utilisées, choisit « renouveler avec une nouvelle fin » ou « fermer », puis consigne qui a pris la décision. Un nouveau connecteur ou un nouveau périmètre appelle une nouvelle revue, pas un simple report de date. La guidance Microsoft Learn recommande précisément de revoir les accès lorsqu’un workflow, ses outils ou ses données changent (consultée le 25/09/2026).
Fermer le pilote : cinq objets à distinguer
Mettre l’agent en pause empêche éventuellement de nouvelles exécutions depuis son interface ; cela ne démontre pas que le fournisseur du connecteur refusera un autre appel. Retirer un rôle ou une autorisation modifie la capacité accordée dans le système qui la porte. Invalider un jeton ou une session relève du mécanisme du fournisseur : demandez à son responsable quelle invalidation existe et comment elle est vérifiée, sans supposer un effet immédiat universel. Désactiver les travaux planifiés évite qu’un traitement en attente relance l’ancien flux. Traiter les données déjà copiées est une décision séparée : retirer un droit futur n’efface pas une copie déjà produite.
Ce sont des contrôles à instruire pour chaque intégration, non une séquence technique universelle. Microsoft demande de tester les chemins de révocation, notamment identité, identifiants, jetons et permissions obsolètes (Microsoft Learn, consulté le 25/09/2026). Une injection de prompt indirecte pose une autre question : ce que l’agent peut faire face à une source hostile. Un incident d’agent IA réclame sa propre procédure de confinement ; fermer un pilote prévu n’est pas une réponse à incident.
Prouver le retrait sans conserver un dossier sensible
Le propriétaire métier demande au responsable de chaque système deux constats : l’autorisation n’y apparaît plus pour le périmètre convenu, et une tentative inoffensive d’accès à une ressource de test précédemment autorisée y est refusée. Le refus d’une interface seule ne suffit pas si le droit était porté ailleurs. Si un test de refus est impossible ou risqué, indiquez « non vérifié », faites décrire le contrôle alternatif par le fournisseur et ne déclarez pas l’accès révoqué sur la seule foi d’un clic.
Conservez le minimum utile : connecteur et périmètre non sensible, propriétaire, date de retrait, résultat du contrôle, éventuel travail en attente et décision « fermé » ou « renouvelé ». Pas de jeton, d’extrait de dossier, de capture contenant des données personnelles ni de journal brut dans cet article ou dans une fiche partagée. Le modèle de preuve est une proposition de gouvernance, pas une certification IAM. Il ne garantit pas l’effacement de ce que l’agent a pu exporter auparavant.
Les questions à poser au prestataire avant le premier essai
Plutôt qu’une promesse générale de sécurité, demandez un exemplaire expurgé de la fiche et une démonstration sur des données d’essai :
- Qui autorise le pilote et qui administre chaque droit côté fournisseur ?
- Quelle identité porte effectivement le droit, et quelles ressources et opérations sont comprises ?
- Quelle date ou condition déclenche la revue, et qui la reçoit si le propriétaire quitte le projet ?
- Qu’est-ce qui s’arrête avec le bouton pause, et quels droits, sessions ou travaux restent à traiter séparément ?
- Dans quel système sera observé le refus après retrait, sur quelle ressource de test sans risque ?
- Qui choisit de fermer ou renouveler, et où garde-t-on la preuve non sensible de cette décision ?
Si personne ne sait répondre à la cinquième question, gardez le pilote déconnecté de cet outil jusqu’à ce qu’une méthode de vérification soit définie. Pour choisir la frontière entre les outils, voir MCP vs API pour un agent IA ; cette décision technique ne remplace pas la fiche de fin de vie.
Un agent pilote va accéder à vos outils ? Décrivons une tâche, ses accès minimaux et la preuve de leur retrait avant de le brancher. Vous pouvez aussi nous écrire avec votre périmètre d’essai, sans partager d’identifiants ni de données sensibles.
