Sandbox de Código Generado por IA: Requisitos para Aplicaciones de Producción

Las aplicaciones de producción que ejecutan código generado por IA necesitan un sandbox que imponga aislamiento a nivel de procesos, soporte sesiones concurrentes, exponga una API de ciclo de vida programable, proporcione registros observables y métricas de recursos, imponga políticas de paquetes y red, y se integre limpiamente con el backend de la aplicación. Elegir un sandbox sin evaluar sistemáticamente cada una de esas dimensiones es la forma más común en que los equipos encuentran problemas después del lanzamiento: una carga de trabajo que parecía segura en staging falla bajo tráfico real, filtra estado entre inquilinos o ejecuta silenciosamente código que la aplicación nunca tuvo la intención de permitir.

Esta guía es una lista de verificación de requisitos. Cubre qué verificar en cada nivel de aislamiento, qué debe exponer una API de ciclo de vida de producción, cómo deberían ser la observabilidad y los controles de recursos, y dónde los patrones de integración con el backend determinan el éxito o fracaso del diseño. Ya sea que estés evaluando un sandbox gestionado o construyendo el tuyo propio, estas son las preguntas que vale la pena responder antes de lanzar.

Aislamiento del Sandbox: Proceso, Contenedor y MicroVM

El aislamiento es un espectro, y cada nivel conlleva diferentes compensaciones en rendimiento, portabilidad y cuánta confianza le estás otorgando al código generado.

El aislamiento a nivel de proceso utiliza primitivas del sistema operativo — namespaces, cgroups, seccomp y perfiles AppArmor o SELinux — para restringir lo que un proceso puede acceder. Es rápido y no requiere un kernel de VM separado, pero todos los procesos comparten el kernel del host. Una vulnerabilidad del kernel o una llamada al sistema privilegiada que se deslice a través del filtro seccomp puede afectar a otras cargas de trabajo en el mismo host. El aislamiento de procesos es un punto de partida razonable para rutas de código de bajo riesgo, corta duración y confiables, pero es un límite delgado para código generado por IA no confiable que puede intentar llamadas al sistema, creación de subprocesos o instalación de paquetes.

Qué verificar en este nivel:

• ¿Qué llamadas al sistema están bloqueadas y cuál es la política predeterminada cuando se intenta una llamada al sistema desconocida?
• ¿Los namespaces están limitados por tarea, por inquilino o se comparten entre trabajos?
• ¿Los límites de cgroup se aplican a nivel de tarea o solo a nivel de host?
• ¿El sandbox limpia todos los procesos, archivos temporales, sockets y memoria compartida al salir?

El aislamiento a nivel de contenedor agrega un límite de sistema de archivos y espacio de nombres de red, y hace que la gestión de imágenes sea repetible. Los contenedores son más rápidos de iniciar que las VM completas, más fáciles de componer y ampliamente compatibles con las capas de orquestación. La compensación es que los contenedores aún comparten el kernel del host, y el límite del contenedor es tan fuerte como la configuración del entorno de ejecución subyacente. Los contenedores con privilegios, conjuntos de capacidades amplias, sockets del host montados y modo de red del host reducen el límite efectivo a prácticamente nada.

Qué verificar en este nivel:

• ¿La imagen del contenedor es mínima, con solo los entornos de ejecución y las herramientas que la carga de trabajo realmente necesita?
• ¿Se eliminan las capacidades al conjunto mínimo requerido?
• ¿El contenedor es sin raíz (rootless), o requiere raíz y qué controles existen al respecto?
• ¿El espacio de nombres de PID del host, la red del host y el socket de Docker están explícitamente excluidos?
• ¿Los volúmenes montados están limitados a rutas definidas explícitamente y el sistema de archivos raíz es de solo lectura cuando sea posible?

