Introducción
La proliferación de agentes autónomos de IA ha revelado una deficiencia crítica en la infraestructura cloud tradicional: los contenedores carecen del aislamiento necesario para ejecuciones con permisos de root, mientras que las máquinas virtuales convencionales introducen latencias de arranque incompatibles con los bucles de herramienta de alta frecuencia. Google identifica este problema como el motor detrás del desarrollo de su nueva plataforma, que ahora está disponible en vista previa para usuarios de Google Cloud.
El núcleo del desafío no es solo escalar, sino garantizar que un agente comprometido por instrucciones maliciosas (prompt injection) no pueda escapar de su entorno ni exfiltrar credenciales. A medida que los agentes de Gemini, Antigravity y los pipelines de entrenamiento de modelos de Google se convierten en consumidores masivos de cómputo, la necesidad de una infraestructura dedicada, que combine la eficiencia de los microVMs con un modelo de seguridad cero-confianza, se vuelve imperativa para cualquier equipo de SRE que despliegue LLMs en producción.
Qué ocurrió
Google anunció en la conferencia AGNTCon+MCPCon de la Linux Foundation en San Jose que el Agent Compute Engine (ACE), la infraestructura interna que potencia actualmente sus propios agentes, estará disponible en vista previa para clientes de Google Cloud a finales de este año. Esta plataforma asigna a cada sesión de agente una microVM aislada por hardware, utilizando Cloud Hypervisor como monitor de máquina virtual de código abierto.
La arquitectura difiere de las soluciones de AWS, como Bedrock AgentCore, que también utiliza microVMs (basadas en Firecracker) pero con un modelo de facturación y duración de sesiones distinto. Mientras AWS cobra por memoria hasta que el runtime la recupera y limita las sesiones a ocho horas (extendible a 14 días con instancias EC2), Google ACE se centra en el «checkpointing» agresivo. Cuando un agente termina una llamada a una herramienta y queda a la espera de la respuesta del modelo o del usuario, el host captura un snapshot de la microVM. Este estado congelado consume recursos activos nulos hasta que se reanuda la ejecución, optimizando drásticamente el costo y la densidad de cómputo para cargas de trabajo asíncronas.
Para los equipos que prefieren gestionar su propia infraestructura, Google también ofrece Agent Substrate, un runtime de código abierto que funciona sobre Kubernetes (GKE o cualquier cluster compatible). Substrate actúa como una capa de control ligera sobre el proyecto Agent Sandbox, permitiendo gestionar millones de llamadas a herramientas de corta duración que saturarían un control plane estándar de Kubernetes.
Impacto para DevOps / Infraestructura / Cloud / Seguridad
La introducción de ACE y Substrate cambia el paradigma de cómo se provisionan los entornos de ejecución para agentes. Para los equipos de infraestructura, esto significa que la orquestación de agentes ya no es un problema de scheduling de contenedores, sino de gestión de ciclos de vida de microVMs efímeras y persistentes. La capacidad de «pausar» un agente con su memoria y sistema de archivos intactos, y reanudarlo en milisegundos, permite modelos de negocio donde el costo del cómputo se alinea perfectamente con el tiempo de actividad real del agente, no con el tiempo de espera del LLM.
Desde la perspectiva de seguridad, el impacto es significativo. La nueva plataforma implementa un modelo donde se asume que el atacante controla todo lo que ocurre dentro de la sandbox. Al eliminar interfaces de red estándar y forzar el tráfico a través de un proxy externo (Agent Gateway) que inyecta credenciales solo si la delegación y la identidad de la sandbox son válidas, se mitiga el riesgo de exfiltración de secretos incluso si el agente es vulnerado por una instrucción oculta en un correo electrónico o documento procesado. Esto establece un nuevo estándar de referencia para el aislamiento de cargas de trabajo de IA, desplazando la responsabilidad de la seguridad del código de la aplicación a la arquitectura de la plataforma.
Detalles técnicos
El Agent Compute Engine se construye sobre tres pilares técnicos fundamentales: Cloud Hypervisor, Titan/Titanium IPU, y un modelo de identidad efímero.
Las microVMs ejecutan su propio kernel huésped y otorgan acceso root al agente, lo cual es vital para cargas de trabajo que requieren instalar dependencias, ejecutar scripts de shell o usar navegadores headless. Sin embargo, este acceso está contenido. El host subyacente es un dispositivo de estado sin estado (stateless appliance) con sistema de archivos de solo lectura, cuyo hardware y firmware son verificados criptográficamente en cada arranque mediante la plataforma de seguridad Titan de Google.
La gestión de identidad es radicalmente diferente a la de los contenedores tradicionales. Cada microVM recibe una identidad de sesión de corta duración, entregada a través de un único listener local por VM. No hay secretos persistentes en memoria ni en disco dentro del sandbox. Todo el tráfico de red pasa por un proxy fuera de la sandbox, y las credenciales reales nunca entran al entorno del agente; el Agent Gateway las añade al flujo de tráfico solo después de validar la delegación del usuario y la identidad de la microVM.
Para quienes optan por Agent Substrate en Kubernetes, la densidad es el métrico clave. En un benchmark de 200,000 agentes, Substrate manejó 500 activaciones por segundo, con suspensiones y reanudaciones en menos de 500 milisegundos. Esto se logra mediante un control plane ligero que toma snapshots de la memoria de los agentes inactivos y devuelve la máquina al pool. A diferencia de ACE, Substrate permite elegir entre aislamiento microVM o gVisor, ofreciendo flexibilidad según el nivel de riesgo de la carga de trabajo.
Qué deberían hacer los administradores y equipos técnicos
Los equipos de DevOps y seguridad deberían comenzar a evaluar sus cargas de trabajo actuales de IA para identificar candidatos ideales para esta arquitectura. Si sus agentes ejecutan código no confiable, requieren permisos de root o pasan más del 50% del tiempo esperando respuestas de modelos LLM, el uso de microVMs con checkpointing ofrecerá ahorros de costos y mejoras de seguridad tangibles.
Para quienes gestionan clusters de Kubernetes, es recomendable probar Agent Substrate en un entorno de staging. Dado que funciona con cualquier harness (incluidos Claude Code y Hermes), la integración puede ser gradual. El comando conceptual para desplegar el control plane en un cluster GKE existente implicaría aplicar los manifiestos CRD de Agent Sandbox y Substrate, aunque Google aún no ha liberado el repositorio público completo con instrucciones paso a paso para la versión de producción.
Los responsables de seguridad deben revisar sus políticas de egress. La arquitectura de ACE y Substrate depende de proxies para la inyección de credenciales. Asegúrense de que sus firewalls y políticas de red permiten el tráfico hacia los endpoints de Google Cloud (Agent Gateway) mientras bloquean todo el tráfico directo desde los pods o microVMs hacia internet, excepto a través de los proxies designados. Esto previene exfiltraciones directas si una sandbox se compromete.
Conclusión
Google no está simplemente vendiendo más cómputo; está redefiniendo la unidad básica de ejecución para agentes de IA. Al convertir su infraestructura interna en un servicio público, valida la necesidad de hardware-isolated microVMs para cargas de trabajo agénticas. Para los arquitectos cloud, la lección es clara: la seguridad de los agentes no puede depender solo de filtros de prompt o validaciones de salida. Requiere un aislamiento a nivel de kernel y una gestión de identidad que haga irrelevante lo que ocurre dentro del sandbox. La disponibilidad en vista previa es una señal para comenzar a experimentar ahora, antes de que este modelo se convierta en el estándar de la industria.
Fuentes
https://thenewstack.io/google-agent-compute-engine/