Retención de la actividad de los agentes de IA: registros en los que confían los investigadores

Los agentes de IA convierten un problema conocido de registro en un problema de evidencia. Una persona puede pasar una tarde haciendo clic en una aplicación; un agente puede realizar muchas llamadas externas mientras un desarrollador lee su resumen. Si el registro solo dice «el agente completó la tarea», no puede responder a las preguntas que aparecen después de una eliminación equivocada, un cambio inesperado en producción o una transferencia discutida.

Unas buenas reglas de retención conservan los hechos necesarios para reconstruir una acción sin crear una segunda copia, mal protegida, de cada secreto y registro de cliente que el agente haya encontrado. Esta diferencia determina qué recopilas, cuánto tiempo lo conservas, quién puede modificarlo y cuándo debe detenerse la eliminación.

La retención comienza con la pregunta que debe responder un investigador

Un registro de actividad solo merece espacio de almacenamiento cuando responde a una pregunta de investigación previsible. Empieza por las preguntas, no por un número predeterminado de días copiado de otro producto.

Para un agente que puede llamar a una API HTTP o abrir una sesión SSH, los investigadores suelen necesitar establecer cinco cosas:

• Qué identidad de ejecución hizo la solicitud y qué persona o servicio autorizó esa ejecución.
• Qué capacidad intentó usar y contra qué destino.
• Qué operación pidió al destino que realizara.
• Cuál fue el resultado, incluidos el rechazo, el tiempo de espera agotado, el éxito parcial o el error remoto.
• Si el equipo puede demostrar que el registro no fue editado discretamente después del evento.

Estas preguntas separan la evidencia de la acción del ruido operativo. Un gráfico de CPU puede ayudar a explicar un tiempo de espera agotado, pero no demuestra que un agente haya emitido DELETE /customers/42. Una transcripción del prompt puede explicar por qué el agente creyó que la eliminación era adecuada, pero no demuestra que la solicitud llegara al servicio remoto.

La publicación especial 800-92 del NIST, Guide to Computer Security Log Management, presenta la gestión de registros como un ciclo de vida: generarlos, transmitirlos, almacenarlos, analizarlos y eliminarlos. Lo útil de esta guía no es una duración mágica de retención. Es la exigencia de que una organización defina el propósito de sus registros y tenga en cuenta el almacenamiento, el acceso y la eliminación. Los equipos de agentes suelen saltar directamente a la recopilación porque es fácil. La disciplina de acceso y eliminación determina si esos registros ayudarán o perjudicarán más adelante.

Escribe una declaración de investigación para cada clase de registro. Por ejemplo: «Conservamos los resultados de las acciones el tiempo suficiente para identificar y reconstruir un cambio externo no autorizado después de la detección y el triaje normales». Esta declaración obliga a argumentar de forma útil sobre el periodo y los campos. «Conservar todos los registros de los agentes para siempre» evita el debate y crea una acumulación permanente de material sensible.

Un registro puede servir para más de un propósito, pero nómbralos por separado. La investigación de seguridad, la respuesta a incidentes, el soporte al cliente, la depuración de versiones, la conciliación de facturación y el cumplimiento pueden necesitar datos y periodos distintos. Si un uso de depuración de poco valor mantiene una carga útil completa durante años, la política de retención ha fallado.

Un registro de acción necesita contexto, no una transcripción

La retención de actividad de los agentes de IA depende primero del esquema de eventos. Captura el conjunto mínimo de hechos que permita a un investigador competente reconstruir la acción y vincularla con una sesión, sin conservar credenciales ni contenido irrelevante.

Yo uso cuatro capas de información.

1. Contexto de identidad y autorización. Registra un identificador de evento inmutable, la marca de tiempo con zona horaria, el identificador del proceso del agente, la ruta del ejecutable o la identidad del paquete, la autoridad de firma de código cuando el sistema operativo la exponga, el identificador de sesión y la identidad del aprobador o del servicio asociado con la sesión. Registra la decisión de autorización y el modo de aprobación utilizado.
2. Acción solicitada. Registra el canal, el host de destino, el puerto cuando sea relevante, el método HTTP y la ruta normalizada, o la clase de comando SSH, el alias de la credencial o la referencia interna, y una descripción segura de la operación solicitada.
3. Resultado observado. Registra el éxito, la denegación, la cancelación, el tiempo de espera agotado, el fallo de transporte, el código de estado remoto cuando corresponda, la clasificación de la respuesta, los bytes enviados y recibidos si son relevantes, y un resumen redactado del error.
4. Vínculos de evidencia. Registra el hash del evento anterior, el hash del registro actual, la versión del esquema y los identificadores que relacionen los intentos, reintentos y acciones posteriores.