El aislamiento de MicroVM coloca cada carga de trabajo dentro de una máquina virtual ligera — con su propio kernel invitado, dispositivos virtuales y un límite respaldado por KVM entre el invitado y el host. Tecnologías como Firecracker utilizan un modelo de dispositivo mínimo para reducir la superficie de ataque mientras mantienen un inicio lo suficientemente rápido para uso interactivo. El límite de MicroVM significa que una explotación del kernel en el invitado no afecta automáticamente al host ni a otros invitados.

Qué verificar en este nivel:

• ¿Cada ejecución de agente, cada inquilino o cada sesión concurrente obtiene una MicroVM separada?
• ¿Cuál es la latencia de inicio desde la llamada API hasta estar listo para ejecutar, y se mide desde un pool cálido, una instantánea o un arranque en frío?
• ¿Las imágenes invitadas tienen control de versiones, se auditan para saber qué entornos de ejecución y herramientas incluyen, y se actualizan según un cronograma regular?
• ¿Qué sucede a nivel del host si el kernel invitado entra en pánico o se vuelve no responde?

La decisión práctica se basa en tu modelo de amenazas. El aislamiento de MicroVM es el límite más fuerte generalmente disponible para código generado por IA no confiable, pero no reemplaza la política del sistema de archivos, los controles de egreso, la gobernanza de paquetes o el manejo de secretos. Esos controles deben situarse sobre la capa de aislamiento que elijas.

Gestión de Sesiones Concurrentes en el Sandbox

Una aplicación de producción que genera código para múltiples usuarios simultáneamente necesita un sandbox que maneje la concurrencia como una preocupación de primera clase, no como una ocurrencia tardía.

Las preguntas clave son:

Aislamiento por sesión: Cuando 50 sesiones se ejecutan al mismo tiempo, ¿cada sesión tiene su propio sistema de archivos aislado, árbol de procesos, espacio de nombres de red y ámbito de credenciales? La fuga de estado entre sesiones es uno de los modos de falla más dañinos en aplicaciones sandbox multiinquilino, y a menudo es invisible en las pruebas donde las sesiones se ejecutan secuencialmente.

Límites de sesión y contrapresión: ¿El sandbox expone los límites de concurrencia como un contrato API claro? Si llegan 500 solicitudes y la plataforma soporta 100 sesiones concurrentes, ¿la API devuelve un error estructurado, pone en cola la solicitud o se degrada silenciosamente? Las aplicaciones de producción necesitan esa señal para implementar contrapresión, gestión de colas y retroalimentación orientada al usuario.

Equidad de recursos bajo carga: Cuando una sesión consume CPU o memoria inusualmente alta, ¿las otras sesiones están protegidas por límites de recursos por sesión, o puede una carga de trabajo ruidosa degradar todo el pool?

Pools cálidos y latencia de inicio de sesión: Las funciones de codificación interactivas necesitan tiempos de inicio de sesión inferiores a un segundo. Eso generalmente requiere un pool de entornos preinicializados que se puedan reclamar de inmediato en lugar de arrancar bajo demanda. Verifica si la plataforma documenta la disponibilidad de pools cálidos y qué latencia de inicio esperar en diferentes niveles de concurrencia.

Reutilización de sesiones vs. entornos nuevos: Algunas aplicaciones se benefician de reutilizar una sesión de larga duración en múltiples turnos de agente, mientras que otras necesitan un entorno limpio para cada solicitud. Verifica que ambos patrones sean compatibles y que la reutilización de sesiones no arrastre estado obsoleto de una conversación anterior.

API de Ciclo de Vida: Crear, Ejecutar, Terminar

La API de ciclo de vida es la interfaz entre tu aplicación y el entorno de ejecución del sandbox. Una API de nivel de producción debe exponer como mínimo:

Crear: Inicializar una nueva sesión de sandbox, opcionalmente a partir de una plantilla o instantánea, con límites de recursos especificados, variables de entorno y volúmenes montados. La respuesta debe incluir un ID de sesión y una señal de listo, no solo un acuse de recibo.

