Exportación de actividad de agentes para revisión legal: crea pruebas

Una exportación de actividad del agente debe permitir que una persona ajena responda cuatro preguntas sencillas sin tener que confiar en quien la preparó: qué acciones ocurrieron, cuándo ocurrieron, si los registros cambiaron y quién controló el material después de recopilarlo. La mayoría de los equipos puede responder a la primera. Las otras tres son las que convierten un incidente rutinario en una disputa sobre las pruebas.

No esperes a recibir una citación judicial, afrontar un conflicto laboral, sufrir un incidente de seguridad o recibir una queja de un cliente para decidir qué conservar. Para entonces, los procesos de retención quizá ya hayan eliminado registros, algunas personas pueden haber abierto y reorganizado archivos y un ingeniero apurado puede haber exportado solo los registros que parecían relevantes. Es comprensible. También es exactamente la forma en que un paquete de revisión pierde credibilidad.

Este es un método práctico para preparar registros de acciones de agentes para abogados, investigaciones internas, revisiones de cumplimiento o un examinador externo. No sustituye al asesoramiento legal. Sí proporciona a los abogados algo mucho mejor que una hoja de cálculo con un nombre de archivo tranquilizador.

Trata el paquete como una prueba, no como un informe

Un paquete de pruebas conserva el material de origen y explica cómo se ha manejado. Un informe selecciona, interpreta y argumenta a partir de ese material. Puedes necesitar ambos, pero combinarlos sin cuidado crea problemas.

Un informe puede afirmar: «El agente intentó ejecutar un comando SSH contra este host en este momento». El paquete de pruebas debe permitir al revisor encontrar el registro de la acción subyacente, ver cómo se representa la hora, inspeccionar el resultado registrado, confirmar qué sistema lo produjo y comprobar si la exportación ha cambiado. El informe debe estar junto al paquete, no dentro de su única copia.

La diferencia importa cuando una teoría inicial resulta equivocada. Los investigadores suelen acotar el foco a medida que descubren más información. Si exportaron un conjunto seleccionado de eventos «malos» y después descartaron los registros circundantes, no podrán comprobar más tarde si un reintento, una aprobación, un cambio de sesión o una acción del operador explica el evento. El contexto no es un adorno. A menudo marca la diferencia entre una acción realmente no autorizada y una secuencia engañosa de fallos ordinarios.

Define el alcance de la recopilación antes de empezar. Escríbelo en una frase breve que indique:

• los identificadores de proceso o sesión del agente incluidos
• los canales de acción incluidos, como HTTP y SSH
• la hora de inicio y finalización en UTC
• los sistemas o cuentas cubiertos
• las exclusiones conocidas y el motivo de cada una

No amplíes el alcance en silencio más adelante. Añade una recopilación complementaria. Por ejemplo, si el primer paquete cubre una ventana de incidente de seis horas y después un revisor solicita el día anterior, crea un segundo paquete con su propio manifiesto y sus propios hashes. Relaciónalo con el primer paquete en el registro de custodia. Así queda constancia de que la primera decisión tenía un límite.

Aquí también cometen los equipos un error perjudicial: confunden una vista de actividad con un registro de origen completo. Un panel puede ser útil para la clasificación inicial, pero a menudo aplica filtros, paginación, preferencias del usuario y límites de retención que no se ven en una captura de pantalla. Recopila los registros sin procesar o la exportación de origen más cercana disponible, y crea después vistas legibles a partir de ese material.

Separa la autenticidad de la integridad

La autenticidad y la integridad son afirmaciones diferentes, y un buen paquete respalda cada una por separado.

La autenticidad pregunta si un registro concreto procede del origen declarado y si alguien lo cambió después de recopilarlo. Los hashes, las firmas, el almacenamiento de solo anexado y las cadenas de hashes ayudan con esta afirmación. La integridad pregunta si el paquete contiene todos los registros que deberían estar dentro del alcance declarado. Las consultas, los recuentos del origen, la configuración de retención y las notas de recopilación ayudan con esa afirmación.

Los equipos suelen exagerar lo que demuestra un hash de archivo. Un hash SHA-256 puede mostrar que activity.jsonl coincide ahora con la versión cuyo hash calculaste antes. No puede demostrar que el archivo incluyera todas las acciones del periodo, que el reloj del sistema fuera correcto o que el archivo procediera del sistema mencionado en el memorando. Un hash es una prueba excelente de continuidad byte a byte. No es un sello universal de verdad.

