Saltar al contenido
ES EN

Cómo evaluar gVisor como sandbox para agentes de IA, paso a paso

Google dona gVisor y otros dos proyectos a la CNCF. Te proponemos una guía para evaluar si esta sandbox encaja en tu infraestructura de agentes.

IA para programar

Cuando un agente de IA escribe y ejecuta código por su cuenta, la pregunta incómoda es dónde se ejecuta eso. Google ha anunciado que dona tres proyectos de infraestructura para agentes a la CNCF, y entre ellos está gVisor, la sandbox de contenedores que, según The New Stack, usan laboratorios como Anthropic y OpenAI. La idea es repetir el camino que Google ya recorrió cuando donó Kubernetes a la fundación.

Esta guía no es un tutorial de instalación oficial: es un método para evaluar si gVisor encaja en tu caso antes de comprometerte. Nosotros seguiríamos este orden, apoyándonos en la documentación de cada proyecto.

Esquema conceptual de un agente de IA ejecutando código dentro de una sandbox aislada del sistema anfitrión
Un agente ejecuta código generado por un modelo; la sandbox limita lo que ese código puede tocar.

Lo que necesitas

Para seguir la guía necesitas un host Linux de pruebas donde puedas instalar un runtime de contenedores, una carga de trabajo representativa (la que hoy ejecutan tus agentes) y una forma de medir tiempos de arranque y errores. Conviene leer antes la entrada del blog de Google sobre la donación y la lista de adopters para ver quién lo usa y en qué contexto.

  1. Define qué código ejecutan tus agentes y qué no debería poder hacer: red, sistema de ficheros, procesos.
  2. Revisa la documentación de gVisor y confirma que tu versión de Linux y tu runtime de contenedores son compatibles.
  3. Ejecuta la misma carga en un contenedor convencional y en uno con gVisor, y compara arranque, rendimiento y errores.
  4. Revisa qué llamadas al sistema falla o ralentiza tu carga y anota las incompatibilidades.
  5. Decide si gVisor basta o si necesitas capas adicionales de aislamiento.

Qué cambia con la donación a la CNCF

gVisor nació en Google y se publicó como código abierto hace tiempo. Lo nuevo es el gobierno: el proyecto pasa a una fundación neutral, algo que Google comunicó en el blog del propio proyecto. Junto a él viajan Agent Substrate y OpenRL, este último presentado en junio para ajustar modelos de lenguaje en infraestructura propia.

Para quien construye sistemas, el valor práctico es la neutralidad: más difícil que un solo proveedor cambie las reglas. Pero una donación no es una garantía de rendimiento ni de madurez, y eso solo lo vas a comprobar tú midiendo.

# Plantilla para anotar tu comparativa (sustituye por tus medidas reales)
# carga: <nombre de tu carga de trabajo>
# runtime_base:   arranque=<ms>  p95=<ms>  errores=<n>
# runtime_gvisor: arranque=<ms>  p95=<ms>  errores=<n>
Truco No juzgues la sandbox con una prueba sintética. Usa tareas reales de tus agentes: es donde suelen aparecer las llamadas al sistema que más penalizan o que directamente no funcionan. Y recuerda que ninguna sandbox sustituye a limitar permisos y credenciales de entrada. Los equipos que publican cómo contienen a sus agentes, como Anthropic, combinan varias capas.
Tabla comparativa de tiempos de arranque y errores entre un contenedor convencional y uno con sandbox
Anota tus propias medidas: son las únicas que importan para tu caso. Imagen: Unsplash — chart

Fuente original: thenewstack.io

Artículo generado mediante AI.larebelion

Kernel

· Dirección de tecnología · España

«Una sandbox buena se mide en milisegundos y en syscalls que fallan, no en comunicados de donación.»

Comentarios