Ejecutar: Enviar código o un comando para su ejecución. Esta debe ser una llamada asíncrona que devuelva un ID de ejecución. La API debe admitir la especificación de un directorio de trabajo, anulaciones de entorno para la llamada y un tiempo de espera.

Transmitir salida: Recuperar stdout y stderr como una transmisión, no solo como un resultado final después de que la ejecución se complete. La transmisión es importante para trabajos de larga duración, pasos de agente que toman muchos segundos y cualquier UX que muestre al usuario progreso incremental.

Terminar: Finalizar una ejecución en curso antes de que se complete. El sandbox debe garantizar que el árbol de procesos se limpie, no solo el proceso padre.

Limpieza: Destruir la sesión y liberar todos los recursos asociados — sistema de archivos, memoria, espacios de proceso, estado de red y cualquier credencial retenida. Esta llamada debe ser idempotente para que los reintentos después de un error de red no causen errores.

Subir y descargar archivos: Transferir archivos de entrada al sandbox antes de la ejecución y recuperar artefactos de salida después. Las transferencias de archivos deben estar limitadas por límites de tamaño y controladas por políticas sobre qué rutas son escribibles.

Capacidades adicionales que vale la pena verificar para uso en producción:

• Pausar y reanudar: ¿Se puede suspender una sesión de larga duración y reanudarla más tarde sin perder el estado? Esto es útil para limitación de velocidad, control de costos y traspaso de sesiones entre turnos de agente.
• Instantánea: ¿Se puede capturar el estado actual de la sesión y usarlo como punto de partida para futuras sesiones? Este es el mecanismo clave para pools cálidos y entornos reutilizables.
• Aplicación del tiempo de espera: Si el código en ejecución excede el tiempo de espera de pared, ¿la plataforma lo termina limpiamente e informa el estado de salida correcto?

Observabilidad: Registros, Métricas y Trazas

No puedes depurar ni auditar lo que no puedes ver. Los sandboxes de producción necesitan observabilidad incorporada, no añadida posteriormente.

Captura de stdout y stderr: Cada ejecución debe producir un registro de salida capturado asociado con el ID de sesión y el ID de ejecución. Esto debe ser accesible a través de la API después de que la ejecución se complete, no solo disponible como una transmisión en tiempo real.

Registros de ejecución: La plataforma debe registrar qué código se ejecutó, cuándo comenzó, cuándo terminó, cuál fue el código de salida, qué usuario o inquilino era el propietario de la sesión y qué plantilla o instantánea se utilizó. Estos registros son el mínimo necesario para reconstruir lo que sucedió cuando algo sale mal.

Métricas de recursos: Las aplicaciones de producción necesitan métricas por sesión para uso de CPU, pico de memoria, tiempo de pared y escrituras en el sistema de archivos. Esto permite la planificación de capacidad, la detección de anomalías y la atribución de costos por sesión.

Trazado de errores: Cuando un sandbox falla al iniciar, ejecutar o limpiar, la superficie de error debe ser estructurada: código de error, mensaje, ID de sesión y suficiente contexto para distinguir un error de usuario (código incorrecto, paquete faltante) de un error de plataforma (cuota excedida, falla interna).

Pista de auditoría: Para aplicaciones multiinquilino, la pista de auditoría debe hacer que el comportamiento del agente sea reconstruible: ID de sesión, inquilino, secuencia de ejecución, instalaciones de paquetes, dominios externos contactados, archivos escritos y resultado de la limpieza. El código de cliente sin procesar y la salida completa del comando pueden no pertenecer a los registros de auditoría por defecto; diseña para lo que tus políticas de retención y acceso puedan realmente soportar.

Qué evitar: un sandbox que solo muestre “ejecución fallida” sin error estructurado, sin registros a nivel de sesión y sin forma de distinguir un tiempo de espera de un OOM de un intento de escape de proceso. Eso te obliga a instrumentar todo en la capa de la aplicación, lo que duplica el trabajo y omite eventos que el sandbox puede observar directamente.

