Google ya aísla cada agente en su propio microVM. Ahora toca decidir si eso lo integras o lo alquilas
# Un microVM por agente: Google ya no te vende una IA, te vende el aislamiento
Hay una fecha que conviene retener: el 22 de octubre de 2026, en San José, en el AGNTCon + MCPCon de la Linux Foundation, Google Cloud anunció Agent Compute Engine. Un servicio de cómputo donde cada agente de IA tiene su propia microVM aislada por hardware, con su propio kernel invitado y sus propios permisos de root dentro de esa frontera.
La frase importante no es "microVM". Es lo que Google decidió meter dentro de esa microVM: nada. Ni credenciales, ni claves de API, ni tokens de refresco OAuth, ni claves de servicio en memoria o en disco. El agente recibe un certificado SPIFFE público, efímero y con alcance de sesión, más un token de identidad de vida corta. Todo lo demás vive fuera de la máquina y se intercambia en vuelo, en el momento en que la petición sale hacia atrás.
Eso no es una función nueva. Es una respuesta a un problema que ya se había cobrado el precio ya: el aislamiento de agentes dejó de ser un detalle de implementación y pasó a ser la línea de defensa que separa "el agente ejecutó código que no debería" de "el atacante tiene tu nube".
Lo que Google ha dicho exactamente
El anuncio describe una arquitectura en cuatro piezas.
La primera es el límite de aislamiento. Cada sesión de agente corre en una microVM de un solo inquilino detrás de una frontera de Cloud Hypervisor, con kernel invitado propio y root propio. Los anfitriones son appliances sin estado con un sistema de ficheros raíz de solo lectura impuesto por dm-verity, y las claves de atestación quedan en el Titanium, la unidad de procesamiento de infraestructura de Google, fuera del invitado. El marco que Google enuncia en su guía técnica es explícito y no deja margen: asume que un atacante controla todo lo que hay dentro del sandbox y comprueba que allí no encuentra nada que le sirva.
La segunda es la red. La microVM no tiene interfaz de red estándar, no tiene gateway por defecto y no tiene acceso directo a la VPC. Todo el tráfico cruza una frontera virtio-vsock hacia un proxy local y de ahí a una pasarela externa. La consecuencia en la practica es que un agente que inyecta instrucciones no tiene ninguna ruta lateral hacia los activos del proyecto. No es una política de firewall; es la ausencia de interfaz.
La tercera es la identidad y las credenciales, repartidas en tres componentes de gobernanza. Agent Gateway actúa de controlador de tráfico entre clientes y agentes, e integra políticas de protección de datos sensibles, protección contra ataques a agentes y gobernanza semántica. Agent Registry es el registro central y la fuente de verdad sobre qué agentes, herramientas, servidores MCP, habilidades, modelos y endpoints están aprobados. Agent Identity asigna a cada agente un identificador único basado en el estándar abierto SPIFFE, con el papel de firma digital para autenticación, control de acceso y auditoría.
La cuarta es la eficiencia, y es la que más se va a discutir. Las microVM arrancan rápido, comparten memoria mediante copy-on-write sobre una única plantilla de sistema operativo, y cada una tiene su propio Hyperdisk para persistir el espacio de trabajo y el contexto del agente entre sesiones largas. Cuando el agente termina una llamada a una herramienta y entra en la fase de "pensar" del bucle agéntico, la microVM se declara inactiva y el anfitrión la detiene mediante checkpoint y restauración rápidos.
El número que no está, y el número que no es de este servicio
Aquí es donde hay que tener cuidado, y donde cualquier responsable de plataforma se va a hacer la misma pregunta.
Google no ha publicado el precio. Tampoco el número de versión, ni la lista de regiones, ni los límites de CPU y memoria, ni las cuotas, ni la superficie de API o SDK, ni el tiempo de arranque, ni una cifra de densidad para el servicio gestionado, ni siquiera el responsable de producto. La única afirmación quantitativa sobre la plataforma gestionada es que aloja "órdenes de magnitud" más microVMs vivas por nodo que una máquina virtual convencional, lo cual, sin un número detrás, es marketing.
Y hay un segundo malentendido, más caro. Las cifras que circulan de 10x más densidad de cómputo, 500 activaciones por segundo, menos de 500 milisegundos de suspender y reanudar, 200.000 agentes en el banco de pruebas o más de 1.000 agentes dormantes por anfitrión son reales, pero no son de Agent Compute Engine. Son de Agent Substrate, el gemelo de código abierto sobre GKE, disponible desde el 15 de septiembre de 2026. Agent Substrate es un runtime de ejecución para agentes, seguro por defecto, con microVMs de Cloud Hypervisor o sandboxes gVisor, proxies de egreso que inyectan credenciales fuera del alcance del agente, y un plano de control mínimo diseñado para no toparse con los límites del control plane de Kubernetes. Funciona con cualquier harness: Google nombra Claude Code, OpenClaw y Hermes. Está abierto a todos los clientes de GKE para cargas no productivas, y el soporte de producción es solo por lista blanca.
Presupuestar con esas cifras como si fueran el precio del servicio gestionado es un error de una sola dirección.
El mapa ya no tiene huecos
Lo que hace tres años era una decisión de infraestructura hoy es una línea de producto en catálogo. AWS ofrece Bedrock AgentCore Runtime, con microVM dedicada por sesión, ocho horas de sesión máxima, facturación por segundo que normalmente no cuenta la espera de E/S y disponibilidad en 38 regiones. Microsoft ofrece sesiones dinámicas sobre un sandbox de Hyper-V, efímeras y destruidas tras un enfriamiento configurable. E2B usa Firecracker con instantánea al pausar y reanudación de alrededor de un segundo. Conviven Vercel Sandbox, Cloudflare Sandbox SDK, Modal, Daytona y el runtime de políticas OpenShell de NVIDIA, y el dinero lo confirma: E2B ha arrancado más de mil millones de sandboxes, Modal ha levantado 355 millones de dólares con una valoración de 4.650 millones y Daytona ha conseguido una Serie A de 24 millones.
El ordenamiento técnico importa más que el marketing: las microVMs de clase Firecracker dan separación a nivel de hardware y arrancan en menos de 200 milisegundos; gVisor intercepta llamadas al sistema en espacio de usuario, con algo menos de profundidad de aislamiento y a menudo arranques más rápidos para imágenes propias; los contenedores de kernel compartido son los más veloces y los más débiles frente a un escape real.
Una guía de comparación de plataformas agentic resume el estado del arte en cuatro fronteras que deben cumplirse a la vez: aislamiento de cómputo por agente, egreso con denegación por defecto, un espacio de nombres o VPC por inquilino, y credenciales limitadas a una sola ejecución. Tres de cuatro no es aislamiento. Es un motivo por el que la pregunta correcta ya no es "qué motor uso", sino "cuántas de mis cuatro fronterasinny puede el proveedor sostener sin que yo tenga que construirla".
Por qué esta semana el aislamiento dejó de ser abstracción
Hay un recordatorio con fecha del 20 de octubre de 2026, dos días antes del anuncio de Google. Investigadores de Pwn.ai, dentro del concurso de un millón de dólares para comprometer el sandbox de Vercel, describieron una fuga de memoria del anfitrión contra sandboxes de producción y, por separado, la consecución de ejecución de código como root en sistemas controlados por los investigadores. El fallo, con identificador CVE-2026-99999 y nombre PwnEscape, no estaba en el hipervisor KVM sino en la pila de red del kernel Linux del anfitrión: el offload de sumas de comprobación permite que metadatos controlados por el invitado modifiquen una cabecera IPv4 ya validada, y el troceado posterior copia bytes más allá de los datos válidos.
La lección no es "Vercel es vulnerable". La lección es que "el agente corre en un sandbox aislado" es una afirmación que hay que auditar, no una propiedad que se hereda. Un hipervisor puede ser impecable y el host seguir siendo el problema, porque KVM vive dentro del kernel Linux. Cuando Google dice que su microVM está separada por hardware con Titanium sosteniendo las claves de atestación fuera del invitado, la pregunta razonable no es si es cierto, sino qué se rompe si el host es el objetivo.
Y esa es exactamente la razón por la que la decisión de un CTO en octubre de 2026 no se parece a la de 2024. No se trata de elegir un runtime. Se trata de decidir si el aislamiento de agentes es una línea de tu inventario que gestionas tú, con tu parcheo, tu capacidad y tu riesgo residual, o si es un servicio que alguien más parchea por ti a cambio de un número que todavía no ha publicado.
Qué decidir mientras no hay precio
No se puede planear un piloto con esta información, y conviene decirlo con claridad en lugar de rellenar los huecos. Lo que sí se puede hacer es fijar el marco de la decisión antes de que llegue el preview, porque la ventana de la preview es exactamente cuando las decisiones de arquitectura se cierran sin haber mirado la factura.
Empieza por escribir tu propia matriz de las cuatro fronteras. Para cada candidato, incluidos los que ya usas hoy, anota qué frontera cubre el proveedor, cuál cubres tú y cuál no cubre nadie. Esa última columna es la que te va a doler. El caso más frecuente no es un proveedor malo: es un contenedor compartido con denegación de egreso y credenciales de larga duración inyectadas en el contenedor, que es el patrón por defecto en casi toda orquestación de agentes que se ha escrito en los últimos dos años.
Segundo, mide el coste ocioso antes de que te lo cobren. La diferencia entre facturar sólo CPU activa y facturar tiempo de pared mueve el coste real entre dos y cinco veces en cargas idénticas, y las políticas de checkpoint de los agentes idle son justo lo que determina esa factura. Si tu agente pasa el 80% del turno pensando, estás pagando, o vas a pagar, por una máquina encendida. Google afirma que las microVM inactivas se detienen a cero recursos activos y se reanudan desde instantánea; el número que importa es cuánto cuesta un minuto de inactividad, y todavía no lo sabes.
Tercero, aparta el residuo de dato y el de residencia. El modelo de credenciales de Agent Compute Engine asume que tu agente no tiene secretos dentro, lo cual es excelente, pero significa que la autoridad real vive en una pasarela fuera de tu VPC. Tu pregunta de cumplimiento deja de ser "qué puede leer mi agente" y pasa a ser "qué ve y registra la pasarela que intercambia mis credenciales". Sin regiones publicadas, la residencia de datos no es planificable. Pregúntalo por escrito antes de comprometerte.
Cuarto, y esto es lo que va a differentiating: prepárate para la ,exit cost de abstracting la abstracción. Si adoptas un modelo propietario de sesión, de identidad y de checkpoint, cada línea de tu plataforma que dependa de él se convierte en deuda de migración. La alternativa no es escribir tu propio hipervisor, es usar el punto de entrada que Google acaba de abrir con Agent Substrate, que es de código abierto, corre en cualquier clúster de Kubernetes, es portable y funciona con los harnesses que ya usas. Puedes empezar por ahí, sin esperar a la preview, y decidir más adelante si el servicio gestionado te ahorra o te encadena.
El punto
Google ha dado el paso que llevabas un año esperando en otra empresa y que nadie quería poner por escrito: el aislamiento por agente como servicio de computo gestionado, con un microVM dedicado por sesión y con la regla de diseño más dura del sector, que es que no haya nada que robar dentro.
La otra parte que hay que leer con lupa es la otra: el servicio no está disponible, no tiene precio, no tiene regiones, no tiene API publicada, y las cifras que circulan pertenecen a otro producto. La parte que hay que preparar es la tercera: cuando el preview llegue, la conversación va a ser sobre cuánto cuesta una hora de agente, y la única forma de que esa conversación no te sorprenda es tener escrita, antes, tu matriz de fronteras y tu factura ociosa.
El aislamiento deja de ser un problema técnico y pasa a ser un compromiso comercial. Lo bueno es que por fin se puede comprar. La advertencia es que todavía no se puede presupuestar.