Lista de verificación de límites de aislamiento de sandbox para agentes de IA en revisiones de seguridad

Una revisión de aislamiento del sandbox de un agente de IA debe verificar el límite de ejecución, la exposición del sistema de archivos, los controles de procesos y recursos, la política de red y DNS, el comportamiento de descarga de paquetes, el manejo de secretos, los registros, la captura de artefactos, la semántica de reinicio, los puntos de aprobación humana y los supuestos de respuesta a incidentes antes de que el código generado pueda ejecutarse contra sistemas o datos reales.

Por qué son importantes las revisiones de aislamiento de agentes de IA

Las revisiones de sandbox tradicionales a menudo comienzan con una pregunta: ¿puede este sistema ejecutar código no confiable sin exponer el host? Las revisiones de agentes de IA necesitan esa pregunta, pero también necesitan una lista de verificación más amplia porque los agentes hacen más que ejecutar un solo script. Pueden clonar repositorios, instalar paquetes, navegar por sitios, escribir archivos, llamar a APIs, abrir sesiones GUI, reintentar comandos fallidos y convertir la salida del modelo en acciones de shell.

Eso cambia el modelo de riesgo. Un agente de codificación puede comportarse como un ingeniero junior con acceso a terminal. Un agente de análisis de datos puede comportarse como un usuario de notebook que sube archivos, descarga paquetes y exporta gráficos. Un agente de navegador puede comportarse como un usuario con cookies, descargas, capturas de pantalla y acciones de relleno de formularios. Un agente de aprendizaje por refuerzo o evaluación puede ejecutar la misma tarea miles de veces, lo que hace que las pequeñas brechas en la salida de datos, recursos o registros sean importantes a escala.

Utilice la lista de verificación a continuación para revisar el límite antes de conectar un sandbox a repositorios confidenciales, datos de clientes, APIs internas, credenciales privilegiadas o sistemas de despliegue en producción.

Seguridad del límite de ejecución

Comience con el límite que separa la carga de trabajo del agente del host y de otros inquilinos. La revisión debe ser lo suficientemente explícita como para que un ingeniero de seguridad pueda describir qué falla si el agente ejecuta código hostil.

Verifique:

• ¿Qué capa de aislamiento se utiliza: contenedor, microVM, VM completa, mediación de llamadas al sistema como gVisor, sandboxing de Kubernetes u otro modelo?
• ¿Cada sandbox tiene su propio límite de kernel o comparte el kernel del host?
• ¿Están separados CPU, memoria, sistema de archivos, tabla de procesos, pila de red y acceso a dispositivos de otras cargas de trabajo?
• ¿Puede el sandbox acceder a sockets del runtime de contenedores, espacios de nombres de procesos del host, rutas del host, servicios de metadatos en la nube o dispositivos privilegiados?
• ¿Cómo se colocan las sesiones de navegador, los escritorios GUI, los flujos VNC y los intérpretes de código dentro del mismo límite?
• ¿Cuál es el supuesto documentado de escape del host: contención, reducción de riesgo o una garantía más fuerte?

Evite aceptar una declaración genérica de “sandbox seguro” como respuesta completa. Pregunte por el mecanismo de aislamiento concreto, qué hay dentro del límite, qué hay fuera y qué supuestos aún necesitan controles compensatorios.

Seguridad del sistema de archivos y montajes

Los sistemas de archivos de los agentes merecen una revisión separada porque los agentes a menudo crean, editan y exfiltran archivos como parte del trabajo normal. La parte riesgosa no es solo el acceso de lectura/escritura; es la transferencia accidental entre tareas y el acceso implícito a archivos del proyecto que el usuario no pretendía compartir.

Verifique:

• ¿El sistema de archivos predeterminado está vacío, basado en plantillas o precargado con archivos del proyecto?
• ¿Qué rutas son editables por el agente y cuáles son de solo lectura?
• ¿Se montan directorios del host, montajes de repositorios, claves SSH, cachés de paquetes, perfiles de navegador o archivos de configuración de la nube dentro del sandbox?
• ¿Puede el agente atravesar enlaces simbólicos o montajes bind en rutas no previstas?
• ¿El acceso a archivos está limitado por sandbox, por usuario, por proyecto o por organización?
• ¿Los archivos subidos se eliminan, retienen, se crean instantáneas o se ponen a disposición de sesiones posteriores?
• ¿Los archivos generados y los diffs se pueden revisar antes de que salgan del sandbox?

Para agentes de codificación, el patrón más seguro suele ser un espacio de trabajo de proyecto estrecho, exportación explícita de artefactos y sin acceso ambiental a los directorios de inicio del desarrollador o almacenes de credenciales compartidos.

Controles de procesos y recursos