Límites de CPU, Memoria y Tiempo de Espera

El consumo ilimitado de recursos es una de las formas más simples en que una carga de trabajo en sandbox puede causar problemas en producción, ya sea degradando otras sesiones o generando costos de infraestructura inesperados.

Un sandbox de producción debe imponer límites a nivel de sesión, no solo a nivel de host:

CPU: Limitar cuánto tiempo de CPU puede consumir una sola sesión. Una sesión que genera un bucle infinito no debería degradar otras sesiones en el mismo host. Verifica si el límite es un tope duro (el proceso es limitado o eliminado) o un límite blando (compite con otros procesos por la CPU disponible).

Memoria: Establecer un tope de memoria que active la limpieza o terminación en lugar de permitir que la sesión agote la memoria del host. Verifica qué sucede cuando se alcanza el límite: eliminación por OOM, respuesta de error estructurada o bloqueo silencioso.

Tiempo de espera de pared: Cada llamada de ejecución debe tener una duración máxima. El tiempo de espera debe ser aplicable a nivel de plataforma, no solo a nivel de cliente — si el cliente pierde la conexión, el sandbox aún debe terminar la ejecución en el límite configurado.

Uso de disco: El código generado puede escribir archivos de salida grandes, instalar paquetes grandes o llenar el directorio de trabajo. Una cuota de disco en el directorio de trabajo de la sesión evita escrituras descontroladas.

Número de procesos: El código generado por IA puede crear subprocesos, trabajadores en segundo plano o comandos de shell que a su vez crean más procesos. Un límite en el número total de procesos en el espacio de nombres de la sesión evita bombas de bifurcación (fork bombs) y árboles de subprocesos descontrolados.

Al evaluar una plataforma de sandbox, verifica si estos límites son configurables por sesión (para que diferentes niveles de usuario o tipos de tarea puedan tener diferentes límites), si se aplican a nivel de sandbox y si alcanzar un límite produce un error de API estructurado o una falla silenciosa.

Políticas de Instalación de Paquetes

El código generado por IA frecuentemente solicita instalaciones de paquetes — pip install, npm install, apt-get, clones de Git, descargas directas de URL. Cada una de esas operaciones extrae código externo al sandbox en tiempo de ejecución, que es una de las operaciones de mayor riesgo que un sandbox necesita gobernar.

Una política de paquetes de producción debe cubrir:

Listas blancas de registros: ¿Qué registros de paquetes están permitidos? PyPI y npm son los predeterminados, pero muchos equipos quieren la opción de restringir a espejos internos, registros seleccionados o fuentes explícitamente aprobadas.

Caché de instalación: Cuando muchas sesiones instalan los mismos paquetes populares, una caché de capas o un proxy de extracción evita descargas redundantes, reduce la latencia de inicio y te da un punto para inspeccionar lo que se está obteniendo.

Modo sin conexión: Algunas cargas de trabajo deberían ejecutarse sin instalaciones de paquetes en absoluto — el entorno está predefinido en la imagen o plantilla, y los intentos de instalación deberían fallar con un error claro. Este es el modo apropiado para ejecuciones de evaluación donde la reproducibilidad importa más que la flexibilidad.

Verificación de hash y archivos de bloqueo: Cuando se permiten paquetes, las versiones fijadas y la verificación de hash reducen el riesgo de que un compromiso del registro cambie qué código se ejecuta dentro del sandbox.

Límites de tamaño: Los paquetes y sus dependencias transitivas pueden ser grandes. Un tope de tamaño en la huella total descargada por sesión evita el agotamiento accidental o intencional del almacenamiento.

Registro de paquetes: Cada intento de instalación debe registrarse en el registro de auditoría de ejecución: nombre del paquete, versión solicitada, fuente del registro y éxito o fracaso. Estos son los datos que necesitas para reconstruir qué entró al sandbox durante un incidente.

