Un kill switch d'agent IA véritablement utile est un chemin de confinement coordonné. Il doit stopper le travail en cours, refuser la prochaine action proposée, fermer le chemin d'identité, isoler la charge de travail et préserver une trace de ce qui s'est passé. Un contrôle unique ne couvre qu'une partie de cette mission. Ce guide présente l'architecture, les modes de défaillance et les preuves de test qu'un opérateur devrait exiger. Il suit la leçon pratique de notre analyse de l'intrusion par agent autonome chez Hugging Face : une action à la vitesse machine exige un contrôle sur le chemin d'action. Conseils techniques d'ordre général uniquement ; adaptez la conception à vos systèmes et à votre modèle de menace.
Le terme « kill switch » recouvre plusieurs contrôles
Les plateformes d'identité emploient ce terme pour le confinement des accès. L'article de support d'Okta de juin 2026 indique que son kill switch actuel est une action manuelle et demande à un administrateur de désactiver l'enregistrement de l'agent, l'application liée et le serveur d'autorisation associé. Son annonce pour les environnements réglementés décrit la désactivation manuelle comme l'action qui empêche les nouvelles demandes de jetons et les autorisations futures.
Ces contrôles ferment un chemin d'identité. Le système d'exploitation peut encore héberger un worker en mémoire, une file d'attente peut encore contenir des travaux planifiés, et un service en aval peut déjà avoir accepté une requête. Un arrêt au niveau du système propage donc une même commande d'incident vers plusieurs points d'application indépendants.
Traitez la commande comme un changement d'état versionné portant un identifiant d'incident, un tenant, un périmètre cible, un motif, un acteur, une heure d'émission et une échéance. Chaque point d'application accuse réception de la même commande et rapporte son résultat. L'incident reste non confiné tant qu'il manque un accusé de réception requis.
| Point d'application | Action requise | Preuve d'accusé de réception |
|---|---|---|
| Orchestrateur d'exécution | Annuler les exécutions actives et retirer les travaux en file pour l'agent, la Release, le tenant ou l'environnement sélectionné | ID d'exécution, état antérieur, état terminal, heure d'annulation, activité inachevée |
| Point d'application des politiques | Refuser chaque nouvel appel d'outil et chaque diffusion de sortie couverts par le périmètre de l'incident | Version de la règle d'incident, reçu de décision, première action refusée, nombre de refus |
| Identité et secrets | Désactiver l'identité de l'agent, révoquer les jetons, effectuer la rotation des identifiants exposés et empêcher leur rafraîchissement | ID d'identité, ID des jetons et des clés, résultat de la révocation, expiration de l'accès résiduel |
| Charge de travail et réseau | Terminer ou mettre en quarantaine les workers et appliquer la politique de sortie réseau de l'incident | ID des charges de travail, politique d'isolation, inventaire des connexions, heure de mise en quarantaine |
| Systèmes en aval | Rejeter l'identité de l'incident ou les clés d'idempotence et arrêter les effets de bord en attente | ID des requêtes rejetées, travaux en attente supprimés, liste des effets de bord déjà validés |
| Magasin de preuves | Sceller la commande, les accusés de réception, les décisions de politique et les lacunes | Chronologie de l'incident, résultat d'intégrité, statut de l'exportateur, responsable des preuves nommé |
Une coupure réseau laisse plusieurs chemins d'exécution ouverts
L'isolation réseau est l'un des actionneurs de cette propagation. Elle stoppe le trafic qui franchit la frontière qu'elle contrôle. Le code local peut continuer à s'exécuter, une transaction de base de données peut déjà être validée, un travail externe peut se poursuivre après acceptation de la requête, et un worker peut détenir un identifiant qui reste valide sur une autre route.
La frontière sûre se situe immédiatement avant chaque effet de bord. L'agent propose un appel d'outil. Un point d'application vérifie l'état de l'incident, l'identité, l'outil, les arguments, la politique et le budget courant. L'appel ne se poursuit qu'après cette décision. Une commande d'arrêt met à jour l'état d'incident que chaque vérification ultérieure lit.
Cette conception couvre aussi les agents qui ignorent un signal interne au processus. Le composant décisionnaire s'exécute hors du processus de l'agent et détient l'accès à l'outil. La terminaison de la charge de travail raccourcit alors le délai de confinement pendant que le point d'application externe empêche de nouveaux effets.
- Exécution locale : terminer ou mettre en quarantaine le processus, le conteneur, la machine virtuelle ou la sandbox
- Exécution en file d'attente : annuler les messages planifiés et invalider les baux détenus par les workers
- Exécution avec identifiants : révoquer ou renouveler chaque identifiant accessible depuis le périmètre affecté
- Travail accepté en aval : annuler les travaux en attente via l'API du système aval et lister les travaux déjà validés
- Travail approuvé par un humain : clore les Decision Requests en attente et empêcher qu'une approbation tardive relance l'exécution
La séquence d'arrêt
La séquence ci-dessous minimise l'écart entre l'action de l'opérateur et le dernier effet de bord possible. La première écriture durable établit l'époque de l'incident. Chaque point d'application des politiques lit cette époque avant d'exécuter un appel gouverné.
| Ordre | Commande | Condition d'achèvement |
|---|---|---|
| 1 | Créer la commande d'incident et placer le périmètre affecté en refus | L'époque d'incident durable est lisible par chaque point d'application |
| 2 | Signaler les exécutions actives et annuler les travaux en file | Chaque exécution est dans un état terminal ou explicitement listée comme encore en cours |
| 3 | Désactiver les identités, révoquer les jetons et renouveler les secrets exposés | Toute nouvelle autorisation échoue et la durée de vie résiduelle des jetons est consignée |
| 4 | Mettre les charges de travail en quarantaine et restreindre le trafic sortant | Les ressources de calcul affectées ne disposent d'aucune route non approuvée vers un outil ou un magasin de données |
| 5 | Annuler les travaux aval en attente et lancer les actions compensatoires | Chaque requête acceptée se trouve dans un état terminé, en attente, en échec ou en compensation |
| 6 | Sceller le dossier de confinement et exposer les accusés de réception manquants | Le responsable de l'incident peut voir le dernier effet de bord, l'exposition restante et les lacunes de preuve |
Comment se comporte le chemin d'arrêt KLA
KLA Control Plane s'appuie sur des contrôles distincts, KLA Runtime et KLA Policy Engine. Un intervenant disposant de la permission de gestion des incidents peut geler une exécution en cours depuis son incident. Le gel envoie un signal kill au workflow de l'exécution, qui l'enregistre comme CANCELLED. Le workflow vérifie le signal avant de démarrer un autre nœud. Une exécution en attente d'une Decision Request observe le signal, annule la demande en attente et se termine sans reprendre l'action proposée. Lorsque l'exécution porte une action d'agent en attente, le worker annule cette action et KLA scelle un reçu d'annulation.
La route générale d'annulation des exécutions ne ferme que les enregistrements orphelins dont le workflow est confirmé absent, et elle ne peut pas arrêter une exécution saine. Les exercices et les runbooks doivent donc utiliser le gel depuis l'incident. Geler un agent depuis un incident met en pause ses étapes dans Processes : chaque étape d'agent vérifie le gel avant de s'exécuter, puis confie le travail à une personne ou arrête l'exécution.
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. La pause de l'agent ne s'applique pas sur ce chemin : révoquez le mandat pour arrêter un agent qui passe par l'ingestion.
Lorsqu'elle est activée, la passerelle de gouvernance de KLA Policy Engine évalue les appels d'outils proposés et applique allow, warn, require_approval ou block. Si l'évaluation de la politique échoue, la passerelle applique par défaut block en production et require_approval dans les autres environnements, jamais allow. Une approbation est liée à une empreinte des arguments de l'outil, et des arguments modifiés sont bloqués. L'opération de nettoyage de la passerelle pour les appels retenus enregistre les entrées de registre annulées et scelle des reçus d'annulation. KLA l'appelle lorsqu'une action d'agent en attente est annulée ; les opérateurs doivent donc vérifier séparément toute autre entrée retenue pendant le confinement.
Une activité qui a déjà franchi son point d'application peut se terminer avant que le workflow n'observe le signal. L'idempotence en aval, la terminaison des charges de travail et les actions compensatoires couvrent cet intervalle. Le dossier d'incident doit indiquer le dernier effet de bord validé après l'émission de la commande par l'opérateur.
Cette section décrit le code source actuel de KLA.
Le guide Autonomie responsable explique où se situent les décisions humaines en fonctionnement ordinaire. Pendant le confinement, le périmètre de l'incident est prioritaire et une approbation tardive ne peut pas rouvrir une exécution annulée.
Concevez chaque mode dégradé
Le chemin d'arrêt a le plus de valeur au moment où une partie du système défaille. Chaque actionneur a besoin d'un état sûr local, d'une échéance et d'un statut d'accusé de réception visible.
| Défaillance | Comportement requis | Preuves à conserver |
|---|---|---|
| Service de politiques injoignable | Appliquer la décision locale de refus par défaut (fail-closed) et conserver l'époque d'incident dans le cache d'application | Code de motif, version du cache, action refusée, heure de rétablissement |
| Signal de workflow retardé | Refuser les nouveaux effets de bord au point d'application et mettre la charge de travail en quarantaine | Tentatives de signal, état du workflow, accusé de réception de la quarantaine |
| Fournisseur d'identité indisponible | Appliquer les règles de refus en aval, isoler la charge de travail et faire expirer les identifiants de courte durée | Erreur du fournisseur, durée de vie résiduelle des identifiants, systèmes sous refus local |
| Exportateur de preuves indisponible | Conserver les enregistrements sources de manière durable et marquer le bundle comme en attente | Emplacements des enregistrements sources, état d'intégrité, responsable des reprises |
| Un effet de bord déjà validé | Ouvrir la procédure de compensation ou de récupération propre au système | Requête d'origine, résultat validé, responsable et résultat de la compensation |
| Un actionneur n'accuse jamais réception | Maintenir l'incident non confiné et l'escalader vers le propriétaire de système désigné | Actionneur manquant, temps écoulé, historique d'escalade |
Testez le kill switch comme un système de contrôle
Une réponse du tableau de bord confirme la réception de la demande de l'opérateur. L'acceptation exige des preuves de chaque point d'application et une borne supérieure observée sur le dernier effet de bord.
Les éléments Manage 2.4 et Manage 4 du NIST AI RMF appellent des mécanismes permettant de désengager ou de désactiver les systèmes d'IA dont les résultats s'écartent de l'usage prévu, ainsi qu'une réponse aux incidents, une récupération et une communication documentées. Le profil IA générative du NIST ajoute une responsabilité nominative, des exercices de répétition, l'amélioration rétrospective et l'alignement sur les obligations légales de signalement pour les plans de réponse aux incidents liés à l'IA tierce.
Nous l'avons appris lors de nos propres tests internes. Un intervenant a mené l'action de gel de l'agent jusqu'au bout du flux de confinement, avec un code de motif, une explication et une revue du périmètre d'impact et de la réversibilité, puis l'a validée. La requête a échoué avec une erreur que l'écran n'affichait pas, et l'incident restait marqué comme non confiné. L'incident faisait référence à l'exécution, alors que le gel avait besoin de l'agent. Nous avons modifié l'action pour qu'elle retrouve l'agent à partir de l'exécution, ou qu'elle renvoie une erreur indiquant l'action à utiliser à la place. Un test doit donc vérifier l'état final de chaque exécution : un intervenant doit savoir si le confinement a eu lieu.
- Exécution active : émettez la commande pendant qu'une exécution multi-étapes se trouve entre deux appels d'outils et vérifiez que l'appel suivant est refusé
- Attente d'approbation : émettez-la pendant qu'une Decision Request est ouverte et vérifiez qu'une approbation ultérieure ne peut pas relancer l'exécution
- Panne du service de politiques : déconnectez le service de politiques et vérifiez qu'aucune action proposée ne se résout en allow
- Identifiant périmé : tentez un accès avec chaque classe de jetons émise avant la commande et consignez la durée de vie résiduelle
- Travaux en file : injectez des travaux planifiés et confirmez que chacun atteint un état terminal ou compensatoire
- Processus non coopératif : ignorez le signal interne au processus et vérifiez que le point d'application externe et l'isolation de la charge de travail assurent malgré tout le confinement
- Défaillance des preuves : arrêtez l'exportateur et confirmez que l'enregistrement source reste durable avec un responsable des reprises visible
- Rétablissement : restaurez une Release sous une nouvelle identité et vérifiez que le refus d'incident reste appliqué à chaque version antérieure affectée
Organisez un exercice de kill switch
Un exercice transforme le chemin d'arrêt en temps mesurés. Menez-le dans un environnement de test avec un agent synthétique qui détient les mêmes types de droits que l'agent de production : une exécution en cours, une Decision Request en attente, un appel d'outil retenu et un identifiant actif. Désignez un responsable de l'exercice, un observateur qui tient le chronomètre et le responsable de chaque système aval.
Un kill switch arrête les actions futures. Un paiement réglé, un e-mail remis ou un enregistrement écrasé avant la commande reste acquis. L'exercice repère ces effets et confie chacun à la procédure de correction du système qui en est responsable.
Nous avons compris pourquoi lors de nos propres tests internes. Un intervenant a mené Freeze agent jusqu'au bout du parcours de confinement, avec un code motif, une explication et une revue du rayon d'impact et de la réversibilité, puis l'a validé. La requête a échoué avec une erreur que l'écran n'affichait pas, et l'incident restait marqué non confiné. L'incident référençait l'exécution, alors que le gel avait besoin de l'agent. Nous avons modifié l'action pour qu'elle retrouve l'agent à partir de l'exécution, ou renvoie une erreur qui nomme l'action à utiliser à la place. C'est pour cette raison que l'étape 2 de l'exercice vérifie l'état final de chaque exécution : un intervenant doit savoir si le confinement a eu lieu.
- Rétablissez uniquement lorsque la cause est connue ou confinée, que chaque action en cours a un état, que chaque effet acquis a un responsable de correction et qu'une personne autre que le demandeur a approuvé la nouvelle autorité.
- Laissez l'ancienne autorité révoquée. L'agent rétabli fonctionne sous un nouveau mandat ou une nouvelle Release, et un test montre que l'ancienne refuse toujours.
- Renforcez la surveillance de l'agent rétabli et fixez le seuil qui met fin à la surveillance renforcée.
| Étape | Action | Condition de réussite | Enregistrement |
|---|---|---|---|
| 1. Déclarer | Ouvrez l'incident, définissez le périmètre (agent, Release, tenant ou environnement) et lancez le chronomètre à T0 | L'incident et le périmètre existent avant tout déclenchement d'actionneur | Identifiant de l'incident, périmètre, déclarant, T0 |
| 2. Geler les exécutions | Gelez chaque exécution active du périmètre et gelez l'agent pour les étapes de Process | Chaque exécution du périmètre est CANCELLED ou listée comme toujours en cours | Identifiants d'exécution, état antérieur, état final, heure |
| 3. Révoquer l'autorité | Révoquez le mandat de l'agent, désactivez l'identité et révoquez les jetons auprès du fournisseur d'identité | Toute nouvelle autorisation échoue et la durée de vie résiduelle des jetons est connue | Auteur de la révocation, motif, heure, identifiants et expiration des jetons |
| 4. Tenter l'action suivante | Faites proposer à l'agent synthétique son action suivante sur chaque chemin qu'il a utilisé : ingestion, passerelle et appel direct avec un ancien jeton | Chaque tentative est refusée et aucune n'atteint le système aval | Heure de la tentative, chemin, code de refus tel que mandate_revoked, journal aval |
| 5. Classer le travail en cours | Listez chaque action en cours ou retenue à T0 | Chaque action est terminée avant T0, terminée après T0, annulée ou en attente, sans aucun état inconnu | Identifiant de l'action, état, heure de validation, responsable |
| 6. Tenter une approbation tardive | Approuvez la Decision Request qui était en attente à T0 | L'approbation ne peut pas relancer l'exécution annulée | Tentative de décision et refus |
| 7. Rétablir | Émettez un nouveau mandat ou une nouvelle Release avec de nouveaux identifiants une fois les conditions de rétablissement réunies | Seule la nouvelle autorité fonctionne ; le mandat révoqué refuse toujours | Approbateur du rétablissement, conditions vérifiées, première action autorisée |
| 8. Clore | Scellez l'enregistrement de l'exercice et listez chaque lacune avec un responsable | Le responsable de l'incident signe l'enregistrement | Référence des preuves, lacunes, responsables de la remédiation, date du prochain exercice |
Exemple d'enregistrement d'exercice (synthétique)
L'enregistrement ci-dessous est synthétique. Il montre le niveau de détail qu'un exercice doit conserver, y compris les constats qu'un exercice a pour objet de faire apparaître.
| Heure (UTC) | Événement | Résultat |
|---|---|---|
| 09:00:00 | Le responsable de l'exercice déclare l'incident INC-DRILL-07 pour un agent de paiement synthétique | Périmètre enregistré |
| 09:00:40 | L'intervenant gèle l'exécution R-118 (en cours) et l'exécution R-121 (en attente d'une Decision Request) | Les deux exécutions sont CANCELLED à 09:00:44 ; la Decision Request de R-121 est annulée |
| 09:01:10 | Le responsable conformité révoque le mandat de l'agent avec le motif « drill » | Deux propositions ouvertes bloquées avec mandate_revoked |
| 09:01:30 | Le responsable de l'identité désactive l'identité de l'agent et révoque ses jetons | Un jeton d'accès émis à 08:55 reste valide auprès de l'API cible jusqu'à 09:10 |
| 09:02:05 | L'agent synthétique propose payments.create_transfer via l'ingestion | Refusé avec mandate_revoked ; aucune requête dans le journal du système de paiement |
| 09:02:20 | L'agent synthétique appelle directement l'API cible avec le jeton de 08:55 | Accepté par l'API cible. Constat : fermer la fenêtre résiduelle des jetons dans le système cible |
| 09:03:00 | L'observateur classe le travail en cours | Un virement validé à 09:00:41 dans R-118 avant que l'exécution ne lise le signal. Constat : la trésorerie est responsable de la demande de rappel |
| 09:04:30 | Un vérificateur tente d’approuver la demande de R-121 qui était en attente à T0 | Refusé parce que la demande n'est plus en attente |
| 09:20:00 | Le responsable de l'exercice scelle l'enregistrement avec deux constats et un responsable pour chacun | Prochain exercice planifié après les deux corrections |
Reliez le kill switch au playbook d'incident
Le kill switch établit le confinement. L'intervenant doit encore délimiter l'incident, préserver les enregistrements volatils, restaurer une Release réputée saine, compenser les effets validés et déterminer quelles notifications s'appliquent.
Utilisez le playbook de réponse aux incidents d'agents IA pour cette séquence. Alimentez ses seuils depuis le plan de surveillance après commercialisation afin que les mêmes signaux qui ouvrent l'incident puissent invoquer un chemin d'arrêt déjà répété.
Foire aux questions
Qu'est-ce qu'un kill switch pour agent IA ?
Un kill switch pour agent IA est une commande d'incident coordonnée qui annule les exécutions actives, refuse les nouvelles actions au point d'application, révoque les identifiants, isole les charges de travail affectées, annule les travaux aval en attente et consigne quels contrôles ont abouti. Le périmètre peut viser une exécution, un agent, une Release, un tenant ou un environnement.
La révocation des jetons peut-elle arrêter un agent IA hors de contrôle ?
La révocation des jetons ferme les chemins d'autorisation gouvernés par ces jetons. L'annulation à l'exécution, l'isolation des charges de travail, l'annulation des files, les règles de refus en aval et les actions compensatoires couvrent le travail déjà en cours d'exécution ou déjà accepté.
Où la vérification du kill switch doit-elle s'exécuter ?
Exécutez la vérification décisive hors du processus de l'agent et immédiatement avant chaque effet de bord. La vérification doit lire un état d'incident durable et refuser les appels dans le périmètre affecté, y compris les appels proposés par un processus qui ignore son propre signal d'annulation.
Comment tester un kill switch d'agent IA ?
Testez les exécutions actives, les attentes d'approbation, les travaux en file, les identifiants périmés, une panne du service de politiques, un processus non coopératif, une défaillance d'export des preuves et le rétablissement sous une Release réputée saine. Mesurez le temps et le nombre d'effets de bord entre la commande et la dernière action validée.
Quelles preuves le kill switch doit-il produire ?
Conservez la commande d'incident, l'acteur, le périmètre, l'heure d'émission, les accusés de réception de chaque actionneur, les actions refusées, les changements de jetons et de clés, le résultat de l'isolation des charges de travail, le dernier effet de bord validé, les compensations en attente et le statut d'intégrité du dossier de preuves.
Points clés à retenir
Un kill switch d'agent IA crédible est un petit système de contrôle doté de plusieurs actionneurs indépendants. Placez un état de refus durable sur le chemin d'action, annulez le workflow, fermez l'accès d'identité, isolez les ressources de calcul, réconciliez les travaux en aval et gardez l'incident ouvert jusqu'à ce que chaque contrôle requis accuse réception. Les exercices de répétition transforment cette architecture en un temps de confinement mesuré et en un dossier qu'un responsable d'incident peut défendre.