¿Qué tan seguro es el sandbox de IA para ejecutar código?

Un sandbox de IA para ejecutar código es tan seguro como su límite de aislamiento — y el límite de aislamiento es solo parte de la respuesta. La mejor pregunta es: ¿qué aísla realmente el sandbox y qué puede aún escapar? La mayoría de los sandboxes detienen bien algunas cosas (ejecución de código a nivel de proceso, escrituras arbitrarias en el sistema de archivos del host) y dejan otras cosas abiertas por defecto (red saliente, instalación de paquetes, secretos en variables de entorno). Comprender esas brechas es cómo evalúas si un sandbox se ajusta a tu modelo de riesgo.

Qué significa “seguro” para un sandbox de ejecución de código

La seguridad en un sandbox de ejecución de código no es una propiedad binaria. Es un conjunto de controles, cada uno aborda una categoría específica de riesgo. Cuando alguien pregunta “¿este sandbox es seguro?” generalmente está haciendo varias preguntas distintas a la vez:

• Aislamiento del host: ¿Puede el código que se ejecuta dentro del sandbox escapar al sistema host?
• Aislamiento de inquilinos: ¿Puede el código de un usuario afectar la sesión de otro usuario?
• Control de salida: ¿Puede el código dentro del sandbox alcanzar internet, servicios internos o puntos finales de metadatos?
• Alcance de secretos: ¿Las credenciales son accesibles a más partes del sandbox de lo necesario?
• Riesgo de cadena de suministro: ¿Pueden las instalaciones de paquetes introducir código inesperado o malicioso?
• Auditabilidad: ¿Puedes reconstruir lo que el agente realmente hizo después del hecho?

Un sandbox puede ser fuerte en aislamiento del host y débil en salida. Fuerte en salida y débil en secretos. Evaluar “qué tan seguro” requiere verificar cada dimensión por separado, no aceptar una sola etiqueta como “contenedorizado” o “basado en microVM” como la respuesta completa.

Comparación de capas de aislamiento

Hay tres modelos principales de aislamiento utilizados en sandboxes de ejecución de código de IA. Cada uno proporciona un límite diferente.

Aislamiento de procesos

El aislamiento de procesos utiliza primitivas a nivel de sistema operativo — namespaces de Linux, cgroups, filtros seccomp y perfiles AppArmor o SELinux — para restringir lo que un proceso puede acceder. El sandbox se ejecuta como un proceso en el sistema operativo host, compartiendo el kernel del host.

Qué previene: Acceso al sistema de archivos más amplio, otros procesos fuera del sandbox y syscalls explícitamente bloqueadas por la política seccomp.

Qué no previene: Exploits del kernel que escalan privilegios a través de una vulnerabilidad compartida. Una evasión de seccomp o una vulnerabilidad del kernel pueden cruzar el límite del host.

Cuándo es apropiado: Código de corta duración, bajo riesgo y relativamente confiable donde la velocidad de inicio y la portabilidad importan más que un límite duro de VM. No se recomienda para ejecutar código arbitrario generado por agentes de usuarios externos.

Aislamiento de contenedores (Docker/namespaces)

El aislamiento de contenedores extiende el aislamiento de procesos con un modelo de imagen más estructurado, namespacing de red y montajes de volúmenes. La mayoría de las implementaciones de sandbox basadas en Docker ejecutan código dentro de un contenedor con una imagen mínima y un perfil seccomp restringido.

Qué previene: Acceso directo al sistema de archivos del host, la mayoría del acceso de red a contenedores adyacentes (cuando se configura correctamente), fácil acceso a procesos del host.

Qué no previene: Los exploits a nivel de kernel aún se aplican — los contenedores comparten el kernel del host. Montajes de volúmenes mal configurados, perfiles seccomp demasiado amplios, modo --privileged y sockets Docker expuestos pueden anular el límite previsto.

Cuándo es apropiado: Muchos despliegues de producción utilizan contenedores de manera efectiva para ejecución de código de IA cuando el perfil seccomp es estricto, la imagen es mínima, la salida está restringida y no se otorga acceso privilegiado. El modelo de riesgo es diferente al de las microVM pero manejable con una configuración cuidadosa.

Aislamiento de microVM (Firecracker/gVisor)

El aislamiento de microVM ejecuta cada sandbox en una máquina virtual ligera con su propio kernel invitado, aislado del host por un límite de hipervisor KVM. Firecracker es la implementación más común; gVisor (con su kernel en espacio de usuario) ofrece una compensación diferente.