Un agente puede crear un fork bomb por accidente, colgar una compilación, llenar un disco, ejecutar un servidor en segundo plano o seguir reintentando un comando costoso. Los controles de recursos convierten esas fallas en fallas acotadas.

Verifique:

• ¿Se aplican límites de CPU, memoria, disco, descriptores de archivos, número de procesos y tiempo de ejecución?
• ¿Hay una duración máxima de tiempo de reloj para comandos y sesiones?
• ¿Pueden los procesos en segundo plano sobrevivir después de que termine un comando?
• ¿Se eliminan los procesos hijos cuando se detiene o reinicia el sandbox?
• ¿Puede el agente abrir puertos de escucha y, de ser así, esos puertos se exponen solo a través de un mecanismo de vista previa explícito?
• ¿El stdout/stderr grande se trunca, se transmite o se almacena?
• ¿Las fallas de cuota son visibles para la persona que llama en lugar de reintentarse silenciosamente?

Para flujos de trabajo de agentes en producción, los límites deben ser parte del contrato de la API, no solo un concepto de facturación. El equipo de seguridad debe saber qué sucede cuando un agente alcanza un límite y si la falla deja un estado parcial atrás.

Controles de red y salida de datos

La política de red es donde muchas revisiones de sandbox se vuelven demasiado vagas. Algunas cargas de trabajo de agentes necesitan acceso a Internet; otras no deberían tenerlo por defecto. La respuesta correcta depende de si el sandbox está ejecutando pruebas, navegando por páginas públicas, descargando paquetes, llamando a APIs internas o procesando datos confidenciales.

Verifique:

• ¿El acceso a Internet saliente está habilitado por defecto?
• ¿Se puede deshabilitar el acceso a la red por sandbox, por plantilla o por proyecto?
• ¿Hay listas de permitidos de salida disponibles para dominios, rangos IP, puertos o protocolos?
• ¿Está bloqueado el acceso a los puntos finales de metadatos de la nube?
• ¿Puede el sandbox llegar a VPC privadas, servicios internos, bases de datos o sistemas de despliegue?
• ¿El tráfico del navegador, el tráfico de CLI, el tráfico del administrador de paquetes y las conexiones de socket directas se rigen por la misma política?
• ¿Las solicitudes salientes se registran con marca de tiempo, destino, contexto de proceso o comando, y estado de respuesta?

Trate la salida de datos del agente como la salida de datos del sistema de compilación. Si el agente puede instalar paquetes, subir artefactos, llamar a webhooks o navegar por sitios arbitrarios, la revisión debe cubrir tanto el comportamiento malicioso como el comportamiento impulsado por inyección de indicaciones.

Riesgos de DNS y acceso a paquetes

DNS y los administradores de paquetes son fáciles de pasar por alto porque parecen infraestructura de plomería. Para los agentes, son parte de la superficie de ejecución. Un script generado puede codificar datos en consultas DNS, descargar un paquete con nombre tipográfico similar o extraer un script de una URL que nunca fue revisada.

Verifique:

• ¿El tráfico DNS sigue la misma política de salida que HTTP y HTTPS?
• ¿Las consultas DNS se registran, filtran o fuerzan a través de resolvedores controlados?
• ¿Los administradores de paquetes pueden acceder a repositorios públicos por defecto?
• ¿Los repositorios de paquetes están en listas de permitidos, proxy, en caché o fijados?
• ¿Se capturan los nombres, versiones, URL, hashes y cambios en el archivo de bloqueo de los paquetes instalados?
• ¿Puede el agente ejecutar scripts de instalación, hooks de post-instalación o pasos de compilación de paquetes arbitrarios?
• ¿Hay un portal de revisión antes de que las nuevas dependencias se persistan en una plantilla o flujo de trabajo de producción?

Si se requiere acceso a paquetes, prefiera versiones fijadas, archivos de bloqueo, listas de permitidos de repositorios y registros que permitan a los revisores reconstruir lo que se descargó y ejecutó.

Manejo de secretos

Los secretos suelen ser la forma más rápida de que un límite de sandbox se vuelva irrelevante. Si un agente ve un token amplio, puede filtrar datos sin escapar del host.

Verifique:

• ¿Los secretos se inyectan solo cuando una tarea los necesita explícitamente?
• ¿Los secretos están limitados al sandbox, tarea, repositorio, entorno y tiempo de vida?
• ¿Se pueden leer los secretos desde variables de entorno, archivos, historial de shell, listas de procesos, registros, capturas de pantalla o almacenamiento del navegador?
• ¿Los registros y artefactos se redactan antes de almacenarlos o exportarlos?
• ¿Se utilizan tokens de corta duración en lugar de credenciales de larga duración?
• ¿Puede el agente acceder a claves SSH de nivel de usuario, credenciales de Git, credenciales de la nube, cookies del navegador o claves de API desde el host?
• ¿El acceso a secretos es visible en los registros de auditoría?

