Evidencia de autorización: demuestra que las acciones del agente de IA se completaron

Un registro de aprobación te dice que una persona permitió que un agente intentara algo. No te dice si la solicitud llegó al servicio, si el host remoto aceptó el comando o si se produjo el cambio previsto. Tratar la aprobación como una prueba de finalización crea registros de auditoría tranquilizadores hasta el momento en que alguien que revisa un incidente pregunta: «¿Qué ocurrió realmente?»

Esta diferencia es urgente en el caso de los agentes de IA, porque pueden ejecutar muchas acciones reales mientras resuelven una tarea de desarrollo común. Una persona puede aprobar una vez el proceso de un agente y, después, el proceso crear un ticket, cambiar un ajuste de despliegue, consultar una API de producción o ejecutar un comando remoto. Cada acción necesita evidencia con un significado distinto. La decisión humana y el resultado posterior deben formar parte de la misma investigación, pero no son intercambiables.

Una aprobación registra permiso, no finalización

La evidencia de autorización responde si una persona con autoridad reconocida permitió una acción definida en un momento concreto. La evidencia de ejecución responde qué intentó hacer la pasarela de acciones y qué devolvió el destino. Un diseño de auditoría que guarda solo la primera respuesta deja un hueco importante.

Imagina un agente que recibe aprobación para llamar a una API que crea un token de acceso. La pasarela envía la solicitud, pero la conexión se interrumpe después de que el servicio la procese y antes de que el cliente reciba una respuesta. La aprobación sigue siendo válida. Un registro que dice «aprobado» no permite saber si el token existe. Un registro que afirma «completado» porque la pasarela envió bytes es peor: convierte la incertidumbre en un hecho falso.

El mismo error aparece con SSH. Una persona aprueba deploy.sh. El cliente SSH se autentica, se inicia el shell remoto y la conexión de red muere mientras se ejecuta el script. ¿Terminó el script? ¿Modificó parcialmente un sistema? El registro de conexión no puede responder. Necesitas el estado de salida remoto, si el cliente lo recibió, y un registro claro de resultado desconocido si no lo recibió.

Mantén separadas estas preguntas:

• ¿Una persona o un control aprobado autorizó este proceso de agente?
• ¿Qué capacidad exacta cubría la autorización?
• ¿La pasarela envió la acción al destino?
• ¿Qué resultado devolvió el destino o el transporte?
• ¿Los revisores posteriores pueden verificar que nadie editó el historial?

Muchos equipos comprimen las cinco preguntas en un único evento llamado agent_action. Es práctico para un panel y resulta inútil cuando los hechos divergen. Guarda eventos relacionados y muéstralos juntos en la interfaz.

La publicación especial 800-53 Rev. 5 del NIST plantea una exigencia práctica parecida en el control AU-3. El contenido del registro de auditoría incluye qué ocurrió, cuándo ocurrió, dónde ocurrió, cuál fue la fuente, cuál fue el resultado y qué identidad está vinculada al evento. Lo importante no es el lenguaje de lista de comprobación. Es la insistencia en que el resultado debe formar parte del registro. Una decisión de permiso no puede ocupar ese campo.

Los dos registros necesitan campos distintos

Un modelo de auditoría claro usa un evento de autorización y uno o más eventos de ejecución para una sola acción solicitada. Comparten un identificador de correlación, pero cada uno conserva los campos que respaldan su propia afirmación.

El registro de autorización debe identificar la solicitud antes de que empiece la ejecución. Captura la identidad del proceso que hace la llamada, la decisión humana, la referencia de la credencial, el canal previsto, el destino y la operación solicitada. Registra el alcance de la autorización con suficiente precisión para que un revisor pueda comprobar si la llamada posterior se mantuvo dentro de él.

Una estructura útil sería esta:

{
  "event_type": "authorization.granted",
  "action_id": "act_01JX7K8N4Q",
  "session_id": "ses_01JX7JYQ2M",
  "time": "2025-03-08T14:21:18Z",
  "agent_process": {
    "pid": 4812,
    "code_signing_authority": "Example Development Team"
  },
  "human_decision": {
    "method": "local_confirmation",
    "actor": "local_user"
  },
  "requested_action": {
    "channel": "http",
    "credential_ref": "billing-api-prod",
    "method": "POST",
    "destination": "api.internal.example",
    "path": "/v1/refunds"
  }
}

Este registro no debe contener por defecto el secreto de la API, la clave privada SSH, el encabezado de autorización ni el cuerpo sin procesar de la solicitud. Un almacén de auditoría lleno de credenciales se convierte en una segunda vía de ataque. Si los revisores necesitan distinguir las solicitudes con contenido privado, conserva un resumen criptográfico de la parte protegida y un resumen breve y redactado conforme a reglas documentadas.

El registro de ejecución comienza cuando la pasarela intenta realizar la acción. Debe indicar si la acción llegó a un límite de protocolo y qué respuesta recibió. En HTTP, captura el método, el destino, el estado de respuesta, el error de transporte, el tamaño de la respuesta y una clasificación limitada de esta. En SSH, captura la cuenta, la identidad del host, la representación del comando, el estado de salida, la señal, si la hubo, y el resultado de la conexión desde el cliente.

{
  "event_type": "execution.finished",
  "action_id": "act_01JX7K8N4Q",
  "time": "2025-03-08T14:21:20Z",
  "channel": "http",
  "attempt": 1,
  "delivery": "response_received",
  "result": {
    "http_status": 201,
    "response_bytes": 428,
    "response_digest": "sha256:..."
  }
}

No escribas success: true como único campo de resultado. El significado del éxito cambia según el protocolo y el producto. HTTP 201 significa que el servidor informa de que se creó un recurso. HTTP 202 significa que aceptó el trabajo para procesarlo más adelante. El estado de salida 0 de SSH significa que el comando remoto informó de éxito, aunque un script todavía podría haber ignorado un fallo interno. Un resultado tipado ofrece hechos a los revisores en lugar de una etiqueta verde y vaga.

El límite de confianza de las acciones debe crear la correlación

El componente que posee las credenciales y ejecuta la acción debe generar el ID de acción. El agente puede solicitar trabajo, pero no puede ser la fuente de registro de lo que tenía permitido hacer ni de lo que envió la pasarela.

Esto importa cuando un proceso de agente tiene errores, está comprometido o simplemente se confunde durante una conversación larga con herramientas. Si crea sus propios identificadores, puede asociar un resultado posterior con una solicitud anterior, omitir llamadas inconvenientes o informar de un estado inventado. Incluso un agente que se comporta correctamente puede perder el contexto después de reiniciarse. El límite de acción ve en un mismo lugar la solicitud, la selección de credenciales, el intento de salida y el resultado recibido.

Usa un identificador sin significado empresarial y no lo reutilices nunca. Funciona un ID único aleatorio o ordenable por tiempo. Adjuntarlo a cada registro local. Cuando el protocolo lo permita, transmítelo también como identificador de solicitud. Así, los operadores del servicio pueden vincular sus registros con el registro de la pasarela sin exponer una credencial.

Para una solicitud HTTP, usa un encabezado específico que el sistema de destino acepte registrar, como X-Action-ID. No confundas ese encabezado con una clave de idempotencia. Un ID de acción ayuda en la investigación. Una clave de idempotencia indica a un servidor compatible que reconozca una mutación duplicada. En ocasiones un mismo valor puede cumplir ambas funciones, pero solo después de que el propietario del servicio confirme su semántica y periodo de conservación.

Authorization: action_id=act_01JX7K8N4Q
Outbound request: POST /v1/refunds
Request header: X-Action-ID: act_01JX7K8N4Q
Response: 201 Created
Execution record: action_id=act_01JX7K8N4Q, delivery=response_received

