- Por qué los sandboxes de agentes de IA necesitan un registro de auditoría diferente
- Registros de ejecución de comandos y procesos
- Eventos de acceso al sistema de archivos
- Llamadas de red salientes y registro de salida
- Eventos de instalación de paquetes
- Invocaciones de herramientas y resultados
- Eventos del ciclo de vida de la sesión
- Eventos de límites de recursos
- Formatos de registro estructurados vs. no estructurados
- Integridad del registro y evidencia de manipulación
- Políticas de retención de registros de auditoría para sandboxes de agentes de IA
- Presentación de registros para respuesta a incidentes
- Qué preguntar a su proveedor de sandbox
- Conclusión
- FAQ
- Artículos recomendados
Los registros de auditoría para sandboxes de agentes de IA deben capturar la ejecución de comandos y procesos, lecturas y escrituras de archivos, llamadas de red salientes y destinos de salida, eventos de instalación de paquetes, invocaciones de herramientas, resúmenes de entrada y salida del modelo a nivel de sesión, impactos en límites de recursos y eventos del ciclo de vida de la sesión. Sin esa cobertura, un equipo de seguridad no puede reconstruir lo que hizo un agente, rastrear un compromiso o satisfacer una revisión posterior a un incidente. Las brechas en cualquiera de estas categorías dejan puntos ciegos que son difíciles o imposibles de cerrar retroactivamente.
Por qué los sandboxes de agentes de IA necesitan un registro de auditoría diferente
Los registros de auditoría tradicionales de servidores asumen que un humano o un proceso de aplicación determinista desencadenó cada acción. Los agentes de IA rompen esa suposición. Un solo prompt puede hacer que una sesión instale paquetes, escriba archivos, ejecute comandos de shell, llame a API externas y genere subprocesos, todo en cuestión de segundos, sin aprobación humana para pasos individuales.
Esto cambia lo que un registro de auditoría necesita responder. Para un servidor tradicional, la pregunta suele ser “¿un usuario autorizado cambió este archivo?”. Para un sandbox de agente, las preguntas son:
- ¿Qué decidió ejecutar el modelo y en qué orden?
- ¿Qué comandos de shell se ejecutaron y como qué proceso?
- ¿Accedió el agente a archivos que no se esperaba que tocara?
- ¿Qué salió del sandbox a través de la red y hacia dónde fue?
- ¿Una instalación de paquete introdujo código inesperado?
- ¿Qué estaba haciendo el agente cuando alcanzó un límite de recurso o fue terminado?
Un sistema de registros que pueda responder esas preguntas brinda a los equipos de seguridad la capacidad de reconstrucción que necesitan. Un sistema de registros que no pueda hacerlo deja a la respuesta a incidentes adivinando.
Registros de ejecución de comandos y procesos
La ejecución de procesos es la categoría de mayor prioridad. Cada comando que ejecute el agente —directamente o a través de un subproceso de shell— debe producir una entrada de registro que incluya: el nombre del proceso y la lista completa de argumentos, el proceso padre y el PID, el usuario y el UID efectivo, el directorio de trabajo, la marca de tiempo con precisión de subsegundo y el código de salida.
Sin la lista de argumentos, comandos como python, curl o bash son casi insignificantes en un rastreo posterior a un incidente. Sin el UID, no se puede saber si el agente se ejecutó con privilegios elevados. Sin la cadena PID padre, no se pueden reconstruir subprocesos anidados ni entender cómo se invocó un comando.
Los subsistemas de auditoría de Linux como auditd con reglas de syscall apropiadas (execve, execveat) pueden capturar esto a nivel de kernel dentro de una microVM invitada. Los sandboxes basados en contenedores pueden usar rastreo basado en eBPF o registro de seccomp como alternativa, aunque cada enfoque tiene diferentes coberturas y compensaciones de rendimiento. El requisito clave desde la perspectiva de un equipo de seguridad es que el registro se genere por debajo de la capa de aplicación: un proceso de agente que controla su propio registro no es confiable para informar su propio comportamiento con precisión.
Eventos de acceso al sistema de archivos
La cobertura de auditoría del sistema de archivos debe registrar lecturas, escrituras, eliminaciones, renombrados y operaciones de montaje. Para cada evento, el registro debe incluir: el tipo de operación, la ruta completa, el proceso y PID responsable, el UID y la marca de tiempo.
En la práctica, registrar cada lectura de archivo en un sandbox ocupado puede generar un volumen alto. Los equipos de seguridad a menudo limitan esto a rutas sensibles, por ejemplo, cualquier ruta bajo /etc, /root, el directorio de trabajo del agente, ubicaciones de archivos de credenciales y secretos montados. Las escrituras y eliminaciones tienen mayor prioridad que las lecturas para la mayoría de los modelos de amenaza, pero las lecturas de archivos de credenciales o configuración vale la pena capturarlas de todos modos.
Los eventos del sistema de archivos son particularmente útiles para identificar intentos de exfiltración de datos (grandes lecturas seguidas de llamadas de red salientes), cambios de configuración inesperados (escrituras en archivos que el agente no debería tocar) y comportamiento de limpieza (eliminaciones ejecutadas al final de una sesión, lo que puede indicar un intento de ocultar actividad).
Llamadas de red salientes y registro de salida
El registro de salida es una de las áreas más comúnmente subespecificadas en las implementaciones de sandboxes de agentes. Muchos sandboxes registran que se intentó una conexión de red; muchos menos registran hacia dónde fue, qué protocolo se usó y si tuvo éxito.
Las entradas de registro de salida completas deben incluir: la dirección IP y el puerto de destino, el nombre de dominio resuelto (consulta y respuesta DNS), el protocolo (TCP, UDP, HTTP, etc.), los bytes transferidos en cada dirección, el proceso que abrió la conexión, el UID y la marca de tiempo.
El registro de consultas DNS es importante por separado. Un agente que consulta un dominio inesperado —incluso si la conexión se bloquea después— es una señal que vale la pena capturar. DNS sobre HTTPS puede eludir el registro de consultas a menos que el sandbox aplique la política de red a un nivel que lo intercepte.
Los sandboxes que proporcionan controles de salida basados en listas permitidas deben registrar tanto los intentos de conexión permitidos como los bloqueados. Un alto volumen de intentos bloqueados hacia destinos inesperados es en sí mismo una señal de seguridad significativa.
Eventos de instalación de paquetes
Las instalaciones de paquetes son un objetivo de auditoría de alto valor porque cambian el entorno de ejecución de maneras que persisten durante la duración de la sesión y potencialmente afectan operaciones posteriores. Cada evento de instalación debe capturar: el gestor de paquetes invocado (pip, npm, apt, cargo, etc.), el nombre del paquete, la versión solicitada, la versión resuelta, la URL de origen o registro, el hash o checksum del paquete, el proceso y UID, y la marca de tiempo.
La URL de origen es importante. Un paquete instalado desde un registro privado, una URL directa o un espejo inusual tiene un perfil de riesgo diferente que uno instalado desde el registro público predeterminado. El hash es importante para la verificación posterior al incidente: si luego se descubre que un paquete era malicioso, se quiere saber si esa versión exacta se instaló en una sesión determinada.
Los sandboxes que bloquean por completo las instalaciones de paquetes eliminan esta categoría de riesgo, pero también restringen significativamente lo que los agentes pueden hacer. La mayoría de las implementaciones de producción necesitan un camino intermedio: registrar todo, permitir instalaciones desde una lista de fuentes aprobadas y marcar o bloquear instalaciones desde fuentes desconocidas.
Invocaciones de herramientas y resultados
Los agentes de IA típicamente operan a través de un mecanismo de llamada a herramientas donde el modelo solicita una acción nombrada —ejecutar código, leer archivo, llamar API, buscar en la web— y la capa de orquestación la ejecuta. Estas invocaciones de herramientas se encuentran por encima del nivel del SO y son eventos de la capa de aplicación, pero son importantes de registrar porque representan la intención del modelo, no solo la consecuencia a nivel de sistema.
Los registros de invocación de herramientas deben capturar: el nombre de la herramienta, un resumen de los parámetros de entrada (no el contenido completo si incluiría secretos o PII de usuario), un resumen del estado del resultado (éxito, error, tiempo de espera), el ID de sesión y la marca de tiempo.
Registrar la entrada y salida completa de cada llamada de herramienta es útil para la depuración, pero crea riesgos de privacidad y fuga de secretos. Un enfoque práctico es registrar nombres de herramientas y estado de forma incondicional, registrar resúmenes de entrada/salida en un nivel de verbosidad configurable y proporcionar una manera de recuperar detalles completos para sesiones específicas durante una investigación con controles de acceso adecuados.
El objetivo es suficiente señal para reconstruir la secuencia de acciones del agente sin crear un almacén de registros que se convierta en un objetivo de alto valor en sí mismo.
Eventos del ciclo de vida de la sesión
Los eventos del ciclo de vida de la sesión anclan todas las demás entradas de registro. Un ID de sesión que aparece en cada tipo de evento hace posible unir registros entre categorías y responder “¿qué sucedió en esta ejecución específica?”.
Eventos del ciclo de vida a registrar:
| Evento | Campos clave |
|---|---|
| Creación de sesión | ID de sesión, ID de usuario/inquilino, nombre de plantilla o imagen, configuración de recursos, marca de tiempo |
| Inicio de sesión | ID de sesión, identificador de host, límites de recursos asignados, marca de tiempo |
| Pausa de sesión | ID de sesión, motivo (llamada API, tiempo de espera, pausa automática), marca de tiempo |
| Reanudación de sesión | ID de sesión, actor que reanuda, marca de tiempo |
| Terminación de sesión | ID de sesión, motivo de terminación (normal, tiempo de espera, OOM, llamada API, violación de política), estado de salida, marca de tiempo |
| Limpieza de sesión | ID de sesión, estado del sistema de archivos en la limpieza (preservado, eliminado, instantánea guardada), marca de tiempo |
El motivo de terminación es especialmente útil después de un incidente. Una sesión que terminó debido a una violación de política, un kill por OOM o una señal inesperada en lugar de una salida limpia vale la pena examinarla más de cerca. Las sesiones que se pausaron y reanudaron vale la pena examinarlas por continuidad de estado: ¿cambió algo en el entorno entre la pausa y la reanudación?
Eventos de límites de recursos
Los eventos de límites de recursos capturan momentos en que una sesión alcanzó un techo configurado y el sistema tomó medidas. Estos eventos señalan comportamiento normal de alta carga o algo más preocupante: un proceso descontrolado, un estallido de cómputo inesperado o un intento deliberado de agotar recursos.
Las entradas de registro para eventos de límites de recursos deben incluir: el tipo de límite (aceleración de CPU, OOM de memoria, cuota de disco, límite de tasa de red, tiempo de espera), el valor medido en el momento del evento, el límite configurado, la acción tomada (acelerar, matar, advertir), el proceso o sesión afectado y la marca de tiempo.
Los kills por OOM son particularmente dignos de examinar porque pueden indicar que un agente intentó un cómputo grande que no se esperaba, que un paquete cargó datos inesperadamente grandes o una fuga de memoria. Los eventos de aceleración de CPU en una sesión que solo debería estar haciendo llamadas ligeras de LLM pueden indicar que algo más se está ejecutando dentro del sandbox.
Formatos de registro estructurados vs. no estructurados
Los registros no estructurados —líneas de texto libre como 2026-06-29 10:04:00 INFO: proceso python iniciado — son legibles pero difíciles de consultar, agregar o integrar con un SIEM o un pipeline de alertas. Para fines de auditoría, requieren análisis que se rompe cuando cambia el formato del registro.
Los registros estructurados —típicamente JSON o un formato de esquema común como CEF u OCSF— permiten que cada campo sea indexado, consultado y alertado directamente. Un evento execve estructurado que incluya {"ts": "2026-06-29T10:04:00.123Z", "event": "process.exec", "session_id": "...", "pid": 1234, "ppid": 1, "uid": 0, "cmd": "curl", "args": ["-s", "https://..."], "exit_code": 0} es consultable inmediatamente por cualquiera de sus campos.
Para los equipos de seguridad que evalúan un proveedor de sandbox, las preguntas clave son:
- ¿Los registros son estructurados o no estructurados?
- ¿Qué esquema o formato se utiliza y está documentado?
- ¿Se pueden transmitir los registros en tiempo real a un SIEM externo o sistema de agregación de registros?
- ¿Cuál es la latencia entre un evento y su disponibilidad en el flujo de registros?
La transmisión en tiempo real o casi en tiempo real es importante para los casos de uso de detección. Un registro que solo está disponible horas después de que termina una sesión es útil para la reconstrucción de incidentes, pero no para alertas en vivo.
Integridad del registro y evidencia de manipulación
Un registro de auditoría que el agente pueda modificar no es un registro de auditoría. Este es el requisito de evidencia de manipulación: el registro debe generarse y almacenarse de manera que el proceso del agente no pueda alterar, eliminar o suprimir sus propias entradas.
A nivel de implementación, esto generalmente significa:
- Generación de registros a nivel de kernel (subsistema de auditoría, eBPF) en lugar de registro a nivel de aplicación dentro del sandbox
- Envío de registros a un destino externo al que el proceso del sandbox no pueda acceder
- Almacenamiento de registros de solo escritura o solo anexión sin API de eliminación accesible desde la red del sandbox
- Entradas de registro firmadas o con checksum en el momento de la generación para que la manipulación o truncamiento sea detectable después del hecho
Para proveedores de sandbox gestionados, la pregunta relevante es si el proceso del agente tiene alguna ruta para modificar la entrega de registros. Si los registros se escriben en un archivo dentro del sandbox y luego se envían, un proceso de agente suficientemente privilegiado puede interferir con el envío. Si los registros se generan a nivel de hipervisor o host y se envían fuera de banda, el agente no tiene acceso.
La cadena de custodia para los datos de registro —particularmente importante para cumplimiento o revisión legal— requiere que la ruta de recolección de registros, los controles de acceso al almacenamiento y cualquier transformación aplicada a los eventos en bruto estén documentados y sean auditables en sí mismos.
Políticas de retención de registros de auditoría para sandboxes de agentes de IA
Los requisitos de retención para los registros de auditoría de sandboxes de agentes de IA dependen del entorno regulatorio, el perfil de riesgo de las cargas de trabajo y el cronograma de respuesta a incidentes que el equipo de seguridad necesita respaldar.
Puntos de partida prácticos para que los equipos de seguridad evalúen:
| Caso de uso | Retención mínima sugerida |
|---|---|
| Investigación activa de incidentes | Consultable en caliente durante al menos 90 días |
| Forense posterior a incidentes | Disponible en almacenamiento frío durante 12–24 meses |
| Revisión de cumplimiento (SOC 2, ISO 27001) | Según los requisitos del marco aplicable |
| Retención legal | Hasta que se libere explícitamente |
Para cargas de trabajo de agentes de IA, 90 días de almacenamiento en caliente es una línea base significativa porque los patrones de compromiso en agentes autónomos pueden no descubrirse de inmediato —un agente que exfiltró datos durante una sesión hace tres semanas puede no ser identificado hasta que se note una anomalía posterior.
El volumen es un factor de costo real. Un sandbox que ejecuta miles de sesiones por día con registro completo de execve y red puede generar datos significativos. El almacenamiento por niveles —caliente para datos recientes, templado para mediano plazo, frío para archivo— es un enfoque común. La compresión y el filtrado a nivel de campo (registrar solo tipos de eventos de alta prioridad con fidelidad completa) también vale la pena considerarlos, con la compensación de que los registros filtrados pueden perder tipos de eventos inesperados.
Presentación de registros para respuesta a incidentes
Recolectar registros es necesario pero no suficiente. Los registros que permanecen en un bucket que nadie consulta no ofrecen protección. Para los equipos de seguridad, el requisito operativo es poder responder preguntas específicas rápidamente:
- ¿Qué hizo la sesión X entre el tiempo T1 y T2?
- ¿Qué sesiones accedieron a la ruta P?
- ¿Qué sesiones hicieron conexiones salientes al dominio D?
- ¿Qué sesiones instalaron el paquete V?
- ¿Qué sesiones terminaron con el motivo R?
Esto requiere una interfaz de consulta —ya sea una integración con SIEM, una plataforma de análisis de registros o una API proporcionada por el proveedor— donde el ID de sesión, el tipo de evento, el rango de tiempo, la ruta, el dominio y otros campos clave estén indexados y sean buscables.
Las alertas sobre patrones específicos son la segunda capa. Las señales de alta prioridad para sandboxes de agentes de IA incluyen: ejecución de comandos peligrosos conocidos (curl | bash, wget -O - | sh, base64 -d | sh), conexiones salientes a dominios inesperados o recién registrados, instalaciones de paquetes desde URL que no son de registro, eventos de escritura en rutas de archivos de credenciales, sesiones que terminan con violación de política o kill OOM, y cualquier evento que ocurra bajo UID 0 cuando el agente no debería estar ejecutándose como root.
Las reglas de detección preconstruidas calibradas para patrones de comportamiento de sandboxes de agentes reducen el tiempo hasta la primera alerta para actividad novedosa. Los equipos de seguridad que evalúan proveedores de sandbox deben preguntar si el proveedor proporciona reglas de detección, documentación del esquema de registro e integraciones de SIEM de muestra, o si construir esa capa queda completamente a cargo del cliente.
Qué preguntar a su proveedor de sandbox
Al evaluar un sandbox de agente de IA para la cobertura de registros de auditoría, estas son las preguntas concretas que vale la pena hacer a un proveedor:
- ¿Qué categorías de eventos se registran por defecto y cuáles requieren configuración?
- ¿Los registros se generan a nivel de kernel/hipervisor o dentro del proceso del sandbox?
- ¿Qué formato de registro estructurado se utiliza y está el esquema documentado públicamente?
- ¿Se pueden transmitir los registros en tiempo real a un destino externo?
- ¿Cuál es la política de retención de datos y se puede extender?
- ¿Tiene el proceso del sandbox alguna ruta para modificar o suprimir sus propias entradas de registro?
- ¿Están las entradas de registro firmadas o son de alguna manera a prueba de manipulaciones?
- ¿Hay una API de consulta o integración con SIEM disponible?
- ¿Hay reglas de detección preconstruidas o plantillas de alertas para patrones comunes de amenazas en sandboxes?
Ninguna implementación de sandbox está completa en cuanto al registro de forma predeterminada. Las brechas entre lo que un proveedor recopila y lo que un equipo de seguridad necesita para reconstruir un incidente son comunes. Identificar esas brechas antes de la implementación, en lugar de después de un incidente, es el beneficio práctico de este tipo de evaluación.
Novita Agent Sandbox proporciona eventos del ciclo de vida de la sesión, registros de ejecución y métricas de recursos accesibles a través de su API. Los equipos de seguridad que evalúan Novita Agent Sandbox deben verificar la cobertura de registro actual, las opciones de exportación y la configuración de retención en la documentación del producto antes de tomar decisiones de arquitectura.
Conclusión
El registro de auditoría para sandboxes de agentes de IA no es una característica que se pueda agregar después de un incidente. Las categorías de eventos que importan —ejecución de procesos, acceso al sistema de archivos, tráfico de salida, instalaciones de paquetes, invocaciones de herramientas, ciclo de vida de la sesión y límites de recursos— deben estar en alcance antes de que una carga de trabajo entre en producción, y la ruta de recolección de registros debe estar fuera del alcance del agente.
La lista de verificación práctica para los equipos de seguridad es sencilla: identificar qué categorías de eventos captura su proveedor de sandbox por defecto, confirmar que los registros se generan a nivel de kernel o hipervisor en lugar de dentro del proceso del agente, verificar que la salida estructurada esté disponible para la integración con SIEM y establecer políticas de retención antes de que las necesite para una investigación.
Las brechas en cualquiera de estas áreas son brechas en su capacidad para responder “¿qué hizo este agente?” — y para agentes autónomos que operan a escala, esa pregunta eventualmente necesitará una respuesta.
FAQ
¿Qué eventos deberían capturar los registros de auditoría de un sandbox de agente de IA?
Como mínimo: ejecución de comandos y procesos (con listas completas de argumentos), lecturas/escrituras/eliminaciones del sistema de archivos, conexiones de red salientes y consultas DNS, eventos de instalación de paquetes con URL de origen y hashes, invocaciones de herramientas y estado del resultado, eventos del ciclo de vida de la sesión (crear, pausar, reanudar, terminar, limpiar) y eventos de límites de recursos (aceleración de CPU, kill OOM, tiempo de espera). La falta de cualquiera de estas categorías deja puntos ciegos que no se pueden reconstruir después del hecho.
¿Por qué no puedo confiar en el registro a nivel de aplicación dentro del sandbox?
Un proceso de agente que controla su propio registro puede suprimir o modificar entradas sobre su propio comportamiento —intencionalmente o por un error. La recolección a nivel de kernel (a través de auditd, eBPF o instrumentación del hipervisor) genera entradas de registro por debajo de la capa de aplicación, donde el agente no tiene acceso de escritura. Este es el requisito de evidencia de manipulación: el registro debe generarse en una ubicación a la que el agente no pueda acceder.
¿Cuánto tiempo deben retenerse los registros de auditoría de sandboxes de agentes de IA?
Una línea base práctica: 90 días en almacenamiento caliente consultable para investigación activa, 12–24 meses en almacenamiento frío para forense posterior a incidentes. Los marcos de cumplimiento como SOC 2 e ISO 27001 tienen sus propios requisitos que pueden anular estas líneas base. Para retenciones legales, la retención debe continuar hasta que el asesor legal la libere explícitamente.
¿Cuál es la diferencia entre registros de auditoría estructurados y no estructurados?
Los registros no estructurados son líneas de texto libre que requieren análisis para consultar. Los registros estructurados utilizan un esquema consistente (JSON, CEF, OCSF) donde cada campo es indexado y consultable directamente. Para las operaciones de seguridad, los registros estructurados son significativamente más fáciles de integrar con plataformas SIEM, escribir reglas de detección y consultar durante la respuesta a incidentes.
¿Puede un agente de IA manipular sus propios registros de auditoría?
Depende de dónde se generen y almacenen los registros. Si los registros se escriben en un archivo dentro del sandbox y se envían externamente, un proceso de agente privilegiado puede interferir con el pipeline de envío. Si los registros se generan a nivel de hipervisor o host y se escriben directamente en un destino externo al que la red del sandbox no puede acceder, el agente no tiene ruta para modificarlos. Siempre verifique la arquitectura de recolección de registros, no solo el formato del registro.
¿Qué debo buscar en la documentación de registros de auditoría de un proveedor de sandbox?
Confirme: qué categorías de eventos se registran por defecto versus las que requieren configuración; si los registros se generan a nivel de kernel/hipervisor o dentro del proceso del sandbox; qué formato y esquema estructurado se utiliza; si se admite la transmisión en tiempo real a sistemas externos; cuál es la política de retención predeterminada y si se puede extender; y si hay reglas de detección preconstruidas o integraciones con SIEM disponibles.