La pregunta para hacer a un proveedor de sandbox no es “¿pueden los usuarios instalar paquetes?” sino “¿cómo se audita cada instalación, qué registros están permitidos por defecto y puedo configurar una política más estricta para cargas de trabajo sensibles?”

Controles de Red y Egreso

El acceso a la red es el segundo vector importante para que un sandbox alcance destinos inesperados. El egreso abierto por defecto es conveniente en desarrollo, pero es un valor predeterminado deficiente para aplicaciones de producción que ejecutan código generado por IA.

Egreso denegado por defecto: La postura de producción más sólida es bloquear todas las conexiones salientes por defecto y permitir explícitamente los destinos que una sesión necesita legítimamente. Esto requiere más configuración pero hace que el modelo de acceso sea auditable.

Destinos permitidos: Para agentes de codificación, los destinos permitidos típicos pueden incluir registros de paquetes, un conjunto específico de APIs públicas que el agente está diseñado para llamar y nada más. Para agentes de análisis de datos, la lista puede incluir fuentes de datos específicas. Verifica que la plataforma admita listas blancas de destinos por sesión o por inquilino.

Política de DNS: El DNS debe manejarse de manera consistente con la política de egreso. Una sesión que no puede alcanzar destinos HTTP arbitrarios tampoco debería poder resolver nombres DNS arbitrarios y usar eso para inferir la topología de red o eludir controles a través de canales basados en DNS.

Acceso a servicios internos: El código generado por IA no debería poder alcanzar puntos finales de metadatos en la nube (por ejemplo, el servicio de metadatos de instancia de AWS), APIs internas, bases de datos privadas o paneles de administración a menos que estén explícitamente configurados. Verifica si la política de red predeterminada del sandbox bloquea rangos de direcciones internas bien conocidos.

Egreso de descarga de paquetes: Las instalaciones de paquetes son operaciones de red. Si el egreso está restringido, asegúrate de que la lista blanca de registros de paquetes sea consistente con la política de egreso, o utiliza un proxy de extracción dentro de la red de confianza.

Registro de conexiones salientes: Incluso cuando se permite el egreso, registrar qué dominios e IPs contactó una sesión es útil para la investigación de incidentes. No todas las plataformas de sandbox proporcionan esto de forma nativa; verifica qué obtendrás.

Inyección de Secretos y Credenciales

Los agentes de IA frecuentemente necesitan credenciales — claves de API, conexiones a bases de datos, tokens OAuth, credenciales en la nube de corta duración. Cómo un sandbox maneja los secretos es importante tanto para la seguridad como para la confiabilidad operativa.

Ámbito estrecho: Cada sesión debe recibir solo los secretos que necesita para la tarea específica que está ejecutando. Montar un archivo de entorno amplio con todas las credenciales en cada sesión es operativamente conveniente, pero significa que el código comprometido o de mal comportamiento en cualquier sesión puede alcanzar todas esas credenciales.

Credenciales de corta duración: Cuando el backend lo soporta, prefiere tokens de corta duración con un TTL limitado a la duración de la sesión. Esto limita la ventana durante la cual una credencial filtrada es útil.

Mecanismo de inyección: Verifica si los secretos se inyectan como variables de entorno, archivos montados o a través de una API de secretos. Las variables de entorno son accesibles para todos los procesos en la sesión por defecto; los archivos montados pueden limitarse a una ruta y conjunto de permisos. Para los secretos más sensibles, considera una API de secretos que proporcione valores solo a un proceso explícitamente autorizado.

Redacción: El sandbox no debe hacer eco de los secretos a través de stdout, stderr, registros de ejecución, mensajes de error o respuestas de herramientas visibles para el modelo. La redacción es una responsabilidad de la capa de aplicación, pero un sandbox que soporte el borrado configurable de registros reduce el radio de explosión de una exposición accidental.

Limpieza: Después de que la sesión finalice, verifica que las variables de entorno, los archivos de secretos montados y cualquier dato de credencial en caché se limpien como parte del desmontaje de la sesión, y no queden para que la siguiente sesión los herede.

