Runbook de emergencia: recupera el control de los agentes de IA

Los sistemas controlados por agentes necesitan un procedimiento de emergencia antes de necesitar otro ajuste de permisos. Cuando un agente puede llamar a una API, abrir una sesión SSH, modificar un despliegue o enviar datos a un servicio externo, una persona debe poder detener el trabajo, retirar la autoridad y reconstruir lo ocurrido bajo presión.

Un runbook de emergencia no convierte un diseño inseguro en seguro. Ofrece una forma de contener la incertidumbre antes de que se convierta en daño. La versión útil cabe en una página para los primeros quince minutos, identifica la autoridad real y no solo los cargos, y ha sido probada por personas que no participaron en su redacción.

La autoridad de emergencia debe pertenecer a roles identificados

Un runbook de emergencia solo funciona cuando indica quién puede actuar sin pedir más permiso. «El equipo de plataforma» y «seguridad» no son respuestas válidas a las 02:00, especialmente cuando varias personas creen que otra se hará cargo de la decisión.

Asigna cuatro roles y vincula cada uno con las personas actuales y sus suplentes. En un equipo pequeño, una misma persona puede ocupar dos roles, pero no permitas que una sola persona los ocupe todos.

• El responsable del incidente declara el modo de emergencia, fija el objetivo inmediato y registra las decisiones.
• La persona encargada de revocar el acceso desactiva la sesión del agente, su canal de acciones o las credenciales a las que puede llegar.
• El propietario del servicio decide si una carga de trabajo crítica puede detenerse sin riesgos y valida la recuperación.
• La persona encargada del registro mantiene una bitácora de eventos con marcas de tiempo y protege el paquete de evidencias.

La persona que revoca el acceso necesita autoridad técnica antes de que ocurra un incidente. Eso significa que puede desactivar el proceso del agente, retirar el acceso en el punto de ejecución de la acción y solicitar la rotación de credenciales cuando sea necesario. Darle un número de teléfono de emergencia sin acceso a las consolas necesarias crea un rol ceremonial.

Usa dos personas para revocar el acceso, una principal y otra suplente, de líneas jerárquicas distintas cuando sea posible. El propietario del servicio puede oponerse a una interrupción prolongada, pero no debería poder vetar la contención inicial cuando el responsable del incidente cree que un agente activo puede ser inseguro. El servicio se puede restaurar después de entender la situación. Una solicitud a una API externa o un comando SSH destructivo no se pueden deshacer.

Incluye estos datos en el runbook para cada rol: nombre, suplente, método de contacto laboral, método fuera del horario si lo utilizas y sistemas que realmente puede controlar. Revisa la lista después de los cambios en el equipo. Una lista de contactos desactualizada no es un problema administrativo menor. Hace que los responsables improvisen justo cuando deberían ejecutar el procedimiento.

Separa la autoridad de la consulta. Es posible que legal, cumplimiento, soporte al cliente y la dirección necesiten recibir un aviso, según el trabajo afectado. No deberían formar una cola delante de la contención. El responsable del incidente les informa después de la primera acción segura, salvo que una obligación legal concreta exija otra cosa.

Detener, revocar y conservar son acciones distintas

Detener un proceso de agente, revocar su autoridad y conservar las evidencias resuelven problemas distintos. Los equipos suelen mezclarlos y luego creen que un proceso inactivo ha perdido el acceso cuando no es así.

Detener impide que ese proceso siga trabajando. Puede significar terminar un proceso local, desactivar una tarea programada, pausar un ejecutor de agentes o eliminar un activador de repositorio. Detén primero si el proceso sigue activo y su comportamiento no está claro.

Revocar elimina la autoridad que hizo posible la acción. Puede implicar desactivar una sesión de acciones, retirar una identidad de servicio, bloquear un almacén de acceso, sustituir un token ascendente o bloquear una integración definida de forma precisa. Un agente detenido hoy puede reiniciarse mañana desde una cola de reintentos o desde otra máquina. Su autoridad no debe seguir disponible por accidente.

La conservación captura lo que los responsables necesitan antes de que la recuperación habitual lo sobrescriba. Registra la identidad del proceso, la revisión de origen o el contexto de la instrucción cuando corresponda, la cuenta del operador, las horas de inicio y detención, los servicios de destino y la última acción confirmada. Conserva los registros y las instantáneas de configuración según tus reglas de retención. No pegues secretos en un ticket de incidente mientras recopilas evidencias.

Usa esta tarjeta de decisión durante los primeros minutos:

ID del incidente:
Declarado por / hora:
Proceso o sesión del agente afectados:
Riesgo inmediato: llamadas activas / posible exposición de credenciales / desconocido

[ ] Detener la ejecución actual
[ ] Revocar la autorización del agente
[ ] Bloquear o rotar la ruta de credenciales afectada
[ ] Conservar la identidad del proceso y los registros de acciones
[ ] Notificar al propietario del servicio

Persona que revoca / hora:
Persona encargada del registro / hora:
La recuperación está prohibida hasta que la apruebe el responsable del incidente.

La última línea evita un fallo habitual. Un desarrollador ve que el trabajo de producción se ha pausado, reinicia el agente para que la cola avance y destruye el límite claro que los responsables acababan de crear. La recuperación necesita una decisión independiente porque vuelve a cambiar el riesgo.

No obligues a los responsables a demostrar que hubo una acción maliciosa antes de actuar. Un destino extraño, un flujo de aprobación fallido, un agente que no se detiene o una diferencia entre las acciones previstas y las observadas bastan para contener primero. La revisión puede distinguir después entre un defecto, una configuración equivocada y un ataque.

El trabajo urgente necesita una vía de aprobación limitada

A veces el trabajo urgente no puede esperar al propietario habitual, pero «urgente» se usa a menudo para saltarse precisamente los controles que sacarían a la luz una solicitud incorrecta. El runbook debe permitir una excepción limitada sin convertir cada incidente en una aprobación general.

Define el trabajo urgente como un resultado concreto del servicio que sufrirá un daño importante si espera al proceso normal. Un despliegue pendiente porque alguien quiere terminar antes de comer no es urgente. Restaurar una dependencia de producción caída puede serlo. La descripción debe identificar la acción exacta, el objetivo, el resultado esperado y la última hora en que su finalización sigue siendo útil.

Usa esta secuencia de aprobación:

1. El solicitante indica el impacto en el servicio, la acción exacta propuesta, la cuenta o el entorno afectados y la hora de expiración.
2. El responsable del incidente confirma que la contención sigue activa y designa al propietario del servicio o a un delegado para validar el alcance.
3. La persona que revoca concede solo la autoridad necesaria para esa acción, con una expiración explícita y un aprobador registrado.
4. El solicitante realiza el trabajo mientras la persona encargada del registro captura el registro de la acción resultante y su resultado.
5. La persona que revoca retira la autoridad temporal inmediatamente después de verificar el resultado.

El registro de aprobación debe ser completo y poco llamativo. No aceptes «aprobado, arréglalo» en un chat. Exige una declaración como esta:

Autorización de trabajo de emergencia
ID de solicitud: IR-2025-041
Acción solicitada: reiniciar el despliegue de payment-worker en producción
Alcance: un despliegue identificado, sin escrituras en repositorios ni cambios de cuenta
Motivo: la cola está fallando y la ventana de recuperación manual termina a las 14:30 UTC
Aprobador: delegado del propietario del servicio
Persona que concede: responsable de revocar el acceso
Expira: 14:30 UTC
Resultado y hora de retirada:

El ejemplo no da permiso a un responsable para reiniciar cualquier cosa. Muestra el nivel de precisión que evita que el alcance se extienda. «Restaurar producción» oculta decenas de acciones posibles. Un despliegue identificado y una expiración se pueden comprobar.

Evita usar una credencial de emergencia permanente para este proceso. A los equipos les gusta porque parece rápida. También crea un objetivo de alto valor permanente y, con el tiempo, la gente acaba usándola para el trabajo habitual porque resulta cómoda. Concede autoridad para una acción limitada y después retírala.

Si ninguna persona autorizada puede aprobar una acción urgente, mantén la contención y escala por la cadena de propietarios. Una recuperación retrasada perjudica. Una recuperación no autorizada que amplía el incidente puede perjudicar mucho más.

Los primeros quince minutos deben seguir un procedimiento mecánico

Bajo presión, la gente omite las marcas de tiempo, discute la terminología y da por hecho que un compañero ha realizado una acción. Un runbook necesita una secuencia ordenada de primera respuesta que funcione aunque la causa aún se desconozca.

En el minuto cero, la persona que observa el problema crea un registro del incidente y expresa el hecho observable. Escribe «el proceso del agente envió solicitudes a un endpoint no reconocido» en lugar de «el agente ha sido comprometido». Los hechos resisten mejor una revisión posterior que las primeras teorías.

