Registros de auditoría resistentes a manipulaciones para agentes de IA que demuestran sus acciones

Los agentes de IA no necesitan una transcripción de chat mejor. Necesitan pruebas producidas en el momento en que una acción sale de la máquina.

Esa diferencia determina si puedes responder a una pregunta de un incidente como «¿Este agente hizo un push a producción, con qué proceso, bajo qué aprobación y qué devolvió el sistema remoto?». Un resumen conversacional no puede soportar ese peso. Un diario resistente a manipulaciones sí puede, siempre que seas preciso sobre lo que demuestra y lo que no.

He visto equipos tratar la salida de la terminal de un agente como un registro de auditoría porque era fácil de guardar. Es al revés. La salida de la terminal resulta útil durante la depuración, pero es una prueba deficiente: el proceso que la escribió pudo fallar antes de producir el efecto, pudo ocultar el argumento importante o pudo ser reemplazado por completo.

Aquí gana la respuesta menos llamativa.

Una puerta de enlace de acciones debería crear el registro mientras ejecuta una llamada HTTP o un comando SSH, sellarlo dentro de un diario ordenado y hacer visibles las modificaciones posteriores. Así, el investigador dispone de un artefacto que no depende de la memoria, del prompt ni de la voluntad de confesar del agente.

Una transcripción y un registro de auditoría responden preguntas distintas

Una transcripción dice qué afirma el agente que intentó hacer; un registro de auditoría dice qué aceptó y qué devolvió el límite de acción. Confundir ambos artefactos deja una brecha justo en el punto donde el trabajo autónomo se vuelve arriesgado.

Imagina que un agente dice que ejecutó terraform apply después de abrir una sesión SSH. Ese texto no demuestra que la conexión SSH tuviera éxito, que el comando llegara al host previsto ni que el host lo aceptara. Podría ser un comando planificado que se imprimió antes de la ejecución. Podría ser un comando que falló en la primera línea. También podría haberlo modificado un envoltorio después de los hechos.

Un registro de acción útil reúne hechos procedentes de distintas capas:

• la ejecución del agente que solicitó la acción
• la identidad del proceso local que recibió la autorización
• el canal y el destino, como el host SSH o el origen HTTP
• un resumen normalizado de la acción y el estado del resultado
• la posición en el diario y el hash predecesor

El registro no tiene que convertirse en una captura de vigilancia. De hecho, escribir cada cuerpo de solicitud y cada cuerpo de respuesta completo en un diario permanente suele ser imprudente. Una API de despliegue puede devolver un token de acceso. Un comando SSH puede incluir un secreto temporal en una asignación de entorno. Captura los hechos necesarios para reconstruir la decisión de seguridad y establece límites estrictos para conservar las cargas sensibles.

NIST SP 800-92 trata la gestión de registros como un proceso que abarca su generación, almacenamiento, análisis y eliminación, no como una carpeta donde las aplicaciones vierten texto. Esa orientación antigua encaja sorprendentemente bien con los agentes: la generación debe ocurrir en el ejecutor, el almacenamiento debe sobrevivir al incidente y el análisis no debe exigir confiar en el actor investigado.

El límite de acción es donde la verdad se vuelve más concreta. Eso es positivo.

Si un agente nunca recibe la credencial y, en su lugar, pide a una puerta de enlace local que haga la llamada, la puerta de enlace puede registrar la solicitud que realmente envió. El agente aún puede verse comprometido. No puede reescribir en silencio el historial de acciones completadas de la puerta de enlace desde su propio contexto.

Resistente a manipulaciones no significa inmutable

Resistente a manipulaciones significa que un verificador puede detectar ciertos cambios; inmutable significa que nadie puede modificar ni eliminar los datos. Son promesas distintas, pero los proveedores suelen mezclarlas porque «inmutable» parece más fácil de comprar.

Una cadena de hashes hace que cada registro dependa del registro anterior. Un registro simplificado podría verse así:

record_1042 = {
  sequence: 1042,
  run_id: "run_7f3c",
  time: "2026-03-18T14:22:09Z",
  action: "ssh.exec",
  destination: "deploy@release-host",
  result: "exit 0",
  previous_hash: "a4c1...",
  hash: "8d72..."
}

La implementación serializa los campos de forma determinista, calcula un hash sobre esa serialización e incluye el hash del registro anterior dentro del siguiente. Cambia exit 0 por exit 1, modifica el host o reordena dos entradas, y la verificación falla a partir de ese punto.

El estándar Secure Hash Standard de NIST define algoritmos de hash aprobados que generan resúmenes de mensaje de longitud fija. Un resumen no es cifrado ni una firma. Es el material compacto de vinculación que permite que un registro posterior dependa de los bytes exactos de los registros anteriores.