Una regla práctica: si un humano no pegaría una credencial en un trabajo de compilación no confiable, no se la dé a un agente autónomo sin un alcance más limitado y un registro más sólido.

Registros y pistas de auditoría

Los equipos de seguridad necesitan más que éxito o fracaso. Necesitan saber qué código se ejecutó, qué archivos cambiaron, qué llamadas de red ocurrieron y qué salidas se produjeron.

Verifique:

• ¿Las invocaciones de comandos se registran con argumentos, directorio de trabajo, código de salida, hora de inicio y duración?
• ¿Se registran las lecturas, escrituras, eliminaciones, subidas, descargas y cambios de permisos de archivos?
• ¿Se registran las instalaciones de paquetes y las descargas externas?
• ¿Se capturan las acciones del navegador, capturas de pantalla, descargas y envíos de formularios cuando corresponda?
• ¿Las llamadas a la API, las invocaciones de herramientas y las transiciones de modelo a herramienta se correlacionan con la misma sesión?
• ¿Los registros son resistentes a manipulaciones desde dentro del sandbox?
• ¿Cuál es el período de retención y quién puede acceder a los registros?

Para flujos de trabajo regulados o empresariales, la pista de auditoría debe respaldar tanto la depuración como la reconstrucción posterior a incidentes. Una transcripción de terminal parcial generalmente no es suficiente.

Captura y revisión de artefactos

Los agentes crean resultados útiles: diffs, resultados de pruebas, informes, capturas de pantalla, archivos generados, URL de vista previa y conjuntos de datos. El manejo de artefactos debe hacer que esos resultados sean revisables sin exponer más estado del necesario.

Verifique:

• ¿Qué artefactos se exportan automáticamente y cuáles requieren selección explícita?
• ¿Pueden los revisores inspeccionar los archivos generados antes de que se confirmen, suban o envíen a otro servicio?
• ¿Se escanean los artefactos en busca de secretos, malware, tipos de archivo no seguros o tamaño inesperado?
• ¿Las descargas del navegador se almacenan por separado de los diffs de código fuente y los resultados de pruebas?
• ¿Se pueden vincular los artefactos al comando, paso de agente y sesión de sandbox exactos que los produjeron?
• ¿Se retienen los artefactos después de la eliminación del sandbox y se pueden purgar?

El objetivo es preservar evidencia útil mientras se evita un segundo canal de fuga de datos a través de registros, capturas de pantalla, archivos o paquetes generados.

Controles de ciclo de vida y reinicio

Las sesiones de agente pueden ser de corta duración, de larga duración, pausadas, reanudadas, con instantáneas o clonadas a partir de plantillas. Cada modo de ciclo de vida cambia el límite.

Verifique:

• ¿Cada sandbox se crea fresco, se reanuda desde un estado o se clona a partir de una plantilla?
• ¿Qué datos sobreviven a la pausa, reanudación, instantánea, creación de plantilla y eliminación?
• ¿Se borran los archivos temporales, cachés de paquetes, historial de shell, cookies del navegador y bases de datos locales al reiniciar?
• ¿Puede una sesión comprometida envenenar una plantilla reutilizable?
• ¿Hay un tiempo de vida máximo de sesión?
• ¿Los sandboxes detenidos están realmente terminados o pueden continuar las tareas en segundo plano?
• ¿Se puede reproducir la misma tarea desde un entorno limpio?

La capacidad de reinicio también es importante para cargas de trabajo de evaluación y aprendizaje por refuerzo. Si cada prueba comienza desde un estado ligeramente diferente, los hallazgos de seguridad y el comportamiento del modelo se vuelven más difíciles de confiar.

Controles de aprobación humana

La aprobación humana no es solo una característica de UX. Es un plano de control para acciones que cruzan límites de confianza.

Verifique:

• ¿Qué acciones pueden ejecutarse de forma autónoma y cuáles requieren aprobación?
• ¿Las indicaciones de aprobación son lo suficientemente específicas como para mostrar el comando, archivos, destino, alcance de credenciales y efecto esperado?
• ¿Pueden las políticas requerir aprobación para instalaciones de paquetes, acceso a red externa, escrituras en repositorios, comandos de despliegue o acceso a secretos?
• ¿Las aprobaciones se registran con usuario, marca de tiempo, acción y comando resultante?
• ¿Las aprobaciones pueden ser limitadas en el tiempo y en la tarea en lugar de otorgar un permiso futuro amplio?
• ¿Hay una ruta de emergencia y está auditada?

