Referencias de tickets de acciones de agentes que resisten la revisión

Un agente que puede llamar a una API de producción o abrir una sesión SSH necesita algo más que un registro de que actuó. Los revisores deben saber por qué se permitió esa acción en ese momento. Una referencia de ticket de cambio les ofrece un camino desde un comando observado o una llamada a una API hasta una intención aprobada.

Ese camino solo funciona cuando la referencia pasa a formar parte de la evidencia de la acción antes de ejecutarla. Pegar un número de ticket en un comentario después de que comienza un incidente es papeleo, no control. Los equipos que confunden ambas cosas terminan descubriendo que toda acción arriesgada tiene un ticket asociado y ninguno explica lo ocurrido.

Una referencia de ticket conecta la intención con la ejecución

Un ticket de cambio responde a una pregunta distinta de la que responde un evento de auditoría. El ticket indica qué solicitó alguien, por qué lo solicitó, qué sistemas pueden verse afectados y quién aceptó el riesgo. El evento indica qué intentó hacer realmente el agente contra un objetivo concreto, con una identidad concreta y con qué resultado.

Mantén separados esos registros y relaciónalos mediante una referencia estable. No incluyas todo el contenido del ticket en cada evento. El texto del ticket cambia, a menudo contiene información confidencial y dificulta las búsquedas en los eventos. Guarda el identificador canónico del ticket junto con una pequeña instantánea de los datos de autorización relevantes en el momento del envío.

Para una migración de una base de datos de producción, esa instantánea podría incluir la referencia del ticket, su revisión o fecha de actualización, la ventana de mantenimiento aprobada y el responsable del cambio. Para una llamada a una API que desactiva una cuenta, podría incluir la referencia, el identificador de la cuenta solicitada y la persona que aceptó la solicitud. El registro de la acción sigue necesitando sus propios detalles de solicitud y resultado.

Esta distinción detecta un fallo habitual. Un equipo abre CHG-418 para un cambio planificado de configuración de caché. Más tarde, un agente usa CHG-418 para eliminar un bucket de almacenamiento porque el ingeniero le dijo que «limpiara los recursos relacionados con el cambio». El ticket existe. La acción del agente tiene una referencia. Sin embargo, la referencia no justifica el objetivo ni la operación. Un revisor necesita suficiente contexto estructurado para detectar esa discrepancia sin leer una transcripción del chat.

OWASP Logging Cheat Sheet recomienda registrar el cuándo, dónde, quién y qué de los eventos relevantes para la seguridad. Esa orientación encaja bien aquí, pero las acciones de los agentes añaden una quinta parte: el contexto de autorización declarado. Una referencia de ticket por sí sola es demasiado escasa; copiar el ticket completo es excesivo. Registra la referencia y los datos concretos usados para decidir que la acción coincidía con ella.

El trabajo sensible necesita un límite escrito

Exige una referencia de ticket para las acciones cuyas consecuencias sean difíciles de revertir, de detectar o de explicar más adelante. No obligues a los agentes a pedir tickets antes de cada lectura inofensiva. Las personas buscarán una forma de esquivar una regla que interrumpe la investigación rutinaria, y las acciones importantes acabarán ocultas entre las excepciones.

Empieza por nombrar clases de acciones, en lugar de intentar predecir cada comando peligroso. La mayoría de los equipos debería incluir acciones que:

• modifiquen infraestructura de producción, configuración de aplicaciones o código desplegado
• creen, revoquen o cambien accesos de usuarios y servicios
• exporten, eliminen o muevan datos regulados o de clientes
• cambien el comportamiento de pagos, facturación, notificaciones o servicios públicos
• utilicen una ruta de emergencia o una credencial con autoridad amplia

Una conexión SSH puede ser sensible en un entorno y habitual en otro. La clasificación debe seguir lo que la conexión puede hacer y el lugar al que llega. Una sesión de diagnóstico de producción de solo lectura quizá necesite un registro de sesión, pero no un ticket. Un comando SSH que cambie reglas del firewall necesita una referencia aunque el comando tenga una sola línea.

No etiquetes una categoría como «alto riesgo» y lo dejes ahí. Define la prueba observable en el punto de control. Por ejemplo: cualquier solicitud que use una credencial de producción y envíe un método HTTP distinto de GET requiere una referencia; cualquier invocación SSH contra el grupo de hosts de producción la requiere, salvo que el comando coincida con una lista de diagnóstico permitida y documentada. Las reglas exactas varían, pero la prueba debe ser algo que un programa y un revisor puedan aplicar de forma coherente.