Eso detecta modificaciones. No detecta todas las formas de deshonestidad.

Un atacante que pueda reescribir el diario y recalcular todos los hashes posteriores puede producir una cadena que se verifique correctamente. Un atacante que elimine los 40 registros finales puede dejar un prefijo anterior válido. Un atacante que mantenga dos cadenas separadas puede mostrar historiales distintos a revisores distintos. La cadena te dice que una secuencia presentada es internamente coherente. Por sí sola no puede demostrar que la secuencia esté completa o sea única a escala global.

Por eso rechazo que alguien llame «no repudio» a una cadena de hashes local. No lo es. El no repudio necesita vincular la identidad y contar con un proceso de verificación que siga siendo válido frente a la parte acusada de actuar. Una cadena local sigue siendo valiosa, pero llámala por lo que es: una prueba sólida contra las modificaciones casuales y la corrupción del almacenamiento.

Una cadena necesita un anclaje fuera del alcance de quien escribe

Una cadena de hashes resulta mucho más difícil de reescribir cuando alguien conserva puntos de control que el escritor del diario no puede reemplazar en silencio. Sin una referencia externa, el atacante que controla al escritor también controla el comienzo de tu historia.

Hay varias formas de anclar un diario. Difieren en coste y en adecuación operativa.

• Exporta puntos de control firmados a una cuenta separada con permisos de escritura estrictamente limitados.
• Envía periódicamente las raíces del diario a un almacén de eventos de seguridad que el host del agente no pueda administrar.
• Replica segmentos cifrados del diario en un almacenamiento sin conexión o de solo anexado.
• Haz que un monitor independiente conserve las raíces observadas e informe de las inconsistencias.

No confundas más destinos con mejores pruebas. Cinco copias en depósitos cloud controlados por el mismo administrador pueden fallar juntas. La separación de autoridades importa más que el número de réplicas.

Certificate Transparency ofrece un modelo mental útil. RFC 9162 usa árboles de Merkle para admitir registros de solo anexado, pruebas de inclusión y pruebas de coherencia entre las cabeceras de árbol publicadas. El RFC también expone claramente la parte difícil: un registro deshonesto puede intentar mostrar vistas incoherentes a clientes distintos.

Una cadena de hashes sencilla no es un árbol de Merkle. Ofrece una verificación secuencial eficiente, no pruebas compactas para entradas arbitrarias ni un protocolo público de coherencia. Para un único Mac que ejecuta un volumen moderado de acciones de agentes, ese suele ser el equilibrio correcto. Añadir un servicio de Merkle porque la palabra aparece en los documentos sobre transparencia es maquinaria innecesaria, a menos que tengas monitores independientes, muchos verificadores o la necesidad de demostrar la pertenencia a un diario compartido grande.

El coste del anclaje es real. Debes operar otro límite de almacenamiento, decidir la frecuencia de los puntos de control, gestionar las interrupciones y conservar suficientes metadatos para asociar un punto de control con un diario local. Crear un punto de control después de cada acción genera tráfico y más casos de fallo. Crear uno al día deja un intervalo largo en el que puede resultar difícil detectar un truncamiento. Elige un intervalo acorde con la velocidad a la que las malas acciones se vuelven costosas.

Para las credenciales de despliegue en producción, prefiero anclar cada acción privilegiada completada antes que discutir si una exportación diaria es técnicamente suficiente. Para llamadas de API de solo lectura y bajo riesgo, una raíz periódica puede bastar.

El cifrado oculta el registro, no el historial

Los diarios cifrados protegen los detalles sensibles de las acciones frente a lectores ocasionales, pero el cifrado por sí solo no dice nada sobre si los registros han cambiado. Los equipos suelen construir una propiedad, describir las dos y descubrir la diferencia durante una investigación.

Supón que una entrada del diario contiene una ruta HTTP, la etiqueta de una credencial de autorización, metadatos de la solicitud y un error devuelto. Cifrar esa entrada impide que un ladrón del disco sepa qué endpoint de cliente tocó el agente. No impide que un proceso local privilegiado sustituya el bloque de texto cifrado por otro bloque. Necesitas cifrado autenticado para cada registro y una cadena entre los registros cifrados o sus representaciones autenticadas.

El diseño limpio permite verificar la integridad sin exponer el contenido. El verificador lee la secuencia de registros cifrados, comprueba el encuadre y las relaciones con los predecesores, recalcula la cadena e informa de si los bytes presentados siguen formando el historial esperado. No necesita que la bóveda de credenciales esté desbloqueada para decidir que el registro 1042 ya no sigue al registro 1041.

