Requisitos de Sandbox de Código IA 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 proceso, admita sesiones concurrentes, exponga una API de ciclo de vida programable, proporcione registros observables y métricas de recursos, aplique 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 backend determinan el éxito o fracaso del diseño. Ya sea que estés evaluando un sandbox administrado 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 cuanto a rendimiento, portabilidad y cuánta confianza le estás otorgando al código generado.

El aislamiento a nivel de proceso utiliza primitivas del SO — namespaces, cgroups, seccomp y perfiles de 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 escape 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, de corta duración y confiables, pero es un límite delgado para código no confiable generado por IA que puede intentar syscalls, generar subprocesos o instalar paquetes.

Qué verificar en este nivel:

• ¿Qué syscalls están bloqueadas y cuál es la política predeterminada cuando se intenta una syscall 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 namespace de red, y hace que la gestión de imágenes sea repetible. Los contenedores se inician más rápido que las VMs completas, son más fáciles de componer y tienen un amplio soporte por parte de 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 solo es tan fuerte como la configuración subyacente del runtime. Los contenedores privilegiados, los conjuntos de capacidades amplias, los sockets del host montados y el 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 runtimes y herramientas que la carga de trabajo realmente necesita?
• ¿Se eliminan las capacidades al conjunto mínimo requerido?
• ¿El contenedor es sin root, o requiere root y qué controles existen al respecto?
• ¿El namespace PID del host, la red del host y el socket de Docker están explícitamente excluidos?
• ¿Los volúmenes montados se limitan 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 arranque 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 que está listo para ejecutar, y se mide desde un pool caliente, una instantánea o un arranque en frío?
• ¿Las imágenes invitadas están bajo control de versiones, auditadas en cuanto a los runtimes y herramientas que incluyen, y actualizadas con un cronograma regular?
• ¿Qué sucede a nivel del host si el kernel invitado entra en pánico o se vuelve no responsive?

La decisión práctica depende de tu modelo de amenaza. El aislamiento de MicroVM es el límite generalmente disponible más fuerte para código no confiable generado por IA, pero no reemplaza la política del sistema de archivos, los controles de salida, la gobernanza de paquetes ni el manejo de secretos. Esos controles deben estar por encima de la capa de aislamiento que elijas.

Gestión de Sesiones Concurrentes del 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 se ejecutan 50 sesiones al mismo tiempo, ¿cada sesión tiene su propio sistema de archivos aislado, árbol de procesos, namespace de red y ámbito de credenciales? La fuga de estado entre sesiones es uno de los modos de fallo 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 admite 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 para el 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 calientes 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 inmediatamente en lugar de arrancar bajo demanda. Verifica si la plataforma documenta la disponibilidad del pool caliente 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 del 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 runtime 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 especificar 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.

Limpiar: 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 para determinar qué rutas son escribibles.

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

• Pausar y reanudar: ¿Se puede suspender y reanudar una sesión de larga duración más tarde sin perder el estado? Esto es útil para limitación de velocidad, control de costos y transferencia de sesión entre turnos del agente.
• Instantánea: ¿Se puede capturar el estado actual de la sesión y usarlo como punto de partida para sesiones futuras? Este es el mecanismo clave para pools calientes y entornos reutilizables.
• Aplicación de tiempo de espera: Si el código en ejecución excede el tiempo de espera de reloj 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 poseía 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 reloj de pared y escrituras en el sistema de archivos. Esto permite planificación de capacidad, detección de anomalías y atribución de costos por sesión.

Trazas 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, fallo interno).

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 limpieza. El código crudo del cliente y la salida completa del comando pueden no pertenecer a los registros de auditoría de forma predeterminada; diseña para lo que tus políticas de retención y acceso puedan soportar realmente.

Qué evitar: un sandbox que muestre solo “ejecución fallida” sin un 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 aplicación, lo que duplica el trabajo y se pierde 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 aplicar 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 debe degradar otras sesiones en el mismo host. Verifica si el límite es un tope duro (el proceso se acelera o se mata) 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: OOM kill, respuesta de error estructurada o bloqueo silencioso.