No dependas solo de las marcas de tiempo para correlacionar registros. Los relojes se desajustan, las solicitudes se solapan y los agentes pueden hacer llamadas idénticas en el mismo segundo. Las marcas de tiempo ayudan a reconstruir el orden. No demuestran la relación entre eventos.

Un ID de sesión también importa, pero responde a una pregunta más amplia: ¿qué ejecución de proceso del agente hizo esta solicitud? Conserva ambos identificadores. La sesión indica qué proceso recibió un permiso permanente. El ID de acción indica qué operación concreta obtuvo qué resultado.

Los códigos de estado HTTP son evidencia con límites

Una respuesta HTTP ofrece una evidencia de ejecución más sólida que una aprobación local, pero aun así necesita interpretación. Registra el estado final y el contexto suficiente para explicarlo. No conviertas automáticamente en fallos todos los estados que no estén dentro del rango 200.

Un 200 OK o 201 Created es un informe explícito del servidor. Un 204 No Content suele indicar una operación correcta sin cuerpo de respuesta. Un 202 Accepted es distinto: el destino recibió la solicitud para procesarla de forma asíncrona, pero el trabajo final podría fallar más adelante. Tu registro de ejecución debe indicar accepted_for_async_processing y vincular después una comprobación de estado o una devolución de llamada con la misma acción cuando el servicio admita ese patrón.

Los redireccionamientos requieren cuidado. Si una pasarela sigue redireccionamientos, registra el destino original y el final, incluido si la regla de inyección de credenciales se aplicó en cada salto. Reenviar un encabezado de autorización a un host inesperado es una filtración de credenciales, no un redireccionamiento normal. En la práctica, rechaza los redireccionamientos entre hosts, salvo que un operador haya configurado explícitamente la relación entre los destinos.

Los errores del cliente y del servidor también contienen datos útiles. Un 403 demuestra que el servicio rechazó la solicitud. Un 409 puede indicar que ya existe un estado duplicado o en conflicto. Un 429 dice que el destino rechazó el trabajo por el momento. Un 500 indica que el servidor informó de un fallo, no que no se haya producido ningún cambio. El cuerpo de la respuesta puede aclarar el resultado, pero guárdalo solo después de aplicar redacción y límites de tamaño. Las respuestas de error suelen contener más detalles operativos que las respuestas correctas.

Los fallos de transporte necesitan sus propios valores de resultado. Registra distinciones como dns_failure, tls_validation_failure, connect_timeout, write_interrupted, response_timeout y connection_reset. Estos resultados indican al revisor dónde termina la certeza.

La categoría peligrosa es una solicitud interrumpida después de que la pasarela empieza a escribirla. El servicio podría haber actuado. Marca el estado como unknown_remote_outcome; no lo etiquetes como fallido porque el cliente no tiene una respuesta. Si la llamada modifica el estado, el agente debe detenerse y usar un método seguro de conciliación. Ese método podría consultar el servicio mediante una clave de idempotencia, leer un recurso usando un identificador de solicitud o pedir a una persona que inspeccione el destino.

SSH necesita evidencia del proceso remoto

Los registros de auditoría SSH suelen detenerse en «conectado al host». Eso solo demuestra que un cliente estableció una sesión SSH. No dice nada sobre el resultado del comando y quizá ni siquiera identifique el host exacto que respondió, a menos que registres la verificación de la clave del host.

Para cada acción SSH, registra el nombre del host de destino, la dirección resuelta si está disponible, la huella de la clave de host verificada, la cuenta solicitada, la referencia del método de autenticación, el comando normalizado y el resultado final del cliente. Si el comando remoto comienza, captura su estado de salida y la señal de terminación. Trata la salida estándar y la salida de error estándar como datos operativos sensibles, no como material que deba registrarse automáticamente.

