Agentes de respuesta a incidentes: acceso a producción sin caos

Los agentes de respuesta a incidentes de producción deberían investigar primero y recuperar el servicio solo después de que una persona apruebe una acción concreta y limitada. Ese límite es práctico, no ceremonial. Durante una interrupción, un agente puede reunir pruebas dispersas más rápido que una persona cansada, pero no puede asumir la decisión de cambiar el estado en vivo.

Un mal diseño entrega al agente un shell de producción, un rol amplio en la nube y una frase en el runbook que dice «usa tu criterio». El diseño parece rápido hasta que el agente reinicia el grupo de trabajadores equivocado, escala un despliegue defectuoso, rota una credencial que una dependencia todavía necesita o convierte un fallo aislado en una interrupción mayor. Un buen diseño le da un mapa de diagnóstico y mantiene las acciones de recuperación suficientemente limitadas para que una persona pueda entender cada una.

La autoridad de diagnóstico y la autoridad de recuperación son permisos distintos

El trabajo de diagnóstico pregunta al sistema qué ocurrió. El trabajo de recuperación le indica al sistema que cambie. Los equipos difuminan la línea porque un comando como restart parece rutinario y porque muchos paneles permiten inspeccionar y modificar el mismo recurso desde una sola pantalla. Tratar ambos permisos como uno solo es la forma en que un asistente útil para incidentes se convierte en un operador de producción cuya responsabilidad no está clara.

Las acciones de diagnóstico no deberían cambiar el comportamiento del servicio. Pueden leer métricas, consultar registros dentro de un intervalo definido, recuperar metadatos de despliegues, inspeccionar endpoints de salud, comparar revisiones de configuración y recopilar datos acotados de una base de datos. Una acción de diagnóstico puede revelar información sensible, así que también necesita alcance y registros de auditoría. No necesita autoridad para modificar el estado de la aplicación.

Las acciones de recuperación modifican alguna parte del sistema en ejecución. Incluyen rollback, reinicio, cambio de tráfico, escalado, cambios en feature flags, rotación de credenciales, reprocesamiento de colas, failover, reparación de bases de datos y desactivación de integraciones. Algunas acciones son reversibles, pero ninguna es inofensiva por defecto. Un reinicio puede terminar con el único proceso que posee un lease. El escalado puede agotar una dependencia compartida. El reprocesamiento de una cola puede duplicar mensajes de clientes.

Usa esta prueba para clasificar una acción: si repetir exactamente la misma acción en el mismo momento podría producir un resultado distinto porque cambia el estado, colócala en recuperación. Si una acción modifica una caché, crea un ticket de soporte, envía un mensaje, cambia el silencio de una alerta o escribe una anotación que consume otra automatización, también cambia el estado. No llames a estas acciones «lecturas» solo porque no toquen la base de datos principal.

NIST SP 800-61 Revision 2 separa la contención, la erradicación y la recuperación de la detección y el análisis. Esa división resulta útil aquí. Un agente puede acortar mucho la detección y el análisis. En el momento en que propone contención o recuperación, una persona responsable debe seleccionar la acción y aceptar sus consecuencias. El documento no resuelve tu modelo de autorización, pero sus fases de incidentes evitan una ficción peligrosa: investigar e intervenir no son el mismo trabajo.

Un rol de solo lectura no es automáticamente seguro. Las consultas de registros pueden contener tokens de acceso. Los atributos de trazas pueden exponer identificadores de cuentas. Un endpoint de configuración puede devolver credenciales. Incorpora la redacción y los límites de campos en la interfaz de diagnóstico, en lugar de dar al agente la capacidad de recuperar artefactos sin restricciones. La visibilidad de producción necesita su propio límite.

Dale al agente preguntas, no un shell general de producción

Un agente trabaja mejor bajo presión cuando sus herramientas expresan directamente las preguntas del incidente. Un shell general obliga al agente a descubrir tanto el sistema como el procedimiento operativo seguro mientras corre el reloj. También hace casi imposible la revisión, ya que kubectl, las CLI de la nube, los clientes de bases de datos y SSH pueden hacer mucho más de lo que requiere el incidente.

Expón acciones de diagnóstico centradas en las pruebas que una persona solicitaría durante los primeros minutos:

• recuperar la tasa de errores, la latencia, la saturación y la disponibilidad de un servicio y un intervalo concretos
• encontrar el despliegue, la revisión de configuración y los cambios de dependencias cercanos al primer error
• buscar en registros estructurados usando un conjunto de campos permitido y un número máximo de resultados
• inspeccionar el estado de salud y los eventos recientes de un componente especificado
• comparar un canary o una región con un equivalente conocido como saludable

Cada acción necesita un contrato de entrada limitado. get_service_errors(service, start, end, group_by) indica al revisor qué solicitó el agente. run_query(text) no le dice casi nada e invita a escaneos completos accidentales, predicados inseguros o texto de consulta inyectado mediante una instrucción.

Pon los límites estrictos en la herramienta, en lugar de pedirle al modelo que los recuerde. Una herramienta de métricas debe rechazar un intervalo demasiado amplio. Una herramienta de registros debe limitar los registros devueltos y ocultar los campos configurados antes de entregar los datos al modelo. Una consulta de despliegues debe aceptar un identificador de aplicación de un inventario conocido, no una URL arbitraria proporcionada en el comentario de un issue. Estos límites reducen el coste y evitan que un incidente se convierta en un ejercicio de exfiltración de datos.

El siguiente catálogo de acciones es deliberadamente aburrido. En una interrupción, aburrido es un elogio.

incident_actions:
  diagnostics:
    - name: service_summary
      inputs: [service, start_time, end_time]
      limits: {max_window_minutes: 180}
    - name: recent_deployments
      inputs: [service, since_time]
    - name: log_sample
      inputs: [service, start_time, end_time, error_code]
      limits: {max_records: 200, redact_fields: [authorization, cookie, token]}
    - name: dependency_health
      inputs: [dependency, region]
  recovery:
    - name: rollback_release
    - name: set_traffic_weight
    - name: restart_component
    - name: disable_feature_flag

Este fragmento evita un fallo frecuente en las herramientas internas: un agente supuestamente de solo lectura recibe un endpoint de consultas universal porque resulta práctico para la primera demostración. Más tarde alguien descubre que puede recuperar cada línea de registro de todos los servicios o invocar una ruta de escritura oculta. Los nombres de las herramientas no crean seguridad. La validación de entradas, una lista permitida, una salida limitada y credenciales que no pueden escribir sí lo hacen.

No des a un agente de diagnóstico acceso SSH a producción solo porque SSH facilita la inspección. El acceso al shell combina lecturas de archivos, control de procesos, acceso de red y, a menudo, una ruta hacia las credenciales. Si tienes que exponer datos del host, ofrece comandos específicos, como el estado de los procesos, el uso del disco, determinadas entradas del journal o un envoltorio de comandos controlado. El envoltorio debe rechazar pipes, redirecciones, sustitución de comandos y flags arbitrarios. Una instrucción en lenguaje natural no vuelve seguro un shell.

Un catálogo de recuperación debe ser lo bastante corto para ensayarlo

Una persona no puede aprobar de forma significativa un menú interminable de cambios en producción. Define un catálogo de recuperación breve para cada clase de servicio, con descripciones claras, parámetros fijos cuando sea posible y una persona responsable identificada. Si una acción de recuperación no se puede explicar en una sola tarjeta de aprobación, hay que dividirla antes de que un agente pueda solicitarla.

Un catálogo razonable puede incluir volver a la versión aprobada inmediatamente anterior, establecer en cero el peso de tráfico de una revisión defectuosa, reiniciar un componente sin estado concreto, desactivar un feature flag existente o pausar un consumidor identificado. No debería incluir «ejecutar una corrección arbitraria», SQL arbitrario, cambios amplios de IAM ni scripts improvisados copiados de una conversación con un agente.

Para cada elemento del catálogo, escribe estos cinco datos antes de que un incidente obligue a debatirlos:

1. Especifica exactamente qué cambia, incluido el entorno y el alcance del recurso.
2. Nombra los requisitos previos que el agente debe recopilar, como un identificador de versión confirmado o una alternativa saludable.
3. Indica qué observación se espera después de la ejecución y cuál es el tiempo máximo de espera antes de escalar.
4. Nombra la acción de rollback o compensación, si existe.
5. Asigna el rol humano que puede aprobarla.