Tiempo de espera de reloj 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 generar subprocesos, trabajadores en segundo plano o comandos de shell que a su vez generan más procesos. Un límite en el número total de procesos en el namespace de la sesión evita bombas fork 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 límites diferentes), si se aplican a nivel de sandbox y si alcanzar un límite produce un error de API estructurado o un fallo silencioso.

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, lo 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, un caché de capa o 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 deben ejecutarse sin instalaciones de paquetes en absoluto: el entorno está preinstalado en la imagen o plantilla, y los intentos de instalación deben 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 que debes 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 Salida

El acceso a la red es el segundo vector principal para que un sandbox alcance destinos inesperados. La salida predeterminada abierta es conveniente en desarrollo, pero es un mal valor predeterminado para aplicaciones de producción que ejecutan código generado por IA.

Salida denegada por defecto: La postura de producción más fuerte es bloquear todas las conexiones salientes por defecto y permitir explícitamente los destinos que una sesión legítimamente necesita. 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 API públicas para las que está construido el agente, 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 destino por sesión o por inquilino.

Política de DNS: El DNS debe manejarse de manera consistente con la política de salida. 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 la red o eludir los 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), API 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.

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

Registro de conexiones salientes: Incluso cuando se permite la salida, 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.

Secretos e Inyección de Credenciales

Los agentes de IA frecuentemente necesitan credenciales: claves 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.

Alcance 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 mal comportado en cualquier sesión puede alcanzar todas esas credenciales.

Credenciales de corta duración: Cuando el backend lo admite, 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 de forma predeterminada; los archivos montados se pueden limitar a una ruta y un 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 reflejar 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 admita la depuración configurable de registros reduce el radio de explosión de una exposición accidental.

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

Almacenamiento de Archivos Efímero vs. Persistente

Diferentes cargas de trabajo tienen diferentes necesidades de persistencia, y un sandbox de producción debe admitir 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, completaciones de código de una sola vez 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 iterativos 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 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 (runtimes, herramientas, dependencias) y lanzar sesiones de manera consistente desde él. Las instantáneas capturan el estado actual de una sesión en ejecución y lo usan como punto de partida para sesiones futuras. Ambas son útiles para equipos que necesitan entornos repetibles y baja latencia de inicio. Verifica que las plantillas tengan versiones, que se controle quién puede crearlas y actualizarlas, 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 tiene la intención de que las sesiones compartan estado o no. El uso compartido accidental, a través de un caché de paquetes compartido, un volumen compartido o un espacio de trabajo mal enrutado, es un fallo de aislamiento multiinquilino común.

Integración 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 los resultados agrega latencia en comparación con las notificaciones push, y transmitir salida de larga duración requiere SSE o consultar un endpoint 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 a medida que 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 muestra o se actúa sobre la salida del sandbox por parte del agente) y la limpieza (activar el desmontaje de la sesión cuando el flujo del 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 deja que tu capa de aplicación construya el comportamiento de producto correcto sobre ellas.

Recuperación de Fallos y Limpieza

Los sistemas de producción fallan. Un sandbox que maneje los fallos con gracia evita 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 limpiamente 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 fallos de sesión: Si el host del sandbox falla o la VM de la sesión sale inesperadamente, la plataforma debe detectar el fallo, 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 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 varias veces en el mismo ID de sesión no debe devolver un error. Esto es importante en la práctica: el código de la 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 su 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 administrada 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 API 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 rápido y repetible del entorno, e integración con las API 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 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 salida, manejo de secretos, modelo de persistencia y soporte de integración backend.

Preguntas Frecuentes

¿Qué modelo de aislamiento debo elegir para el código generado por IA?

El aislamiento de MicroVM proporciona el límite más fuerte para código no confiable generado por IA, pero agrega complejidad operativa. El aislamiento de contenedor es adecuado para cargas de trabajo de menor riesgo cuando el contenedor está correctamente endurecido: 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 delgado para código no confiable que pueda intentar syscalls, generar subprocesos o instalar paquetes. Iguala el nivel de aislamiento a tu modelo de amenaza real.

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

Utiliza listas blancas de registros en lugar de acceso abierto predeterminado. Agrega un caché de extracción para reducir descargas redundantes y darte un punto de inspección. Registra cada intento de instalación con el nombre del paquete, la versión, la fuente y el 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é preinstalado 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 los 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 alcance de las credenciales estrechamente a la tarea, no a un archivo de entorno amplio. Prefiere tokens de corta duración. No registres stdout completo de forma predeterminada 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