Esa separación resulta útil durante la contención. Un investigador puede copiar el diario, ejecutar la verificación y conservar el resultado antes de pedir a alguien que desbloquee material sensible. La persona que realiza la primera revisión del incidente no debería necesitar acceso amplio a las credenciales de despliegue solo para determinar si las pruebas fueron alteradas.

El cifrado también obliga a decidir cuánto tiempo conservar los datos. Si nadie puede descifrar las entradas antiguas después de migrar el dispositivo, la prueba de integridad puede seguir intacta mientras el diario pierde su significado operativo. Mantén los procedimientos de recuperación y conservación separados del formato de auditoría. No guardes el secreto de descifrado junto al archivo cifrado y des por resuelto el problema.

En macOS, la protección respaldada por hardware puede reducir la exposición de los secretos locales. La documentación de seguridad de Apple describe Secure Enclave como un procesador de seguridad de hardware aislado, y la documentación para desarrolladores de Apple señala que el material secreto en texto plano no puede transferirse al mecanismo de Secure Enclave que describe ni extraerse de él. Eso permite diseñar una bóveda local, pero no autentica mágicamente todos los procesos del Mac.

El diario aún debe identificar qué proceso recibió la aprobación y qué acción cruzó la puerta de enlace. La protección de hardware protege un límite. Las pruebas de auditoría necesitan varios.

El fallo suele empezar antes del comando peligroso

Un incidente plausible con un agente rara vez empieza con un comando que parece malicioso. Empieza con una solicitud cotidiana que hereda demasiada autoridad.

Imagina que un agente de programación recibe una incidencia para diagnosticar un lanzamiento fallido. Lee el repositorio, encuentra un script de despliegue y abre un canal SSH hacia un host de lanzamiento. El primer comando es inofensivo:

systemctl status web.service

La salida incluye una ruta a un archivo de configuración temporal. El agente lee entonces ese archivo, encuentra una referencia a una credencial de despliegue y ejecuta un segundo comando que cambia un valor de entorno. El comando remoto devuelve el código de salida 0. Veinte minutos después, un cliente informa de que las solicitudes han fallado.

¿Dónde podrían los controles haber detenido o dejado al descubierto el problema?

Primero, la puerta de la bóveda podría haber impedido todas las acciones externas mientras estuviera bloqueada. Eso no decide si el comando era prudente, pero evita que un agente en segundo plano use credenciales después de que el usuario haya cerrado el límite de seguridad.

Segundo, la autorización de la sesión podría haber mostrado la identidad del proceso del agente antes de su primera acción. Aquí importa la autoridad de firma de código. Un proceso conocido del editor y un ayudante sin firmar lanzado desde /tmp no deberían recibir el mismo trato solo porque ambos hablan MCP.

Tercero, exigir aprobación para la credencial del host de lanzamiento podría haber interrumpido la segunda acción. El aviso debería mostrar suficiente contexto del destino y de la operación para que una persona reconociera que aquello ya no era diagnóstico. Un botón genérico de «permitir SSH» no cumple ese estándar.

Por último, el diario debe mostrar los dos comandos como acciones completadas distintas dentro de la misma ejecución. Si el registro del incidente solo dice «el agente investigó el fallo de despliegue», oculta el momento en que la ejecución pasó de observar a modificar.

Prefiero la aprobación por uso para las credenciales que pueden cambiar el estado de producción. Es más lento. También obliga a una persona a enfrentarse al momento concreto en que una tarea de diagnóstico se convierte en un cambio operativo.

No exijas un clic para cada solicitud inofensiva. Las personas aprobarán una pared de avisos idénticos sin leerlos, porque la interfaz les enseñará exactamente a hacer eso. Coloca la fricción en los usos de credenciales cuyo radio de impacto cambie con cada llamada.

La identidad del proceso pertenece al registro

Un registro de auditoría que diga «Claude Code usó SSH» es demasiado impreciso para resolver una disputa. Necesitas saber qué proceso local inició la ejecución, qué autoridad de firma comunicó el sistema operativo y si la aprobación cubría esa instancia del proceso.

Esta es otra definición que los equipos suelen simplificar: la identidad de la aplicación no es la identidad del proceso. Un nombre de marca puede describir un producto legítimo, mientras que una extensión comprometida, un binario copiado o un envoltorio de shell invoca el mismo protocolo desde un contexto ejecutable distinto. La decisión de aprobación debe vincularse al proceso real que solicitó actuar y caducar cuando termine esa ejecución.

El registro debe capturar un identificador estable de ejecución y suficiente procedencia del proceso para responder después a estas preguntas:

• ¿El mismo proceso hizo la primera y la última solicitud?
• ¿El usuario aprobó esta ejecución antes de que realizara la llamada?
• ¿La ejecución fue revocada antes de que llegara una solicitud posterior?
• ¿Un proceso local no relacionado intentó reutilizar el canal?

Evita registrar un nombre visible mutable como tu campo de identidad principal. Los nombres cambian. Las rutas pueden sustituirse. Una autoridad de firma o una identidad de plataforma equivalente resulta más útil porque conecta la pantalla de aprobación, el diario de la sesión y la investigación posterior.

Tiene un coste. Las compilaciones legítimas de desarrollo, los forks locales y las herramientas sin firmar generarán más trabajo de revisión. Eso no es un defecto del modelo de auditoría. Es el precio visible de permitir que software experimental acceda a credenciales reales. Decide si esas herramientas deberían usar una credencial independiente con pocos privilegios, en lugar de enseñar a los revisores a ignorar los detalles de identidad desconocidos.

El registro también debe distinguir los intentos denegados de las acciones completadas. Una solicitud SSH denegada demuestra que un control funcionó. Una conexión fallida demuestra que se intentó una ruta, no que hubiera ejecución remota. Una solicitud completada con un resultado devuelto es una prueba aún más sólida. No reduzcas esos resultados a un único booleano llamado success.

Un único diario para ejecuciones y llamadas crea una mejor línea temporal

Los eventos de sesión y los eventos de acción deberían proyectarse desde la misma fuente de verdad ordenada, aunque los operadores los lean por motivos distintos. Los archivos de registro separados, escritos por componentes separados, se desincronizan bajo presión.

La vista de sesión responde preguntas sobre el ciclo de vida del agente: cuándo apareció una ejecución, a qué proceso pertenecía, si un usuario la autorizó y si alguien la revocó. La vista de actividad responde preguntas sobre acciones concretas: qué etiqueta de credencial se seleccionó, qué destino se usó, si se permitió la llamada y qué resultado devolvió.

Esas vistas no deberían ser fuentes independientes. Si aparece una acción sin su sesión, o una ejecución revocada parece seguir emitiendo llamadas, el investigador necesita una única secuencia para determinar si los datos son incoherentes o si el comportamiento del sistema es incorrecto.

Aquí un diario cifrado de solo escritura ofrece una ventaja práctica. Los componentes pueden añadir la información que tienen derecho a comunicar, mientras que el formato del diario les impide consultar fácilmente entradas no relacionadas. La mejora de seguridad no procede de hacer que los registros sean misteriosos. Procede de reducir el número de rutas de código que pueden leer, editar y reinterpretar los registros históricos.

Sallyport proyecta los diarios Sessions y Activity desde un único registro de auditoría cifrado y encadenado mediante hashes, y sp audit verify comprueba esa cadena sin conexión sobre el texto cifrado y sin necesidad de desbloquear la bóveda. Esa es la forma adecuada para las pruebas locales de los agentes, porque la ruta de verificación sigue disponible durante la contención.

Aun así, exportaría puntos de control en entornos de alto impacto. La verificación local te dice si la copia que tienes conserva su integridad interna. Un punto de control externo ayuda a detectar que alguien te entregó un historial más antiguo y corto.

Mantén separadas la presentación del diario y la verdad del diario. Una interfaz cómoda puede filtrar, agrupar y ocultar entradas para el uso diario. El verificador subyacente debe operar sobre bytes estables y un orden determinista, no sobre lo que la interfaz actual decida mostrar.

La verificación debe ser rutinaria, no ceremonial

Un comando de verificación que solo se ejecuta después de un incidente es una función que nadie ha probado. Inclúyelo en el mantenimiento habitual y haz que la gestión de fallos sea predecible.

En una instalación de Sallyport, la primera comprobación concreta es:

sp audit verify

Ejecútalo contra una copia del diario antes de una actualización importante, antes de borrar un Mac de desarrollo y cuando sospeches que el estado local ha cambiado inesperadamente. Conserva la copia exacta del diario que verificaste. Ejecutar de nuevo el comando más tarde sobre una copia diferente no demuestra qué existía durante el incidente.

El comando por sí solo no basta. Combínalo con una pequeña rutina operativa:

1. Conserva la copia del diario y la referencia a su punto de control antes de corregir el problema.
2. Registra el identificador de la ejecución afectada y el intervalo temporal que investigas.
3. Compara las acciones HTTP y SSH completadas con los registros del propio proveedor remoto.
4. Revoca la ejecución activa antes de pedir al agente que haga tareas de limpieza.
5. Verifica de nuevo después de exportar o transferir las pruebas para confirmar que la copia se conserva intacta.

