Kill switch para agentes de IA: cómo detener acciones de emergencia sin release

Idea en 30 segundos

Kill switch es un control de emergencia en runtime que permite detener de inmediato nuevas acciones del agente durante un incidente, sin release y sin cambiar el prompt.

Cuándo se necesita:
cuando un agente puede ejecutar acciones de escritura, trabaja con APIs externas y un error ya está escalando a incidente de producción.

Problema

Cuando un agente empieza a hacer acciones dañinas, normalmente no hay tiempo para "ajustar prompt y sacar release". Mientras el equipo analiza el problema, el agente puede seguir haciendo las mismas acciones. Y cada minuto de retraso son nuevos efectos secundarios (cambios de estado) en producción.

Patrón típico:

correos o mensajes duplicados
operaciones masivas de create/update
llamadas excesivas a APIs externas

Analogía: es como un botón de parada de emergencia en una línea de producción. Durante una falla, primero hay que detener el movimiento, y después investigar la causa.

Si kill switch funciona solo en UI, no es control de emergencia. La parada real debe ocurrir en runtime loop y en tool gateway.

Solución

La solución es agregar una capa policy de kill switch centralizada, que se verifica después de formar la siguiente acción, pero antes de ejecutarla. La policy devuelve allow o stop con razón explícita: killed_global, killed_tenant, writes_disabled, tool_disabled.

Modelo base:

global kill — detiene de emergencia a todos
tenant kill — detiene a un cliente concreto
writes disabled — permite read, bloquea write
tool disabled — bloquea de forma puntual una herramienta concreta

Es una capa de control de emergencia separada, no parte del prompt ni de la lógica de UI.

Kill switch ≠ sistema completo de governance

Kill switch y governance resuelven tareas distintas:

Kill switch detiene el incidente "aquí y ahora"
Governance controla el comportamiento del agente de forma continua (RBAC, límites, budgets, approval)

Uno sin el otro no funciona bien:

sin kill switch, es difícil detener un incidente al instante
sin governance, los incidentes ocurren con demasiada frecuencia

Envolvente de control kill switch

Estas verificaciones trabajan juntas como una envolvente de emergencia en runtime.

Componente	Qué controla	Mecánicas clave	Para qué
Global stop	Parada de todos los runs	`global_kill=true` stop before next action	Detiene rápido un incidente masivo
Tenant stop	Parada dentro de un tenant	`tenant_kill=true` tenant-scoped flag	Localiza el problema sin outage global
Writes disabled mode	Bloqueo de acciones de escritura	write tool policy read-only fallback	Permite degradación segura en lugar de parada total
Tool disable list	Bloqueo puntual de una herramienta	`tool_disabled[]` incident mode rules	Desactiva una herramienta problemática sin detener todos los runs
Operator observability	Transparencia de acciones del operador y bloqueos	audit logs actor + reason + scope	Permite explicar quién activó el stop y por qué

Cómo se ve en la arquitectura

La capa policy de kill switch está en runtime loop entre planificación y ejecución de la siguiente acción. Cada decisión (allow o stop) se registra en audit log.

Cada paso pasa por este flow antes de ejecutar: runtime no ejecuta acciones de forma directa, primero entrega la decisión a policy layer.

Resumen del flow:

Runtime forma la siguiente acción
Policy lee global/tenant flags + writes/tool rules
allow -> se ejecuta la siguiente acción del agente
stop -> el run se detiene con reason explícita (killed_global, killed_tenant, writes_disabled, tool_disabled)
la decisión se escribe en audit log

Ejemplo

Un agente de soporte empezó a enviar email.send en masa por un escenario defectuoso. Un operador activa writes_disabled para un tenant específico.

Resultado:

nuevas acciones write se bloquean de inmediato
las acciones read pueden seguir disponibles
en logs queda who/when/why para cada bloqueo

Kill switch detiene el incidente directamente en runtime loop y no espera un release nuevo.

En código se ve así

El esquema simplificado de arriba muestra el flujo principal. En práctica, el estado kill se lee de forma centralizada y se cachea por segundos. Crítico: kill-check debe ser O(1) y con caché corto (1-2 segundos), si no, la parada de emergencia reacciona tarde. En producción, el mismo kill-check suele duplicarse en tool gateway para que ninguna llamada pueda saltarse el control de runtime.

Ejemplo de configuración kill switch:

YAML