Del mismo modo, una cadena de auditoría puede revelar una eliminación o alteración dentro de la secuencia que cubre, pero no corrige una definición de alcance deficiente. Si recopilas una sola sesión del agente cuando el incidente implicó dos, una cadena intacta para la primera sesión no hace que el paquete sea completo.

Usa un manifiesto para que estas afirmaciones puedan revisarse. El manifiesto debe identificar el origen, el alcance, quién recopiló el material, la hora de recopilación, el inventario de archivos y el material de verificación. Guárdalo en un formato de texto plano que no dependa de una aplicación concreta para poder leerlo.

case_reference: IR-2025-017
package_id: 2025-017-agent-actions-01
collected_at_utc: 2025-03-08T14:27:19Z
collected_by: employee-id-1842
source_system: macOS workstation, asset WS-042
scope_start_utc: 2025-03-07T18:00:00Z
scope_end_utc: 2025-03-08T02:00:00Z
channels: HTTP, SSH
included_files:
  - original/activity-records.jsonl
  - original/session-records.jsonl
  - original/audit-verification.txt
  - derived/action-timeline.csv
exclusions: Browser history and local shell history were outside this collection.

El directorio original debe contener el material de origen recopilado. El directorio derived puede contener una línea temporal en CSV, un memorando de revisión o una copia redactada. Esta separación evita un fallo habitual: alguien abre un archivo JSON, lo guarda desde un editor que cambia los saltos de línea o la codificación de caracteres y después descubre que el hash original ya no coincide.

Las Federal Rules of Evidence abordan la autenticidad en la Rule 901 mediante pruebas suficientes para respaldar la conclusión de que un elemento es lo que la parte que lo presenta afirma que es. La Rule 902(14) trata específicamente de datos certificados copiados de un dispositivo electrónico, un medio de almacenamiento o un archivo cuando una persona cualificada los identifica mediante un proceso de identificación digital. Estas reglas no permiten que el personal técnico omita la documentación. Hacen que el proceso de identificación forme parte de la prueba.

Congela el origen antes de hacerlo legible

Recopila una vez, conserva esa recopilación y realiza la clasificación y el formateo sobre copias. Puede parecer excesivo hasta la primera vez que un investigador tiene que explicar por qué un archivo cambió después de que el equipo lo declarara prueba.

Empieza creando un directorio del caso con acceso restringido. Registra la ubicación exacta del sistema desde la que recopilaste los registros, la cuenta utilizada y si el origen siguió activo después de la recopilación. Si el origen puede seguir recibiendo eventos, anótalo. Un sistema activo no es una pieza estática de prueba, y fingir lo contrario produce líneas temporales confusas.

Después realiza una exportación directa del origen. Evita abrir los archivos en un programa de hojas de cálculo antes de calcular los hashes. Estas aplicaciones reinterpretan habitualmente las fechas, truncan valores largos, cambian delimitadores y tratan los identificadores como números. Eso puede ser aceptable en un archivo de análisis de trabajo. Es inaceptable para la copia conservada.

En macOS, calcula un inventario SHA-256 desde el directorio del paquete después de colocar allí los originales:

find original -type f -print0 | sort -z | xargs -0 shasum -a 256 > SHA256SUMS.txt
cat SHA256SUMS.txt

La salida contiene una línea por archivo, con un resumen hexadecimal de 64 caracteres seguido de la ruta del archivo. Guarda la salida del comando como parte del paquete y registra quién lo ejecutó. Más adelante, verifica el inventario con:

shasum -a 256 -c SHA256SUMS.txt

Una comprobación correcta muestra cada ruta seguida de OK. Si una ruta muestra FAILED, deja de tratar el paquete como inalterado. Conserva la copia que falló, documenta el resultado y determina si lo causó una transferencia, un cambio de nombre, una conversión de saltos de línea o una modificación real. No regeneres el archivo de hashes para continuar sin más.

Los nombres de archivo deben ser sencillos y estables. Cuando sea útil, incluye el identificador del paquete, la categoría del origen y la hora de recopilación en UTC. Evita nombres como final-final-v3 o suspicious stuff. Un revisor no debería necesitar una explicación oral para distinguir una exportación original de una hoja de trabajo filtrada por un analista.

NIST Special Publication 800-86, Guide to Integrating Forensic Techniques into Incident Response, pone el acento en conservar los datos y documentar su recopilación y manejo. Sus recomendaciones son anteriores a las herramientas de agentes, pero la disciplina sigue siendo válida. Las acciones de los agentes ocurren rápidamente; eso exige mejores notas de recopilación, no una rebaja del estándar.