La diferencia entre un destino y una solicitud importa. api.example.internal es un destino. PATCH /v1/users/42 es una acción. Un registro que solo conserva el host no puede distinguir una consulta de inventario de credenciales de la desactivación de una cuenta. Un registro que solo conserva una ruta puede omitir el entorno de destino, que a menudo marca la diferencia entre una prueba inofensiva y un incidente.

Normaliza antes de almacenar. Coloca los identificadores variables en un campo estructurado en lugar de obligar a los investigadores a analizar texto libre. Registra route_template: "/v1/users/{user_id}" junto a un campo protegido target_identifier si el identificador importa. En SSH, distingue entre el comando enviado por el agente y el comando remoto después de la expansión del shell si tu ruta de ejecución puede observar ambos. No afirmes tener una certeza que no tienes.

Un registro JSON práctico podría verse así:

{
  "event_id": "01J8...",
  "occurred_at": "2025-03-08T14:22:31.482Z",
  "session_id": "ses_7f...",
  "actor": {
    "process_id": 18422,
    "signing_authority": "Developer ID Application: Example Developer"
  },
  "authorization": {
    "decision": "approved",
    "mode": "session"
  },
  "action": {
    "channel": "http",
    "destination": "billing.internal:443",
    "operation": "POST /v2/invoices/{invoice_id}/void",
    "credential_ref": "billing-production"
  },
  "outcome": {
    "status": "remote_rejected",
    "http_status": 403,
    "error_class": "authorization"
  },
  "previous_hash": "...",
  "record_hash": "..."
}

Este registro no contiene el bearer token, un encabezado de autorización ni el cuerpo de una factura. Aun así, informa al investigador de que un proceso firmado específico, durante una sesión aprobada concreta, intentó anular una factura en producción mediante una referencia de credencial identificada y recibió un 403.

No escondas campos de alto riesgo dentro de un bloque details. Los bloques de texto libre se convierten en un depósito de prompts, encabezados, datos personales y trazas de errores. También hacen imposible aplicar la retención por clase. Si un campo tiene una razón para existir, asígnale un nombre, una clasificación, un grupo de acceso y una regla de eliminación.

Conserva las clases de evidencia durante periodos distintos

Una única duración para todos los registros de agentes es fácil de explicar y normalmente resulta equivocada en la práctica. Conserva la evidencia compacta de las acciones durante más tiempo que el contenido de diagnóstico detallado, porque el registro compacto puede establecer lo ocurrido sin multiplicar la exposición.

Usa clases que correspondan al trabajo de investigación real. Un conjunto inicial viable es:

La tabla es un método, no una afirmación de que todos los equipos necesiten todas las clases. Si el agente solo lee el estado de una compilación, puede que no haya motivo para una clase de cargas útiles protegidas. Si modifica registros financieros, un libro mayor de acciones que omita el identificador exacto del objetivo puede ser demasiado limitado.

Evita la recomendación habitual de conservar las solicitudes y respuestas originales «por si acaso». Es popular porque facilita la depuración inicial y porque el almacenamiento parece barato. El almacenamiento no es la parte difícil. El acceso de búsqueda, el alcance de una filtración, las solicitudes de acceso de interesados, las garantías de eliminación y la captura accidental de secretos son los costes importantes.

Conserva un resumen criptográfico del cuerpo cuando necesites demostrar que se utilizó un cuerpo concreto sin conservar su contenido. Un resumen por sí solo no explica el significado y no sirve de ayuda si el cuerpo original ya no existe en otro lugar. Úsalo para correlacionar y comparar más adelante, no como sustituto de una descripción de la acción.

Conserva los intentos fallidos y denegados. Las denegaciones suelen revelar que un agente intentó utilizar una capacidad equivocada, que una ruta de aprobación está rota o que un proceso comprometido está probando los límites. Pueden merecer un periodo distinto del de las acciones exitosas si su volumen es mucho mayor, pero eliminarlos primero porque «no pasó nada» borra el contexto que los investigadores necesitan después de un intento exitoso.

Define el periodo a partir del descubrimiento y la respuesta, no del coste de almacenamiento

