¿Qué es un sandbox de IA? Cómo ejecutan código los agentes con límites

Un agente de programación puede proponer un cambio sin ejecutar nada. El riesgo cambia cuando instala un paquete, ejecuta una prueba, abre un archivo subido o inicia un servidor. Esas acciones ejecutan programas con los permisos del entorno. Un comando de pruebas puede ejecutar scripts de dependencias; una tarea de análisis puede abrir archivos que el usuario nunca quiso compartir.

Piensa en un agente encargado de arreglar una aplicación que falla. Lee el proyecto, modifica un módulo, instala dependencias y ejecuta las pruebas. Darle tu entorno de desarrollo habitual también le da acceso a todo lo que ese entorno alcanza: directorios montados, credenciales, servicios de red y quizá sistemas de producción. Un límite de ejecución permite darle menos capacidades.

El objetivo es hacer explícitas las acciones permitidas. Un sandbox puede ejecutar código incorrecto, contactar un endpoint autorizado o usar indebidamente una credencial proporcionada a propósito. Trata el código generado y sus dependencias como entradas que debes comprobar y diseña el entorno según las consecuencias de ejecutarlas.

Una ejecución típica comienza con un proyecto o unas entradas. El agente propone código o un comando, una herramienta lo ejecuta en el entorno configurado y devuelve evidencias como salida, código de retorno o un archivo generado. El agente puede usar esos datos para hacer otro cambio.

Para una aplicación, el resultado puede incluir un servidor de vista previa. Para una tarea de datos, un gráfico. Para revisar código, una prueba fallida con sus registros. Un contrato útil define las entradas, lo que se ejecutó, las salidas y lo que debe sobrevivir al detener la ejecución.

Sandbox describe un propósito, no una implementación concreta. Los contenedores Linux normales usan namespaces y otros controles del kernel para separar procesos compartiendo el kernel del host. La guía de seguridad de Docker cubre namespaces, grupos de control, capabilities y el riesgo de acceder al daemon de Docker. Los montajes, privilegios e interfaces expuestos siguen formando parte del límite.

gVisor añade un kernel de aplicación en espacio de usuario que implementa una interfaz similar a Linux. Media entre las aplicaciones y el host para reducir la exposición a vulnerabilidades del kernel del host. Esa capa adicional también exige evaluar la compatibilidad y el rendimiento de la carga.

Una microVM ejecuta un kernel invitado dentro de un límite de máquina virtual. Firecracker es una implementación: su diseño describe invitados Linux, KVM, un modelo de dispositivos reducido y un jailer para producción. La plataforma que lo rodea sigue teniendo que configurar almacenamiento, red, identidad y el ciclo de vida de cada entorno.

Un sandbox no tiene por qué ser desechable. El aislamiento describe el límite de la ejecución; la persistencia, lo que queda después. Puedes ejecutar una tarea breve sobre código duradero, mantener un entorno entre turnos o descartar sus archivos tras recoger el resultado.

Define con precisión qué persiste. Un repositorio guardado no es lo mismo que una caché de dependencias, un volumen de datos montado o la memoria de un proceso en ejecución. Detener un entorno puede conservar unos y perder otros. Una sesión larga no sustituye las copias de seguridad ni el control de versiones.

Para los agentes de programación, resulta útil un espacio de trabajo duradero con un ciclo de ejecución propio. El equipo puede seguir revisando el código tras detener una vista previa y reconstruir desde las entradas registradas. Para cálculos puntuales, puede bastar con conservar la referencia de entrada y el artefacto de salida.

El aislamiento del runtime no decide si la acción solicitada por un agente es apropiada. Si un entorno puede alcanzar un servicio externo y tiene una credencial que ese servicio acepta, el código puede usar ese acceso. Proteger el host y limitar los permisos de la aplicación son tareas relacionadas, pero diferentes.

El modelo de seguridad de gVisor distingue explícitamente los recursos externos al sandbox de los disponibles dentro. Aplica esa distinción al decidir qué archivos, destinos de red y credenciales exponer. Introducir datos sensibles en un entorno aislado sigue siendo una decisión de ponerlos a disposición de la tarea.

Lo mismo se aplica a producción. Un agente puede generar una compilación válida e introducir una comprobación de permisos defectuosa o una consulta costosa. Mantén la revisión de la aplicación y la autorización de publicación en el flujo; el aislamiento no demuestra que una función sea correcta.

Un asistente de programación necesita archivos del proyecto, herramientas de compilación y una forma de revisar cambios. Un agente que crea aplicaciones también necesita un proceso de vista previa y una ruta accesible. Uno de análisis de datos necesita la entrada pertinente y una forma de devolver un artefacto. Estas tareas pueden compartir infraestructura sin requerir los mismos permisos ni reglas de retención.

Ejecutar scripts de clientes es otro caso. El código puede ser hostil a propósito, y una tarea no debe consumir la cuota de otro cliente ni acceder a sus datos. Evalúa explícitamente ese modelo de confianza antes de tratar un espacio de desarrollo cómodo como un servicio de ejecución de código arbitrario.

Mide el recorrido completo de la tarea al comparar opciones. Una cifra de arranque del runtime deja fuera la carga del código, la instalación de dependencias, las colas, el inicio de la aplicación y las comprobaciones de salud. El tiempo hasta que el agente puede usar un resultado suele ser más útil.

Define el contrato de ejecución antes de elegir un proveedor o crear la integración. Pruébalo con cargas representativas, incluidos fallos. Un comando bloqueado, una dependencia ausente o una vista previa detenida deben producir un estado que tu aplicación pueda entender y del que pueda recuperarse.

Adios conecta el flujo de programación mediante un espacio de trabajo basado en código fuente. Su documentación describe archivos, operaciones de Git, actividad del agente, compilaciones, registros, controles de vista previa y despliegue. El equipo conserva así un proyecto al que volver después de que termine un comando o una vista previa.

Un cliente MCP compatible puede usar las herramientas alojadas de Adios para crear un espacio de trabajo, escribir archivos, preparar una vista previa e inspeccionar registros. La autenticación limita el cliente a los recursos autorizados del equipo. El flujo MCP documentado exige aprobación explícita antes de desplegar.

El resumen de seguridad de Adios describe namespaces de Linux, cgroups y límites de recursos cuando el runtime seleccionado los admite. Esos controles documentados deben guiar la evaluación; la palabra sandbox no promete una microVM ni un kernel invitado dedicado para cada espacio de trabajo. Confirma las propiedades del runtime necesarias para el código que vas a ejecutar.

Para probar el flujo, conecta un cliente MCP o abre un espacio de trabajo, haz un pequeño cambio e inspecciona la compilación y la vista previa. Guarda el resultado en Git. Así tendrás un punto de partida concreto para decidir qué necesita la siguiente tarea del agente.