Registra las marcas de tiempo junto con el contexto del reloj

Una marca de tiempo sin un reloj definido es un dato incompleto. Conserva el valor original, su zona horaria u offset, el nombre del campo y cualquier identificador de ordenación conocido.

Usa UTC como hora de referencia del paquete. Exprésala en formato ISO 8601, por ejemplo 2025-03-08T14:27:19Z. Conserva también las marcas de tiempo exactamente como las exportó el origen. Si un origen muestra la hora local, incluye su zona configurada e indica si el sistema sincronizaba la hora mediante un servicio aprobado. No sobrescribas una marca de tiempo de origen solo porque el equipo prefiera otro formato de visualización.

Una acción de un agente puede generar varias horas. Un registro de acción puede incluir el momento en que el agente solicitó una operación, el momento en que apareció una aprobación, la hora en que una persona la aprobó, la hora en que el sistema la ejecutó y la hora en que respondió un servicio remoto. No son intercambiables.

Para crear una línea temporal útil, etiqueta estos momentos según el evento en lugar de agruparlos en una única columna timestamp. Una solicitud a las 10:00:01, una aprobación a las 10:00:28, una ejecución a las 10:00:29 y un fallo remoto a las 10:00:31 cuentan una historia distinta de una ejecución anterior a la aprobación. El orden puede confirmar o invalidar una afirmación de control humano.

Captura los identificadores de secuencia cuando existan. Una secuencia de auditoría creciente, un número de llamada local de la sesión o un identificador de solicitud pueden resolver empates cuando dos registros tienen la misma precisión temporal. Si los registros solo ofrecen marcas de tiempo con precisión de segundos, dilo. No inventes precisión de milisegundos registrando la hora de exportación.

Las discrepancias entre relojes merecen una nota propia. Si la estación de trabajo local y una API remota difieren varios minutos, conserva esa observación e identifica los orígenes. No «corrijas» un registro para que la línea temporal parezca más limpia. Más adelante, un revisor puede necesitar comprobar si los sistemas usaban relojes separados o si un evento cruzó un límite temporal.

El paquete de pruebas debe incluir una breve declaración temporal como esta: «Todas las vistas de la línea temporal usan UTC. Los valores de origen permanecen en los archivos originales. La estación de trabajo informó de un offset UTC de +00:00 durante la recopilación. No se realizó una comparación independiente de relojes». La última frase puede resultar poco satisfactoria, pero es honesta. Una certeza sin respaldo causa más daño que una limitación documentada.

Conserva la acción y el contexto de la decisión

Un registro de acción necesita suficiente contexto para distinguir una solicitud intentada, una ejecución autorizada y un efecto externo completado. Son eventos separados.

Para la actividad HTTP, conserva la hora de la acción, el identificador de sesión o proceso, el método, el host de destino, la ruta, las cabeceras de solicitud relevantes después de eliminar los secretos, el tratamiento del cuerpo de la solicitud, el estado de la respuesta y los metadatos del resultado. El paquete de revisión no debe contener tokens de portador reutilizables, contraseñas ni claves privadas solo porque hayan pasado por un sistema de acciones. Un secreto puede crear un segundo incidente dentro del proceso de conservación de pruebas.

Para la actividad SSH, conserva el host de destino o alias, la identidad de usuario utilizada por el sistema de acciones, el comando o la categoría del comando cuando se registre, el resultado de la autenticación, el estado de salida y la salida devuelta, sujetos a una regla de redacción documentada. Si la salida puede contener datos de clientes, conserva el original con acceso restringido y crea una copia de revisión que describa cada redacción. Las barras negras sin un registro de redacciones hacen que los revisores se pregunten qué más desapareció.

La identidad del proceso importa tanto como la acción. Registra el proceso del agente que inició la llamada, su autoridad de firma de código cuando esté disponible, su identificador de sesión y la duración de la sesión. Decir que «lo hizo el agente de programación» es demasiado impreciso para una revisión legal. Procesos distintos pueden tener orígenes, aprobaciones y permisos diferentes aunque una persona los llame a todos de la misma forma, agente.

Los registros de aprobación requieren una redacción cuidadosa. Una aprobación significa que una persona permitió una operación o sesión definida conforme al diseño del sistema. No demuestra que esa persona leyera cada detalle, entendiera todas las consecuencias o tuviera autoridad según una política de la empresa. No hagas esas afirmaciones salvo que existan pruebas independientes que las respalden.