El catálogo necesita límites para sus parámetros. «Establecer el peso del tráfico» es demasiado amplio. «Establecer la revisión orders-v184 en cero por ciento en eu-west después de confirmar que la revisión estable está saludable» es una solicitud que se puede aprobar. La solicitud no debe permitir que el modelo elija una región, una revisión y un porcentaje sin restricciones.

No hagas que la lista de acciones parezca completa. Debe omitir las acciones que requieren un criterio específico. La reparación de migraciones de bases de datos, la eliminación de datos, las comunicaciones con clientes, la concesión de accesos y la rotación de credenciales suelen implicar información que ningún agente genérico de incidentes puede inferir. El resultado correcto para una acción que no aparece en la lista es una negativa clara junto con las pruebas reunidas hasta ese momento.

Un catálogo breve también permite hacer simulacros. Ejecuta un incidente de prueba y pregunta si la persona designada para aprobar puede distinguir una solicitud para pausar un consumidor de una solicitud para eliminar su cola pendiente. Si la respuesta depende de leer el código fuente o de confiar en el resumen del agente, el texto de aprobación es débil.

La aprobación debe vincular una solicitud exacta con una persona y un momento

Una aprobación humana solo sirve cuando autoriza una acción propuesta específica, no una sesión de incidente vaga. «Aprueba la corrección de payments» deja al agente margen para elegir un cambio después de que la persona haya dejado de observar. Vincula la aprobación al tipo de acción, el objetivo, los parámetros, el identificador del incidente, la identidad de quien realiza la llamada y una caducidad breve.

Una solicitud de aprobación debe mostrar las pruebas que respaldan la acción, pero separar las pruebas del cambio solicitado. Las personas que responden a incidentes necesitan ver que las tasas de error subieron después de la versión 184, que la versión anterior sigue disponible y que la región seleccionada tiene capacidad saludable. También necesitan ver exactamente qué ocurrirá si hacen clic en aprobar.

Usa un objeto de solicitud con campos inmutables y rechaza la ejecución si cambia cualquiera de los campos aprobados:

{
  "incident_id": "inc-2025-041",
  "action": "rollback_release",
  "target": {"service": "orders", "environment": "production", "region": "eu-west"},
  "parameters": {"from_release": "184", "to_release": "183"},
  "evidence_refs": ["metric:err-17", "deploy:184", "health:183"],
  "requested_by": {"agent_session": "sess-8f2a", "process_identity": "signed-agent-build"},
  "expires_at": "2025-03-08T14:35:00Z"
}

El ejecutor debe devolver un resultado que conserve el identificador de la solicitud y registre si la acción comenzó, terminó, falló o agotó el tiempo. Un mensaje de estado como «rollback terminado» es demasiado impreciso para la cronología de un incidente. El agente debe leer el resultado y volver a ejecutar sus comprobaciones de diagnóstico. No debe asumir que una respuesta correcta de la API ha restaurado el servicio.

No uses una única aprobación temprana para todas las acciones posteriores. La fatiga de aprobación existe, pero una autorización general cambia la fatiga por ambigüedad. Agrupa solo las acciones que compartan el mismo objetivo, efecto esperado y riesgo. Una persona podría aprobar como un único paquete de recuperación la retirada del tráfico y el rollback de una versión si ambas acciones se fijan de antemano. Eso no debería aprobar un cambio de base de datos, una rotación de credenciales ni una región diferente.

Exige una nueva aprobación cuando cambie la hipótesis del agente. Esto detecta una secuencia de fallo frecuente: el agente empieza sospechando de un despliegue, obtiene aprobación para revertirlo, observa después un error de base de datos y decide ejecutar otra acción con la autorización anterior. La aprobación antigua ha caducado en la práctica aunque el reloj diga que aún es válida.

Las sesiones de incidentes evitan la autoridad permanente en producción

Un agente de incidentes necesita una identidad separada de la persona operadora y de su transcripción de chat. Registra qué ejecutable o proceso remoto solicitó el acceso, a qué incidente pertenece, qué acciones de diagnóstico invocó y quién aprobó cada solicitud de recuperación. Sin esa separación, la revisión posterior al incidente se convierte en una búsqueda entre textos en lugar de un registro de autoridad.