A continuación, el responsable del incidente declara uno de dos estados: investigación o contención de emergencia. Investigación significa que el equipo no tiene indicios de una autoridad activa insegura y puede inspeccionar sin pausar el trabajo. Contención de emergencia significa que el equipo no puede establecer de forma segura la autoridad o las acciones actuales del agente. El segundo estado autoriza a la persona encargada de revocar el acceso a actuar.

Durante los quince minutos siguientes, haz lo siguiente en orden:

1. Identifica el proceso o la sesión activa y registra su identidad visible, host, propietario, hora de inicio y tarea actual.
2. Detén la ejecución adicional si sigue activa o si un programador puede volver a iniciarla.
3. Revoca la autoridad disponible para ese proceso, empezando por la ruta de acción externa con consecuencias más graves.
4. Informa al propietario del servicio afectado de que la contención está activa y explica claramente la consecuencia operativa.
5. Conserva los registros de acciones y el contexto de configuración antes de cambiar ajustes no relacionados.

Evita una limpieza amplia durante este periodo. No reconstruyas hosts, borres directorios de trabajo, rotes todos los secretos de la empresa ni cambies los ajustes de despliegue solo porque la situación parezca alarmante. Esas acciones pueden estar justificadas más adelante, pero entierran las evidencias y crean interrupciones independientes.

La persona encargada del registro debe mantener una línea temporal sencilla en un único lugar compartido:

14:07  El observador informó de una solicitud saliente inesperada de la ejecución de agente A-184.
14:09  El responsable del incidente declaró la contención de emergencia.
14:10  La persona encargada de revocar detuvo A-184 y desactivó su autorización de acciones.
14:12  El propietario del servicio confirmó que el procesamiento de pedidos podía pausarse.
14:14  La persona encargada del registro guardó los registros de acciones y el resumen de configuración.
14:18  El equipo comenzó la revisión del alcance. No se concedió autoridad de recuperación.

Esto resulta más útil que una narración larga escrita después. Muestra qué sabía el equipo, quién actuó y cuándo cambió la autoridad. Mantén las opiniones y las hipótesis en una nota de investigación independiente.

La fatiga de aprobación es un fallo de diseño

La gente ignora las advertencias cuando aparece el mismo aviso para un trabajo inofensivo y para otro con consecuencias importantes. Repetir las aprobaciones no genera más cuidado. Enseña a hacer clic en la tarjeta para que el trabajo continúe.

Tu runbook de emergencia debe indicar qué acciones requieren una decisión humana explícita y cuáles pueden realizarse dentro de la autoridad normal. Haz que el límite tenga sentido. Una acción que cambia la infraestructura, llega a un nuevo destino externo, modifica una cuenta o usa una credencial fuera de la ruta de servicio prevista merece más revisión que una operación de lectura dentro de un alcance conocido.

No intentes resolverlo con una política escrita gigantesca y llena de condiciones. Durante un incidente, el responsable necesita unas pocas opciones claras: denegar, detener, revocar, conceder una acción de emergencia limitada o restaurar el funcionamiento normal. Si el procedimiento exige interpretar veinte cláusulas de excepción, fallará de una forma distinta con cada responsable.

La pantalla o el registro de aprobación debe identificar suficientemente al solicitante para que una persona distinga una ejecución prevista de otra inesperada. El nombre del proceso por sí solo es una evidencia débil porque los nombres se pueden copiar fácilmente. Captura el origen del proceso, la identidad de firma de código cuando el sistema operativo la proporcione, el contexto de lanzamiento y el identificador de sesión. Así, el aprobador puede decir «esta es la herramienta de desarrollo prevista, iniciada desde esta ruta» en lugar de «la etiqueta me resulta familiar».

Una recomendación habitual y equivocada dice que toda llamada sensible debe requerir la aprobación de una persona. Suena segura porque pone a alguien en cada circuito. Falla cuando una tarea legítima realiza muchas llamadas: el operador aprueba a ciegas, el agente no puede completar un mantenimiento limitado y el equipo acaba desactivando el ajuste. Reserva la aprobación de un solo uso para una autoridad con consecuencias importantes y usa la aprobación a nivel de sesión solo cuando la identidad de la sesión sea clara y su alcance aceptable.

Sallyport sigue esta separación práctica con un control del almacén, autorización predeterminada por sesión y un requisito opcional por clave para aprobar cada uso. Eso no sustituye a un runbook, porque una persona sigue necesitando autoridad para detener el trabajo y decidir si se justifica una excepción urgente.