Sallyport registra las ejecuciones de los agentes en un diario Sessions y las llamadas individuales en un diario Activity, y ambas vistas se generan a partir de un único registro de auditoría cifrado y encadenado mediante hashes. Este diseño resulta útil para la revisión porque una pregunta sobre una sesión y otra sobre una llamada pueden remitir a la misma secuencia de registros subyacente.

Mantén intacta la relación entre la solicitud original y el resultado. Una llamada fallida puede ser tan relevante como una correcta. Los fallos repetidos pueden mostrar que un agente reintentó usar una credencial bloqueada, que cambió el endpoint o que un operador corrigió una configuración. Eliminar los fallos para acortar la línea temporal suele eliminar la explicación del único éxito que importa.

Verifica las pruebas de manipulación mientras el origen siga disponible

Realiza la verificación de integridad durante la recopilación y guarda la salida junto con los registros originales. Una verificación posterior sigue siendo útil, pero un resultado temprano vincula el paquete con el estado del sistema de registro en el momento de la recopilación.

Un registro encadenado mediante hashes enlaza cada registro con el material anterior mediante datos criptográficos. Alterar, eliminar o insertar registros normalmente rompe la relación con los enlaces posteriores. Esto proporciona a los revisores una propiedad concreta que pueden comprobar: si la secuencia se verifica tal como fue emitida. No demuestra que la acción registrada estuviera justificada desde el punto de vista ético ni que todos los eventos posibles del sistema llegaran al registro. Mantén separadas esas afirmaciones.

Para un registro de auditoría de Sallyport, ejecuta sp audit verify sobre el origen recopilado antes de basarte en las vistas de los diarios. La verificación puede ejecutarse sin conexión sobre el texto cifrado y no necesita una clave de bóveda, lo que permite conservar un resultado de integridad sin obtener las credenciales utilizadas para acciones externas.

Guarda la transcripción completa del terminal, incluidos el comando, el directorio actual, la identidad de la cuenta si tu procedimiento la captura, las horas de inicio y finalización y el estado de salida. Una captura de pantalla es más débil que el texto porque resulta difícil buscarla, copiarla y volver a ejecutarla de forma independiente. Si el comando informa de un fallo, conserva el resultado. No exportes únicamente los registros que parecen verificarse correctamente.

La verificación necesita condiciones reproducibles. Anota la versión de la aplicación, la versión del sistema operativo cuando sea relevante y la ruta exacta de recopilación. Si la herramienta de verificación depende de una instalación local concreta, conserva constancia de esa dependencia. No tienes que incluir todos los ejecutables por defecto, pero los revisores deben saber qué necesitarían para repetir la comprobación.

Una nota de verificación sencilla puede decir: «El recopilador ejecutó el comando de verificación de auditoría a las 2025-03-08T14:31:02Z sobre el registro de auditoría cifrado copiado en original/. El comando terminó correctamente. La transcripción del terminal sin editar está en original/audit-verification.txt». Si no terminó correctamente, dilo claramente y registra el efecto sobre el paquete. Las pruebas de integridad son útiles precisamente porque pueden contradecir la explicación que prefieres.

Mantén un registro de custodia que identifique a las personas y las transferencias

La cadena de custodia es un registro cronológico de la posesión y el control. No es una página de firmas que se completa después de los hechos cuando alguien la solicita.

Empieza el registro cuando el recopilador crea el paquete. Cada entrada debe indicar el identificador del paquete, la fecha y hora en UTC, la persona o cuenta de servicio que transfiere el control, el destinatario, el propósito, el método de transferencia, la ubicación de almacenamiento y el hash del paquete o la referencia al inventario de hashes. Si una persona mantiene la custodia durante toda la recopilación, regístralo también.

Usa nombres o identidades internas estables que la empresa pueda resolver más adelante. «El equipo de seguridad» no es un custodio. «Jane, de legal» tampoco basta. Las personas cambian de función, dejan las empresas y recuerdan los hechos de manera diferente bajo presión.

2025-03-08T14:38:11Z
Package: 2025-017-agent-actions-01
Released by: employee-id-1842
Received by: legal-ops-id-77
Purpose: counsel review under incident hold
Method: encrypted internal file transfer
Integrity reference: SHA256SUMS.txt verified before transfer
Storage: matter workspace, restricted folder

Cuando una transferencia utiliza almacenamiento cifrado o un intercambio seguro de archivos, registra el método, pero no supongas que el cifrado demuestra la custodia. El cifrado protege la confidencialidad durante el tránsito. La entrada de custodia establece quién transfirió y recibió intencionadamente el paquete. Pide al destinatario que confirme la recepción y registra después cualquier copia realizada para un consultor, una aseguradora, un regulador o un abogado externo.

