¿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 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 abiertas por defecto (red saliente, instalaciones de paquetes, secretos en variables de entorno). Comprender esas brechas es cómo se evalúa si un sandbox se ajusta a tu modelo de riesgo. Para obtener antecedentes sobre qué es un sandbox de agente de IA y cómo se integran los conceptos principales (aislamiento, salida, instantáneas, microVM), consulta la guía de definición antes de profundizar en los detalles de seguridad.

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 de los cuales 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 entre 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 endpoints de metadatos?
• Alcance de secretos: ¿Son accesibles las credenciales a más partes del sandbox de las necesarias?
• 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 el aislamiento del host y débil en la salida. Fuerte en la salida y débil en los secretos. Evaluar “qué tan seguro” requiere verificar cada dimensión por separado, no aceptar una sola etiqueta como “contenedorizado” o “basado en microVM” como respuesta completa.

Comparación de capas de aislamiento

Existen tres modelos principales de aislamiento utilizados en los 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 llamadas al sistema 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 omisió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, de bajo riesgo, 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, namespaces 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 aplican: los contenedores comparten el kernel del host. Los montajes de volúmenes mal configurados, los perfiles seccomp demasiado amplios, el modo --privileged y los sockets de Docker expuestos pueden anular el límite previsto.

Cuándo es apropiado: Muchos despliegues de producción utilizan contenedores de manera efectiva para la ejecución de código de IA cuando el perfil seccomp es ajustado, 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 aspectos.

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

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

Qué puede escapar aún 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, endpoints 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.

Instalaciones 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 paquetes, un ataque de typosquatting o un ataque de confusión de dependencias puede introducir código malicioso que se ejecuta 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, los registros de paquetes compartidos, las imágenes de plantilla compartidas o los montajes de sistemas de archivos compartidos crean canales entre inquilinos que eluden 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 a APIs y obtener recursos. Pero también crea riesgos:

Endpoints de metadatos en la nube: En infraestructura de nube alojada, 169.254.169.254 (y su equivalente IPv6) sirve metadatos de instancia, incluidas las credenciales de IAM. El código dentro de un sandbox con salida abierta puede alcanzar este endpoint 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 filtrado 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 privado, 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 predeterminada denegada	Conexiones salientes a destinos no listados	¿Bloquea también DNS además de TCP/UDP?
Salida basada en lista blanca	Conexiones a dominios no aprobados	¿La lista blanca es configurable por el cliente?
Bloqueo de endpoint de metadatos	Recuperación de credenciales en la nube mediante 169.254.169.254	¿También se bloquea el metadato IPv6?
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 internos	¿Qué resolución se usa dentro del sandbox?

No existe una política de salida universalmente correcta. Algunas cargas de trabajo de agentes realmente necesitan un amplio acceso 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 la 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 para 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 de 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 atravesar, o obtenidos dinámicamente solo cuando se ejecuta la herramienta específica que los necesita, 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 por el modelo y registros de auditoría. Un agente que hace eco de 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 a través de 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 duros 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 en ejecución.
• Límites de ancho de banda 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 bifurcan agresivamente o generan procesos en segundo plano pueden agotar las ranuras de la tabla de procesos.

Las violaciones de los 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 los 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, terminación y limpieza con códigos de motivo.
• Eventos de límite de recursos: Eliminaciones por OOM, límite de CPU, terminació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 del hipervisor) se genera 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. Para una comparación lado a lado de cómo los principales proveedores responden estas preguntas, consulta Mejores sandboxes de agentes de IA en 2026 o la guía de evaluación de E2B y Daytona.

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 es abierta por defecto o denegada por defecto?
• ¿Se puede configurar la política de salida por inquilino o por sesión?
• ¿Está bloqueado el endpoint de metadatos en la nube (169.254.169.254)?
• ¿Cómo se maneja el DNS dentro del sandbox?

Instalaciones de paquetes

• ¿Se permiten las instalaciones de paquetes por defecto?
• ¿Se pueden limitar las instalaciones a registros aprobados?
• ¿Se registran los eventos de instalación 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?
• ¿Se redactan los secretos de los registros y las salidas visibles por 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: limitación, eliminación o alerta?

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?

Inquilinos

• ¿Las cargas de trabajo de diferentes inquilinos están aisladas entre sí?
• ¿Existen 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 las APIs de modelo 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 a herramientas requieren aprobación humana y cómo se supervisan los registros de auditoría.