El tercer punto importa porque la integridad local y la verdad externa se complementan. Un diario válido puede mostrar que la puerta de enlace emitió POST /deployments; el proveedor del despliegue puede mostrar si aceptó, puso en cola o rechazó la operación. El estado de salida de SSH puede indicar que un comando de shell terminó; los registros de servicios del host pueden mostrar qué proceso actuó después.

Tengo poca paciencia con los sistemas de auditoría que solo muestran eventos en un panel. Si no puedes validar el diario almacenado sin el panel, has hecho que la respuesta al incidente dependa de la misma pila de aplicaciones que podría estar siendo cuestionada.

La verificación también debe fallar claramente ante segmentos ausentes, números de secuencia inválidos, un encuadre incorrecto del texto cifrado o una discrepancia con el predecesor. Una herramienta que omite los registros dañados para producir una línea temporal más bonita es una trituradora de pruebas con buenos modales.

Los registros de aprobación necesitan la misma precisión que los registros de acciones

Un clic de aprobación forma parte del evento de seguridad, no es un detalle decorativo de la interfaz. Si el sistema solo registra que se permitió una acción, después no podrás demostrar si el usuario aprobó una ejecución concreta, una categoría de credencial o un aviso completamente distinto.

Guarda el contexto de decisión que la persona realmente vio: la identidad del proceso solicitante, el alcance de la aprobación, la etiqueta de la credencial correspondiente y la hora. Para una decisión a nivel de sesión, registra cuándo comenzó la sesión y cuándo terminó o fue revocada. Para una decisión por uso, vincula la aprobación a una única acción intentada para que no pueda autorizar en silencio un destino posterior.

Un buen límite de aprobación implica un intercambio claro. Una autorización de sesión más amplia reduce las interrupciones y hace utilizables los bucles autónomos. Una autorización estrecha por llamada ofrece a una persona más oportunidades de detener un giro peligroso, pero se vuelve agotadora si la aplicas a lecturas rutinarias. Ninguna configuración es universalmente más segura; el efecto de la credencial determina el alcance razonable.

El modelo de tres controles suele ser suficiente: mantén la bóveda bloqueada hasta que el usuario la abra, autoriza un proceso identificado para una sesión y exige confirmación explícita para determinadas credenciales en cada uso. Un lenguaje de reglas puede parecer más sofisticado, pero cada condición se convierte en otra afirmación que las personas deben probar durante un lanzamiento. Para una puerta de enlace de acciones de escritorio, elegiría un conjunto pequeño y fijo de controles antes que un motor de políticas que nadie pueda explicar a las dos de la madrugada.

Esa elección excluye algunos flujos de trabajo. No puedes expresar todas las excepciones de entorno ni todas las políticas basadas en el tiempo con una escalera fija de decisiones. Los equipos con una flota de servidores y delegaciones complejas quizá necesiten otro sistema. Pretender que una aplicación de barra de menús local debe convertirse en un servidor de autorización general es la forma de transformar un límite de seguridad enfocado en uno frágil.

Decide qué necesitas demostrar antes de conceder acceso

La pregunta útil no es «¿Tenemos registros?». Es «¿Qué afirmación necesitaremos demostrar cuando esta ejecución salga mal?».

Para cada credencial que pueda usar un agente, escribe la afirmación en lenguaje sencillo. Algunos ejemplos son: este proceso firmado recibió autorización para esta ejecución; esta ejecución llamó a este endpoint de API; este comando SSH cruzó la puerta de enlace local; esta credencial estaba bloqueada cuando se denegó la solicitud; estos registros no se han modificado desde el punto de control conservado.

Después, prueba el diario con un escenario incómodo. Elimina sus últimas 50 líneas. Cambia un campo de destino. Cópialo a otro Mac. Bloquea la bóveda e intenta verificarlo. Revoca una ejecución entre dos llamadas. Si no puedes decir qué control debería detener el evento y qué registro debería mostrarlo, tienes observabilidad, no pruebas.

Una cadena de hashes no vuelve segura una credencial peligrosa. El cifrado no demuestra que el historial esté completo. Un aviso de aprobación no rescata a un revisor distraído. Cada control tiene una función más limitada.

Construye el registro donde ocurre la acción, protege su contenido, encadena su orden, conserva un anclaje fuera del alcance del escritor y practica la verificación antes de que un agente tenga acceso a algo que pueda perjudicarte. Esa secuencia resulta menos llamativa que un enorme motor de políticas. También es mucho más fácil de defender cuando alguien pregunta qué se ejecutó realmente.