Los registros de acceso pueden respaldar el registro de custodia, pero no lo sustituyen. Un registro de almacenamiento puede mostrar que una cuenta accedió a un archivo. No siempre puede explicar por qué lo hizo, si la cuenta pertenecía a la persona prevista en ese momento o si se produjo una transferencia aprobada fuera del sistema de almacenamiento.

Evita enviar el único original por correo electrónico ordinario. El correo crea copias sin control, riesgo de reenvío automático, problemas de retención y ambigüedad sobre las versiones de los adjuntos. Si el abogado necesita una copia, crea una copia de distribución documentada, verifica su hash después de la transferencia y conserva el original en la ubicación controlada.

La redacción debe ser reversible en el proceso, no en los archivos

Redacta para una audiencia y un propósito definidos, pero conserva un original sin redactar cuando la ley, la política y la investigación lo exijan. No conviertas la versión redactada en el único paquete que sobrevive.

Los registros de los agentes pueden contener secretos, código fuente, datos personales, datos de clientes, nombres de host internos o detalles operativos que generen nuevos riesgos si se comparten ampliamente. La revisión legal rara vez necesita una credencial API reutilizable o material de SSH privado. Exclúyelos de la copia de revisión y explica cómo los gestionó el proceso de recopilación. Si una exportación de origen contiene secretos, restringe más el original en lugar de distribuirlo a todos los revisores.

Usa un registro de redacciones con una fila por elemento redactado o por categoría coherente. Indica el archivo, el identificador del registro, el campo, el motivo, la persona que realizó la redacción, la fecha y si el original sigue disponible con acceso restringido. El revisor debe poder distinguir entre una cabecera de autorización redactada y un resultado de acción eliminado.

No dependas de superposiciones visuales en PDF ni de capturas de pantalla. Las redacciones incorrectas han dejado expuesto el texto subyacente suficientes veces como para no considerarlas nunca un detalle menor de producción. Crea un nuevo artefacto de revisión a partir de una copia controlada, inspecciónalo con herramientas normales de extracción y verifica que el contenido sensible ya no aparezca. Después calcula el hash del artefacto redactado por separado. Su hash no debe sustituir al inventario original.

Una línea temporal filtrada puede ser útil, especialmente cuando un caso abarca miles de llamadas rutinarias. Etiquétala como un elemento derivado e incluye la lógica del filtro. Por ejemplo: «Incluye llamadas al tenant del cliente indicado entre las horas UTC especificadas; excluye todos los demás destinos; los registros de origen permanecen en original/activity-records.jsonl». Esa frase permite al abogado explicar qué es el elemento sin afirmar que constituye el historial de auditoría completo.

Prepara el paquete para revisarlo seis meses después

La persona que recopila el paquete puede no ser quien tenga que explicarlo más adelante. Escribe las notas de recopilación pensando en quien herede el asunto después de que desaparezca el chat del incidente y el ingeniero original haya olvidado los detalles.

Incluye un README breve que responda a preguntas prácticas: qué archivos son originales, cuáles son derivados, qué herramienta produjo cada exportación, cómo verificar los hashes, cómo interpretar las marcas de tiempo y dónde se controla el acceso al original conservado. Mantén las opiniones en un análisis separado del incidente, salvo que el paquete las identifique claramente como una declaración del analista.

La barrera de la bóveda, la autorización de sesiones y las aprobaciones por llamada de Sallyport pueden generar registros que ayuden a explicar el control humano sobre una acción. Conserva el nivel exacto de pruebas de aprobación que necesite el asunto y evita afirmar que un control del producto responde a una cuestión legal que corresponde a la política, la autoridad o la intención.

Realiza un ejercicio de prueba antes de que una investigación te obligue a hacerlo. Pide a un compañero que no haya recopilado el paquete que use únicamente el README, el manifiesto, los hashes y la transcripción de verificación para responder: ¿Qué registros de origen están incluidos? ¿Puedo verificarlos? ¿Qué referencia temporal se aplica? ¿Quién tuvo la custodia? Si ese compañero tiene que hacer preguntas básicas al recopilador, el paquete aún no está listo.

La primera mejora útil suele ser poco llamativa: crea ahora una plantilla de directorio del caso, un manifiesto de texto plano, un comando para inventariar hashes y un registro de custodia. Cuando llegue un incidente real, esos cuatro elementos evitarán que una exportación apresurada se convierta en una historia imposible de verificar.