Utilice la aprobación humana para acciones irreversibles o de alto impacto: eliminar archivos, escribir en ramas de producción, llamar a APIs de despliegue, acceder a datos de clientes y cambiar plantillas de sandbox.

Supuestos de respuesta a incidentes

Ninguna revisión de sandbox está completa sin preguntar qué sucede cuando un límite falla o un flujo de trabajo se comporta inesperadamente. Esto es especialmente importante para los sistemas de agentes porque una acción riesgosa puede ser causada por la salida del modelo, inyección de indicaciones, compromiso de dependencias o errores de software comunes.

Verifique:

• ¿Quién es dueño del triaje cuando se sospecha que un sandbox está filtrando datos o ejecutando código hostil?
• ¿Se pueden eliminar, poner en cuarentena o bloquear los sandboxes por proyecto u organización?
• ¿Se puede deshabilitar rápidamente la salida de red?
• ¿Se preservan los registros y artefactos para la investigación?
• ¿Se invalidan las plantillas, cachés de paquetes e instantáneas afectadas?
• ¿Se rotan las credenciales automáticamente o mediante un runbook documentado?
• ¿Hay una distinción clara entre un problema de contención de sandbox y un problema de política de agente?

La revisión debe terminar con un modelo de amenazas escrito y un runbook breve. Incluso si la decisión final es “aprobado solo para cargas de trabajo no sensibles”, ese límite es útil.

Cómo encaja Novita Agent Sandbox

Novita Agent Sandbox está diseñado para código generado por IA, flujos de trabajo de navegador, uso de computadora, evaluaciones, entornos de aprendizaje por refuerzo y tareas de larga duración. La página del producto describe sandboxes aislados, inicio en subsegundos, sesiones persistentes, visualización de sesiones en vivo basada en VNC, precios basados en uso, plantillas y soporte de sistema de archivos aislado. La guía de inicio rápido de Novita Agent Sandbox muestra la creación de sandboxes basada en SDK, ejecución de comandos, listado de archivos y apagado de sandbox.

Esas capacidades pueden respaldar muchos de los flujos de trabajo de esta lista de verificación, pero los criterios de evaluación y las afirmaciones del producto deben mantenerse separados. Cuando su equipo revise Novita Agent Sandbox, o cualquier otro runtime de agente, mapee la configuración en vivo que planea usar contra los controles anteriores: límite, archivos, límites de procesos, red, DNS, descargas de paquetes, secretos, registros, artefactos, ciclo de vida, aprobación y respuesta a incidentes.

Para los equipos de ingeniería que ya usan las APIs de modelos de Novita AI, combinar la inferencia de modelos con la ejecución de sandbox puede reducir la proliferación de plataformas para cargas de trabajo de agentes. Para uso de producción sensible a la seguridad, aún realice una revisión específica de la carga de trabajo antes de conectar el sandbox a repositorios privados, conjuntos de datos confidenciales, servicios internos o credenciales de despliegue.

Conclusión

Apruebe un sandbox de agente de IA solo después de que la revisión pueda responder tres preguntas claramente: qué está aislado, qué puede salir del límite y qué evidencia queda si algo sale mal. Si esas respuestas son vagas, limite el sandbox a cargas de trabajo no sensibles hasta que los controles faltantes estén documentados y probados.

Preguntas frecuentes

¿Qué debe verificar primero un equipo de seguridad en una revisión de sandbox de agente de IA?

Comience con el límite de ejecución, la exposición del sistema de archivos y los valores predeterminados de red. Estos tres controles determinan si el código hostil puede llegar al host, a archivos confidenciales o a destinos externos antes de que siquiera llegue a detalles específicos del flujo de trabajo como aprobaciones y exportación de artefactos.

¿Es suficiente un sandbox solo de contenedor para agentes de codificación autónomos?

Depende de la carga de trabajo y los datos a los que pueda acceder. Un contenedor puede ser aceptable para tareas de baja sensibilidad con montajes ajustados, política de salida estricta, credenciales de corta duración y registro sólido, pero los equipos de seguridad deben tomar esa decisión basándose en controles documentados y no solo en la palabra “contenedor”.

¿Por qué se debe revisar el acceso a DNS y paquetes por separado de la salida general?

Porque los agentes a menudo instalan dependencias y resuelven hosts externos como parte de la operación normal. Las consultas DNS y las descargas de paquetes pueden convertirse tanto en una ruta de exfiltración de datos como en un riesgo de la cadena de suministro si no se registran, filtran o restringen.

Artículos recomendados:

• Cómo los sandboxes de agentes impulsan la innovación segura y escalable en IA
• Creación de un agente de codificación con Novita Agent Sandbox
• Novita vs E2B: La comparación definitiva de sandboxes para agentes para desarrolladores y empresas