Un responsable des opérations retire à un agent l'autorisation de libérer des paiements. Le processus principal de l'agent s'arrête. Un paiement reste dans une file d'attente, une tâche déléguée est toujours en cours, et un worker peut relancer une requête dont l'issue est incertaine. Chacun de ces éléments doit faire l'objet d'un traitement documenté, confié à un responsable, avant que le responsable de l'incident puisse dire ce qui s'est arrêté.
Ce scénario est illustratif. Il pose une question de recherche : quelles observations étayent l'affirmation que l'autorité retirée à un agent ne peut plus déclencher d'action, dans un périmètre déclaré ? Nous passons en revue des travaux de recherche et des spécifications de protocoles récents, rendons compte d'une petite reproduction d'un vérificateur de clôture publié, et proposons une fiche que le responsable d'un incident peut remplir. Cet article fait partie d'une série de recherche en trois volets sur l'autorité des agents, publiée le 26 octobre 2026 : preuves d'arrêt, politiques dans la mémoire des agents et standards de contrôle des agents.
Définir d'abord le périmètre de l'affirmation
Des travaux récents distinguent des étapes qu'un simple statut « révoqué » peut masquer. Revocation Is Not Complete at Receipt, une prépublication d'octobre 2026 de Lifei Liu, Haoran Yu et Danping Zhang, distingue la validation et la transmission d'une révocation de son application par les passerelles et de la prévention des effets protégés pendant une fenêtre d'observation. Ses expériences utilisent une seule topologie de transmission, volontairement partitionnée, et les auteurs ne donnent aucun taux de défaillance à l'échelle du secteur. Lire l'article.
Une prépublication de septembre 2026 de Genliang Zhu et Chu Wang traite de l'autorité qui se prolonge à travers la délégation et le travail asynchrone. Son protocole suit l'origine de l'autorité et l'évolution de l'état d'autorisation, et vérifie l'autorisation au point où une action prend effet. Il tient aussi compte du travail qui se poursuit sous une autre autorité, distincte et valide. Les deux articles sont des prépublications ; leurs résultats dépendent des hypothèses qu'ils énoncent. Lire le protocole et l'évaluation.
L'étape pratique consiste à rédiger l'affirmation avant d'en réunir les preuves. Nommez l'autorité retirée, les actions concernées, les voies d'application et la fenêtre d'observation. Consignez explicitement les exclusions. Une déclaration sur la libération de paiements doit préciser si elle couvre les tâches planifiées, les relances, les workers délégués et les requêtes qu'un prestataire de paiement avait déjà acceptées.
La transmission et l'annulation ont des limites définies
Les protocoles existants couvrent déjà une partie de ce problème. La spécification OAuth de révocation des jetons traite du délai de propagation, et la spécification d'introspection des jetons décrit le coût en sécurité de la mise en cache des réponses d'introspection. Les deux comptent lorsque les workers d'un agent consultent des copies différentes de l'état d'autorisation. RFC 7009, RFC 7662.
Les versions finales des spécifications OpenID CAEP 1.0 et Shared Signals Framework 1.0 définissent des contrats d'événements et de transmission qui peuvent coordonner un changement entre systèmes. Le responsable de l'incident a toujours besoin de preuves de ce que chaque récepteur et chaque point d'application en aval ont fait du signal. CAEP 1.0, Shared Signals Framework 1.0.
L'annulation a ses propres limites. La spécification du Model Context Protocol datée du 2025-06-18 rend les notifications d'annulation facultatives et reconnaît que le traitement peut déjà être terminé, ou impossible à annuler. Un compte rendu de l'issue d'un workflow doit tenir compte de ces courses entre annulation et achèvement. Annulation MCP.
Ce que nous avons vérifié de façon indépendante
RISU Research publie un vérificateur de clôture distinct, bounded-agent-closure. Il est cité dans les travaux connexes et se distingue des deux prépublications ci-dessus. Nous avons exécuté sa suite de tests sans modification au commit ef07236 (paquet 0.3.1, Node 20) : les 75 tests ont réussi. Nous avons ensuite soumis au vérificateur les huit lots de preuves synthétiques fournis et conservé les décisions qu'il a rendues. Dépôt amont épinglé.
- Une vue manquante est une lacune. Lorsque la vue du planificateur était absente, le vérificateur a rendu UNKNOWN.
- Une tâche encore planifiée correspond à du travail inachevé. La présence d'une telle tâche a donné INCOMPLETE, même lorsque le lot déclarait un succès.
- L'historique peut rester. Des preuves historiques conservées étaient compatibles avec CLOSED dans ce profil.
- Les successeurs sont explicites. Un transfert à un successeur a été clos dans les conditions encodées par le cas.
| Cas fourni | Résultat observé |
|---|---|
| Tâche survivante directe | INCOMPLETE |
| Tâche survivante transitive | INCOMPLETE |
| Engagement en attente | INCOMPLETE |
| Preuves conservées | CLOSED |
| Transfert à un successeur | CLOSED |
| Couverture manquante | UNKNOWN |
| Succès déclaré alors qu'une tâche reste planifiée | INCOMPLETE |
| Mise à l'arrêt achevée avec des relevés finaux stables | CLOSED |
Ce que la reproduction ne montre pas
Le vérificateur évalue les preuves qu'on lui fournit. Notre exécution n'a lancé aucun agent, aucune file d'attente ni aucun paiement, n'a pas recherché de files cachées, et ne montre pas qu'un collecteur réel rapporte tout fidèlement. La suite de tests et le rejeu des cas se recoupent : les huit cas ne constituent donc pas huit validations indépendantes supplémentaires. Un résultat du vérificateur ne vaut que par le périmètre des preuves et le processus de collecte qui le sous-tendent.
Nous n'avons reproduit aucune des deux prépublications. Le premier article rapporte 112 effets protégés sur 225 tentatives dans sa topologie partitionnée ; le second rapporte 17 cas acceptés et 44 mutations rejetées pour son outil de contrôle. Ces deux chiffres sont ceux des auteurs. Le point d'accès aux artefacts du premier article n'a renvoyé aucun contenu exploitable avec nos outils.
Donner au responsable de l'incident un dossier de preuves
Nous avons tiré de ces travaux une fiche de preuves d'arrêt (en anglais). Elle demande l'autorité retirée, le travail en aval, les points qui appliquent le retrait, les effets déjà produits et les observations non résolues. Elle prévoit de la place pour le travail repris par un successeur sous une autorité indépendante et pour la personne responsable du rapprochement.
Prenons un worker qui a envoyé une demande de paiement avant la révocation et en reçoit l'accusé de réception après. Cet accusé appartient au dossier d'incident. L'action suivante du worker exige sa propre vérification d'autorisation à jour. Un effet déjà produit peut appeler une réponse métier distincte, comme un rapprochement ou une contrepassation autorisée. La fiche consigne ces responsabilités et ne présume la réversibilité d'aucun effet.
| Champ | À consigner |
|---|---|
| Autorité retirée | Identifiants de la racine et de la délégation ; identifiants de la demande de révocation et du changement validé |
| Fenêtre d'observation | Sources d'horloge, incertitude, début et fin |
| Périmètre | Actions et destinations des effets incluses ; voies exclues et motif de chaque exclusion |
| Voies d'application | Dernière version d'autorisation observée sur chaque voie |
| Travail en attente ou en cours | Entrées de file d'attente, relances, travail délégué et engagements en attente |
| Sort de chaque élément | Empêché, achevé avant la coupure, transféré, en attente ou inconnu |
| Après la coupure | Tentatives et effets déjà produits ; accusés de réception tardifs et actions de rapprochement |
| Lacunes | Collecteurs manquants, vues périmées ou preuves contradictoires |
| Responsables | Actions restantes, responsables et date de la prochaine revue |
Rédiger la déclaration d'arrêt avec ses limites
La fiche se termine par une déclaration que le responsable de l'incident peut réutiliser : « Pour [autorité] et [voies déclarées], les observations de [début] à [fin] montrent [résultat]. [Éléments] restent non résolus en raison de [lacune de preuve précise]. [Responsable] est chargé du rapprochement. »
Conservez les limites temporelles et de périmètre quand la déclaration est reprise dans une synthèse d'incident. La déclaration indique alors quelles actions ont été empêchées, lesquelles avaient déjà produit leurs effets, quelles tâches ont été transférées et quelles observations manquent. Les responsables des opérations, de l'ingénierie et des risques peuvent examiner un seul dossier dans lequel le mot « arrêté » a un sens clair.
Comment le chemin d'arrêt de KLA se rapporte à la fiche
Les agents qui agissent via l'ingestion d'actions d'agents de KLA travaillent sous un mandat d'agent. La révocation du mandat bloque les propositions ouvertes qui y sont liées avec le code de motif mandate_revoked, annule leurs Decision Requests en attente et refuse la prochaine action proposée par l'agent. Une action déjà admise peut se terminer ; elle relève alors des lignes « achevé avant la coupure » ou « après la coupure » de la fiche.
Les travaux présentés dans cet article n'ont pas testé KLA. Le guide d'architecture du kill switch décrit le chemin d'arrêt complet de KLA, y compris le gel depuis l'incident, et le playbook de réponse aux incidents couvre le reste du dossier d'incident.
Foire aux questions
Comment prouver qu'un agent d'IA s'est arrêté ?
Énoncez d'abord l'affirmation : l'autorité retirée, les voies couvertes et la fenêtre d'observation. Consignez ensuite la dernière version d'autorisation vue sur chaque voie d'application, le sort de chaque élément en file, relancé ou délégué, les effets déjà produits après la coupure et les preuves manquantes. L'affirmation ne vaut que dans ce périmètre et cette fenêtre.
La révocation du jeton d'un agent arrête-t-elle le travail déjà en cours ?
Pas nécessairement. La propagation d'une révocation OAuth peut prendre du temps et une introspection mise en cache peut être périmée. Le travail déjà en file, délégué ou accepté par un système en aval peut encore se terminer, et l'annulation MCP est facultative et peut entrer en concurrence avec l'achèvement. Le traitement de chaque élément doit être consigné.
Peut-on annuler les actions déjà réalisées par un agent révoqué ?
La révocation arrête les nouvelles actions. Un effet déjà produit subsiste : un paiement, par exemple, appelle une réponse métier distincte, comme un rapprochement ou une contrepassation autorisée, consignée avec son responsable.
Qu'a montré la reproduction du vérificateur de clôture ?
Au commit ef07236, les 75 tests amont ont réussi, et les huit lots synthétiques fournis ont donné trois CLOSED, quatre INCOMPLETE et un UNKNOWN. L'exécution n'a évalué que les preuves fournies. Elle n'a lancé aucun agent ni aucune file d'attente et ne dit rien de l'exhaustivité d'un collecteur réel.
Points clés à retenir
Un agent n'est arrêté que dans un périmètre que quelqu'un a mis par écrit : l'autorité, les voies et la fenêtre de temps. Réunissez les preuves pour ce périmètre, documentez le traitement de chaque élément non clos, et nommez les lacunes et leurs responsables. Commencez par la fiche de preuves d'arrêt, et lisez l'architecture du kill switch pour les contrôles qui produisent ces preuves.
Les sources ont été vérifiées le 26 octobre 2026. Les deux prépublications n'ont pas été reproduites de façon indépendante. Nos observations reposent sur des cas synthétiques publiés et ne contiennent aucun résultat de production de KLA.