Elige el periodo de retención trabajando hacia atrás desde el último momento en que todavía esperas investigar un evento. El cálculo no es elegante, pero hace visibles las suposiciones.

Para una clase de registro, suma:

• el tiempo máximo creíble antes de la detección;
• el tiempo necesario para abrir, delimitar y asignar una investigación;
• el tiempo necesario para obtener registros relacionados de destinos o proveedores;
• cualquier obligación contractual, normativa o legal aplicable a esa clase;
• un margen moderado para informes retrasados y discrepancias entre relojes.

Supón que un equipo descubre una acción de producción sospechosa durante una revisión mensual, tarda dos semanas en confirmar el alcance y puede necesitar un mes para obtener el historial de un servicio remoto. Un periodo de retención de acciones de 30 días ya ha fallado antes de que empiece la investigación. La respuesta correcta no es automáticamente un periodo de varios años. El equipo debe elegir un periodo que cubra sus prácticas reales de detección y respuesta y después contrastarlo con las obligaciones de las jurisdicciones y contratos aplicables.

Separa la regla de la excepción. El calendario ordinario debe eliminar los registros automáticamente. Una retención por caso debe conservar un conjunto definido de registros debido a un incidente activo, una disputa, una auditoría o una instrucción legal. Cuando termine la retención, la eliminación debe reanudarse según la política en lugar de dejar los registros indefinidamente porque nadie los recordó.

No confundas la retención de copias de seguridad con la retención de registros. Una copia de seguridad de una base de datos que contenga registros de actividad eliminados puede mantenerlos disponibles mucho después de que la aplicación indique que los ha eliminado. Documenta si las copias están cifradas, quién puede restaurarlas, cuánto tiempo duran y si una restauración podría volver a introducir registros eliminados por el proceso de borrado. Si no puedes purgar un registro individual de copias inmutables, indícalo en la política y establece el periodo de las copias en consecuencia.

En sistemas que manejan datos personales, consulta al asesor jurídico y al responsable de privacidad antes de asignar un periodo. La legislación de privacidad normalmente no ofrece un número universal que sirva para la actividad de los agentes. Sí exige limitar la finalidad, minimizar los datos y justificar la eliminación. Una justificación vaga basada en la seguridad no permite conservar indefinidamente todo el contenido.

La evidencia de manipulación necesita un límite de confianza independiente

Un registro que solo puede escribir y borrar el mismo administrador no ofrece mucha seguridad después de un incidente grave. La protección frente a cambios requiere prevención y evidencia de las modificaciones posteriores.

El control AU-9 de NIST SP 800-53 exige proteger la información de auditoría frente al acceso, la modificación y la eliminación no autorizados. Esto importa porque un almacenamiento que parece inmutable no resuelve por sí solo el control de acceso, y el control de acceso tampoco revela todos los cambios indebidos. Construye ambas capas.

Primero, separa la ejecución de acciones de la administración de auditoría. El proceso que registra un evento debe tener permiso para añadir, no permisos amplios para reescribir o purgar el historial. Los administradores que gestionan la retención no deberían editar tranquilamente el contenido de eventos individuales. Usa un proceso distinto y auditable para la eliminación y la corrección.

Segundo, vincula los registros en una cadena ordenada. Cada registro incluye un hash del registro anterior y un hash de su propio contenido canónico. Un editor que cambie un evento antiguo rompe la cadena en ese evento y todos los enlaces posteriores, salvo que pueda regenerar toda la secuencia afectada. El encadenamiento de hashes es útil, pero tiene un límite: un atacante que controle al escritor y todas las copias almacenadas puede reescribir la cadena completa. Exporta puntos de control firmados a una ubicación independiente o establece un proceso de revisión que compare puntos de control fuera del control del escritor.

Tercero, protege el tiempo. Los relojes del sistema se desajustan y los atacantes pueden alterarlos. Registra la hora de recepción en el recolector, registra números de secuencia monotónicos cuando sea posible y trata las marcas de tiempo como evidencias que deben compararse con registros externos, no como una verdad aislada. RFC 3161 define un protocolo para marcas de tiempo confiables. Puede reforzar la prueba de que un resumen existía en un momento determinado, pero no demuestra que el contenido de la solicitud fuera correcto o estuviera autorizado.

Cuarto, verifica en lugar de limitarte a afirmar que existe integridad. Un comando de verificación debe informar de la primera secuencia incorrecta, el hash predecesor esperado, el hash predecesor observado y el identificador del registro. Este formato proporciona al operador algo útil:

$ audit verify activity.log
records_checked: 18427
chain_status: valid
first_error: none
checkpoint_status: matched

Cuando la verificación falle, conserva el almacenamiento afectado antes de que alguien lo «arregle». Ejecuta la verificación sobre una copia de los datos, captura el resultado, identifica el último punto de control válido y compáralo con exportaciones independientes. Reparar primero la cadena puede destruir la evidencia de la propia alteración.

Un fallo plausible revela lo que ocultan los registros limitados

Considera un agente de programación que recibe permiso para una tarea de desarrollo y después intenta hacer una llamada HTTP a un servicio de facturación en producción. La puerta de enlace de acciones rechaza la llamada porque la autorización de la sesión cubre un proceso distinto del que realiza la solicitud. Unos minutos después, un desarrollador reintenta desde otra ejecución del agente y la aprueba sin advertir que el destino es producción.

El servicio remoto devuelve una respuesta 200. La transcripción del chat del agente solo dice que «resolvió un problema de facturación». El equipo se entera de una queja de un cliente tres semanas después.

Con un registro débil, el equipo encuentra una llamada exitosa de una cuenta genérica de «agente» y una marca de tiempo imprecisa. No puede determinar si la primera llamada denegada procedía del mismo ejecutable, si la aprobación ocurrió en la misma sesión, qué credencial se seleccionó, qué factura se vio afectada ni si alguien cambió el registro después de la queja. Termina buscando en historiales de shell, exportaciones de chats y registros del servicio remoto, que pueden tener una retención más corta que su propio sistema.

Con un registro útil, el investigador puede reconstruir la secuencia:

1. Un proceso firmado inició una sesión y recibió una aprobación vinculada a esa ejecución.
2. Un proceso con una identidad diferente intentó realizar la operación en producción y recibió una denegación.
3. Una sesión posterior utilizó una referencia de credencial concreta, apuntó al host de producción, solicitó anular una factura usando un identificador protegido y recibió un resultado 200.
4. La cadena de actividad se verifica con un punto de control creado antes de la queja.

Esto no demuestra si el desarrollador tenía intención de realizar la acción. Sí establece quién aprobó qué proceso, qué hizo la ruta de ejecución y dónde debe continuar la investigación. Los registros de auditoría deben resistir la tentación de narrar motivos. Deben conservar hechos que permitan evaluar los motivos más adelante.

Conserva un identificador de correlación entre los reintentos, pero no agrupes los intentos en un único registro final de éxito. Los reintentos pueden mostrar un cambio de destino, un cambio de credenciales o una prueba de límites antes de una acción permitida. Esos detalles importan cuando la solicitud final causa daños.

La redacción debe ocurrir antes de que los registros entren en el libro mayor

Un almacén de auditoría cifrado protege los registros en reposo. No hace aceptable registrar contraseñas, tokens de acceso, cookies de sesión, claves privadas u objetos completos de clientes. Una vez que el contenido original entra en un libro mayor con retención prolongada, todos los investigadores futuros, operadores de restauración y responsables de responder a filtraciones heredan esa exposición.

Crea una lista de campos permitidos para cada canal. En HTTP, permite el método, el destino, la plantilla de ruta, nombres seleccionados de parámetros de consulta seguros, la longitud del contenido, el estado y la clase de error. Descarta explícitamente Authorization, Cookie, Set-Cookie, tokens de API, secretos de cliente y encabezados sensibles conocidos. Trata los cuerpos de solicitudes y respuestas como prohibidos por defecto.

La redacción basada únicamente en coincidencia de patrones no detectará formatos nuevos de secretos y puede dañar la evidencia. Usa primero controles estructurales: no ingieras campos que nunca deberían estar presentes. Aplica la redacción por patrones como segunda barrera para el texto de errores o los datos proporcionados por servicios remotos. Conserva una versión de redacción en el evento para que los investigadores sepan qué reglas se aplicaron.

Los datos personales requieren la misma disciplina. Un identificador de cuenta puede ser necesario para identificar el objeto afectado. Un perfil completo, un documento o una transcripción de soporte rara vez pertenece a un libro mayor general de acciones. La seudonimización puede reducir la exposición rutinaria, pero no llames anónimo a un identificador reversible estable. Si alguien con otra tabla puede recuperar la identidad, sigue siendo un dato personal a efectos de gobernanza.

