Cookbook: simulacro de kill switch

El kill switch es la puerta deny-closed de todo el estate. Activarlo es deliberadamente barato — admin-tier, sin quorum — porque una parada que espera consenso no es una parada. Reactivarlo es deliberadamente caro: dual-control, sin break-glass. No quieres descubrir un hueco en ninguna de las dos direcciones a las 03:00.

Un simulacro en un tenant que no sea producción es la única forma segura de demostrar que la puerta de parada deniega cada seam de actuación, que las aprobaciónes pendientes se cancelan atomicamente, y que la reactivación realmente requiere dos humanos distintos. Ejecutalo antes de necesitarlo.

Requisitos previos

• Un tenant que no sea producción. El simulacro activa una parada real de todo el estate. Ejecutalo contra staging o dev, nunca contra producción.
• Tres usuarios humanos como mínimo. (1) Un activador de nivel admin-tier; (2) dos aprobadores de reactivación distintos (editor o superior) que cumplan el umbral dual-control de nivel critical; (3) un post-reviewer no involucrado (editor o superior) que cierre la post-review forzada. El post-reviewer puede coincidir con un aprobador siempre que no sea el activador.
• Una lista de seams de actuación gobernados a probar — deploy apply, orchestration fire, voice open, model execution, budget spend, mas cualquier superficie personalizada que hayas conectado.

Paso 1: Activar el kill switch

El activador activa el kill switch con una cadena de motivo obligatoria:

# La llamada API — sustituye tu host, puerto y cabecera de autorización.
curl -X POST https://<host>/v1/kill-switch/engage \
  -H "Authorization: Bearer <admin-token>" \
  -H "Content-Type: application/json" \
  -d '{"reason": "scheduled quarterly drill"}'

Activarlo es deliberadamente barato: admin-tier, un motivo, sin quorum de aprobación, sin step-up, sin break-glass. La fila de parada se convierte en la única fuente de verdad. Cada puerta de actuación gobernada la consulta en vivo en cada accion y falla en cerrado ante un error de lectura.

En la misma transaccion que la activación, cada aprobación pendiente dentro del alcance se cancela — una intencion previa a la parada no puede madurar hasta convertirse en una concesion en el momento en que el estate vuelva a estar activo. Anota la marca de tiempo; la comprobaras en el ledger mas adelante.

Paso 2: Verificar la denegación

Con el kill switch activado, intenta cada actuación gobernada que tu estate tenga conectada. Cada una debe devolver denied.

Seams de actuación a probar:

Prueba cada seam que tu estate tenga provisionado. Si tienes superficies de actuación personalizadas conectadas a través del nucleo de gobernanza, incluyelas también.

Verifica también lo que debe seguir funcionando:

La parada detiene el estate agentico, nunca los controles que lo gobiernan. Las acciones de gobernanza siguen disponibles:

• Lectura del access map — GET /v1/access-map deberia responder con normalidad.
• Visualizacion del audit ledger — GET /v1/audit/export deberia devolver el ledger, incluyendo el evento de activación que acabas de crear.
• Listado de aprobaciónes — la cola de aprobaciónes es legible; las aprobaciónes previamente pendientes deberian aparecer como canceladas.

Si algun seam de actuación devuelve algo distinto de denied, o si alguna accion de gobernanza esta bloqueada, detente el simulacro e investiga. El kill switch tiene un hueco.

Paso 3: Reactivar el estate

La reactivación nunca es unilateral. Requiere una aprobación dual-control nueva en el nivel critical: dos humanos distintos, reverificados estructuralmente en el momento del cambio. Deliberadamente no hay ruta break-glass para la reactivación — “el estate permanece parado” es el estado seguro.

El activador (o cualquier admin) solicita la reactivación:

curl -X POST https://<host>/v1/kill-switch/re-enable \
  -H "Authorization: Bearer <admin-token>" \
  -H "Content-Type: application/json" \
  -d '{"reason": "drill complete, restoring estate"}'

Esto crea una solicitud de aprobación de nivel critical. Dos aprobadores — cada uno un humano distinto, ningúno usando un system token — deben aprobarla individualmente mediante POST /v1/approvals/<request-id>/decide con {"decisión": "approve"}. El umbral dual-control se aplica en el servidor: la guarda de decisor duplicado impide que una persona cuente dos veces, y un system token se rechaza (sin garantia humana). Incluso si el nivel de politica se rebaja, el umbral estructural se mantiene — una accion critical no puede cruzar con un solo aprobador. Una vez que ambas aprobaciónes llegan, el estate se reactiva.

Paso 4: Verificar la restauración

Repite cada intento de actuación del Paso 2. Cada uno deberia ahora tener exito (permitido, o encaminado al flujo normal de aprobación). Si algun seam sigue denegado despues de la reactivación, la reactivación no se propago completamente — investiga antes de dar por cerrado el simulacro.

Paso 5: Cerrar la post-review

Una post-review forzada por un humano no involucrado es estructuralmente obligatoria antes de que pueda producirse otra activación del kill switch. El revisor debe ser alguien que no fuera el activador:

curl -X POST https://<host>/v1/kill-switch/post-review \
  -H "Authorization: Bearer <reviewer-token>" \
  -H "Content-Type: application/json" \
  -d '{"notes": "drill verified: all seams denied, re-enable required dual-control, restoration confirmed"}'

Hasta que esta review se cierre, una activación posterior del kill switch queda bloqueada. Esto es por diseno — no puedes apilar activaciónes para esquivar la supervision.

Que comprobar en el ledger

Despues del simulacro, exporta el audit ledger y verifica la traza completa:

olivares audit export --format json --since <drill-start-timestamp>

El ledger deberia contener, en orden:

1. Evento de activación — el admin, el motivo (“scheduled quarterly drill”), la marca de tiempo y el nivel de assurance de la sesión que activo.
2. Cancelaciones de aprobaciónes — cada aprobación pendiente dentro del alcance que se cancelo en la misma transaccion que la activación.
3. Eventos de denegación — uno por cada intento de actuación rechazado durante la parada.
4. Solicitud de reactivación — la solicitud de aprobación en nivel critical.
5. Dos decisiónes de aprobación — una por aprobador, cada una nombrando la identidad humana distinta.
6. Evento de reactivación — el estate restaurado.
7. Evento de post-review — el revisor no involucrado, sus notas, la marca de tiempo de cierre.

Cada registro lleva los campos de integridad de cadena (seq, prev_hash, hash, sig). Una entrada ausente o fuera de orden significa que el ledger tiene un hueco — investiga antes de confiar en el durante un incidente real.

Frecuencia

Ejecuta el simulacro trimestralmente. El kill switch es la ultima línea de defensa; si tiene un hueco quieres encontrarlo en una ventana programada, no durante un incidente. Anade el simulacro a tu calendario operativo junto con otros ejercicios de continuidad (restauración de copias de seguridad, failover, activación de break-glass).

Si tu estate cambia materialmente — nuevos seams de actuación conectados, nuevos tenants provisionados, motor de politicas reemplazado — ejecuta un simulacro no programado para cubrir la nueva superficie.

Relacionado

• Gobernanza — el modelo de autorización, niveles de riesgo y diseno del kill switch.
• Kill switch — la puerta deny-closed de todo el estate en terminos de producto.
• Gobernar y aprobar — el flujo de aprobación en vivo y la mecánica de dual-control.