Una sesión debe comenzar con una referencia al incidente, un entorno declarado, un alcance explícito de diagnóstico y una caducidad. Debe terminar cuando sale el proceso del agente, pasa la caducidad o una persona operadora la revoca. La revocación debe aplicarse antes de la siguiente acción, incluidas las lecturas. Durante un posible incidente de credenciales o de inyección de instrucciones, mantener el acceso de lectura también puede aumentar el daño.

La autorización por sesión es un mejor valor predeterminado que tratar cada llamada de diagnóstico como una instrucción aislada. La primera solicitud de un proceso de agente nuevo permite a la persona operadora inspeccionar de dónde procede la solicitud y por qué tiene visibilidad de producción. Después, el agente puede reunir pruebas sin pedir aprobación para cada gráfico o muestra de registros. La recuperación sigue necesitando aprobación para cada llamada.

La diferencia entre la identidad del agente y la identidad de la persona importa en máquinas compartidas y entornos similares a CI. Una cuenta humana puede estar autorizada para responder a incidentes, mientras que un proceso de agente copiado o un envoltorio de herramienta malicioso no lo está. Captura la autoridad de firma del código u otra identidad de proceso verificable cuando el entorno lo permita. El título de una ventana y una etiqueta proporcionada por el usuario no son una identidad.

Sallyport usa una puerta absoluta para la bóveda, autorización de sesión para un proceso de agente nuevo y una opción por clave para cada uso individual. Ese diseño encaja con el trabajo de incidentes porque la persona puede permitir una ejecución de diagnóstico limitada y reservar las credenciales sensibles de recuperación para una decisión nueva.

Evita pasar credenciales por el contexto del agente, incluso temporalmente. Una credencial pegada en una instrucción del agente no se puede recuperar y el agente podría reproducirla en un comando, una transcripción, un registro o una solicitud externa. El ejecutor debe conservar la credencial, realizar la acción de API o SSH permitida y devolver solo el resultado necesario para la investigación.

Los registros de auditoría deben explicar la intención y la ejecución

Las notas de los incidentes suelen registrar lo que las personas creen que ocurrió. Rara vez registran la solicitud exacta que hizo un agente, la autoridad que la permitió y el resultado devuelto por el sistema posterior. Necesitas las cuatro cosas. Una cronología que diga «el agente revirtió orders» no puede responder si el agente solicitó un rollback, si una persona aprobó la versión 183 o si el sistema de despliegue aceptó realmente el comando.

Registra un evento duradero para la creación de la sesión, cada llamada de diagnóstico, cada propuesta de recuperación, cada aprobación o denegación, cada intento de ejecución, cada resultado, cada revocación y el final de la sesión. Cada evento debe incluir una marca de tiempo, identificadores de correlación, identidad del proceso, nombre de la acción, objetivo, parámetros normalizados y código de resultado. Guarda con cuidado el contenido sensible de las solicitudes: la auditoría debe conservar el significado sin convertirse en otro almacén de secretos sin control.

Una cadena de hashes facilita detectar modificaciones posteriores porque cada registro incorpora el hash del registro anterior. No demuestra que el recopilador recibiera todos los eventos desde el principio. Diseña para ambas propiedades. Haz que al ejecutor de acciones le resulte difícil reescribir el registro de eventos, conserva los identificadores de solicitud de origen y verifica periódicamente la cadena fuera del control del agente.

Un comando de verificación sin conexión debería producir un resultado sencillo y fácil de inspeccionar:

$ sp audit verify
verified: 1842 records
first sequence: 2025-03-08T12:01:09Z
last sequence:  2025-03-08T14:42:31Z
chain: valid

Sallyport proyecta un diario de sesión y un diario de actividad individual a partir de un único registro cifrado y encadenado mediante hashes, y sp audit verify puede comprobar la cadena sobre el texto cifrado. Esto resulta útil como prueba del incidente porque la verificación no requiere abrir la bóveda solo para comprobar si se ha modificado el historial.

Mantén la revisión de auditoría fuera del ciclo activo del agente. El agente puede citar sus propios identificadores de acciones registradas, pero la persona responsable del incidente o el revisor deben poder inspeccionar el registro de forma independiente. De lo contrario, un agente que tergiverse lo que hizo también podría controlar las pruebas que ve la persona que responde.

Un rollback fallido muestra por qué las pruebas deben preceder a la intervención