Qué previene: Los exploits del kernel invitado no se propagan al kernel del host ni a otros invitados. La superficie de ataque del host se reduce al VMM (monitor de máquina virtual), que está diseñado para ser mínimo.

Qué no previene: Vulnerabilidades en el propio VMM (raro pero no imposible). Los controles de red, paquetes y secretos aún viven fuera del límite de la VM — el aislamiento de microVM no maneja esos.

Cuándo es apropiado: Ejecutar código no confiable o generado por agentes de usuarios externos, entornos multiinquilino donde el radio de explosión importa y cargas de trabajo que pueden ejecutar comandos arbitrarios de shell o scripts de instalación de paquetes.

Modelo de aislamiento	Kernel del host compartido	Separación de inquilinos	Sobrecarga de inicio	Riesgo de escape del host
Proceso	Sí	Débil	Más baja	Más alto
Contenedor	Sí	Moderada	Baja	Medio (depende de la configuración)
MicroVM	No	Fuerte	Moderada	Baja

Qué puede aún escapar de cada límite

El modelo de aislamiento aborda la ejecución de código en tiempo de ejecución. No aborda automáticamente lo que entra o sale del sandbox a través de otras rutas.

Red saliente: Los tres modelos de aislamiento dejan el acceso a la red saliente a la configuración de la política. La salida abierta por defecto significa que el código dentro del sandbox puede alcanzar internet público, puntos finales de metadatos en la nube (169.254.169.254 en AWS y GCP), servicios internos en la misma red y APIs externas arbitrarias. Eso es una ruta de exfiltración de datos, una ruta de recuperación de secretos y una ruta de comando y control independientemente del modelo de aislamiento.

Instalación de paquetes: Un apt install, pip install o npm install obtiene y ejecuta código desde un registro externo. Si el sandbox permite instalaciones de paquetes y tiene salida abierta, una colisión de nombres de paquete, un ataque de typosquatting o un ataque de confusión de dependencias puede introducir código malicioso que se ejecute con todos los permisos del sandbox. El límite de aislamiento contiene el radio de explosión pero no previene la instalación.

Estado compartido: En despliegues multiinquilino, los cachés compartidos, registros de paquetes compartidos, imágenes de plantilla compartidas o montajes de sistema de archivos compartidos crean canales entre inquilinos que evitan el límite de aislamiento.

Secretos en variables de entorno: Las variables de entorno visibles para el proceso del agente son legibles por cualquier código que ejecute el agente. Si una credencial de base de datos o una clave de API está en el entorno, es accesible para el sandbox y cualquier cosa que ejecute o instale.

Controles de salida y red

La salida es donde la mayoría de los sandboxes tienen su mayor brecha. El acceso abierto a internet saliente es común porque es conveniente — los agentes necesitan instalar paquetes, llamar APIs y obtener recursos. Pero también crea riesgos:

Puntos finales de metadatos en la nube: En infraestructura de nube alojada, 169.254.169.254 (y su equivalente IPv6) sirve metadatos de instancia incluyendo credenciales IAM. El código dentro de un sandbox con salida abierta puede alcanzar este punto final y recuperar credenciales para el host subyacente.

Exfiltración basada en DNS: Incluso si HTTP está bloqueado, las consultas DNS salientes pueden usarse para exfiltrar datos codificándolos en búsquedas de dominio. El bloqueo de DNS requiere filtrar a nivel del resolvedor, no solo bloquear TCP/UDP 53 a servidores externos.

Servicios internos: Si el sandbox se ejecuta en un segmento de red privada, la salida abierta puede permitir el acceso a bases de datos internas, paneles de administración y APIs que no están destinadas a ser accesibles desde el código del agente.

Controles a evaluar:

Control	Qué previene	Qué verificar
Salida con denegación por defecto	Conexiones salientes a destinos no listados	¿Bloquea también DNS además de TCP/UDP?
Salida basada en listas permitidas	Conexiones a dominios no aprobados	¿La lista permitida es configurable por el cliente?
Bloqueo de punto final de metadatos	Recuperación de credenciales en la nube vía 169.254.169.254	¿También se bloquea IPv6 de metadatos?
Proxy de salida	Registro e inspección de todo el tráfico saliente	¿El registro del proxy es accesible?
Filtrado de DNS	Exfiltración basada en DNS y resolución de nombres interna	¿Qué resolvedor se usa dentro del sandbox?

No existe una política de salida universalmente correcta. Algunas cargas de trabajo de agentes realmente necesitan acceso amplio a internet para ser útiles. La clave es que la política sea deliberada y auditable, no abierta por defecto porque nunca se configuró.

Manejo de secretos

