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. L'API d'annulation résout une exécution rattachée au tenant en état PENDING, RUNNING ou GATED, envoie un signal kill à son workflow et enregistre l'exécution 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 elle aussi l'annulation et se termine sans reprendre l'action proposée.
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. La passerelle comporte une opération de nettoyage distincte pour les appels d'outils retenus, qui enregistre les entrées de registre annulées et scelle les reçus d'annulation. La route d'annulation d'exécution n'appelle pas cette opération aujourd'hui ; les opérateurs doivent donc vérifier séparément les entrées retenues 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.
Ces comportements sont vérifiés dans l'environnement de développement KLA, seul environnement que KLA exploite actuellement.
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.
- 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
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.