Existe una recomendación popular de exigir un ticket para cada acción porque parece disciplinada. Normalmente produce una pila de tickets genéricos, referencias copiadas y aprobaciones que nadie lee. Usa el requisito del ticket donde cree un punto de decisión. Conserva registros completos para todo lo demás, porque la ausencia de un ticket no debe convertirse en la ausencia de un evento.

Captura la referencia antes de enviar la solicitud

El punto de control debe rechazar una solicitud sensible que no tenga una referencia válida antes de enviar la llamada HTTP o iniciar el comando SSH. Un proceso posterior de enriquecimiento de registros no puede reparar esa brecha. Una vez que un sistema externo acepta una solicitud, tu registro local puede retrasarse, alterarse o no existir durante el fallo exacto que los investigadores necesitan reconstruir.

El flujo de la solicitud debe seguir un orden claro:

1. El agente propone una acción con objetivo, operación y referencia de ticket.
2. El punto de control comprueba que la referencia tenga el formato requerido y obtiene los datos del ticket que necesita.
3. Si hace falta una aprobación humana, esta cubre conjuntamente la acción propuesta y la referencia.
4. El punto de control escribe un evento de intención, envía la acción y después escribe el evento de resultado.

Es importante escribir un evento de intención. Supón que se produce un tiempo de espera de red después de que un proveedor de API recibe DELETE /v1/projects/acme-prod. Si solo registras las respuestas correctas, el diario de acciones indica falsamente que no ocurrió nada. Un registro de intención informa al revisor de que el sistema intentó enviar la solicitud. Un resultado unknown no es un defecto del registro de auditoría. Es el resultado honesto hasta que alguien compruebe el sistema de destino.

El mismo principio se aplica a SSH. Registra la identidad del host de destino, el comando o un resumen de comando aprobado, la referencia del ticket y el inicio de la ejecución antes de lanzar el proceso. Después registra el estado de salida, la política aplicada a la salida capturada y la hora de finalización. Si el proceso pierde la conexión, conserva ese resultado en lugar de convertirlo en un fallo limpio.

No permitas que un cliente envíe un campo de texto libre modificable llamado change_note y dé por terminado el trabajo. Un campo estructurado ticket_ref permite validar, generar informes y conciliar. El texto libre da al agente un lugar donde ocultar un número creíble dentro de un párrafo.

El número del ticket debe coincidir con el alcance solicitado

Una referencia con aspecto válido no demuestra que la acción encaje en el trabajo aprobado. El punto de control debe comparar el alcance conocido del ticket con la solicitud cuando esa información esté disponible, y debe exigir una decisión humana cuando no lo esté.

Como mínimo, valida que el ticket exista, no haya sido cancelado y se encuentre en un estado que tu organización acepte para la ejecución. Muchos equipos también exigen una ventana de cambio vigente y un responsable aprobado. Estas comprobaciones evitan el uso descuidado de un ticket antiguo, pero no detectan el desvío del objetivo.

El desvío del objetivo ocurre cuando el ticket describe un servicio, cuenta, entorno o región y la solicitud afecta a otro. La mejor defensa es disponer de un alcance estructurado en el propio sistema de tickets. Si un ticket tiene campos legibles por máquinas para entorno, servicio, repositorio, cuenta o ventana de mantenimiento, compáralos con los atributos de la solicitud. Evita inferir el alcance a partir de la prosa. Las descripciones en lenguaje natural son útiles para las personas, pero un analizador puede aprobar disparates con una confianza impresionante.

Cuando un ticket solo contiene prosa, presenta juntos la acción y la referencia para su aprobación. La persona debe ver el destino y el verbo en términos claros: «Aplicar una actualización de configuración al servicio de producción billing-api bajo CHG-418». No muestres únicamente «Aprobar la acción del agente bajo CHG-418». Esa redacción oculta la decisión exacta que se pide tomar.

No construyas un lenguaje de reglas enorme solo para gestionar cada matiz de los tickets. Empieza con un conjunto pequeño de comparaciones que puedas explicar durante un incidente: entorno, identificador del objetivo, hora solicitada y solicitante o responsable. Envía los casos inciertos a una aprobación explícita. Una comprobación limitada que falla de forma segura es mejor que una capa de interpretación ingeniosa que nadie pueda auditar.

Usa un contrato de eventos que los revisores puedan consultar

Un evento de acción necesita campos estables, no una narración ensamblada a partir de la salida de la terminal. Este ejemplo muestra un registro JSON genérico para el intento de acción. Separa deliberadamente la referencia declarada de los datos observados durante la ejecución.