Los secretos en los sandboxes de agentes de IA siguen los mismos principios que los secretos en cualquier sistema de software, con una restricción adicional: el agente puede ejecutar código que lea, registre o transmita el entorno sin intención del desarrollador.

Alcance: Monta solo las credenciales que el sandbox realmente necesita para la tarea actual. Un sandbox que ejecuta una tarea de codificación no necesita credenciales de base de datos de producción. Un sandbox que evalúa salidas de modelo no necesita la clave de API de un servicio de facturación.

Vida útil: Las credenciales de corta duración son significativamente más seguras que las de larga duración. Si una credencial se filtra dentro de un sandbox, un TTL corto limita la ventana de exposición. Muchos sistemas IAM en la nube admiten tokens de corta duración que expiran en minutos u horas.

Método de inyección: Las variables de entorno son el método de inyección más común y el más accesible para cualquier código en el proceso. Los secretos que se pueden inyectar mediante montajes del sistema de archivos, montados en una ruta que el agente no necesita recorrer, o obtenidos dinámicamente solo cuando la herramienta específica que los necesita se ejecuta, están más restringidos que un conjunto de variables de entorno general.

Redacción: Los secretos deben redactarse de stdout, stderr, cargas de respuesta de herramientas, contexto visible para el modelo y registros de auditoría. Un agente que imprime su entorno, llama a env o pasa un token a una llamada API fallida puede filtrar credenciales en registros que luego se almacenan o son visibles para los operadores.

Límites de recursos y riesgo de denegación de servicio

Un sandbox sin límites de recursos es vulnerable a cargas de trabajo de agentes que agotan CPU, memoria, disco o ancho de banda de red — ya sea por código descontrolado, un bucle infinito, una fuga de memoria en un paquete instalado o un intento deliberado de interrumpir cargas de trabajo adyacentes.

Controles de recursos a verificar:

• Límites de CPU: La limitación o los límites estrictos por sesión evitan que una sesión monopolice la capacidad del host.
• Límites de memoria: Las políticas de eliminación por OOM deben terminar la sesión del sandbox, no el proceso del host.
• Cuotas de disco: Los límites de escritura por sesión evitan que una sesión llene el almacenamiento compartido.
• Tiempo de espera de ejecución: Las sesiones que exceden un límite de tiempo real deben terminarse limpiamente, no dejarse ejecutando.
• Límites de velocidad de red: Los límites de ancho de banda saliente pueden restringir la exfiltración incluso cuando la política de salida permite el destino.
• Límites de procesos concurrentes: Los agentes que se bifurcan agresivamente o generan procesos en segundo plano pueden agotar los espacios de la tabla de procesos.

Las violaciones de límites de recursos también merecen ser registradas. Una sesión que consistentemente alcanza el límite de CPU o la eliminación por OOM durante tareas que deberían ser ligeras es una señal que vale la pena investigar.

Visibilidad de auditoría

Los controles de aislamiento reducen el radio de explosión cuando algo sale mal. Los registros de auditoría son cómo te enteras de que algo salió mal y reconstruyes lo que sucedió.

Para sandboxes de agentes de IA específicamente, la cobertura de auditoría útil incluye:

• Ejecución de procesos: Cada comando que se ejecuta, con la lista completa de argumentos, UID y proceso padre. Sin listas de argumentos, curl y python en un registro no son significativos.
• Acceso al sistema de archivos: Lecturas y escrituras en rutas sensibles. Las escrituras y eliminaciones tienen mayor prioridad que las lecturas para la mayoría de los modelos de amenaza.
• Red saliente: Destinos, protocolos, consultas DNS y bytes transferidos. El registro de consultas DNS a menudo falta pero es importante.
• Instalaciones de paquetes: Gestor de paquetes, nombre del paquete, versión, registro de origen y hash.
• Ciclo de vida de la sesión: Eventos de creación, pausa, reanudación, finalización y limpieza con códigos de motivo.
• Eventos de límite de recursos: Eliminaciones por OOM, limitación de CPU, finalización por tiempo de espera.

El mecanismo de recolección importa tanto como la cobertura. Los registros generados dentro del proceso del sandbox pueden ser suprimidos o modificados por un agente suficientemente privilegiado. La recolección a nivel de kernel (mediante auditd, eBPF o instrumentación de hipervisor) se genera por debajo de la capa de aplicación, donde el agente no tiene acceso de escritura.

Preguntas para hacer a cualquier proveedor o proyecto de sandbox

Usa esta lista de verificación al evaluar un servicio de sandbox administrado o un framework de sandbox de código abierto:

Aislamiento

• ¿Cada sesión de agente tiene su propio entorno aislado, o las sesiones se agrupan en entornos de ejecución compartidos?
• ¿Qué modelo de aislamiento se utiliza: proceso, contenedor o microVM?
• ¿El kernel invitado se comparte con el host?

Red y salida

• ¿La salida está abierta por defecto o denegada por defecto?
• ¿Se puede configurar la política de salida por inquilino o por sesión?
• ¿Está bloqueado el punto final de metadatos en la nube (169.254.169.254)?
• ¿Cómo se maneja el DNS dentro del sandbox?

Instalaciones de paquetes

• ¿Las instalaciones de paquetes están permitidas por defecto?
• ¿Se pueden limitar las instalaciones a registros aprobados?
• ¿Los eventos de instalación se registran con origen y hash?

Secretos

• ¿Cómo se inyectan las credenciales en el sandbox?
• ¿Se pueden limitar las credenciales a la herramienta o tarea específica que las necesita?
• ¿Los secretos se redactan de los registros y las salidas visibles para el modelo?

Límites de recursos

• ¿Se aplican límites de CPU, memoria, disco y tiempo de espera?
• ¿Qué sucede cuando se alcanza un límite: limitar, eliminar o alertar?

Registros de auditoría

• ¿Los registros se generan a nivel de kernel/hipervisor o dentro del proceso del sandbox?
• ¿Qué categorías de eventos se registran por defecto?
• ¿Se pueden exportar los registros a un SIEM externo o sistema de agregación de registros?
• ¿Cuál es la política de retención de registros?

Inquilinato

• ¿Las cargas de trabajo de diferentes inquilinos están aisladas entre sí?
• ¿Hay cachés, imágenes o montajes compartidos que creen canales entre inquilinos?

Dónde encaja Novita Agent Sandbox

Novita Agent Sandbox está diseñado para cargas de trabajo de agentes que necesitan entornos de ejecución aislados para código, archivos, procesos y sesiones de mayor duración. Está dirigido a equipos que construyen agentes de codificación, pipelines de evaluación, agentes de análisis de datos y flujos de trabajo de agentes basados en navegador.

El sandbox admite controles del ciclo de vida de la sesión, incluyendo pausa, reanudación y pausa automática para sesiones inactivas. Proporciona métricas de recursos y registros de ejecución a nivel de sesión accesibles a través de la API. Para equipos que ya usan APIs de modelos de Novita, puede servir como la capa de ejecución en una arquitectura de agente donde el modelo planifica y llama a herramientas, y el sandbox maneja la ejecución en tiempo de ejecución en un entorno aislado.

Al evaluar Novita Agent Sandbox para casos de uso sensibles a la seguridad, verifica el modelo de aislamiento actual, los valores predeterminados de la política de salida, la cobertura de registros y el manejo de secretos en la documentación del producto antes de tomar decisiones de arquitectura. Los requisitos de seguridad varían significativamente según la carga de trabajo — lo que es apropiado para un pipeline de evaluación interno puede no ser suficiente para un producto multiinquilino que maneja código proporcionado por el usuario.

Como con cualquier sandbox, la postura de seguridad depende tanto de los valores predeterminados de la plataforma como de tus controles a nivel de aplicación: cómo se limitan las credenciales, qué se le permite solicitar al agente, qué llamadas de herramientas requieren aprobación humana y cómo se monitorean los registros de auditoría.

Limitaciones y lo que ningún sandbox elimina

Ningún sandbox elimina todo el riesgo. Comprender lo que queda fuera del límite es tan importante como comprender lo que proporciona el límite.

Decisiones de confianza a nivel de aplicación: El sandbox controla la ejecución en tiempo de ejecución. No decide lo que el agente puede solicitar. Si tu aplicación permite que un agente solicite una credencial, ejecute comandos arbitrarios de shell o llame a cualquier API, el sandbox reduce el radio de explosión pero no previene esas acciones.

Inyección de prompts: Un agente que procesa contenido no confiable — páginas web, archivos subidos por el usuario, respuestas de APIs externas — puede ser manipulado a través de ese contenido para tomar acciones que no debería. Esto es un problema de diseño de la aplicación, no un problema del sandbox. El sandbox puede limitar dónde aterrizan esas acciones, pero la lógica de decisión vive en tu aplicación.

Vulnerabilidades de día cero: Todos los modelos de aislamiento tienen vulnerabilidades conocidas y desconocidas. El aislamiento de microVM proporciona el límite más fuerte en el uso de producción actual, pero existen vulnerabilidades de VMM. La defensa en profundidad — combinar múltiples controles en lugar de confiar en un solo límite — es una postura más robusta que cualquier modelo de aislamiento único.

