Les pedimos a los agentes de IA cosas cada vez más alocadas. Escribir código. Navegar la web. Ejecutar comandos de shell. Abrir navegadores. Hacer clic por ahí. Desplegar sitios web. Usar una computadora como lo haría un humano. Y, en su mayoría, lo están logrando.

Pero hay un problema latente que mantiene despiertos a los ingenieros de plataforma:

¿Dónde diablos está corriendo ese código?

Cuando le pides a un agente que “ejecute este script”, “instale este paquete” o “verifique si ese endpoint responde”, en la práctica le estás entregando un arma cargada a un pasante muy entusiasta que ha leído todos los libros de programación pero no tiene absolutamente ningún instinto de supervivencia. Ese código podría ser malicioso. O tener bugs. O simplemente volverse nuclear contra tu sistema host porque el agente decidió hacer rm -rf / pensando que estaba limpiando archivos temporales.

Ahí es donde entran los Agent Sandboxes.

Piénsalo como darle a cada agente su propio contenedor Linux hermético y desechable. Una cunita de VM. Un corralito con paredes de goma donde pueden correr y romper cosas sin tocar jamás tu infraestructura real.

Y lo mejor: esto no es un concepto futurista de vaporware. Google Cloud ofrece Agent Sandbox como una funcionalidad administrada de GKE, y el proyecto open source detrás de las APIs de Kubernetes vive en kubernetes-sigs/agent-sandbox. Puedes correr el controlador open source en tu propio clúster de Kubernetes o usar la integración administrada de GKE.

Qué es realmente GKE Agent Sandbox

Déjame citar la documentación para que estemos en la misma página:

“GKE Agent Sandbox te ayuda a gestionar cargas de trabajo aisladas, con estado y de réplica única en GKE. Está optimizado para casos de uso como runtimes de agentes de IA, donde código no confiable generado por LLM debe ejecutarse en un entorno seguro y de alto rendimiento.”

Traduciendo a español claro: obtienes una forma nativa de Kubernetes para levantar un contenedor único con estado que se comporta como una VM liviana. Tiene hostname estable, almacenamiento persistente que sobrevive reinicios, aislamiento a nivel de kernel y políticas de red que por defecto son “deny all”. Tu agente puede conectarse, hacer lo suyo, desconectarse, volver más tarde y encontrar todo exactamente como lo dejó. O puede ser recolectado tras un TTL y desaparecer sin dejar rastro.

Con un SandboxWarmPool, los sandboxes ya iniciados se pueden asignar en milisegundos, en lugar de esperar que un Pod frío se programe, baje la imagen y arranque. La latencia de cold start sigue dependiendo de tu clúster, scheduler, imagen y runtime.

La arquitectura: CRDs hasta el fondo

Todo está construido sobre definiciones de recursos personalizados (CRDs) de Kubernetes. Hay cuatro principales que importan:

1. Sandbox (el núcleo)

Es la primitiva. Un Pod único con estado, hostname estable, almacenamiento persistente opcional y gestión completa del ciclo de vida. Lo creas y el controlador se encarga del resto: creación del Pod, identidad de red, aprovisionamiento de volúmenes, borrado programado, pausa y reanudación.

Es la respuesta a la pregunta: “Quiero una caja Linux que siga viva para mi agente. ¿Cómo consigo una?“

2. SandboxTemplate (el blueprint)

¿Cansado de escribir el mismo YAML una y otra vez? Las plantillas te permiten codificar la configuración del runtime una sola vez — imagen, límites de recursos, runtime class (gVisor, Kata, estándar), políticas de red, variables de entorno — y reutilizarla en todas partes. Los equipos de plataforma definen las plantillas. Los desarrolladores solo eligen una y listo.

3. SandboxClaim (la solicitud)

Es la abstracción orientada al usuario. En la API actual v1beta1, un desarrollador o un SDK de agente crea un SandboxClaim que referencia un SandboxWarmPool. El warm pool referencia el SandboxTemplate. El controlador adopta un sandbox pre-calentado disponible de ese pool, o crea capacidad según la configuración del pool, y entrega un entorno listo para usar.

Este es el Claim Model en acción. Separas el qué (necesito un sandbox) del cómo (aquí es donde corre en el clúster). Y, honestamente, es el patrón que Kubernetes necesitaba para cargas de trabajo con estado desde hace mucho tiempo.

4. SandboxWarmPool (el truco de rendimiento)

Aquí es donde se pone rápido. Un SandboxWarmPool mantiene un conjunto de instancias de Pod pre-calentadas en estado listo. Cuando llega una solicitud, el controlador asigna un Pod del pool al instante, en lugar de esperar descargas de imágenes y arranques de contenedores.

Los warm pools reducen la latencia de aprovisionamiento manteniendo instancias Sandbox pre-creadas y listas para ser reclamadas. En GKE, los Pod snapshots son una funcionalidad aparte que puede guardar y restaurar el estado del sandbox para pausa/reanudación y recuperación más rápida; no son necesarios para que un warm pool funcione.