Imagina un servicio cuya tasa de errores sube poco después de un despliegue. El agente observa la coincidencia temporal y propone un rollback. Un agente de producción con acceso amplio podría ejecutarlo de inmediato. Es rápido, pero puede estar equivocado.

Un agente disciplinado recupera primero el desglose de errores por versión y región, los registros de despliegue recientes, la salud de las dependencias y la saturación de recursos. Las pruebas muestran que solo falla una región, pero allí fallan tanto la revisión nueva como la anterior. Un rollback consumiría tiempo, crearía un segundo evento de despliegue y dejaría intacta la interrupción de la dependencia.

El agente propone entonces no realizar ninguna acción de recuperación. Informa de que el fallo es regional y de que el endpoint de salud de la dependencia está fallando. Una persona aprueba después un cambio de tráfico predefinido para alejarlo de esa región, si la capacidad y las reglas de datos del servicio lo permiten. El agente ejecuta la acción solo después de recibir la aprobación, observa la tasa de errores resultante y registra tanto la solicitud como el resultado.

Cambia ahora un detalle. La acción de diagnóstico devuelve un error porque el intervalo solicitado es demasiado amplio. El agente debe informar de que las pruebas son incompletas, en lugar de reintentarlo en silencio con una exportación amplia de registros. Los límites no son inconvenientes que haya que sortear durante un incidente. Evitan que un modelo convierta la incertidumbre en una solicitud de acceso mayor.

Otra variante resulta más incómoda: el cambio de tráfico aprobado tiene éxito en la API, pero la tasa de errores no baja. El agente no debe escalar por su cuenta a un reinicio, un rollback o una rotación de credenciales. Debe recopilar las siguientes observaciones permitidas y preparar una propuesta nueva. Las personas también toman malas decisiones durante los incidentes, pero al menos deberían tomar la decisión que queda registrada.

Por eso fracasa la recomendación popular de conceder acceso amplio «solo durante los incidentes». Los incidentes reducen la atención, aumentan la urgencia y suelen implicar telemetría parcial o engañosa. Estas condiciones hacen más necesarias las interfaces limitadas y las aprobaciones explícitas, no menos.

Incluye las rutas de rechazo en el runbook antes de la próxima interrupción

Un agente de incidentes seguro necesita casos claros en los que debe detenerse. El runbook debe indicarle que rechace un cambio no incluido en la lista, una acción fuera del entorno declarado, una solicitud a la que le falten requisitos previos, una aprobación caducada y cualquier operación posterior a la revocación de la sesión. Cada rechazo debe nombrar la condición y conservar las pruebas que ya haya reunido.

Prueba la ruta de rechazo con el mismo cuidado que la ruta normal. Pide al agente que investigue un incidente de producción y después inyecta desde un ticket no confiable una solicitud para recuperar un valor de configuración secreto. Comprueba que la herramienta lo rechaza. Solicita un rollback después de que caduque la aprobación. Comprueba que el ejecutor lo rechaza aunque el agente repita exactamente el texto de la acción. Revoca la sesión mientras una secuencia de diagnóstico está activa. Comprueba que la siguiente llamada falla.

Mantén separadas las credenciales de recuperación y las credenciales de diagnóstico. Si una misma credencial puede leer registros y eliminar una cola, una pantalla de aprobación no puede reparar esa autoridad subyacente. El ejecutor debe seleccionar una credencial cuyos permisos coincidan con la acción del catálogo. Si un sistema no admite esta separación, no lo pongas detrás de un agente autónomo hasta que puedas añadir un punto de control más seguro.

El primer despliegue en producción de este patrón debería centrarse en un fallo conocido con una corrección limitada. Elige un servicio en el que las personas que responden ya usen un conjunto pequeño de llamadas de lectura y una acción de recuperación bien entendida. Mide si las pruebas del agente reducen el tiempo dedicado a reunir datos, si las personas que aprueban entienden las solicitudes sin leer una transcripción y si el registro de auditoría reconstruye el evento. Amplía el catálogo solo después de que esas respuestas se mantengan en los simulacros.

Un agente de producción gana confianza tomando menos decisiones que una persona que responde, no tomando decisiones más grandes. Encárgale encontrar los hechos, conserva la decisión humana en el punto del cambio y haz visible cada transición de las pruebas a la acción cuando la alerta ya haya dejado de sonar.