Un comando normalizado conserva el valor para la revisión y reduce la exposición. Por ejemplo, en lugar de conservar un comando que contiene un argumento secreto, guarda el ejecutable, las opciones fijas, las posiciones de los argumentos sensibles y un resumen criptográfico de los valores protegidos.

requested_command: /usr/local/bin/rotate-service-token --project payments --token [redacted]
command_digest: sha256:...
remote_exit_status: 0
remote_signal: null
connection_result: clean_close

El estado de salida 0 es evidencia del comando remoto, no una prueba de que se hayan producido todos los efectos empresariales. Un script de shell mal escrito puede ejecutar curl, ignorar su error y aun así terminar con el estado 0. Si controlas el script, haz que falle de forma explícita y devuelva un valor distinto de cero cuando falle una operación necesaria. Si no lo controlas, registra el resultado del comando con precisión y no afirmes más de lo que sabes.

Las sesiones SSH interactivas merecen cautela. Crean una brecha enorme entre «permiso concedido» y «comandos ejecutados». Un comando remoto limitado produce mejor evidencia que conceder a un agente un shell interactivo general. Si una tarea necesita varios comandos, usa un script revisado con salidas explícitas o crea registros de acción separados para cada comando. Es menos espectacular que dejar que un agente escriba libremente en una terminal, pero resulta mucho más fácil de investigar.

La verificación del host debe mantenerse activa. Un registro que dice que un agente ejecutó un comando en build-01 significa poco si el cliente aceptó un host no verificado durante un ataque de red o después de sustituir un host por error. Conserva la huella de la clave de host verificada en el evento de ejecución. Así, los revisores podrán distinguir la etiqueta del nombre del host de su identidad criptográfica.

Un tiempo de espera debe terminar en incertidumbre, no en una avalancha de reintentos

El fallo que más suele sorprender a los equipos comienza con una llamada de API que modifica datos y termina con un tiempo de espera agotado. El agente recibió permiso. La pasarela abrió una conexión y envió la solicitud. El destino completó el cambio, pero la respuesta desapareció, o el destino nunca recibió los bytes finales. Para el cliente, ambos caminos parecen iguales.

Imagina que un agente crea un ticket de incidente de producción mediante una API. Envía:

POST /v1/incidents
Idempotency-Key: inc_72f9c
X-Action-ID: act_01JX7K8N4Q

El cliente espera y después registra response_timeout. Un registro de auditoría basado solo en aprobaciones dice que la persona aprobó un ticket. Un registro de acciones simplista dice que la creación del ticket falló. Ninguna de las dos afirmaciones es segura.

El registro de ejecución correcto indica que la pasarela intentó realizar la solicitud y no recibió respuesta. Debe conservar el ID de acción y la referencia de la clave de idempotencia. Después, el agente consulta al servicio por el estado asociado con inc_72f9c, si el servicio ofrece esa consulta. Si el servicio informa de que existe un ticket, registra un evento de conciliación que apunte a la acción original. Si no encuentra ningún registro y su contrato de idempotencia permite reintentar, vuelve a intentarlo una sola vez con la misma clave de idempotencia, no con una nueva.

La secuencia contiene tres hechos distintos:

1. Una persona aprobó la solicitud original.
2. La pasarela no pudo confirmar el resultado inicial.
3. Una lectura posterior o una repetición idempotente estableció el estado final.

No borres el tiempo de espera después de la conciliación. Explica por qué se produjo la acción posterior. También muestra si el equipo sufre un problema de transporte recurrente que un recuento de éxitos impecable ocultaría.

SSH tiene un fallo equivalente. Un comando remoto puede continuar después de que el cliente local pierda la sesión. Evita los reintentos automáticos, salvo que el comando sea demostrablemente idempotente. Prefiere un ID de operación remoto, un archivo de estado con permisos controlados o una API de destino que informe del estado. Si no existe ninguna de estas opciones, registra el resultado desconocido y exige una revisión humana. Ya se han producido suficientes daños por comandos de despliegue duplicados sin que un agente los repita a velocidad de máquina.