Ingeniería social a través de la salida del modelo: Un agente puede producir una salida que persuada a un operador humano a tomar una acción insegura. Los sandboxes no auditan las decisiones humanas.

Riesgo de cumplimiento y regulatorio: Los controles de aislamiento abordan el riesgo técnico. Los requisitos regulatorios (GDPR, HIPAA, SOC 2, ISO 27001) abordan el manejo, retención, documentación y requisitos de auditoría de datos que se extienden más allá de lo que un sandbox proporciona a nivel de infraestructura.

La seguridad en un sandbox de ejecución de código se enmarca mejor como un conjunto de controles para evaluar y configurar, no una propiedad que adquieres al elegir un producto. Las preguntas de evaluación anteriores se aplican a cada decisión de sandbox — incluida tu propia infraestructura si estás construyendo en lugar de comprando.

Preguntas frecuentes

¿Qué tan seguro es un entorno de ejecución de código de IA en sandbox en comparación con ejecutar código en un servidor?

Un sandbox bien configurado reduce significativamente el radio de explosión de ejecutar código no confiable en comparación con ejecutarlo directamente en un servidor. Restringe el acceso al sistema de archivos, el alcance del proceso y el acceso a la red. Sin embargo, la diferencia depende de la configuración. Un contenedor con salida abierta e inyección amplia de variables de entorno puede ser menos seguro que un servidor endurecido con controles de red. El modelo de aislamiento es un punto de partida, no una garantía.

¿El aislamiento de microVM significa que un sandbox es completamente seguro?

No. El aislamiento de microVM (Firecracker, basado en KVM) proporciona un límite fuerte del host que los contenedores con kernel compartido no tienen. Pero no controla la salida, los secretos, las instalaciones de paquetes o la cobertura de auditoría. Una microVM con salida abierta y sin recolección de registros no es “completamente segura” aunque la capa de aislamiento sea fuerte.

¿Puede el código generado por IA escapar de un sandbox?

Depende del modelo de aislamiento y la configuración. Las fugas de contenedores requieren explotar el kernel o una mala configuración; las fugas de microVM requieren explotar el VMM. Ambos son posibles pero poco comunes. Los riesgos más prácticos son la exfiltración de datos a través de rutas de red permitidas, leer secretos del entorno o instalar paquetes maliciosos a través de gestores de paquetes sin restricciones.

¿Cuál es el mayor riesgo de seguridad en la mayoría de los sandboxes de código de IA?

La salida abierta hacia el exterior es el riesgo menos abordado con mayor frecuencia. Muchos sandboxes permiten acceso sin restricciones a internet saliente por defecto porque es conveniente para agentes que necesitan instalar paquetes y llamar APIs. Esto crea rutas para la exfiltración de datos, el robo de credenciales a través de puntos finales de metadatos en la nube y la comunicación de comando y control que existen independientemente de lo fuerte que sea el límite de aislamiento.

¿Debería usar un sandbox administrado o construir el mío propio?

Los sandboxes administrados manejan la complejidad operativa del ciclo de vida de microVM o contenedores, la capacidad del host y la gestión de imágenes. Construir el tuyo propio te da más control sobre toda la pila de políticas. De cualquier manera, se aplican las mismas preguntas de evaluación: política de salida, manejo de secretos, cobertura de registros, límites de recursos y exportación de auditoría. La decisión de construir vs. comprar es independiente de la evaluación de seguridad.

¿Qué hace que la seguridad del sandbox de agente sea diferente de la seguridad tradicional de ejecución de código?

La seguridad tradicional de ejecución de código supone que sabes aproximadamente qué código se ejecutará. Los agentes de IA cambian esto: un solo prompt puede hacer que una sesión instale paquetes, escriba archivos, ejecute comandos de shell, llame a APIs externas y genere subprocesos sin aprobación explícita del desarrollador para cada paso. Esto hace que la cobertura de auditoría sea más importante (no puedes anticipar cada acción), los controles de salida más importantes (el agente puede alcanzar destinos que no esperabas) y el alcance de los secretos más importante (el agente tiene acceso a todo en su entorno).

Artículos recomendados

• Firecracker para Sandboxes de Agentes de IA: Beneficios, Límites y Preguntas de Evaluación
• Registros de Auditoría para Sandboxes de Agentes de IA: Lo que los Equipos de Seguridad Necesitan
• Sandbox de Código Generado por IA: Requisitos para Aplicaciones de Producción