- Modelos de Aislamiento del Sandbox
- Egreso del Sandbox y Política de Red
- Acceso a Archivos y el Sistema de Archivos del Anfitrión
- Estado de la Sesión y Persistencia
- Instalaciones de Paquetes y Dependencias en Tiempo de Ejecución
- Manejo de Secretos y Credenciales
- Registros de Auditoría y Observabilidad
- Cumplimiento y Revisión de Seguridad
- Precios del Sandbox y Factores de Costo
- Autoalojamiento vs. Sandbox de Agente de IA Administrado
- Artículos Recomendados
Modelos de Aislamiento del Sandbox
¿Qué significa “aislamiento” en un sandbox de agente de IA?
Aislamiento significa que el código, archivos, procesos y acceso a la red del agente están confinados a un entorno acotado que no puede afectar al sistema anfitrión ni a otros inquilinos. En la práctica, el aislamiento es un espectro: el aislamiento a nivel de proceso utiliza primitivas del SO (namespaces, cgroups, seccomp) para restringir las llamadas al sistema y el acceso a recursos; el aislamiento de contenedor añade un límite de sistema de archivos y espacio de nombres de red; y el aislamiento de microVM envuelve la carga de trabajo en una máquina virtual ligera con su propio kernel invitado. Cada paso hacia arriba en la pila aumenta la solidez del límite a costa de cierta sobrecarga de inicio y complejidad operativa. Consulta Firecracker para Sandboxes de Agentes de IA para un marco de evaluación detallado.
¿Es Docker suficiente para ejecutar código generado por agentes?
Los contenedores proporcionan imágenes repetibles y buenos controles de recursos, pero todos los contenedores en el mismo anfitrión comparten el kernel del anfitrión. Una vulnerabilidad del kernel, o una llamada al sistema que se escape del filtro seccomp, puede afectar a otras cargas de trabajo. Para tareas de bajo riesgo y corta duración que ejecutan código confiable o casi confiable, los contenedores suelen ser adecuados cuando se endurecen correctamente —sin modo privilegiado, capacidades mínimas, sin montar el socket de Docker, sistema de archivos raíz de solo lectura cuando sea posible. Para código no confiable generado por IA que puede instalar paquetes, generar subprocesos o ejecutar comandos arbitrarios del shell, vale la pena evaluar un límite más fuerte. La respuesta depende de tu modelo de amenaza real. Consulta Sandbox de Código Generado por IA: Requisitos para Aplicaciones de Producción para la lista de verificación en cada nivel de aislamiento.
¿Cuál es la diferencia entre el aislamiento de contenedor y de microVM?
La diferencia clave es el límite del kernel. Los contenedores comparten el kernel del anfitrión; las microVM ejecutan cada una un kernel invitado dentro de una máquina virtual ligera, respaldada por virtualización de hardware (KVM). Un sandbox basado en microVM que utiliza tecnología como Firecracker proporciona un límite de tipo VM sin la sobrecarga completa de una VM tradicional: la latencia de inicio está diseñada para ser rápida, el modelo de dispositivos es mínimo para reducir la superficie de ataque, y el invitado está aislado del kernel del anfitrión por diseño. La implicación práctica es que una explotación del kernel en el invitado no afecta automáticamente al anfitrión ni a otros invitados, mientras que en un modelo de contenedor con kernel compartido podría hacerlo. Consulta Firecracker para Sandboxes de Agentes de IA para saber dónde ayuda el límite de microVM y dónde no resuelve todo el problema.
¿Existe un sandbox por agente, por usuario o por tarea?
Eso depende de la plataforma y de cómo esté diseñada la aplicación. El patrón más seguro para aplicaciones multiinquilino es un entorno de sandbox aislado por ejecución de agente o por tarea, lo que significa que la sesión de cada usuario tiene su propio árbol de procesos, sistema de archivos, espacio de nombres de red y alcance de credenciales. Compartir un sandbox entre usuarios o entre tareas no relacionadas es la fuente más común de fuga de estado en aplicaciones de agentes en producción. Al evaluar una plataforma, verifica que las sesiones concurrentes estén aisladas a nivel de sistema de archivos, proceso y red, no solo a nivel de enrutamiento de API. Consulta Sandbox de Código Generado por IA: Requisitos para Aplicaciones de Producción para la lista de verificación de aislamiento por sesión.
Egreso del Sandbox y Política de Red
¿Puede un agente de IA realizar llamadas de red salientes desde un sandbox?
Depende de la política de egreso del sandbox. Por defecto, muchos sandboxes permiten conexiones salientes, lo cual es conveniente para investigación web, llamadas a API e instalación de paquetes. Para cargas de trabajo de producción que ejecutan código no confiable, el egreso abierto por defecto es un riesgo: un agente comprometido o con mal comportamiento puede exfiltrar datos, alcanzar servicios de metadatos internos o extraer código inesperado de URL arbitrarias. Una postura de producción más sólida es el egreso denegado por defecto con una lista blanca explícita de destinos permitidos. Cualquiera que sea la política que elijas, debe ser explícita y estar registrada. Consulta Firecracker para Sandboxes de Agentes de IA para saber cómo evaluar los controles de red.
¿Cómo se controla el DNS en un sandbox?
El DNS es una brecha común en la política de egreso: una lista blanca para destinos HTTP no restringe automáticamente la resolución de DNS. Un agente que puede resolver nombres de dominio arbitrarios puede inferir la topología de la red, sondear nombres internos o usar DNS como canal secundario incluso cuando HTTP está bloqueado. Para una política de egreso coherente, la resolución de DNS debe manejarse de manera consistente, ya sea apuntando a un resolvedor interno que respete la lista blanca o restringiendo la resolución a dominios aprobados. Verifica con tu proveedor de sandbox cómo se define el alcance del DNS en relación con la política de egreso más amplia.
¿Cómo se controlan las descargas de paquetes durante sesiones con restricciones de red?
Las instalaciones de paquetes son operaciones de red. Si el egreso está restringido a una lista blanca, la lista blanca debe incluir los registros de paquetes que el agente necesita legítimamente, o el sandbox debe proporcionar un caché de extracción directa dentro de la red de confianza. El caché de extracción directa tiene el beneficio adicional de servir como punto de inspección: puedes ver qué paquetes se obtienen, detectar dependencias inesperadas y reducir el egreso redundante. Algunos equipos usan plantillas de sandbox preconfiguradas para cargas de trabajo donde la reproducibilidad importa más que la flexibilidad, lo que elimina por completo las descargas de paquetes en tiempo de ejecución. Consulta la sección Instalaciones de Paquetes para obtener más información sobre cómo gobernar las instalaciones en tiempo de ejecución.
Acceso a Archivos y el Sistema de Archivos del Anfitrión
¿Qué acceso a archivos tiene un agente en un sandbox?
Un agente en un sandbox debería tener acceso solo a los archivos explícitamente montados en su espacio de trabajo. Para un agente de codificación, podría ser un repositorio clonado y un directorio de trabajo para artefactos generados. Para un agente de análisis de datos, podría ser un CSV cargado y una carpeta de salida. El agente no debería poder acceder al sistema de archivos del anfitrión, a los espacios de trabajo de otros inquilinos, a los secretos del servidor de aplicaciones ni a los directorios del sistema fuera de sus rutas montadas. Una buena práctica es montar el material fuente como solo lectura y proporcionar un directorio de salida separado de lectura y escritura para los artefactos generados. Consulta Sandbox de Servidor MCP: Servidores MCP Aislados con Sistema de Archivos, Secretos y Controles de Red para saber cómo definir el alcance de los montajes del sistema de archivos por herramienta.
¿Es accesible el sistema de archivos del anfitrión desde dentro de un sandbox?
No debería serlo. Un sandbox correctamente configurado —contenedor o microVM— restringe la vista del agente a su propio sistema de archivos invitado. Acceder al sistema de archivos del anfitrión desde dentro de un sandbox es un fallo de configuración, no un comportamiento esperado. Los errores comunes que rompen este límite incluyen montar directorios amplios (como el directorio de inicio de un desarrollador o /), usar el modo privilegiado en contenedores o montar el socket de Docker dentro del sandbox. Al evaluar una plataforma o construir la tuya propia, verifica qué está montado, cuáles son los permisos del sistema de archivos raíz y si los escapes de enlaces simbólicos o los trucos de extracción de archivos pueden alcanzar rutas fuera del espacio de trabajo previsto.
¿Qué sucede con los archivos después de que finaliza una sesión?
Para sesiones efímeras, el directorio de trabajo y todos los archivos generados se destruyen cuando la sesión termina. Este es el valor predeterminado correcto para la finalización de código, ejecuciones de evaluación y cualquier tarea donde la reproducibilidad importe más que la continuidad. Para espacios de trabajo persistentes (agentes de codificación de larga duración, sesiones de desarrollo iterativas), los archivos pueden sobrevivir a múltiples llamadas de ejecución dentro de una sesión y pueden conservarse después de que la sesión finalice si la plataforma admite la persistencia del espacio de trabajo o instantáneas. Las preguntas clave a responder son: ¿quién posee un espacio de trabajo retenido?, ¿cuándo se limpia? y ¿puede el espacio de trabajo de un usuario filtrarse al de otro? Consulta Sandbox de Código Generado por IA: Requisitos para Aplicaciones de Producción para la lista de verificación del modelo de persistencia.
Estado de la Sesión y Persistencia
¿Una sesión de sandbox es con estado o efímera?
Ambos patrones existen y sirven para diferentes cargas de trabajo. Las sesiones efímeras comienzan desde una línea base limpia para cada tarea, sin paquetes, archivos ni historial acumulados. Son más fáciles de razonar e ideales para ejecuciones de evaluación o ejecución de código de una sola vez. Las sesiones con estado conservan archivos, paquetes instalados, historial del shell y el estado del entorno a través de múltiples llamadas de ejecución, lo cual es necesario para agentes de codificación de múltiples pasos, análisis de datos interactivos y flujos de trabajo de larga duración. La mayoría de las plataformas de producción admiten ambas. La compensación es que las sesiones con estado requieren políticas de limpieza explícitas y un aislamiento de inquilinos más cuidadoso.
¿Cuánto tiempo persiste el estado en un sandbox administrado?
La duración de la sesión varía según la plataforma y el plan. Algunos proveedores establecen un tiempo de espera de sesión predeterminado (comúnmente de 60 minutos a 24 horas), después del cual la sesión se termina y el estado se pierde a menos que se persista en una instantánea o almacenamiento externo. Los flujos de trabajo de agentes de larga duración —sesiones que pueden pausarse entre llamadas de LLM durante minutos u horas— necesitan una plataforma que admita la pausa y reanudación de la sesión o la pausa automática para evitar la facturación por tiempo inactivo mientras se conserva el estado. Verifica la duración máxima de la sesión y qué sucede con el estado en curso cuando se produce un tiempo de espera. Novita Agent Sandbox admite sesiones de hasta 24 horas y documenta una capacidad de Pausa/Reanudación Automática para gestionar el tiempo inactivo. Consulta Novita Sandbox: Una Alternativa Rentable a E2B Pro con Compatibilidad Perfecta para una comparación de funciones.
¿Se pueden pausar y reanudar las sesiones?
Algunas plataformas admiten la pausa y reanudación, donde la sesión se suspende en disco y puede reiniciarse más tarde desde el mismo estado. Esto es útil para agentes que esperan respuestas de LLM entre pasos, para limitar la velocidad de cargas de trabajo costosas y para sesiones que abarcan múltiples interacciones de usuario a lo largo del tiempo. Las cosas clave a verificar son: cuánto tiempo puede permanecer suspendida una sesión en pausa, qué sucede con las conexiones de red mantenidas durante una pausa, y si las credenciales inyectadas al inicio de la sesión siguen siendo válidas después de la reanudación o deben actualizarse.
¿Se puede capturar y reutilizar el estado del sandbox?
Las plantillas y las instantáneas son conceptos relacionados pero distintos. Una plantilla es un entorno base preconstruido —tiempos de ejecución, herramientas, paquetes aprobados— desde el que se inician nuevas sesiones. Una instantánea captura el estado actual de una sesión en ejecución y lo utiliza como punto de partida para sesiones futuras. Las plantillas reducen la sobrecarga de inicio por sesión y garantizan que todos los agentes comiencen desde una línea base consistente y gobernada. Las instantáneas son útiles para preservar trabajo parcial o reiniciar trabajos iterativos. Ambas necesitan gobernanza: quién puede crearlas, quién puede leerlas, a qué inquilino pertenecen y cómo se versionan.
Instalaciones de Paquetes y Dependencias en Tiempo de Ejecución
¿Pueden los agentes instalar paquetes en tiempo de ejecución?
La mayoría de los entornos de sandbox permiten instalaciones de paquetes en tiempo de ejecución (pip install, npm install, apt-get, etc.) por defecto porque muchas cargas de trabajo de agentes las necesitan. La cuestión no es si las instalaciones están permitidas, sino si cada instalación está gobernada. Las instalaciones de paquetes no controladas son una de las operaciones de mayor riesgo en un sandbox: extraen código externo al entorno de ejecución en tiempo de ejecución, pueden incluir scripts post-instalación que ejecutan comandos arbitrarios y pueden introducir riesgos en la cadena de suministro.
¿Qué políticas rigen las instalaciones de paquetes en tiempo de ejecución?
Una política de paquetes de producción suele incluir alguna combinación de listas blancas de registros (obtener solo de registros o espejos de paquetes aprobados), cachés de extracción directa (inspeccionar lo que entra antes de que se ejecute), registro de instalaciones (registrar el nombre del paquete, versión, origen y resultado para cada instalación) y modo fuera de línea opcional (preconfigurar dependencias en la plantilla y no permitir instalaciones en tiempo de ejecución para pipelines de evaluación donde la reproducibilidad es importante). La política correcta depende de la carga de trabajo: un agente de codificación que ayuda a un desarrollador a depurar código puede necesitar acceso flexible a paquetes; un pipeline de evaluación automatizado probablemente debería ejecutarse desde un entorno congelado. Consulta Construye un Analista de Datos de IA con Python en Sandbox y Acceso Controlado a Paquetes para un ejemplo de implementación práctica.
Manejo de Secretos y Credenciales
¿Cómo se manejan los secretos y las credenciales en un sandbox?
Los secretos deben inyectarse de manera estrecha —solo la credencial que necesita una tarea específica, durante la duración de esa sesión. El antipatrón común es montar un archivo de entorno amplio que contenga todas las claves de API en cada sesión; esto significa que cualquier sesión, si se ve comprometida, puede acceder a todas las credenciales de ese archivo. Prefiere tokens de corta duración con alcance limitado a la tarea y prefiere mecanismos de inyección (variables de entorno o archivos montados) en lugar de codificarlos. Para las credenciales más sensibles, una API de secretos en tiempo de ejecución que proporciona valores solo a un proceso explícitamente autorizado ofrece un aislamiento más fuerte que una variable de entorno plana disponible para todos los procesos.
¿Puede el modelo ver las variables de entorno inyectadas en el sandbox?
Sí, si la variable de entorno se inyecta en el proceso donde se ejecuta el código del modelo. Las variables de entorno son visibles para todos los procesos en la misma sesión por defecto. El modelo no puede leerlas directamente desde su ventana de contexto, pero el código generado que se ejecuta dentro del sandbox puede leerlas con os.environ, process.env o equivalente. Es por esto que el alcance estrecho es importante: solo inyecta las credenciales que requiere la tarea y prefiere tokens de corta duración para que una credencial filtrada tenga una ventana de utilidad limitada. La redacción es responsabilidad de la aplicación: no registres la salida estándar completa por defecto si los secretos pueden aparecer en mensajes de error o declaraciones de impresión.
¿Qué sucede con los secretos cuando finaliza una sesión?
Las variables de entorno y los archivos de secretos montados deben limpiarse como parte del cierre de la sesión. Si la plataforma conserva el estado entre sesiones (instantáneas, volúmenes persistentes), verifica que las credenciales escritas en el sistema de archivos o almacenadas en caché por un proveedor de credenciales también se limpien o roten. Las credenciales obsoletas en una instantánea reanudable son un riesgo: después del cierre de la sesión, la instantánea no debe retener tokens que solo eran válidos para la duración de la sesión original.
Registros de Auditoría y Observabilidad
¿Qué eventos se registran en un sandbox?
Los registros de auditoría útiles del sandbox incluyen la creación y el cierre de la sesión (ID de sesión, inquilino, versión de la plantilla, asignación de recursos, duración), eventos de ejecución (qué código o categoría de comando se ejecutó, hora de inicio/fin, estado de salida), instalaciones de paquetes (nombre, versión, origen, resultado), contactos de red salientes (dominios, IP, puertos), archivos leídos o escritos desde rutas específicas y el resultado de la limpieza. El objetivo es hacer que el comportamiento del agente sea reconstruible a posteriori sin convertir el registro de auditoría en un segundo almacén de secretos. Los archivos de clientes sin procesar, la salida completa de comandos y los avisos completos generalmente no pertenecen a los registros de auditoría a menos que tus controles de retención y acceso estén diseñados específicamente para esos datos.
¿Quién puede acceder a los registros de auditoría?
Los controles de acceso en los registros de auditoría deben limitarse al operador y, cuando corresponda, al inquilino. En plataformas multiinquilino, los registros de auditoría de un inquilino no deben ser visibles para otros inquilinos. Para implementaciones sensibles al cumplimiento, el rastro de auditoría debe ser resistente a manipulaciones, conservarse durante el período requerido y ser accesible para revisores autorizados (equipo de seguridad, oficial de cumplimiento) a pedido. Pregunta a tu proveedor de sandbox qué período de retención de registros se proporciona por defecto, si los registros se pueden exportar a tu propio SIEM o almacenamiento, y qué controles de acceso protegen los datos del registro.
Cumplimiento y Revisión de Seguridad
¿Qué revisión de cumplimiento se necesita antes de usar un sandbox en producción?
Los requisitos específicos dependen de tu industria y jurisdicción, pero las preguntas estándar para cualquier sistema de agente en producción incluyen: qué datos ingresan al sandbox (y si esos datos están sujetos a GDPR, HIPAA, SOC 2 u otros marcos), dónde está alojado el sandbox y si eso satisface los requisitos de residencia de datos, cuál es el modelo de aislamiento y si se puede documentar para un auditor, cómo se gestionan y rotan las credenciales, y cómo es el rastro de auditoría. La mayoría de las revisiones de seguridad también preguntarán si el código generado podría alcanzar bases de datos de producción, superficies administrativas internas o datos de clientes fuera del alcance previsto. Estos son controles arquitectónicos, no solo certificaciones de proveedores.
¿Qué preguntas deberían hacer los equipos de seguridad al evaluar un sandbox de agente de IA?
Una lista de verificación de evaluación práctica para la revisión de seguridad:
- Aislamiento: ¿Cuál es el límite —proceso, contenedor o microVM? ¿Cada sesión de agente está aislada a nivel de sistema de archivos, proceso y red?
- Egreso: ¿Cuál es la política de egreso predeterminada? ¿Se pueden incluir en una lista blanca los destinos salientes? ¿Cómo se controla el DNS?
- Secretos: ¿Cómo se inyectan las credenciales? ¿Están limitadas a la tarea? ¿Se limpian al cerrar la sesión?
- Auditoría: ¿Qué eventos se registran? ¿Quién puede acceder a los registros? ¿Cuál es el período de retención?
- Residencia de datos: ¿Dónde están alojados los sandboxes? ¿Se puede limitar la implementación a una región o cuenta de nube específica?
- Postura de cumplimiento: ¿El proveedor posee certificaciones relevantes (SOC 2, ISO 27001)? ¿Cuál es su modelo de responsabilidad compartida?
- Alcance de la red: ¿Puede un sandbox alcanzar servicios de metadatos internos, API privadas o recursos de otros inquilinos? ¿Cómo se evita el movimiento lateral?
Enmarca estas como preguntas para evaluar, no como requisitos que cualquier proveedor cumple automáticamente. Las afirmaciones de seguridad y cumplimiento en la documentación del proveedor deben verificarse con la documentación actual del producto, no tomarse al pie de la letra. Para equipos con requisitos regulatorios o contractuales, haz que tu equipo de seguridad complete la revisión antes de la implementación en producción, no después.
¿Cuándo es relevante BYOC (trae tu propia nube) o la implementación en VPC?
Los requisitos de residencia de datos, las políticas de seguridad de red o las restricciones regulatorias que prohíben que los datos salgan de una cuenta de nube específica son las razones principales por las que los equipos eligen BYOC o la implementación en VPC en lugar de un servicio administrado compartido. Ejecutar sandboxes dentro de tu propia VPC de AWS o GCP significa que el entorno de ejecución está dentro de tu perímetro de red, se aplican los controles de acceso de tu cuenta de nube y el egreso del sandbox puede regirse por tus políticas de red existentes. La compensación es la responsabilidad operativa: tú gestionas la infraestructura, las actualizaciones y el escalado. Novita Agent Sandbox documenta la implementación BYOC en cuentas de AWS o GCP como una función para equipos con estos requisitos. Verifica la disponibilidad actual y las opciones de configuración en la documentación de Novita Agent Sandbox.
Precios del Sandbox y Factores de Costo
¿Qué impulsa los costos del sandbox?
Los costos del sandbox suelen ser una combinación de tiempo de cómputo (vCPU y memoria facturados por segundo o por minuto), sobrecarga de sesión (una tarifa de inicio por sesión en algunas plataformas), almacenamiento persistente por encima del nivel gratuito incluido y transferencia de datos salientes (egreso). El peso relativo de cada uno depende de tu carga de trabajo: un intérprete de código de sesión corta es principalmente cómputo; un agente de automatización de navegador que descarga archivos grandes puede generar un egreso significativo; un espacio de trabajo de codificación persistente acumulará almacenamiento. El manejo del tiempo inactivo es un diferenciador importante: las plataformas con pausa automática dejan de facturar cuando un sandbox espera una respuesta de LLM, lo que puede reducir los costos significativamente para flujos de trabajo interactivos. Consulta Modelos de Precios de Sandbox para Agentes de IA: Por Sesión, Cómputo, Almacenamiento y Egreso para un desglose detallado de cada eje de precios.
¿Cómo interactúan el tiempo de sesión, el cómputo y el egreso en el costo?
Para la mayoría de las cargas de trabajo, el tiempo de cómputo domina. Una sesión de codificación de 10 minutos en 1 vCPU cuesta más que 1 GB de egreso a tarifas típicas. Pero la interacción es importante para cargas de trabajo específicas: un agente de datos que descarga un gran conjunto de datos de entrenamiento generará cargos de egreso que superan el costo de cómputo. Un agente de navegador que mantiene sesiones abiertas entre turnos de LLM acumulará cómputo inactivo si la pausa automática no está habilitada. El enfoque práctico es estimar cada dimensión contra tu perfil de carga de trabajo real antes de comprometerte con una plataforma. Novita Agent Sandbox factura por segundo según el uso real de vCPU y memoria sin tarifa de inicio por sesión; a mediados de 2026, 1 vCPU tiene un precio de $0.0000098/s. (Fuente: página de precios de Novita AI, verificada en la documentación publicada. Siempre verifica las tarifas actuales antes de la planificación presupuestaria).
Autoalojamiento vs. Sandbox de Agente de IA Administrado
¿Cuándo deberían los equipos autoalojarse en lugar de usar un sandbox administrado?
El autoalojamiento (ejecutar tu propia infraestructura de sandbox, a menudo en Firecracker o una capa de microVM comparable) tiene sentido cuando: los requisitos de residencia de datos o política de red prohíben el uso de un servicio administrado de terceros, el volumen de carga de trabajo es lo suficientemente alto como para que el costo del servicio administrado supere el costo operativo de ejecutar tu propia infraestructura, o el equipo tiene capacidad existente de ingeniería de plataforma y desea control total sobre el modelo de aislamiento, la gobernanza de imágenes y la política de red. El autoalojamiento es más difícil de lo que parece: gestionar kernels, sistemas de archivos raíz, imágenes, instantáneas, limitadores de velocidad, métricas, limpieza y aislamiento multiinquilino es un trabajo real. Consulta Firecracker para Sandboxes de Agentes de IA para conocer el alcance operativo.
¿Cuándo tiene más sentido un sandbox administrado?
Para la mayoría de los equipos que construyen agentes de codificación, herramientas de análisis de datos, flujos de trabajo de automatización de navegadores o pipelines de evaluación, un sandbox administrado es el camino más rápido a la producción. La plataforma se encarga del aprovisionamiento de infraestructura, el endurecimiento de seguridad, las actualizaciones de imágenes, el escalado y la gestión del ciclo de vida. El equipo se centra en la arquitectura del agente, no en los detalles internos del sandbox. La comparación de costos no son solo las tarifas de cómputo en la nube: hay que tener en cuenta el tiempo de ingeniería para construir y mantener la capa de aislamiento, el trabajo de cumplimiento para documentarla y la respuesta a incidentes cuando ocurre algo inesperado. Para equipos sin capacidad dedicada de ingeniería de plataforma, los servicios administrados suelen llegar a producción más rápido y mantienen un costo total de propiedad más bajo. Consulta Modelos de Precios de Sandbox para Agentes de IA para un marco que compare el costo total administrado vs. autoalojado.
¿Qué preguntas deberían hacer los equipos al evaluar proveedores de sandbox administrados?
Preguntas de evaluación prácticas más allá del precio principal:
- ¿Cuál es el modelo de aislamiento por sesión (microVM, contenedor, proceso)?
- ¿Cuál es la política de egreso predeterminada y configurable?
- ¿Qué opciones de gobernanza de instalación de paquetes existen?
- ¿Cómo se inyectan y limpian los secretos?
- ¿Qué datos de registro de auditoría están disponibles y cómo se accede a ellos?
- ¿Cuáles son los límites de duración de la sesión y concurrencia en tu nivel requerido?
- ¿El proveedor admite BYOC o implementación en VPC?
- ¿Cuál es el comportamiento de pausa/reanudación y cómo afecta a la facturación?
- ¿Cómo se comporta la latencia de inicio a escala (grupo activo, instantánea, inicio en frío)?