Seguridad: Default Deny es el único camino

Hay algo de lo que no se habla lo suficiente. Cuando le das a un agente una caja Linux, le estás confiando acceso de red. Muchas soluciones de sandbox para agentes solo te lanzan un contenedor y te dicen “buena suerte”.

GKE Agent Sandbox implementa una postura de seguridad de red Default Deny. De fábrica, el código dentro de un sandbox no puede acceder a tus redes internas, a tu plano de control de GKE ni a nada que no deba. Tú defines explícitamente las reglas de egress e ingress permitidas en tu SandboxTemplate.

¿Por qué importa esto? Porque la amenaza más realista del código generado por LLM no es “la IA se vuelve consciente y toma el mundo”. Es “la IA escribió un script de Python con un typo que accidentalmente golpeó la base de datos de producción”. Default deny previene el accidente. Las reglas granulares te permiten abrir puertas específicas cuando lo necesitas (por ejemplo, pip necesita llegar a PyPI, tu agente necesita llamar a una API).

Runtimes de aislamiento: elige tu veneno

El CRD de Sandbox es agnóstico al runtime. Puedes combinarlo con:

  • Contenedores estándar — rápidos, familiares, pero con aislamiento mínimo entre cargas de trabajo
  • gVisor — el kernel de espacio de usuario de Google. Te da una segunda frontera de seguridad entre tu contenedor y el kernel host. Es el default recomendado para ejecución de código no confiable.
  • Kata Containers — aislamiento de VM a nivel de hardware. Cada sandbox recibe su propia VM liviana con su propio kernel. El aislamiento más pesado, pero también el más fuerte.

La belleza de la API es que cambiar entre estos es un cambio de campo en tu SandboxTemplate. No rediseñas tu arquitectura. Solo cambias runtimeClassName.

SDKs de acceso programático

No necesitas escribir YAML de Kubernetes para usar esto. Hay librerías cliente de primera clase:

  • Python SDK — cliente de alto nivel para LangChain, Vertex AI Agentic SDK o cualquier framework de agentes en Python. Crea, consulta, gestiona y destruye sandboxes desde tu código de agente.
  • Go SDK — para ingenieros de plataforma que construyen controladores y servicios sobre Agent Sandbox.

Ambos SDKs abstraen el ciclo de vida del claim. Con el Python SDK actual, tu agente crea un sandbox con client.create_sandbox(warmpool="python-sandbox-pool", namespace="default"). Por debajo, el SDK crea un SandboxClaim, el controlador asigna un Sandbox del warm pool y el cliente devuelve un handle para ejecución de comandos y operaciones de archivos.

La tabla comparativa

CaracterísticaGKE Agent Sandbox (administrado)kubernetes-sigs/agent-sandbox (open source)
TipoAdd-on administrado de GKEControlador Kubernetes auto-instalado
CRDsSandbox, SandboxTemplate, SandboxClaim, SandboxWarmPoolSandbox, SandboxTemplate, SandboxClaim, SandboxWarmPool
Velocidad de aprovisionamientoWarm pools reducen la latencia de claim a asignación de escala milisegundoVaría según el clúster; los warm pools evitan el trabajo de cold start
Runtimes de aislamientogVisor es requerido para cargas de trabajo administradasAgnóstico al runtime vía runtimeClassName de Kubernetes
Seguridad de redDefault deny, reglas granulares de egress/ingressConfigurable vía NetworkPolicies estándar de K8s
SnapshotsPod snapshots de GKE integrados con pausa/reanudaciónDependiente de plataforma/runtime; no requeridos para warm pools
SDKsPython + GoPython + Go
Gestión de ciclo de vidaGestionado por Google (upgrades, parches)Auto-gestionado vía controlador
LimitacionesRequiere GKE 1.35.2-gke.1269000+ para soporte completoCompatibilidad específica por release; pinear y probar un release
LicenciamientoSLA de Google CloudApache 2.0
Mejor paraEquipos nativos de Google Cloud que quieren “que funcione solo”Entornos multi-cloud, auto-gestionados y air-gapped

La conclusión práctica

Agent Sandbox resuelve un problema real que se vuelve más urgente cada mes. A medida que los LLMs mejoran generando código, el volumen de código no confiable ejecutado en loops de agentes va a explotar. Cada una de esas ejecuciones es una oportunidad para que algo salga mal.

El enfoque viejo era: “solo córrelo en un contenedor Docker, va a estar bien”. Un contenedor puede tener hostname y volúmenes persistentes, claro, pero un flujo Docker descartable no te da el ciclo de vida Sandbox nativo de Kubernetes, el modelo de asignación claim/warm-pool, la identidad gestionada por controlador ni un runtime de aislamiento más fuerte por sí solo. Esas son las abstracciones que Agent Sandbox está agregando.