kill_switch:
  global_flag: agent_kill_global
  tenant_flag_prefix: "agent_kill_tenant:"
  writes_disabled_default: false
  disabled_tools_key: agent_disabled_tools
  cache_ttl_seconds: 2

PYTHON

while True:
    action = planner.next(state)
    action_key = make_action_key(action.name, action.args)  # clave estable para dedupe/audit

    kill_state = kill_store.read(tenant_id=state.tenant_id)
    decision = kill_policy.check(kill_state, action)

    if decision.outcome == "stop":
        audit.log(
            run_id,
            decision=decision.outcome,
            reason=decision.reason,
            scope=decision.scope,
            action=action.name,
            action_key=action_key,
            actor=kill_state.last_updated_by,
        )
        return stop(decision.reason)

    result = tool.execute(action.args)

    audit.log(
        run_id,
        decision=decision.outcome,
        reason=decision.reason,
        scope=decision.scope,
        action=action.name,
        action_key=action_key,
        result=result.status,
    )

    if result.final:
        return result

Kill switch detiene acciones nuevas. Para acciones in-flight suele hacer falta un mecanismo best-effort cancel separado.

Cómo se ve durante la ejecución

Escenario 1: global stop

Operador activa global_kill=true.
Runtime forma la siguiente acción y lee kill state.
Policy devuelve stop (reason=killed_global).
No se ejecutan nuevas acciones.
En logs aparece scope=global y actor.

Escenario 2: tenant stop

Se activa tenant_kill=true para tenant t_42.
Los runs de ese tenant reciben stop (reason=killed_tenant).
Los demás tenants continúan.
Incidente localizado sin parada global.

Escenario 3: writes disabled

Se activa writes_disabled=true.
Una acción read pasa con allow.
Una acción write recibe stop (reason=writes_disabled).
El sistema entra en read-only degrade mode.

Errores típicos

kill switch solo en UI, pero no en runtime/tool gateway
un solo stop global sin modo per-tenant
falta de modo writes-disabled
cache TTL largo (minutos en lugar de segundos)
falta de audit trail para acciones de operador
falta de runbook de incidente probado

Resultado: el equipo tiene un "botón", pero no tiene control real de emergencia.

Autoevaluación

Chequeo rápido de kill switch antes de lanzar a producción:

Existe global kill switch para parada de emergencia
Existe per-tenant kill switch para aislamiento local del incidente
Kill switch se verifica en runtime loop y en tool gateway
Existe modo writes-disabled (read-only degrade)
Existe disable list puntual para tools
Cada stop tiene stop reason explícita
Audit logs contienen actor, scope, reason y action
Existe runbook probado: activate -> verify -> recover

Progreso: 0/8

⚠ Faltan controles base de governance

Antes de production necesitas como mínimo control de acceso, límites, audit logs y parada de emergencia.

FAQ

P: ¿Qué conviene activar primero: global stop o writes disabled?
R: Empieza con writes_disabled si el incidente está en acciones write. Usa global_kill cuando el riesgo de falla es amplio y necesitas una parada total inmediata.

P: ¿Dónde se debe verificar kill switch exactamente?
R: Como mínimo en dos lugares: en runtime loop antes de la siguiente acción y en tool gateway antes de ejecutar herramienta.

P: ¿Se puede cachear kill state?
R: Sí, pero por poco tiempo (segundos). En incidente, caché de minutos hace casi inútil al kill switch.

P: ¿Cómo implementar kill flags técnicamente?
R: Normalmente como flags globales y tenant-scoped en Redis/config store, que policy layer lee antes de cada acción.

P: ¿Kill switch cancela acciones ya iniciadas?
R: No siempre. Bloquea con fiabilidad acciones nuevas. Para tareas in-flight se necesita un mecanismo best-effort cancel separado.

P: ¿Kill switch puede reemplazar RBAC y budgets?
R: No. Kill switch es mecanismo de parada de emergencia. RBAC, límites y budgets son necesarios para control continuo.

Dónde encaja Kill Switch en el sistema

Kill switch es la capa de emergencia de Agent Governance. Junto con RBAC, budgets, approval y audit, forma un sistema completo de control en producción.

Páginas relacionadas

Siguiente sobre este tema:

Resumen de Agent Governance — modelo general de control de agentes en producción.
Control de acceso (RBAC) — cómo limitar quién puede ejecutar qué.
Budget Controls — cómo limitar gasto y runaway runs.
Step limits — cómo detener loops en runtime loop.
Human approval — dónde hace falta confirmación manual antes de acciones riesgosas.