{
  "event_id": "act_01J8M7FQ6F2Y3K9D",
  "event_type": "action.intent",
  "occurred_at": "2025-03-08T14:32:11Z",
  "agent_run_id": "run_7e9d2",
  "actor": {
    "agent_process": "release-agent",
    "human_requester": "ops-204"
  },
  "ticket": {
    "system": "changes",
    "reference": "CHG-418",
    "observed_state": "approved",
    "observed_at": "2025-03-08T14:31:58Z",
    "scope_digest": "sha256:4ea4..."
  },
  "action": {
    "channel": "http",
    "operation": "PATCH",
    "target": "prod/billing-api/config",
    "request_digest": "sha256:35b9...",
    "idempotency_id": "chg-418-billing-01"
  },
  "decision": {
    "reference_required": true,
    "authorized_by": "ops-204",
    "decision_at": "2025-03-08T14:32:07Z"
  }
}

El evento de finalización reutiliza event_id como referencia principal o usa un attempt_id separado. Registra el estado HTTP, el código de salida de SSH, el ID de solicitud del proveedor cuando esté disponible y un resultado como succeeded, failed o unknown. No incluyas en este registro encabezados de autorización sin procesar, cookies de sesión, cuerpos de solicitud con secretos ni material privado de SSH.

Un resumen criptográfico tiene sentido cuando puedes conservar pruebas de la carga exacta sin hacer que el contenido sensible pueda buscarse por cualquier lector de registros. Canonicaliza los datos antes de calcular el hash. Define el orden de los campos, la codificación y las reglas de redacción; de lo contrario, dos solicitudes equivalentes producirán resúmenes distintos y la comparación será una simple apariencia de control.

Puedes detectar referencias ausentes en JSON delimitado por saltos de línea antes de que los eventos lleguen al almacenamiento a largo plazo. Esta comprobación de jq devuelve un estado de salida distinto de cero cuando una acción sensible no tiene referencia:

jq -e '
  select(.event_type == "action.intent")
  | select(.decision.reference_required == true)
  | select((.ticket.reference // "") | length == 0)
  | error("sensitive action has no ticket reference")
' actions.ndjson

Ejecuta una consulta complementaria que encuentre referencias sin evento de finalización. Un vínculo con el ticket solo sirve cuando el diario muestra si la ejecución solicitada tuvo lugar.

No permitas que el agente fabrique su propia evidencia

Un agente puede proponer una referencia de ticket, pero no debe poder declarar que la referencia está aprobada y dentro del alcance. Es el mismo error que pedir a un proceso que certifique que sus propias credenciales son adecuadas.

Ofrece al agente uno de dos caminos. En el primero, una persona proporciona una referencia al asignar el trabajo y el agente recibe un contexto de trabajo de corta duración que contiene esa referencia y el alcance de objetivos permitido. En el segundo, el agente solicita a un servicio de confianza que busque un ticket por referencia, y el punto de control comprueba la respuesta de forma independiente antes del envío. El agente solo ve los datos que necesita para formular la solicitud.

Un contexto de trabajo firmado podría tener este aspecto conceptual:

{
  "ticket_ref": "CHG-418",
  "allowed_targets": ["prod/billing-api/config"],
  "allowed_operations": ["PATCH"],
  "expires_at": "2025-03-08T15:00:00Z",
  "issued_for_run": "run_7e9d2"
}

El emisor firma el contexto serializado. El punto de control verifica la firma, la caducidad, el objetivo, la operación y la identidad de la ejecución. El agente no puede ampliar la caducidad ni añadir un segundo objetivo sin invalidar la firma. Si tu sistema de tickets no puede emitir contextos firmados, conserva la misma lógica en el servidor y registra en el evento los datos de la respuesta de la consulta.

Vincula el contexto a una ejecución concreta del agente. Sin esa vinculación, un proceso comprometido puede copiar una referencia aprobada de una tarea a otra. Registra también la identidad del código o del proceso que realizó la llamada cuando tu entorno pueda proporcionarla. Un nombre humano en un ticket y un proceso local anónimo en un registro no establecen una cadena confiable.

Los reintentos y lotes necesitan evidencia individual

Un ticket puede autorizar un cambio limitado a una ventana concreta, pero nunca debe agrupar muchas acciones en una única entrada de auditoría ambigua. Los revisores necesitan distinguir una secuencia planificada de un fallo repetido, una finalización parcial o un agente que se salió del alcance.

Asigna a cada intento su propio ID de acción. Adjunta la referencia compartida del ticket a cada intento y agrupa los intentos relacionados con un ID de ejecución o de ejecución del cambio. Registra un identificador de idempotencia cuando el destino lo admita. Este identificador ayuda a determinar si un reintento creó un segundo cambio, pero no sustituye el registro del intento.

Imagina un agente que actualiza diez configuraciones de servicios. Las primeras siete llamadas devuelven un resultado correcto, la octava agota el tiempo de espera y el agente la reintenta dos veces. Un diario útil lo dice exactamente: diez objetivos previstos, siete resultados confirmados, un resultado desconocido y dos reintentos. Un único comentario del ticket que diga «actualización de configuración completada» oculta el único servicio que quizá necesite una revisión manual.

Para los lotes, exige que el ticket nombre una población limitada o incluya un manifiesto. Guarda un resumen de ese manifiesto con la ejecución. Si el agente descubre un undécimo objetivo después de comenzar el cambio, detente y solicita una nueva decisión sobre el alcance. Tratar el descubrimiento como permiso es la forma en que un trabajo de mantenimiento se convierte en una migración no revisada.

El trabajo de emergencia también merece una referencia, aunque esta se cree después de la primera acción de protección. Registra un indicador de emergencia, el motivo, la persona que aprobó la acción y la hora en que se abrió el ticket normal. No reutilices en silencio un ticket rutinario porque abrir un registro de incidente parezca lento. Las emergencias necesitan más evidencia, no menos.

Concilia los tickets y las acciones en ambas direcciones

Un informe semanal que enumera los tickets mencionados en los registros no basta. Necesitas dos comprobaciones separadas. Primero, encuentra cada acción sensible sin una referencia válida. Segundo, encuentra cada ticket completado o aprobado que afirma que hubo ejecución pero no tiene evidencia de acción coincidente.

La primera comprobación detecta omisiones de control. La segunda detecta notas de finalización falsas, trabajo manual fuera de la ruta del agente y fallos de integración. Ningún informe demuestra por sí solo una conducta indebida. Ambos indican al operador dónde hacer una pregunta concreta mientras el contexto todavía está disponible.

Usa una regla de relación estable. Si el sistema de cambios tiene varios proyectos, guarda el nombre del sistema y la referencia. Si las referencias pueden reutilizarse después del archivado, incluye un ID inmutable del registro del ticket o una revisión de la instantánea. Si un ticket puede editarse después de la ejecución, conserva el estado y el resumen del alcance observados cuando se autorizó la acción. De lo contrario, una edición posterior puede hacer que una evidencia antigua parezca aprobada cuando no lo estaba.

Trata las excepciones como registros de primera clase. Una excepción debe indicar quién la aceptó, por qué falló la vinculación normal, qué acción ocurrió y cuándo caduca la excepción. Una hoja de cálculo con excepciones informales se convierte en pocos meses en un segundo sistema de cambios, más débil.

El diario de actividad documentado de Sallyport registra llamadas individuales, pero los equipos deben conservar la vinculación con los tickets en sus propios registros de cambios o en un evento inmutable complementario hasta que exista un campo documentado de referencia de ticket. No afirmes que una nota de texto libre tiene el mismo valor probatorio que un campo capturado y validado antes del envío.

Conserva la evidencia sin exponer el contenido de los tickets

Los sistemas de tickets suelen contener nombres de clientes, detalles de incidentes, notas de arquitectura e información de acceso. Los registros de acciones suelen tener una audiencia más amplia durante las operaciones y las revisiones. Guarda la referencia y la instantánea de autorización, y permite que los revisores autorizados abran el sistema de tickets cuando necesiten el texto completo.

Redacta los datos de la solicitud antes de calcular una representación que pueda buscarse y conserva el original con control de acceso solo si los requisitos de investigación lo justifican. Un resumen puede confirmar que una carga conservada no ha cambiado, pero no ayuda a un revisor a entender una carga que no puede recuperar. Decide deliberadamente qué sistema conserva el original protegido y quién puede recuperarlo.

Conserva la referencia del ticket incluso después de que el sistema de tickets elimine o archive el registro de origen. La referencia ofrece a los investigadores un punto de partida, mientras que el estado capturado, el objetivo, la decisión y el resultado mantienen inteligible el registro de la acción por sí solo. Si las reglas de conservación exigen eliminarlo, registra ese hecho en lugar de dejar un vínculo roto que parezca un error.

Un primer control sencillo basta para revelar las brechas: rechaza las acciones sensibles sin una referencia estructurada, escribe la intención antes del envío y conserva el resultado después del envío. Cuando eso funcione, añade la comparación de alcance y la conciliación. El número del ticket debe ayudar al revisor a trabajar más rápido y con mayor certeza, no dar al agente una cadena decorativa que adjuntar a un trabajo arriesgado.