Google Cloud lanzó un servicio gestionado de GKE Agent Sandbox, mientras que el proyecto de código abierto kubernetes-sigs/agent-sandbox aporta la misma capacidad a cualquier clúster de Kubernetes. Ambos ofrecen a los desarrolladores un contenedor Linux desechable para agentes de IA, dejando el resto de la infraestructura intacta.
Por qué el código generado por IA necesita un entorno de pruebas
Los agentes de IA modernos no solo responden preguntas. Escriben scripts, navegan por la web, ejecutan comandos de shell e incluso lanzan servicios web. Ese poder crea una brecha de seguridad: el código que generan puede tener errores, ser malicioso o demasiado agresivo. Un agente que ejecute rm -rf / o se conecte a una base de datos interna sin permiso puede comprometer todo un sistema.
Un sandbox aísla a cada agente en su propio contenedor: una máquina virtual diminuta y desechable. Si el agente se comporta de forma indebida, el daño se queda dentro de ese contenedor; el host y las demás cargas de trabajo permanecen seguros. La nueva oferta de GKE y el proyecto impulsado por la comunidad convierten esta idea en un servicio listo para usar.
Dos formas de obtener un sandbox
- GKE Agent Sandbox – un servicio totalmente gestionado para clientes de Google Cloud.
kubernetes-sigs/agent-sandbox– un proyecto de código abierto para cualquier clúster de Kubernetes.
Ambos comparten la misma arquitectura central, construida sobre primitivas estándar de Kubernetes.
Cómo se compone el sistema
| Componente | Función |
|---|---|
| Sandbox | El contenedor aislado que ejecuta el código del agente. Tiene un nombre estable y almacenamiento persistente si es necesario. |
| SandboxTemplate | Una plantilla que define la imagen del contenedor y las políticas de seguridad: una receta para nuevos sandboxes. |
| SandboxClaim | Una solicitud emitida por un agente (o su controlador) para levantar un sandbox a partir de una plantilla específica. |
| SandboxWarmPool | Un pool de sandboxes precreados listos para entregarse al instante. Mantener los contenedores "calientes" (warm) evita la latencia de descargar imágenes e iniciar un nuevo pod cada vez. |
Cuando un agente necesita un entorno, publica un SandboxClaim. El controlador comprueba el pool de sandboxes listos (warm pool), elige uno que esté inactivo y lo vincula a la solicitud. Si el pool está vacío, crea un sandbox nuevo a partir de la plantilla; de lo contrario, la entrega ocurre en milisegundos.
Ajustes de seguridad que puedes realizar
- Red con denegación por defecto – Por defecto, un sandbox no puede acceder a la red interna. Debes añadir reglas explícitas para permitir conexiones entrantes o salientes, evitando la exposición accidental de servicios internos.
- Niveles de aislamiento – Elige el tiempo de ejecución de contenedores (container runtime) que se ajuste a tu tolerancia al riesgo:
- Contenedores estándar para mayor velocidad,
- gVisor para una capa adicional de aislamiento en el espacio de usuario, o
- Kata Containers para un aislamiento asistido por hardware que se comporta como una VM ligera.
- SDKs – Las librerías de cliente para Python y Go permiten a los desarrolladores crear, solicitar y destruir sandboxes de forma programática, adaptándose al flujo de trabajo de los pipelines impulsados por IA.
Quién se beneficia y quién podría oponerse
Conclusión
Dar a los agentes de IA su propia caja de Linux desechable elimina la mayor incógnita