Sandbox de IA: aislamiento, ejecución de código y costes

Un sandbox de IA (AI sandbox) es un entorno aislado donde un agente de IA puede ejecutar código, instalar paquetes y trabajar con archivos. Su función es limitar a qué puede acceder ese código: la máquina host, el trabajo de otros usuarios, las credenciales y los servicios externos.
Antes de elegir un entorno de ejecución para tu agente, comprueba cómo aísla el código, si soporta tu carga de trabajo y cuánto cobra mientras se ejecuta. Esta guía explica esas opciones y muestra un pequeño flujo de ejecución con Lizard SDK.
Qué es un sandbox de IA
En una aplicación de agentes, el modelo propone una acción y tu aplicación decide dónde y cómo ejecutarla. Un sandbox proporciona el ordenador para las acciones que necesitan ejecución de código. El modelo puede escribir un script de Python, editar un repositorio o iniciar una aplicación web allí.
El término también describe programas empresariales para probar productos de IA. Aquí, se refiere al entorno de ejecución que ejecuta el código de un agente.
El entorno de ejecución necesita más que una carpeta para cada usuario. Un diseño útil separa procesos y archivos, limita la CPU y la memoria, y da a la aplicación una forma de detener el trabajo. Las credenciales, el acceso a la red y el almacenamiento persistente necesitan sus propias reglas.
Por ejemplo, un agente que analiza un CSV subido debe recibir ese archivo y suficiente capacidad de cálculo para procesarlo. No debería tener motivos para leer las variables de entorno del servidor web ni las subidas de otro cliente.
Cómo funciona un sandbox de IA
Una petición típica sigue este camino:
- Tu backend recibe una tarea y pide al modelo que genere código o llamadas a herramientas.
- Tu backend crea un sandbox y copia los archivos que necesita esa tarea.
- El sandbox ejecuta el código. Tu backend recoge stdout, stderr, los archivos y el código de salida.
- Tu backend comprueba el resultado antes de mostrarlo al usuario o enviarlo a otro servicio.
- Tu backend guarda la salida necesaria y detiene el sandbox.
Mantén la clave del proveedor del modelo y la clave de gestión del sandbox en tu backend. Dar una clave de gestión al código generado le permitiría solicitar más recursos usando tu cuenta.
Una sesión de programación puede necesitar el mismo sandbox durante varios turnos. Un cálculo puntual puede usar un sandbox nuevo por trabajo. Decide cuánto tiempo conservar el estado y a qué usuario pertenece antes de añadir la reutilización.
Docker, gVisor y Firecracker: qué cambia
Estas tecnologías proporcionan diferentes límites de aislamiento. El resto del sistema sigue determinando a qué archivos, redes y credenciales puede acceder el código.
| Enfoque | Dónde se sitúa el límite | Qué comprobar |
|---|---|---|
| Contenedor Docker estándar | Los espacios de nombres de Linux y los controles de recursos separan los procesos; los contenedores comparten el kernel del host. | Capacidades, modo privilegiado, montajes del host, acceso al demonio y parches del host. |
| gVisor | Un kernel de aplicación en el espacio de usuario gestiona las llamadas al sistema de la aplicación, reduciendo la exposición directa al kernel del host. | Compatibilidad de llamadas al sistema y rendimiento para tu carga de trabajo. |
| microVM Firecracker | Una máquina virtual tiene su propio kernel invitado y usa KVM para la virtualización de hardware. | Parches del invitado y del host, política de red, datos montados y controles de ciclo de vida. |
Docker puede adaptarse a cargas de trabajo con un nivel de confianza conocido y un host configurado cuidadosamente. Su seguridad depende de cómo lo ejecutes; exponer el socket de Docker o montajes amplios del host cambia lo que la carga de trabajo puede controlar. Consulta la documentación de seguridad de Docker.
gVisor añade un límite de kernel en el espacio de usuario, con concesiones en compatibilidad. Firecracker usa un pequeño monitor de máquina virtual y un modelo de dispositivos limitado. Ninguno elimina la necesidad de proteger secretos o restringir el acceso a servicios sensibles.
Lizard Sandboxes usa Firecracker. Los volúmenes o instantáneas más antiguos, y un respaldo tras un inicio fallido de Firecracker, pueden usar el entorno de ejecución de contenedores. Comprueba getInfo().runtime si tu aplicación requiere una microVM. El ejemplo de abajo rechaza cualquier otro entorno de ejecución. Consulta la documentación de Lizard Sandboxes.
Qué protege y qué no protege el aislamiento
Un sandbox limita el efecto de la ejecución de código. Tu aplicación todavía tiene que decidir qué acciones puede realizar un usuario o agente.
Credenciales y acceso a la red
Cualquier cosa que copies en el sandbox queda disponible para la carga de trabajo bajo los permisos que le des. Evita copiar todo tu .env, directorio SSH o credenciales en la nube. Si una tarea necesita una API externa, dale una credencial de corta duración con permisos limitados, o enruta la operación a través de una herramienta del backend que compruebe cada petición.
El aislamiento no implica bloquear el acceso a internet. Si el código puede leer un secreto y hacer peticiones salientes, podría enviar ese secreto a otro lugar. Elige un proveedor y una configuración que cumplan tus requisitos de red saliente. No asumas que existe una lista de permitidos de red sin comprobar los controles del producto.
Usuarios y archivos almacenados
Asigna cada sandbox a un usuario autenticado o a un trabajo. Comprueba la propiedad en cada petición para ejecutar código, descargar un archivo o reabrir una sesión. Adivinar un ID de sandbox no debe conceder acceso.
Mantén los archivos persistidos separados por usuario también. Reutilizar un espacio de trabajo escribible entre clientes no relacionados puede exponer datos incluso cuando cada ejecución obtiene una máquina virtual nueva.
Límites de tiempo y salida devuelta
Establece un tiempo de espera de ejecución y un tiempo de vida del sandbox. Un tiempo de espera en el cliente puede dejar de esperar sin detener el proceso remoto. La limpieza y una caducidad en el lado del servidor protegen contra diferentes fallos.
Trata los archivos y el texto devueltos como entrada no confiable. Valida el JSON contra la forma que espera tu aplicación. Escapa el texto al renderizarlo y evita servir HTML generado en el mismo origen que el panel de tu cuenta.
Para los agentes que omiten las aprobaciones interactivas, estos controles importan antes de que se ejecute el primer comando. Nuestra guía de permisos de Claude Code cubre ese flujo de trabajo.
Ejecutar una tarea de Python en Lizard Sandboxes
Este ejemplo usa Node.js como controlador del backend y Python dentro del sandbox. Ejecuta un cálculo fijo para que puedas comprobar la ruta de ejecución antes de añadir un modelo. No llama a un LLM.
Usa Node.js 22 o posterior, un proyecto de Lizard y una clave API de Lizard. Configura LIZARD_API_KEY y LIZARD_PROJECT_ID en el entorno de tu backend. Mantén ambos fuera del código del navegador; la clave API pertenece a tu almacén de secretos.
Instala el cliente de JavaScript:
npm install @lizard-build/sdk@0.1.69Guarda esto como run-task.mjs:
import { Lizard } from "@lizard-build/sdk";
const project = process.env.LIZARD_PROJECT_ID;
if (!project || !process.env.LIZARD_API_KEY) {
throw new Error("Set LIZARD_PROJECT_ID and LIZARD_API_KEY");
}
const lizard = new Lizard({ project });
const sandbox = await lizard.create("base", {
size: "small",
timeoutMs: 120_000,
});
try {
const info = await sandbox.getInfo();
if (info.runtime !== "firecracker") {
throw new Error("This task requires the Firecracker runtime");
}
const script = [
"import json",
"values = [12, 8, 5]",
"print(json.dumps({'total': sum(values)}))",
].join("\n");
await sandbox.fs.write("/tmp/task.py", script);
const result = await sandbox.process.exec(
["python3", "/tmp/task.py"],
{ user: "user", timeoutMs: 30_000 },
);
if (result.exitCode !== 0 || result.truncated) {
throw new Error("Task failed or returned incomplete output");
}
if (Buffer.byteLength(result.stdout, "utf8") > 4096) {
throw new Error("Task output exceeds the application limit");
}
const output = JSON.parse(result.stdout);
if (
output === null ||
typeof output !== "object" ||
Array.isArray(output) ||
Object.keys(output).length !== 1 ||
output.total !== 25
) {
throw new Error("Unexpected task output");
}
console.log(output);
} finally {
await sandbox.kill();
}Ejecútalo desde tu máquina backend:
node run-task.mjsEl 17 de octubre de 2026, ejecutamos este mismo script desde un sandbox de Lizard usando la plantilla codex y Node.js 22.23.2. Creó un sandbox Firecracker Small a partir de la plantilla base, ejecutó Python como user, imprimió { total: 25 } y completó la limpieza con el código de salida 0.
El SDK lee LIZARD_API_KEY del entorno del controlador. Este código no lo pasa al sandbox que ejecuta Python.
El array de argumentos ejecuta Python sin interpolación de shell. Python todavía puede realizar cualquier operación que permita el sandbox. El tiempo de espera del comando de 30 segundos limita cuánto tiempo espera el cliente; el tiempo de vida del sandbox de dos minutos establece una caducidad separada. El bloque finally solicita la limpieza incluso si falla la validación de la salida. Consulta la referencia de Lizard SDK.
Para convertir esto en una herramienta de agente, reemplaza el script fijo con el código que devuelve tu modelo y define un esquema de resultados para esa tarea. Mantén la autorización, los límites de recursos y las comprobaciones de salida en el backend. Un código de salida exitoso por sí solo no demuestra que la respuesta sea correcta.
Qué puedes construir con un sandbox de IA
Análisis de datos: procesa la subida de un usuario, ejecuta Python y devuelve un gráfico o un pequeño resultado JSON. Limita el tamaño del archivo y el tiempo de ejecución, luego conserva solo la salida que necesita el usuario.
Agentes de programación: obtén una copia de un repositorio específica para la tarea, edita archivos y ejecuta pruebas. Revisa las diferencias y los resultados de las pruebas antes de que un flujo de trabajo separado fusione o despliegue los cambios.
Creadores de aplicaciones: instala dependencias, inicia un servidor de desarrollo y proporciona una vista previa privada. Mantén la vista previa separada del origen y la autenticación de tu panel. Nuestra guía de creador de aplicaciones estilo Lovable muestra el flujo de la aplicación más amplio.
Agentes de navegador: usa un entorno de ejecución con navegador y escritorio cuando la tarea necesite interacción con la interfaz de usuario. Trata cualquier sesión iniciada como una credencial con acceso a esa cuenta.
Lizard Sandboxes ofrece comandos de shell, acceso a archivos y vistas previas privadas por HTTPS. El trabajo de navegador y escritorio usa la plantilla desktop. Una vista previa de desarrollo y una aplicación desplegada tienen diferentes tiempos de vida; elige cuál necesita tu usuario. Consulta Lizard Sandboxes.
Cuánto cuesta un sandbox de IA
Empieza por el tiempo total de ejecución, incluyendo el tiempo entre comandos. Luego añade el almacenamiento, las llamadas al modelo y cualquier otro servicio que use tu aplicación.
Lizard enumera estas tarifas de cálculo a partir de octubre de 17, 2026:
| Tamaño | vCPU | RAM | Cálculo por hora |
|---|---|---|---|
| Small | 2 | 4 GB | $0.0162 |
| Medium | 4 | 8 GB | $0.0324 |
| Large | 8 | 16 GB | $0.0648 |
Lizard mide el cálculo por segundo mientras se ejecuta un sandbox, incluyendo el tiempo de inactividad. Lizard Pro cuesta $19 al mes e incluye $19 de uso; el uso excedente es pay as you go. Persistent Volumes cuesta $0.14 por GB al mes. Consulta los precios actuales antes de presupuestar.
Para 1,000 trabajos Small que mantienen un sandbox en ejecución durante cinco minutos cada uno:
1,000 × (5 / 60 hours) × $0.0162 = $1.35 in compute usageEsa es la parte de cálculo de la carga de trabajo. Tu factura total sigue incluyendo la suscripción Pro y cualquier uso más allá de su límite. Los tokens del modelo son un coste aparte.
Si esos trabajos dejan un sandbox en ejecución durante una hora extra cada uno, añaden $16.20 en uso de cálculo. Un tiempo de vida explícito y una limpieza fiable pueden importar más que una pequeña diferencia en las tarifas por hora.
Cómo elegir un sandbox de IA
Haz pruebas con el trabajo que ejecutarán tus usuarios. Un comando de shell rápido te dice poco sobre la compilación de un repositorio o una sesión de navegador.
Registra el tiempo de inicio, el tiempo de instalación de dependencias, el tiempo total de la tarea, los fallos y los segundos totales de ejecución. Comprueba las peticiones más lentas además de la mediana. Nuestra comparativa de E2B, Daytona y Modal ofrece un punto de partida para comparar flujos de ejecución.
Antes de adoptar un entorno de ejecución, responde a estas preguntas:
- ¿Qué separa el código y los archivos de un cliente de los de otro?
- ¿A qué secretos y servicios externos puede acceder el código generado?
- ¿Puede el entorno de ejecución ejecutar los lenguajes, paquetes y herramientas de navegador que necesita la tarea?
- ¿Qué ocurre cuando el controlador falla o pierde su conexión?
- ¿Qué archivos sobreviven al apagado y cómo haces una copia de seguridad de ellos?
- ¿Cuánto costará la carga de trabajo completa con el tiempo de inactividad, el almacenamiento y las llamadas al modelo?
Para una primera implementación, empieza con una tarea, un sandbox temporal y un pequeño resultado validado. Crea Lizard Sandboxes, mide ese flujo y luego añade persistencia o sesiones más largas cuando la aplicación las necesite.
Construye con IA. Publica con Lizard.
No necesitas un equipo de plataforma para publicar. Todo tu entorno está a un solo comando de Lizard CLI.
- Servicios
- —
- Add-ons
- —
- Despliegues
- —
- Sandboxes iniciados
- —