Almacenamiento de Archivos Efímero vs. Persistente

Diferentes cargas de trabajo tienen diferentes necesidades de persistencia, y un sandbox de producción debe soportar ambos patrones claramente.

Sesiones efímeras: El valor predeterminado para la ejecución de código de corta duración es una sesión que crea un directorio de trabajo limpio, ejecuta código, produce salida y se destruye. Las sesiones efímeras son fáciles de razonar: cada ejecución comienza desde una línea base conocida, no se acumula estado y la limpieza es sencilla. Son la opción correcta para trabajos de evaluación, finalizaciones de código de un solo uso y cualquier tarea donde la reproducibilidad importe más que la continuidad.

Espacios de trabajo persistentes: Los agentes de codificación de larga duración, los flujos de trabajo de desarrollo iterativo y las sesiones de agente de múltiples turnos a menudo necesitan un espacio de trabajo que sobreviva a múltiples llamadas de ejecución. Los archivos instalados, las dependencias almacenadas en caché, el código escrito y el historial acumulado en un turno deben estar disponibles en el siguiente. Los espacios de trabajo persistentes son más complejos de operar: acumulan estado, pueden desviarse de la plantilla y necesitan un ciclo de vida explícito — cuándo se limpia el espacio de trabajo, quién es el propietario y qué controles de acceso lo protegen entre sesiones?

Instantáneas y plantillas: Las plantillas te permiten definir un entorno de línea base conocido y bueno — entornos de ejecución, herramientas, dependencias — y lanzar sesiones desde allí de manera consistente. Las instantáneas capturan el estado actual de una sesión en ejecución y lo utilizan como punto de partida para futuras sesiones. Ambos son útiles para equipos que necesitan entornos repetibles y baja latencia de inicio. Verifica que las plantillas tengan control de versiones, que quién puede crearlas y actualizarlas esté controlado y que las instantáneas estén aisladas por inquilino.

Exportación de artefactos de salida: Después de la ejecución, ¿qué puede salir del sandbox? Una política de producción debe definir qué rutas de archivos son exportables, qué límites de tamaño se aplican y si los artefactos se revisan o filtran antes de que la aplicación los reciba.

Estado entre sesiones: Sé explícito sobre si el diseño de tu aplicación pretende que las sesiones compartan estado o no. El intercambio accidental — a través de una caché de paquetes compartida, un volumen compartido o un espacio de trabajo mal enrutado — es una falla común de aislamiento multiinquilino.

Integración con el Backend: REST, WebSocket, SDK

Un sandbox solo es útil si se integra limpiamente en el backend de la aplicación. Los tres patrones de integración principales son REST, WebSocket y SDK.

REST: Una API REST es la integración de menor fricción para aplicaciones que envían solicitudes de ejecución discretas y consultan los resultados. Funciona bien para tareas de corta duración, es fácil de depurar con herramientas HTTP estándar y encaja naturalmente en las arquitecturas de servicios existentes. La compensación es que consultar resultados agrega latencia en comparación con las notificaciones push, y la transmisión de salida de larga duración requiere SSE o consultar un punto final de registro.

WebSocket: Una conexión WebSocket admite comunicación bidireccional y de baja latencia entre la aplicación y el sandbox. Esta es la opción correcta para casos de uso interactivos: un asistente de codificación que transmite salida mientras se ejecuta el código, un agente de navegador que necesita enviar comandos y recibir respuestas en tiempo real, o un arnés de evaluación que monitorea la ejecución continuamente. La compensación es la complejidad operativa: las conexiones WebSocket requieren estado persistente, manejo de reconexión e infraestructura más compleja tanto en el lado del cliente como del servidor.

SDK: Un SDK nativo del lenguaje oculta los detalles de transporte, maneja la autenticación, proporciona interfaces tipadas para la gestión de sesiones y ejecución, y a menudo incluye ayudantes para transmitir salida, subir archivos y gestionar plantillas. Un SDK es la ruta más rápida hacia la integración para la mayoría de los desarrolladores de aplicaciones. Verifica que el SDK se mantenga activamente, cubra toda la superficie de la API y maneje los errores de manera estructurada para que tu aplicación pueda actuar en consecuencia.