Cuando un caso necesite realmente el contenido, crea una captura de evidencia limitada con un identificador de caso, un grupo de acceso definido, una fecha de caducidad y una fecha de revisión. Registra la existencia de la captura en el libro mayor de acciones, pero no copies su contenido en todos los informes posteriores. Así las investigaciones normales siguen siendo útiles sin dar a todos los lectores acceso al material más sensible.

Las eliminaciones, retenciones y correcciones deben dejar su propia evidencia

La retención es un proceso operativo, no un párrafo de una política de seguridad. Un calendario que nadie prueba acabará convirtiéndose en almacenamiento permanente accidental o en una purga automática durante un incidente.

Ejecuta la eliminación mediante un trabajo registrado. En cada ejecución, conserva la versión de la política, la clase de registro, el intervalo temporal seleccionado, el número de registros eliminados, el número omitido por estar retenido, la identidad del ejecutor y el resultado. El trabajo de eliminación debe seguir la misma disciplina de solo adición que el registro de acciones. Un operador no debería necesitar acceso directo a la base de datos para «limpiar» registros.

Una retención necesita un alcance que una máquina pueda aplicar. Defínela mediante un identificador de caso y un intervalo temporal del evento, un identificador de sesión, un destino, una identidad de actor u otro selector estable. Evita las retenciones escritas como una frase en un ticket, porque un trabajo de retención no puede evaluar una frase. Registra quién estableció la retención, la autoridad que la respalda, la fecha de revisión y el evento de liberación.

Las correcciones merecen un cuidado similar. A veces los sistemas registran una ruta analizada incorrectamente, una marca de tiempo retrasada o una clasificación engañosa. Conserva intacto el evento original. Añade un evento de corrección que identifique el evento original, describa la interpretación modificada, explique el motivo e identifique a la persona o proceso que hizo la corrección. Los informes deben mostrar la corrección sin ocultar el registro de origen.

Prueba todo el proceso en una copia que no sea de producción: crea registros de todas las clases, establece una retención sobre parte del intervalo, ejecuta la retención, verifica la eliminación esperada, libera la retención y vuelve a ejecutar el proceso. Después restaura una copia de seguridad y confirma que no crea un archivo oculto y accesible de forma rutinaria que contradiga el calendario declarado.

Una política compacta es más fácil de aplicar que un documento perfecto

Una política de retención debe adaptarse al sistema que tiene que ejecutarla. La siguiente plantilla es deliberadamente sencilla porque cada afirmación se corresponde con un responsable, un campo, un trabajo o una actividad de verificación.

Purpose: reconstruct externally executed agent actions and investigate misuse.

Action ledger: retain for [period].
Fields: actor identity, session, authorization decision, destination,
operation, credential reference, protected target identifier, outcome,
integrity fields. Exclude secrets and raw bodies.

Diagnostic detail: retain for [shorter period].
Fields: bounded error text and timing. Apply allowlist and redaction rules.

Protected evidence capture: case-only. Require case identifier, expiry,
access group, and documented approval.

Integrity: append records; verify chain [cadence]; export or compare
checkpoints [cadence]. Record verification failures.

Deletion: execute [cadence]. Record policy version, range, result, and holds.
Holds: suspend deletion for defined selectors. Review [cadence].
Corrections: append a correction record; never overwrite an action record.

Asigna responsables concretos para el esquema de registros, el calendario de retención, la revisión de privacidad, las retenciones por incidentes y las comprobaciones de integridad. Una misma persona puede desempeñar varios roles en un equipo pequeño, pero las responsabilidades siguen necesitando nombres. De lo contrario, la persona que opera el agente se convierte también en quien decide qué evidencia desaparece después de un incidente.

Sallyport mantiene un diario de sesiones y un diario de actividad proyectado desde un único registro de auditoría cifrado y encadenado mediante hashes, y sp audit verify puede verificar esa cadena sin conexión sobre texto cifrado. Este diseño solo resulta útil si los equipos deciden de antemano qué campos pertenecen a sus registros y cómo los gestionan sus trabajos de retención, retenciones y exportaciones.

Revisa la política después del primer incidente real o de un ejercicio de simulación deliberado. Pide a los investigadores que reconstruyan una acción usando solo los registros que habrían sobrevivido al calendario. Si necesitan un secreto, una transcripción original o la memoria de un administrador para responder preguntas básicas, cambia el esquema. Si pueden responderlas, pero cada registro contiene datos de clientes, reduce el esquema antes de que se vuelva permanente.