Los registros deben responder quién actuó y quién lo aprobó

Un registro de incidente que dice «lo hizo el agente» está incompleto. Los agentes funcionan mediante procesos, identidades, canales de acciones y vías de aprobación humana. Tus evidencias deben mostrar cada vínculo.

Para cada llamada importante, conserva la identidad de la sesión o del proceso del agente, la persona o el sistema que la inició, el servicio o host de destino, la acción solicitada, el estado de autorización, el resultado y una hora fiable. Para el trabajo de emergencia, registra junto a la llamada el aprobador, la persona que revoca, el alcance solicitado, la expiración y la hora de retirada.

Mantén separado el registro de aprobación del resultado de la acción y relaciónalos mediante un identificador de incidente o de solicitud. Esta distinción importa. Una aprobación significa que alguien autorizó un intento limitado. No demuestra que el intento tuviera éxito, que solo afectara al objeto previsto o que se detuviera al expirar.

Durante la revisión, plantea estas preguntas:

• ¿Qué proceso hizo la solicitud y cómo se inició?
• ¿Qué autoridad permitió la solicitud en ese momento?
• ¿Quién aprobó el trabajo de emergencia y qué alcance exacto aprobó?
• ¿Coincidió el resultado con ese alcance?
• ¿Puede un revisor independiente detectar registros modificados o ausentes?

La publicación especial 800-61 revisión 2 de NIST, Computer Security Incident Handling Guide, trata la preparación, la detección y el análisis, la contención, la erradicación y recuperación, y las actividades posteriores al incidente como un trabajo conectado. Sus indicaciones sobre documentar y conservar los datos del incidente siguen siendo útiles, pero las operaciones de agentes añaden un detalle que los runbooks antiguos suelen omitir: necesitas registrar la autoridad delegada a las máquinas, no solo los inicios de sesión humanos.

No confundas los registros habituales de una aplicación con un registro de auditoría. Los registros de aplicación pueden omitir el contexto de autorización, permitir cambios administrativos amplios o desaparecer cuando se reconstruye una máquina. Consérvalos, pero documenta qué puede demostrar cada registro y qué no.

En los sistemas que mantienen una cadena de auditoría criptográfica, incluye la verificación en el simulacro. Sallyport ofrece verificación sin conexión mediante sp audit verify, que permite a un revisor comprobar su registro de auditoría cifrado y encadenado mediante hashes sin necesitar la clave del almacén. Ejecuta ese comando sobre un conjunto de evidencias copiado durante el ensayo, no por primera vez cuando el responsable del incidente esté esperando una respuesta.

La recuperación debe volver a ganarse la autoridad

Restaurar el servicio no equivale a cerrar el incidente. El equipo solo debe restaurar la autoridad que pueda explicar y debe hacerlo en pasos lo bastante pequeños como para que una recurrencia tenga un límite visible.

Antes de la recuperación, el responsable del incidente necesita tres respuestas: qué causó la decisión de contener, qué autoridad quedó expuesta o se utilizó y qué control evita ahora que vuelva a ocurrir. Puede que aún no conozcas la causa raíz completa. Aun así, necesitas la confianza suficiente para explicar por qué la primera acción restaurada es segura.

Restaura el servicio en etapas limitadas. Empieza, cuando sea posible, con una validación de solo lectura, continúa con una única acción conocida y después realiza una ejecución breve y supervisada. No restablezcas todos los agentes, integraciones y credenciales porque un servicio se haya recuperado. Conserva el límite del incidente hasta que el propietario del servicio y el responsable del incidente acuerden que la ruta afectada se entiende.

Usa una autorización de recuperación distinta de la aprobación del trabajo urgente. La aprobación de emergencia permite una acción necesaria a pesar del incidente. La aprobación de recuperación confirma que la autoridad normal puede volver después de la contención. Dale un registro independiente:

Autorización de recuperación
ID del incidente:
Causa o incertidumbre restante:
Autoridad que se restaura:
Validación realizada:
Responsable de la supervisión y hora de revisión:
Aprobado por el responsable del incidente y el propietario del servicio:

La expiración también importa aquí. Si un permiso temporal de recuperación sigue disponible después de una prueba satisfactoria, se convierte en un acceso permanente no documentado. La persona encargada de revocar debe confirmar su retirada como parte del registro de recuperación.