Agent Sandbox te da esas primitivas de ciclo de vida y asignación sobre Kubernetes, con SDKs en Python y Go. La fuerza del aislamiento sigue dependiendo del runtime que configures; la funcionalidad administrada de GKE impone gVisor para cargas de trabajo de sandbox.

El proyecto open source bajo kubernetes-sigs/agent-sandbox es la base. El add-on administrado de GKE es la versión “aprieta este botón y funciona”. Ambos valen la pena conocer.

Un reality check (porque nada es perfecto)

La latencia es baja pero no es cero. Incluso con warm pools y Pod snapshots, estás viendo cientos de milisegundos a un segundo para la asignación del sandbox. Para la mayoría de los casos de uso de agentes eso está bien. Para loops en tiempo real que necesitan respuestas sub-100ms, lo vas a sentir.

La gestión de estado es tu problema. Un sandbox tiene estado por diseño. Pero ¿qué pasa cuando una sesión de agente crashea a mitad de ejecución? ¿Mantienes el sandbox? ¿Por cuánto tiempo? El TTL ayuda, pero diseñar tu estrategia de garbage collection es responsabilidad tuya.

La complejidad de políticas de red es real. Default deny es genial para seguridad. Pero la primera vez que tu agente no pueda hacer pip install porque el egress a PyPI está bloqueado, vas a pasar tiempo debuggeando. Y la primera vez que el script de un cliente necesite llegar a una API interna, estarás escribiendo reglas de política. Es manejable. Pero no es cero esfuerzo.

Los costos se acumulan en los warm pools. Cada Pod pre-calentado es un contenedor corriendo que quema CPU y memoria mientras espera. Si mantienes un pool de 20 sandboxes calientes, estás pagando por 20 contenedores ociosos. La pausa/reanudación vía Pod snapshots ayuda a compensar, pero es algo a presupuestar.

El monitoreo es un lienzo en blanco. ¿Tu monitoreo de Kubernetes existente? Probablemente está configurado para Deployments y StatefulSets. Los sandboxes efímeros que viven de segundos a minutos son un desafío de monitoreo distinto. Agregación de logs, métricas, atribución de costos — parte de esto lo vas a construir tú mismo.

Cómo empezar

Si quieres reproducir el setup open source en un clúster de Kubernetes nuevo, la secuencia completa es: instalar el controlador y las extensiones, crear una plantilla de runtime Python ejecutable, crear un warm pool, darle al cliente in-cluster el RBAC requerido y correr el SDK desde un Pod de Python normal.

Los 3 fallos más probables y sus soluciones:

  1. SandboxWarmPoolNotFoundError: SandboxWarmPool "python-sandbox-pool" not found → verifica que el warm pool exista en el mismo namespace: kubectl get sandboxwarmpools -n default
  2. 403 Forbidden mencionando sandboxclaims o sandboxes → revisa el RBAC del ServiceAccount: kubectl auth can-i get sandboxes.agents.x-k8s.io --as=system:serviceaccount:default:sandbox-client -n default
  3. Connection refused en el puerto 8888 → verifica la imagen del Pod del sandbox: kubectl get pods -n default -o custom-columns=NAME:.metadata.name,IMAGE:.spec.containers[*].image,IP:.status.podIP. El sandbox debe correr un servidor runtime que implemente /execute en el puerto 8888; una imagen de Python normal que solo duerme no funcionará con sandbox.commands.run().

En GKE: la funcionalidad administrada requiere GKE 1.35.2-gke.1269000 o posterior. En un clúster Standard existente, Google también requiere un node pool con gVisor habilitado antes de activar Agent Sandbox:

gcloud beta container clusters update "${CLUSTER_NAME}" \
  --location="${LOCATION}" \
  --enable-agent-sandbox

GKE además impone requisitos como runtimeClassName: gvisor, deshabilitar el montaje automático de tokens de ServiceAccount, correr como non-root, eliminar capacidades de Linux, fijar límites de CPU/memoria y programar sobre el node pool de sandbox gVisor. Usa el manifest de despliegue administrado de la guía oficial de GKE en lugar de la plantilla mínima auto-gestionada.

La conclusión final

GKE Agent Sandbox — y el proyecto open source kubernetes-sigs/agent-sandbox sobre el que está construido — es lo que pasa cuando alguien finalmente construye la abstracción correcta para runtimes de agentes. Es nativo de Kubernetes, lo que significa que encaja en la infraestructura existente sin pelear con ella. Es lo suficientemente rápido para uso interactivo. Es seguro por defecto. Y tiene SDKs que permiten a los agentes gestionar sus propios entornos programáticamente.

La era de “solo córrelo en Docker y reza” está terminando. La era de “dale al agente su propia caja Linux, bien aislada, bien gestionada, bien rápida” ya está aquí.

Y, honestamente, ya era hora.

Referencias