Limitaciones y lo que ningún sandbox elimina

Ningún sandbox elimina todo el riesgo. Comprender qué queda fuera del límite es tan importante como comprender qué 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 qué se le permite solicitar al agente. Si tu aplicación permite que un agente solicite una credencial, ejecute comandos de shell arbitrarios 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 aplicación, no un problema del sandbox. El sandbox puede limitar dónde terminan esas acciones, pero la lógica de decisión reside 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 actual de producción, 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 individual.

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 de datos, la retención, la documentación y los requisitos de auditoría 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 como una propiedad que se adquiere al elegir un producto. Las preguntas de evaluación anteriores se aplican a cada decisión sobre sandboxes, 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 ni 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. Los escapes de contenedores requieren explotar el kernel o una mala configuración; los escapes 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, la lectura de secretos del entorno o la instalación de 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 es el riesgo menos abordado con mayor frecuencia. Muchos sandboxes permiten el acceso a internet saliente sin restricciones por defecto porque es conveniente para agentes que necesitan instalar paquetes y llamar a APIs. Esto crea rutas para la exfiltración de datos, el robo de credenciales a través de endpoints 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 la pila de políticas completa. 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 separada de la evaluación de seguridad.

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

La seguridad tradicional de ejecución de código asume 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 la 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 secretos más importante (el agente tiene acceso a todo en su entorno).

¿Cuáles son las mejores prácticas para el aislamiento de agentes de IA en producción?

Una lista de verificación práctica de aislamiento para despliegues de agentes en producción: usa aislamiento de clase microVM (Firecracker o equivalente) en lugar de solo contenedores para código no confiable o proporcionado por el usuario; asigna un entorno aislado por tarea o por sesión de usuario, nunca compartas un sandbox entre cargas de trabajo no relacionadas; salida denegada por defecto con una lista blanca explícita para destinos requeridos; inyecta solo las credenciales que requiere la tarea actual usando tokens de corta duración; recolecta registros de auditoría a nivel de kernel o hipervisor, no dentro del proceso del sandbox; aplica límites de CPU, memoria, disco y tiempo real por sesión; y limpia las sesiones agresivamente: destruye los sandboxes efímeros tan pronto como se complete la tarea. La defensa en profundidad en todos estos controles proporciona una seguridad significativamente mejor que cualquier límite único fuerte.

¿Qué deben evaluar los equipos de seguridad al revisar sandboxes de agentes de IA para despliegue empresarial?

La revisión de seguridad empresarial debe cubrir seis áreas: (1) Aislamiento: ¿microVM o contenedor? ¿Cada sesión está completamente aislada a nivel de sistema de archivos, proceso y red? (2) Salida: ¿abierta por defecto o denegada por defecto? ¿La política de salida es configurable por el cliente? ¿Está bloqueado el endpoint de metadatos en la nube (169.254.169.254)? (3) Secretos: ¿cómo se inyectan las credenciales? ¿Están limitadas por tarea con tokens de corta duración? ¿Se limpian al desmontar la sesión? (4) Auditoría: ¿los registros se generan debajo del proceso del sandbox (nivel de kernel/hipervisor)? ¿Se pueden exportar los registros a un SIEM? (5) Residencia de datos: ¿está disponible BYOC o despliegue en VPC para que las cargas de trabajo permanezcan dentro de tu cuenta en la nube? (6) Postura de cumplimiento: ¿qué certificaciones tiene el proveedor y cuál es su modelo de responsabilidad compartida? Para equipos con requisitos regulatorios, completa esta revisión antes del despliegue en producción, no después.

¿Cómo funciona el aislamiento del kernel en un sandbox de agente de IA?

El aislamiento del kernel significa que el código del agente se ejecuta en un entorno con su propio kernel, separado del kernel del host por un límite de virtualización de hardware (KVM). En los sandboxes basados en Firecracker, cada sesión inicia un kernel invitado mínimo dentro de una microVM. Los procesos dentro del sandbox interactúan con el kernel invitado; el kernel del host no es visible ni accesible desde el interior. Una vulnerabilidad explotada en el kernel invitado no se propaga automáticamente al host porque el límite de KVM se encuentra entre ellos. Esta es la ventaja de seguridad clave sobre el aislamiento basado en contenedores, donde todos los contenedores comparten el kernel del host y un exploit del kernel afecta a todos ellos simultáneamente.

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