La rotación de credenciales requiere criterio, no un ritual. Rota una credencial cuando pueda haber llegado a un proceso, destino, repositorio, registro o persona no confiables, o cuando no puedas establecer el límite de su uso. No afirmes que la rotación resolvió el incidente si un agente aún tiene una vía para obtener el reemplazo mediante la misma ruta insegura. Repara primero esa ruta.

La revisión posterior al incidente debe producir cambios, no solo observaciones. Sustituye «la comunicación no fue clara» por «la persona encargada del registro usará la plantilla de línea temporal del incidente y la página del propietario del servicio incluirá un suplente». Sustituye «el acceso era difícil» por el permiso exacto que faltaba, la persona responsable de concederlo y la fecha del próximo simulacro.

El ensayo descubre las partes de las que nadie se hace cargo

Un runbook que no se ha practicado es una propuesta. El primer uso real descubrirá contactos desactualizados, autoridad insuficiente y desacuerdos sobre quién puede reiniciar el trabajo. Un ensayo convierte esas incógnitas en defectos corregibles cuando las consecuencias son pequeñas.

Primero realiza un ejercicio de mesa y después un simulacro técnico controlado. En el ejercicio de mesa, entrega a los participantes un escenario breve con información incompleta, como un agente que abre una conexión SSH inesperada durante un despliegue. Pídeles que sigan la cadena de llamadas, decidan si deben contener, completen el registro de aprobación e indiquen qué evidencias conservarían. No permitas que el autor del runbook responda a todas las preguntas.

En el simulacro técnico, usa un objetivo que no sea de producción o una ruta de prueba aislada de forma explícita. Inicia un proceso de agente conocido, autoriza una acción inofensiva, activa la contención, confirma que las acciones posteriores fallan, conserva los registros y realiza una recuperación limitada. Cronometra las acciones, pero no conviertas el ejercicio en una competición de velocidad. Una respuesta rápida que no revoca el acceso es peor que una respuesta más lenta que establece un límite claro.

Evalúa el simulacro con comprobaciones observables:

• ¿Pudo el observador contactar con el responsable del incidente y con la persona encargada de revocar usando los métodos documentados?
• ¿Tenía la persona encargada de revocar la autoridad necesaria sin que un administrador tuviera que improvisar el acceso?
• ¿Distinguió el equipo entre detener el proceso y retirar su autoridad?
• ¿Pudo un revisor relacionar la aprobación de emergencia con el registro de la acción resultante?
• ¿Desapareció el acceso temporal en la hora de expiración o retirada indicada?

NIST SP 800-61 recomienda explícitamente probar las capacidades de respuesta a incidentes, y ofrece una razón práctica: los ejercicios revelan carencias en los procedimientos, la formación y los controles técnicos. No limites las pruebas al equipo de respuesta a incidentes. Incluye a las personas que ejecutan el agente, son propietarias del servicio afectado y aprueban el trabajo urgente. Sus suposiciones suelen ser el punto donde se rompe el proceso.

Actualiza el runbook justo después del simulacro, mientras los nombres, las demoras y las instrucciones confusas aún están recientes. Después programa el siguiente ejercicio y asigna cada corrección a una persona responsable. Si nadie se hace cargo de una corrección, has registrado un defecto y has elegido no solucionarlo.

Coloca la tarjeta de primera acción donde el fallo no pueda ocultarse

El runbook completo puede vivir en tu sistema de documentación controlado, pero los responsables necesitan una tarjeta breve que siga disponible cuando las herramientas habituales sean lentas o estén afectadas. Guárdala en un lugar al que el equipo pueda acceder sin depender del entorno del agente y asegúrate de que remita a contactos actuales en lugar de copiar datos que cambian con frecuencia.

La tarjeta debe decir al observador a quién llamar, indicar al responsable del incidente cuándo puede declarar la contención, explicar a la persona encargada de revocar qué autoridad debe retirar primero y recordar a todos que la recuperación necesita una nueva decisión. También debe identificar el registro de evidencias y el lugar donde la persona encargada del registro escribe la línea temporal.

Revisa la tarjeta cada vez que cambies los ejecutores de agentes, los canales de acciones, la propiedad o los sistemas que conceden el acceso. No esperes a una auditoría anual. En el momento en que un equipo cambia la forma en que un agente llega al mundo exterior, su procedimiento de emergencia puede haberse convertido en ficción.

Un buen simulacro termina con una lista ligeramente incómoda de suposiciones equivocadas. Consérvala. El equipo que descubre sus fallos durante un ensayo ha hecho el trabajo necesario para no descubrirlos durante una interrupción.