Agent Sandbox es un nuevo proyecto de Kubernetes (SIG Apps) que define un workload nativo para correr agentes de IA con aislamiento real — sandbox de kernel con gVisor o VMs con Kata Containers — eliminando el cold start con pools pre-provisionados y manteniendo identidad estable por agente.
En 30 segundos
- Agent Sandbox introduce 4 CRDs nuevos para Kubernetes: Sandbox, SandboxWarmPool, SandboxTemplate y SandboxClaim, publicados el 20 de marzo de 2026 por SIG Apps
- El aislamiento corre sobre gVisor (kernel en user space) o Kata Containers (VM completa), pensado para que agentes IA ejecuten código no confiable sin comprometer el nodo
- SandboxWarmPool elimina el cold start de ~1 segundo manteniendo pods pre-provisionados listos para asignación inmediata
- Soporta scale-to-zero conservando estado, ideal para agentes que pasan horas inactivos entre tareas
- Reemplaza el workaround clásico de StatefulSet + headless Service + PVC por agente, que a escala se vuelve inmanejable
Qué es Agent Sandbox y por qué Kubernetes lo necesitaba
Agent Sandbox es un proyecto del SIG Apps de Kubernetes que define un tipo de workload nativo para agentes de inteligencia artificial. Lo presentaron Janet Kuo y Justin Santa Barbara el 20 de marzo de 2026 en el blog oficial de Kubernetes, y el código vive en el repositorio kubernetes-sigs/agent-sandbox.
El problema que resuelve es concreto. Si hoy querés correr un agente IA en Kubernetes — ponele, uno que audite vulnerabilidades en WordPress o que genere y ejecute código autónomamente — necesitás armar un frankenstein: un StatefulSet de tamaño 1, un headless Service, un PersistentVolumeClaim por agente. Para un agente, zafa. Para cincuenta, es un quilombo operacional.
Los agentes IA no encajan en el modelo de pods transitorios. Son singleton, stateful y long-running. Pueden estar activos semanas manteniendo contexto, y entre medio pasan horas sin hacer nada. Ni un Deployment ni un Job ni un CronJob representan bien ese patrón. Agent Sandbox llena ese hueco con primitivos diseñados específicamente para este caso de uso.
Arquitectura y CRDs principales de Agent Sandbox en Kubernetes
El proyecto define cuatro Custom Resource Definitions construidos sobre primitivos nativos de Kubernetes:
Sandbox
El recurso core. Representa un contenedor single lightweight donde corre el agente. Cada Sandbox recibe hostname estable y network identity persistente — algo que un pod efímero no te da.
SandboxWarmPool
Un pool de pods pre-provisionados listos para asignación. La idea es simple: en vez de esperar que el pod arranque cuando lo necesitás, ya tenés varios calientes esperando. Es una extensión, no parte del core.
SandboxTemplate
El blueprint. Definís acá la configuración de seguridad, los recursos, el runtime de aislamiento, y después lo referenciás desde los Claims. Pensalo como un molde reutilizable. Si te interesa, podés leer más sobre estrategias de microsegmentación y firewalls perimetrales.
SandboxClaim
La solicitud transaccional. Un agente (o un orquestador) hace un Claim contra un Template, y si hay un Sandbox disponible en el WarmPool, lo recibe instantáneamente. Si no, se crea uno nuevo.
Eso sí: tanto WarmPool como Template y Claim son extensiones opcionales. El CRD Sandbox funciona solo si querés algo más simple, pero perdés las ventajas de pre-provisioning.
Aislamiento de seguridad: gVisor vs Kata Containers
Acá viene lo que más nos importa desde seguridad. Cuando un agente IA genera y ejecuta código autónomamente — sin revisión humana — la superficie de ataque se amplifica brutalmente. Si ese agente corre en un cluster multi-tenant donde también vivís tu WordPress, un escape de contenedor te puede costar todo.
Agent Sandbox ofrece dos runtimes de aislamiento, y la elección depende de tu threat model.
| Característica | gVisor | Kata Containers |
|---|---|---|
| Mecanismo | Kernel en user space que intercepta syscalls | VM ligera con virtualización de hardware |
| Nivel de aislamiento | Proceso (syscall filtering) | Hardware (hipervisor) |
| Overhead | Bajo, ideal para agentes compute-intensive con I/O limitado | Mayor, pero con aislamiento más fuerte |
| Mejor para | Agentes que procesan datos pero no ejecutan código arbitrario de alto riesgo | Código completamente no confiable en entornos multi-tenant |
| Escape de contenedor | Muy difícil: el kernel del host no ve las syscalls directamente | Requiere escape de VM, significativamente más complejo |
| Compatibilidad | Buena, pero algunas syscalls no soportadas | Casi completa, corre un kernel Linux real |
Si administrás WordPress en un cluster compartido, la recomendación es clara: Kata Containers para agentes que ejecutan código no confiable, gVisor para el resto. La verdad es que gVisor cubre el 80% de los casos, pero si un agente puede escribir y correr scripts arbitrarios, el aislamiento a nivel VM de Kata te da un margen de seguridad que con gVisor no tenés.
El punto es que antes de Agent Sandbox, configurar esto requería conocimiento profundo de RuntimeClasses, seccomp profiles y pod security standards. Ahora lo definís en el SandboxTemplate y listo.
Eliminación del cold start con SandboxWarmPool
Un segundo. Eso es lo que tarda un pod en arrancar en Kubernetes, incluyendo pull de imagen, scheduling y startup. Parece poco, pero cuando un agente necesita responder a un evento de seguridad — una detección de malware, un intento de login sospechoso — ese segundo puede ser la diferencia entre bloquear el ataque y llegar tarde. Si te interesa, podés leer más sobre plugins gratuitos que amplían WordPress.
SandboxWarmPool mantiene pods ya provisioned y listos. El flujo es directo: creás un SandboxClaim referenciando un SandboxTemplate, el controller busca en el pool, y si hay uno disponible lo asigna. Latencia sub-segundo.
Para agentes que monitorean vulnerabilidades en tiempo real, esto es un golazo. Imaginá un sistema multi-agente donde cada agente audita un aspecto diferente de tu infraestructura WordPress: uno escanea plugins, otro revisa configuraciones de servidor, otro analiza logs de acceso. Si necesitás escalar de 3 a 10 agentes porque detectaste actividad sospechosa, el WarmPool te los da instantáneamente.
Gestión del ciclo de vida y scale-to-zero
Los agentes IA tienen un patrón de uso re particular: ráfagas de actividad intensa seguidas de horas de inactividad. Un agente que audita tu WordPress quizás trabaja 10 minutos cada hora y el resto del tiempo está al pedo consumiendo recursos.
Agent Sandbox permite escalar a cero. El agente se pausa, libera CPU y memoria, pero conserva su estado en disco. Cuando lo necesitás de vuelta, se reanuda sin perder contexto — sin re-cargar el modelo, sin re-leer la configuración, sin perder el historial de conversación.
Las operaciones de ciclo de vida que soporta, según la documentación oficial: creación, eliminación programada, pausa, reanudación, reconexión automática de red, y compartición de memoria entre sandboxes. Eso último es interesante para sistemas donde un agente especialista le pasa contexto a otro.
Identidad estable y comunicación multi-agente
Cada Sandbox recibe un hostname y una network identity que persisten durante toda su vida útil. No es un detalle menor.
En un pod normal de Kubernetes, si el pod se reinicia, pierde su IP y potencialmente su hostname. Para un servidor web stateless eso no importa. Para un agente que mantiene relaciones con otros agentes y necesita ser localizable, es un problema serio. Agent Sandbox resuelve esto con identidad estable, integrada con headless Services para service discovery nativo.
El caso de uso más claro: sistemas multi-agente coordinados para seguridad. Un agente orquestador asigna tareas, un agente scanner busca vulnerabilidades, un agente reporter genera informes. Se necesitan descubrir entre sí, mantener sesiones, y no perder la conexión si uno se pausa y reanuda. Con pods vanilla, armar eso es artesanal. Con Sandbox, viene de fábrica. Si te interesa, podés leer más sobre parches críticos de marzo 2026 en AWS.
Cómo instalar y empezar a usar Agent Sandbox
La instalación es directa. Necesitás un cluster de Kubernetes (1.28+ recomendado) y kubectl configurado.
- Instalá los componentes core:
kubectl apply -f https://github.com/kubernetes-sigs/agent-sandbox/releases/download/vX.Y.Z/manifest.yaml - Instalá las extensiones (WarmPool, Template, Claim):
kubectl apply -f https://github.com/kubernetes-sigs/agent-sandbox/releases/download/vX.Y.Z/extensions.yaml - Para el SDK Python:
pip install k8s-agent-sandbox
Reemplazá vX.Y.Z por la versión que quieras desde los releases del repositorio oficial. GKE de Google Cloud ya tiene soporte integrado, así que si usás ese servicio de donweb.com o cualquier proveedor con GKE, la integración es aún más directa.
El repositorio incluye ejemplos en Python para crear, listar y destruir sandboxes programáticamente. Fijate en el directorio clients/python/agentic-sandbox-client del repo.
Casos de uso reales y por qué le importa a quien administra WordPress
La documentación oficial lista cinco casos de uso principales: agentes autónomos LLM long-running, sistemas multi-agente coordinados, ejecución de código no confiable en sandbox, workloads stateful con identidad persistente, y deployments con scale-to-zero.
Ahora bien, si administrás sitios WordPress a escala — agencia, hosting, o un multisitio corporativo — los tres primeros te tocan directamente. Pensá en agentes que automatizan auditorías de seguridad, que escanean plugins buscando CVEs recientes, que analizan logs de Wordfence o Sucuri para detectar patrones. Todo eso necesita un runtime seguro, persistente y escalable.
El tema es que sin aislamiento real, un agente comprometido puede pivotar al cluster. Y si tu WordPress comparte nodo con ese agente, la cadena de ataque es corta: escape de contenedor, acceso al nodo, lectura de secrets de Kubernetes, credenciales de la base de datos, game over.
Agent Sandbox no es la solución mágica, pero achica esa superficie de ataque significativamente. La visión del proyecto lo dice claro: «el futuro de los agentes es cloud native». Y Kubernetes es la plataforma natural para esa evolución.
Errores comunes
Correr agentes IA en el mismo namespace que producción sin aislamiento
Lo veo todo el tiempo. Alguien monta un agente de automatización en el mismo cluster y namespace donde corre su WordPress, sin NetworkPolicies, sin RuntimeClass, sin nada. Si el agente tiene un bug o es explotado, tiene acceso lateral a todo. Mínimo: namespace separado con NetworkPolicies restrictivas. Ideal: Agent Sandbox con gVisor o Kata. Si te interesa, podés leer más sobre el ataque a Trivy en GitHub Actions.
Ignorar el cold start en agentes de respuesta a incidentes
Si tu agente de seguridad tarda 10 segundos en levantar porque tiene que cargar un modelo, y el ataque dura 5 segundos, no sirvió de nada. Usá SandboxWarmPool para agentes que necesitan respuesta inmediata. No todos la necesitan — un agente de reportes puede arrancar en frío sin drama — pero los que responden a eventos, sí o sí.
Usar StatefulSet para cada agente y no escalar nunca
El approach de StatefulSet + headless Service + PVC por agente funciona para uno o dos agentes. Cuando pasás de diez, el overhead de manifests, la gestión de PVCs huérfanos y la complejidad operacional te come. Agent Sandbox unifica todo en un solo CRD con lifecycle management incluido. Si ya estás en ese punto de dolor, migrar tiene sentido.
Preguntas Frecuentes
Qué es Agent Sandbox en Kubernetes y para qué sirve?
Agent Sandbox es un tipo de workload nativo de Kubernetes, desarrollado por SIG Apps, que define CRDs específicos para correr agentes de IA con aislamiento, identidad estable y gestión de ciclo de vida. Sirve para ejecutar agentes que generan y corren código autónomamente sin comprometer la seguridad del cluster. Reemplaza la combinación manual de StatefulSet + headless Service + PVC que se usaba antes.
Qué diferencia hay entre gVisor y Kata Containers para aislar agentes?
gVisor intercepta syscalls en user space, con menor overhead pero aislamiento a nivel proceso. Kata Containers corre cada sandbox en una VM ligera con virtualización de hardware, más pesado pero con aislamiento más fuerte. Para código no confiable en entornos multi-tenant, Kata es la opción más segura.
Cómo eliminar el cold start de agentes IA en Kubernetes?
Con SandboxWarmPool, una extensión de Agent Sandbox que mantiene pods pre-provisionados listos para asignación inmediata. Hacés un SandboxClaim contra un SandboxTemplate y recibís un entorno ya caliente, con latencia sub-segundo en vez del ~1 segundo que tarda un pod en arrancar normalmente.
Agent Sandbox sirve para seguridad WordPress?
Sí, para cualquier escenario donde agentes IA interactúen con infraestructura WordPress: auditorías automatizadas, escaneo de vulnerabilidades, análisis de logs, respuesta a incidentes. El aislamiento garantiza que un agente comprometido no pueda pivotar al resto del cluster donde corre tu sitio.
Conclusión
Agent Sandbox formaliza algo que la comunidad venía armando con alambre y cinta: un runtime seguro para agentes IA en Kubernetes. Los cuatro CRDs — Sandbox, WarmPool, Template, Claim — cubren el ciclo completo: aprovisionamiento, aislamiento, scale-to-zero y comunicación multi-agente.
Para quienes administramos WordPress en clusters de Kubernetes, lo más relevante es el aislamiento. Cada vez más herramientas de seguridad usan agentes IA, y correrlos sin sandbox es como darle root a un script que no auditaste. Ahora hay una forma nativa y estandarizada de hacerlo bien. El proyecto está en desarrollo activo bajo kubernetes-sigs — todavía no es GA, pero la dirección es clara y la adopción temprana por parte de GKE lo valida.
Si ya corrés agentes en Kubernetes, evaluá migrar a estos CRDs. Si todavía no, al menos asegurate de que cualquier agente que despliegues tenga aislamiento de runtime configurado. El default de Kubernetes — contenedores compartiendo kernel — no alcanza cuando el workload puede escribir y ejecutar código solo.
Fuentes
- Kubernetes Blog – Running Agents on Kubernetes with Agent Sandbox (Janet Kuo, Justin Santa Barbara, marzo 2026)
- kubernetes-sigs/agent-sandbox – Repositorio oficial del proyecto en GitHub
- Agent Sandbox – Documentación oficial del SIG
- Google Cloud Blog – Agentic AI on Kubernetes and GKE
- Google Open Source Blog – Why Kubernetes Needs a New Standard for Agent Execution (noviembre 2025)