La aprobación por sesión y la aprobación por llamada responden a riesgos distintos

La autorización por sesión establece que un proceso de agente concreto puede usar canales de acción aprobados durante su ejecución. Reduce la fatiga de aprobaciones cuando una persona espera una secuencia breve y limitada de tareas de bajo impacto. No convierte las llamadas posteriores en decisiones revisadas de forma individual.

La aprobación por llamada registra una decisión humana para cada uso de una credencial seleccionada. Úsala en operaciones en las que cada destino, mutación o comando remoto merezca una atención renovada. El registro de ejecución sigue siendo necesario. Una persona puede aprobar una llamada destructiva a una API y el servicio puede rechazarla, procesarla parcialmente o agotar el tiempo de espera.

La diferencia se vuelve clara cuando los revisores preguntan: «¿Quién aprobó este cambio?». Un registro de sesión puede responder: «Este proceso de agente firmado tenía permiso para llamar a este canal». Un registro por llamada puede responder: «Una persona aprobó exactamente esta solicitud en este momento». Ninguno responde: «¿Ocurrió?». Solo la evidencia de ejecución resultante puede responder a esa pregunta.

Las solicitudes de aprobación deben mostrar suficiente información para que una persona tome una decisión significativa: identidad del proceso que hace la llamada, referencia de la credencial, destino, método o comando y si la solicitud cambia el estado. Una solicitud que solo dice «¿Permitir acceso al agente?» registra un clic, pero captura muy poca intención útil.

No intentes resolver esto con un lenguaje de políticas enorme antes de poder producir evidencia coherente. Los equipos suelen recurrir a las reglas porque quieren menos solicitudes de aprobación. Las reglas pueden limitar las acciones, pero no sustituyen un modelo de auditoría que distinga entre aprobación, intento, respuesta y resultado desconocido. Primero haz que los hechos sean legibles. Después decide dónde es segura la automatización.

Las cadenas de hashes protegen el historial, no la verdad de una afirmación

Un registro inmutable y encadenado mediante hashes permite detectar manipulaciones posteriores. Cada evento incluye o contribuye a un resumen que depende de los registros anteriores. Si alguien modifica una autorización antigua, elimina una solicitud fallida o reordena una secuencia, la verificación falla, salvo que pueda reescribir la cadena desde el punto modificado y sustituir la cabecera de cadena de confianza.

Esta propiedad importa en la actividad de los agentes porque los registros más incómodos suelen ser los que alguien quiere eliminar: una acción denegada, un despliegue fallido, una solicitud enviada al servicio equivocado o una sesión que continuó más de lo previsto. Un registro que los administradores pueden editar discretamente no resistirá una revisión seria.

Pero una cadena de hashes no convierte una entrada falsa en verdadera. Si un agente no confiable proporciona «HTTP 201» y el registro encadena fielmente esa mentira, la cadena solo demuestra que la mentira persistió. El recopilador debe observar el evento en el límite de acción. La pasarela debe crear el resultado de ejecución después de recibir la respuesta o detectar el fallo de transporte.

NIST SP 800-92, Guide to Computer Security Log Management, advierte que los registros necesitan protección durante su generación, transmisión, almacenamiento, análisis y eliminación. La lección práctica va más allá de centralizar archivos de texto. Conserva la fuente del evento original, protege la secuencia, controla quién puede modificar los registros y permite la verificación sin conceder un acceso amplio a los secretos utilizados por las acciones.

Sallyport proyecta las ejecuciones de los agentes y las llamadas individuales desde un único registro de auditoría cifrado, encadenado mediante hashes y protegido contra escritura. Su comando sp audit verify verifica la cadena sin conexión sobre el texto cifrado, sin necesitar la clave de la bóveda. Este diseño separa al revisor que comprueba la integridad del historial del proceso que puede usar credenciales de producción.