Puntos de integración que tu aplicación debe poseer: Independientemente del transporte, tu aplicación es responsable de la autorización (qué usuarios pueden crear sesiones y con qué límites de recursos), las puertas de aprobación (qué llamadas a herramientas o ejecuciones de código requieren revisión humana antes de ejecutarse), el manejo de resultados (cómo se presenta o actúa sobre la salida del sandbox por parte del agente) y la limpieza (activar el desmontaje de la sesión cuando el flujo de usuario se completa o el turno del agente termina).

Una API de sandbox bien diseñada no intenta poseer la lógica de negocio de tu aplicación. Expone primitivas — crear, ejecutar, transmitir, terminar, limpiar — y permite que tu capa de aplicación construya el comportamiento de producto correcto sobre ellas.

Recuperación de Fallas y Limpieza

Los sistemas de producción fallan. Un sandbox que maneje las fallas con gracia previene fugas de recursos, estado obsoleto e incidentes difíciles de depurar.

Manejo de tiempo de espera de ejecución: Cuando una ejecución en curso excede su tiempo de espera, la plataforma debe terminar el árbol de procesos de manera limpia y devolver una respuesta de error estructurada — no dejar una sesión zombie consumiendo recursos. Verifica qué sucede con la sesión después de un tiempo de espera: ¿se limpia automáticamente o requiere una llamada de limpieza explícita?

Recuperación de fallo de sesión: Si el host del sandbox falla o la VM de la sesión sale inesperadamente, la plataforma debe detectar la falla, marcar la sesión como terminada y mostrar ese estado a través de la API para que la aplicación pueda reaccionar. Las sesiones no deben desaparecer silenciosamente sin una señal de la API.

Garantías de limpieza: Una llamada a la API de cleanup o terminate debe liberar de manera confiable todos los recursos: asignaciones de CPU y memoria, cuota del sistema de archivos, espacios de proceso, estado de red y credenciales. La limpieza debe ser idempotente — llamarla múltiples veces en el mismo ID de sesión no debe devolver un error. Esto es importante en la práctica: el código de aplicación que reintenta la limpieza después de un error de red no debe romperse.

Fallos de ejecución parcial: Cuando el código falla a mitad de la ejecución — una excepción no manejada, un proceso eliminado, un paquete faltante — el sandbox debe devolver un resultado estructurado que distinga el éxito parcial (se produjo algo de salida antes del fallo) del fallo total. Las aplicaciones construidas sobre resultados parciales necesitan esto para evitar presentar salida incompleta o engañosa a los usuarios.

Manejo de procesos descontrolados: Si el código generado crea un proceso en segundo plano que sobrevive a la ejecución principal, el sandbox debe terminarlo como parte de la limpieza de la sesión en lugar de permitir que se ejecute indefinidamente. Verifica si la limpieza de la plataforma cubre todo el árbol de procesos, no solo el hijo inmediato de la llamada de ejecución.

Errores de capacidad y cuota: Cuando la plataforma está en capacidad máxima de sesiones o un inquilino ha alcanzado su cuota, la API debe devolver un código de error específico que la aplicación pueda manejar explícitamente — no un 500 genérico o un bloqueo silencioso. Esto permite que la aplicación ponga en cola, retroceda o muestre un mensaje útil al usuario.

Novita Agent Sandbox

Novita Agent Sandbox es una plataforma de sandbox gestionada construida para cargas de trabajo de agentes. Está dirigida a agentes de codificación, agentes de análisis de datos, flujos de trabajo orientados al navegador y sesiones de agente de mayor duración donde el código generado necesita ejecutarse en un entorno aislado y observable sin aterrizar en servidores de aplicaciones o infraestructura compartida.

