Un kill switch real vive fuera del razonamiento del agente. Una sola llamada, y cada verificación de decisión posterior para ese agente devuelve deny en la capa de políticas — sin importar lo que diga el prompt del agente. No es una instrucción de "por favor, detente" que el modelo pueda ignorar, rebatir o que lo convenzan de ignorar con una entrada manipulada. Es un indicador que el modelo nunca ve, verificado en una capa sobre la que no tiene ningún voto.
"Añade un mensaje de sistema que le diga al agente que se detenga" es la respuesta instintiva, y es la capa equivocada. Un system prompt es una instrucción que el modelo interpreta junto con cualquier otra instrucción que compite por su atención — incluida una inyección de prompt exitosa, un bucle agéntico atascado que ha dejado de leer nuevas instrucciones, o un modelo que simplemente da menor prioridad a una instrucción enterrada más arriba en el contexto. Ninguno de esos modos de fallo es hipotético; son exactamente los escenarios para los que existe un kill switch. Si el mecanismo en el que confías para detener al agente está dentro del mismo proceso de razonamiento que en ese momento se está comportando mal, no es un control. Es una sugerencia.
Un operador con el permiso guard.killswitch.write llama a POST /v1/suite/guard/kill/{agent_id} con un motivo. Eso establece is_killed = true en el registro del agente — nada más, y el propio proceso del agente no participa en ello.
POST /v1/decisions/check evalúa el indicador de agente eliminado antes que cualquier otra rama. Cada solicitud posterior vuelve como deny con reason_code: "agent_killed", sea cual sea la acción que el agente intentaba realizar.
Un agente eliminado no puede emitir una nueva credencial de confianza portátil. POST /v1/credentials/issue devuelve un 403 en el momento en que verifica is_killed, antes de que se ejecute nada más.
Se escribe una entrada en el libro de Vault (agent.killed), una fila estándar de registro de auditoría y una notificación de severidad de peligro al workspace en el momento de la eliminación — hay un registro de quién, cuándo y por qué, independiente del agente.
POST /v1/suite/guard/unkill/{agent_id} borra el indicador y restaura la verificación de decisiones y la emisión de credenciales normales. Eliminar un agente no toca su historial de puntuación de confianza — es una acción de operador separada y registrada en auditoría.
Sé preciso sobre el límite. El kill switch deniega en cada punto de control que pide permiso a VeriSwarm — una verificación de decisión, una solicitud de credencial, una transferencia de tarea A2A hacia o desde el agente eliminado. No llega hasta el propio runtime del agente para detener la ejecución a mitad de tarea, y no revoca las credenciales que el agente ya posee y que aún podría presentar a un sistema que no consulta primero a VeriSwarm. Por eso es un control entre seis, no un sustituto de los demás — los permisos de herramientas de mínimo privilegio y la tokenización de PII reducen lo que un agente puede hacer mal en la ventana de tiempo antes de que alguien recurra siquiera al kill switch. Consulta la lista completa de seis controles.
Activar o revertir el kill switch requiere un token de sesión que lleve guard.killswitch.write — en manos de los roles super_admin, platform_admin, tenant_admin y operator. Deliberadamente no es accesible con la propia clave de API del agente: un agente que ha sido comprometido, o uno que está razonando su camino hacia una mala acción, no puede eliminarse ni restaurarse a sí mismo. El control tiene que venir desde fuera.
Una anulación activada por un operador que bloquea de inmediato la capacidad de un agente específico para actuar, sin depender de la ruta de código propia del agente ni de su cooperación. En VeriSwarm, una sola llamada — POST /v1/suite/guard/kill/{agent_id} — activa un indicador en el registro del agente. A partir de ese momento, toda verificación de confianza y decisión contra ese agente (POST /v1/decisions/check) devuelve deny con reason_code: "agent_killed", y se rechaza de plano la emisión de nuevas credenciales para ese agente. Es reversible: una llamada de restauración (POST /v1/suite/guard/unkill/{agent_id}) restablece el funcionamiento normal.
No — una instrucción en el system prompt es una petición de la que se puede convencer al modelo para que se aparte. Esa es la distinción central. Un kill switch real no le pide al agente que se detenga; cambia lo que ocurre cuando el agente intenta actuar. La verificación sucede en la capa de decisión, fuera del propio bucle de razonamiento del modelo, así que una inyección de prompt exitosa, un bucle agéntico atascado o que el modelo simplemente ignore una instrucción anterior no importa — la siguiente verificación de decisión vuelve denegada de todos modos.
Tres cosas, confirmadas contra la ruta de decisión en vivo: toda llamada posterior a POST /v1/decisions/check para ese agente devuelve deny (decision_preview.py verifica agent.is_killed antes que cualquier otra rama); se rechaza la emisión de nuevas credenciales portátiles para ese agente con un 403 (routes/credentials.py); y, cuando el protocolo A2A de VeriSwarm y las verificaciones de acceso JIT están en juego, también se bloquean los intentos de otros agentes de entregar tareas o conceder acceso al agente eliminado. Lo que no hace es entrar en el propio proceso del agente y detenerlo a mitad de ejecución — ver la siguiente respuesta.
No, y este es el límite honesto de un kill switch en la capa de decisión. Deniega en cada punto de control posterior que le pide permiso a VeriSwarm — decisiones, emisión de credenciales, transferencia de tareas A2A. Si un agente ya tiene credenciales emitidas que puede usar en otro lugar, o si opera en un sistema que no consulta a VeriSwarm antes de actuar, eliminarlo en VeriSwarm no llega a esa ruta. El kill switch es un control de capa de políticas para agentes que verifican decisiones antes de actuar — que es exactamente por qué el control #2 de la lista de seguridad (permisos de herramientas de mínimo privilegio) y el control #4 (escaneo de inyecciones) importan de forma independiente, no como respaldo del kill switch, sino como controles que reducen lo que un agente puede hacer mal antes de que necesites recurrir a él.
No — activarlo o revertirlo requiere un token de sesión con el permiso guard.killswitch.write, en manos de roles de acceso completo (super_admin, platform_admin, tenant_admin, operator). No está expuesto a la propia clave de API del agente, por diseño: un agente — o algo que lo haya comprometido — no puede eliminarse a sí mismo para cubrir sus huellas, y tampoco puede restaurarse a sí mismo.
El kill switch es parte de VeriSwarm Guard, una capacidad del plan Max. Cada activación y reversión escribe una entrada inmutable en el libro de Vault (agent.killed / agent.unkilled) cuando Vault está habilitado, además de una entrada estándar de registro de auditoría y una notificación de severidad de peligro al workspace — así que existe un registro de quién eliminó al agente, cuándo y por qué, independiente de lo que el propio agente informe.
El kill switch es una capacidad de Guard del plan Max. El nivel gratuito de Gate te da la capa de decisión y la visibilidad de eventos a la que se conecta.