Un comando de verificación debe producir un resultado inequívoco e identificar el intervalo comprobado. Por ejemplo:

$ sp audit verify
verified: 1847 records
chain: valid
first_record: 2025-03-01T08:15:02Z
last_record: 2025-03-08T14:21:20Z

Una cadena válida no resuelve si una API externa cumplió su promesa. Sí establece que el registro conservado por la pasarela sobre la aprobación y el resultado recibido no ha cambiado sin que se detecte.

Revisa las relaciones entre eventos, no los recuentos aislados

La revisión de auditoría falla cuando los equipos cuentan aprobaciones, llamadas correctas y llamadas denegadas en gráficos separados, pero nunca inspeccionan las relaciones entre ellas. La unidad de revisión útil es una línea temporal de acción: solicitud, decisión de autorización, intentos de ejecución, resultado y cualquier conciliación.

Empieza por los registros que no tienen una pareja correspondiente. Una autorización sin evento de ejecución puede reflejar una solicitud cancelada, un fallo de la pasarela o un error de registro. Un evento de ejecución sin una autorización previa puede revelar un bypass. Un resultado remoto desconocido sin conciliación es trabajo operativo pendiente, no un fallo cerrado.

Usa un conjunto pequeño de consultas o informes que obliguen a responder estas preguntas:

• ¿Qué acciones aprobadas que modificaban datos terminaron con un resultado remoto desconocido?
• ¿Qué llamadas recibieron una respuesta fuera del alcance de autorización?
• ¿Qué comandos SSH terminaron sin estado de salida?
• ¿Qué aprobaciones por sesión produjeron acciones después de que terminara la tarea prevista?
• ¿Qué IDs de acción aparecen en los registros locales, pero no en los registros del servicio de destino?

La última consulta exige prudencia. La ausencia en un registro de destino puede significar que el destino no conservó el ID de solicitud, que el intervalo temporal es incorrecto o que los registros pertenecen a otro equipo. Márcala como señal de investigación, no como prueba de una conducta indebida.

El registro de sesiones y el registro de actividad de Sallyport hacen práctica esta separación: una vista muestra la ejecución del agente y su estado de revocación, mientras que la otra muestra las llamadas individuales. Los revisores deben pasar de una vista a otra mediante los identificadores de sesión y de acción, en lugar de tratar cualquiera de los dos registros como la historia completa.

Mantén un vocabulario explícito para la certeza. authorized, attempted, response_received, remote_exit_received, denied, failed_before_send y unknown_remote_outcome son más fáciles de defender que un único indicador de éxito. Cuando un equipo usa estos términos de forma coherente, los casos difíciles dejan de desaparecer dentro de paneles verdes y amables.

Construye la evidencia antes de conceder un acceso más amplio a los agentes

No necesitas empezar con un plano de control complejo. Coloca el uso de credenciales detrás de un límite de acción de confianza, crea allí el ID de acción, registra la decisión humana por separado del resultado y conserva los resultados desconocidos sin reescribirlos como fallos. Así proporcionas a quienes responden a incidentes una secuencia que pueden contrastar con los registros de servicios y hosts.

Después, prueba el registro durante los fallos, no solo en un camino correcto. Aprueba una solicitud y corta la conexión después del envío. Ejecuta un comando SSH que devuelva un estado de salida distinto de cero. Provoca un fallo de DNS. Revoca una sesión de agente y comprueba que las llamadas posteriores reciban registros de denegación. Comprueba si un revisor puede explicar cada evento sin abrir un archivo fuente ni preguntar al agente qué quiso decir.

Se puede permitir que un agente actúe sin entregarle una credencial. No se le puede permitir redefinir lo que ocurrió. Conserva el registro de la decisión, conserva el resultado de ejecución y deja visible la incertidumbre cuando la red no coopere.