Para equipos que ya utilizan las APIs de modelo de Novita AI, Agent Sandbox puede ser parte de una arquitectura de agente más amplia: el modelo planifica y genera código, el sandbox proporciona ejecución aislada con un ciclo de vida programable, y la capa de aplicación es propietaria de la autorización, las puertas de aprobación y el manejo de resultados.

Novita ha descrito capacidades que incluyen aislamiento de MicroVM, soporte de sesiones concurrentes, una API de ciclo de vida que cubre crear, ejecutar, transmitir, terminar y limpiar, Pausa y Reanudación Automática para gestionar el estado de la sesión, plantillas e instantáneas para un inicio de entorno rápido y repetible, e integración con las APIs de modelo de Novita. Verifica la disponibilidad actual de funciones, las opciones de configuración de recursos y los precios en la documentación de Novita Agent Sandbox y en la página del producto antes de tomar decisiones de arquitectura. Las afirmaciones sobre límites de aislamiento específicos, límites de concurrencia, latencia de inicio y política de red deben confirmarse con la documentación actual del producto.

Al evaluar Novita Agent Sandbox frente a los requisitos de esta guía, aplica la misma lista de verificación que con cualquier otro proveedor: límite de aislamiento por sesión, integridad de la API de ciclo de vida, superficie de observabilidad, límites de recursos configurables, opciones de política de paquetes, controles de egreso, manejo de secretos, modelo de persistencia y soporte de integración con el backend.

Preguntas Frecuentes

¿Qué modelo de aislamiento debería elegir para código generado por IA?

El aislamiento de MicroVM proporciona el límite más fuerte para código generado por IA no confiable, pero agrega complejidad operativa. El aislamiento de contenedor es adecuado para cargas de trabajo de menor riesgo cuando el contenedor está correctamente reforzado — sin modo privilegiado, capacidades mínimas, sistema de archivos raíz de solo lectura cuando sea posible y sin montajes de socket del host. El aislamiento de procesos por sí solo es un límite demasiado débil para código no confiable que puede intentar llamadas al sistema, creación de subprocesos o instalación de paquetes. Iguala el nivel de aislamiento a tu modelo de amenazas real.

¿Cómo manejo las instalaciones de paquetes en un sandbox de producción?

Utiliza listas blancas de registros en lugar de acceso abierto por defecto. Agrega una caché de extracción para reducir descargas redundantes y darte un punto de inspección. Registra cada intento de instalación con nombre del paquete, versión, fuente y resultado. Para cargas de trabajo donde la reproducibilidad importa más que la flexibilidad — ejecuciones de evaluación, pipelines automatizados — considera un modo sin conexión donde el entorno esté predefinido y las instalaciones estén completamente deshabilitadas.

¿Qué debería exponer una API de ciclo de vida como mínimo?

Crear, ejecutar con transmisión de salida, terminar y limpiar. La transmisión de salida es la capacidad que más a menudo falta en las implementaciones mínimas, y es la que más importa para las interfaces de usuario interactivas de agentes. La limpieza debe ser idempotente y debe cubrir todo el árbol de procesos, no solo el proceso de punto de entrada.

¿Cómo evito que los secretos se filtren a través de un sandbox?

Limita el ámbito de las credenciales estrechamente a la tarea — no un archivo de entorno amplio. Prefiere tokens de corta duración. No registres stdout completo por defecto si los secretos pueden aparecer allí. Verifica que el sandbox limpie las variables de entorno y los archivos de secretos montados al desmontar la sesión. Trata la redacción como una responsabilidad de la aplicación, no una garantía del sandbox.

---

Artículos recomendados

• Firecracker para Sandboxes de Agentes de IA: Beneficios, Límites y Preguntas de Evaluación
• Servidores MCP en Sandboxes Aislados: Compensaciones de Sistema de Archivos, Secretos y Red
• Construye un Analista de Datos de IA con Python en Sandbox y Acceso Controlado a Paquetes