Un vrai kill switch existe en dehors du raisonnement de l'agent. Un seul appel, et chaque vérification de décision suivante pour cet agent renvoie deny au niveau de la politique — quoi que dise le prompt de l'agent. Ce n'est pas une instruction "merci de t'arrêter" que le modèle peut ignorer, contester ou se laisser convaincre d'ignorer par une entrée manipulée. C'est un indicateur que le modèle ne voit jamais, vérifié à un niveau où il n'a pas voix au chapitre.
"Ajoute un message système disant à l'agent de s'arrêter" est la réponse instinctive, et c'est le mauvais niveau. Un prompt système est une instruction que le modèle interprète aux côtés de toute autre instruction en concurrence pour son attention — y compris une injection de prompt réussie, une boucle agentique bloquée qui a cessé de lire de nouvelles instructions, ou un modèle qui déprioritise simplement une instruction enfouie plus tôt dans le contexte. Aucun de ces modes de défaillance n'est hypothétique ; ce sont exactement les scénarios pour lesquels un kill switch existe. Si le mécanisme sur lequel tu comptes pour arrêter l'agent se trouve à l'intérieur du même processus de raisonnement qui se comporte mal en ce moment, ce n'est pas un contrôle. C'est une suggestion.
Un opérateur disposant de la permission guard.killswitch.write appelle POST /v1/suite/guard/kill/{agent_id} avec un motif. Cela définit is_killed = true dans l'enregistrement de l'agent — rien de plus, et le propre processus de l'agent n'y est pour rien.
POST /v1/decisions/check évalue l'indicateur d'élimination avant toute autre branche. Chaque requête suivante revient avec deny et reason_code: "agent_killed", quelle que soit l'action que l'agent tentait de réaliser.
Un agent éliminé ne peut pas émettre de nouvel identifiant de confiance portable. POST /v1/credentials/issue renvoie un 403 au moment où il vérifie is_killed, avant que quoi que ce soit d'autre ne s'exécute.
Une entrée du registre Vault (agent.killed), une ligne standard de journal d'audit et une notification d'espace de travail de sévérité danger sont toutes écrites au moment de l'élimination — il existe une trace de qui, quand et pourquoi, indépendamment de l'agent.
POST /v1/suite/guard/unkill/{agent_id} efface l'indicateur et rétablit la vérification normale des décisions et l'émission des identifiants. Éliminer un agent ne touche pas à son historique de score de confiance — c'est une action d'opérateur distincte, journalisée pour audit.
Soyons précis sur la limite. Le kill switch refuse à chaque point de contrôle qui demande une autorisation à VeriSwarm — une vérification de décision, une demande d'identifiant, une passation de tâche A2A vers ou depuis l'agent éliminé. Il n'atteint pas le runtime propre de l'agent pour interrompre l'exécution en pleine tâche, et il ne révoque pas les identifiants que l'agent détient déjà et pourrait encore présenter à un système qui ne consulte pas VeriSwarm au préalable. C'est pourquoi c'est un contrôle parmi six, pas un substitut aux autres — les permissions d'outils à moindre privilège et la tokenisation des PII réduisent ce qu'un agent peut faire de mal pendant la fenêtre avant même que quiconque n'ait recours au kill switch. Voir la liste complète des six contrôles.
Activer ou inverser le kill switch nécessite un jeton de session portant guard.killswitch.write — détenu par les rôles super_admin, platform_admin, tenant_admin et operator. Il n'est délibérément pas accessible avec la propre clé API de l'agent : un agent qui a été compromis, ou un agent qui raisonne son chemin vers une mauvaise action, ne peut ni s'éliminer ni se restaurer lui-même. Le contrôle doit venir de l'extérieur.
Une dérogation déclenchée par un opérateur qui bloque immédiatement la capacité d'agir d'un agent spécifique, sans dépendre du propre chemin de code de l'agent ni de sa coopération. Chez VeriSwarm, un seul appel — POST /v1/suite/guard/kill/{agent_id} — bascule un indicateur sur l'enregistrement de l'agent. À partir de ce moment, chaque vérification de décision de confiance contre cet agent (POST /v1/decisions/check) renvoie deny avec reason_code: "agent_killed", et l'émission de nouveaux identifiants pour cet agent est purement et simplement refusée. C'est réversible : un appel de restauration (POST /v1/suite/guard/unkill/{agent_id}) rétablit le fonctionnement normal.
Non — une instruction dans le prompt système est une demande dont le modèle peut se laisser détourner. C'est la distinction essentielle. Un vrai kill switch ne demande pas à l'agent de s'arrêter ; il change ce qui se passe quand l'agent tente d'agir. La vérification a lieu au niveau de la décision, en dehors de la propre boucle de raisonnement du modèle, donc une injection de prompt réussie, une boucle agentique bloquée, ou le modèle ignorant simplement une instruction antérieure, n'a pas d'importance — la prochaine vérification de décision revient refusée quand même.
Trois choses, confirmées par rapport au chemin de décision en direct : chaque appel suivant à POST /v1/decisions/check pour cet agent renvoie deny (decision_preview.py vérifie agent.is_killed avant toute autre branche) ; l'émission de nouveaux identifiants portables pour cet agent est refusée avec un 403 (routes/credentials.py) ; et, là où le protocole A2A de VeriSwarm et les vérifications d'accès JIT entrent en jeu, les tentatives d'autres agents de confier des tâches à l'agent éliminé ou de lui accorder un accès sont bloquées elles aussi. Ce qu'il ne fait pas, c'est atteindre le propre processus de l'agent et l'arrêter en pleine exécution — voir la réponse suivante.
Non, et c'est la limite honnête d'un kill switch au niveau décision. Il refuse à chaque point de contrôle suivant qui demande une autorisation à VeriSwarm — décisions, émission d'identifiants, passation de tâche A2A. Si un agent dispose déjà d'identifiants émis qu'il peut utiliser ailleurs, ou s'il opère dans un système qui ne vérifie pas auprès de VeriSwarm avant d'agir, l'éliminer dans VeriSwarm n'atteint pas ce chemin. Le kill switch est un contrôle au niveau politique pour les agents qui vérifient les décisions avant d'agir — c'est exactement pourquoi le contrôle #2 de la liste de sécurité (permissions d'outils à moindre privilège) et le contrôle #4 (analyse d'injection) comptent indépendamment, non pas comme une sauvegarde du kill switch, mais comme des contrôles qui réduisent ce qu'un agent peut faire de mal avant même que tu aies besoin d'y recourir.
Non — l'activer ou l'inverser nécessite un jeton de session avec la permission guard.killswitch.write, détenue par des rôles à accès complet (super_admin, platform_admin, tenant_admin, operator). Il n'est pas exposé à la propre clé API de l'agent, par conception : un agent — ou quelque chose qui l'a compromis — ne peut pas s'éliminer lui-même pour couvrir ses traces, et ne peut pas non plus se restaurer lui-même.
Le kill switch fait partie de VeriSwarm Guard, une capacité du forfait Max. Chaque activation et chaque inversion écrit une entrée immuable dans le registre Vault (agent.killed / agent.unkilled) quand Vault est activé, plus une entrée de journal d'audit standard et une notification d'espace de travail de sévérité danger — il existe donc une trace de qui a éliminé l'agent, quand et pourquoi, indépendamment de ce que l'agent lui-même rapporte.
Le kill switch est une capacité Guard du forfait Max. Le niveau gratuit de Gate te donne d'abord la couche de décision et la visibilité des événements à laquelle il se connecte.