La respuesta corta
Los sandboxes de Cloud Run permiten ejecutar código no confiable o generado por IA dentro de su servicio de Cloud Run actual, aislado de modo que, por defecto, no puede leer sus variables de entorno, llamar al servidor de metadatos ni acceder a la red. Google anunció la vista previa pública el 10 de julio de 2026 en el WeAreDevelopers World Congress. Los sandboxes arrancan en milisegundos; en una demostración, un servicio arrancó, ejecutó y detuvo 1,000 de ellos con una latencia media de 500ms. Como comparten la CPU y la memoria ya asignadas a su instancia, usarlos no tiene sobrecoste, y la vista previa es gratuita.
La lectura práctica para los responsables de ingeniería: la parte más difícil de lanzar un agente de IA que escribe y ejecuta código (hacerlo sin entregar a un LLM sus credenciales cloud) ya tiene en Google Cloud una opción por defecto gestionada y barata. No sustituye al modelado de amenazas, pero elimina una gran parte de la fontanería de seguridad sin valor diferencial que los equipos construían a mano.
¿Qué lanzó realmente Google?
El 10 de julio de 2026, en el WeAreDevelopers World Congress, Google Cloud puso en vista previa pública los sandboxes de Cloud Run. Un sandbox es un límite de ejecución ligero y aislado que se crea casi al instante dentro de una instancia de servicio de Cloud Run existente. En lugar de levantar un clúster de contenedores aparte o pagar por un servicio especializado de micro-VM, su aplicación crea un entorno desechable y bloqueado sobre el cómputo que ya tiene, ejecuta en él código no confiable y lo desmonta.
El problema al que apunta es concreto y cada vez más común: ¿cómo ejecutar de forma segura código que escribió un LLM, o que envió un usuario, sin poner en riesgo su aplicación host, sus datos y sus credenciales de Google Cloud? Google lo presenta como respuesta a un cambio que observa en el diseño de aplicaciones, en el que dejar que un modelo escriba y ejecute código (para análisis de datos, navegación o automatización) se está convirtiendo en una parte rutinaria del producto y no en un caso límite exótico. Es el mismo patrón con el que nos encontramos cuando los clientes nos piden construir funciones agénticas: el agente solo es útil si puede actuar, y actuar suele significar ejecutar código que usted no escribió y en el que no puede confiar del todo.
Google señala tres casos de uso concretos. Los intérpretes de código de LLM permiten que un modelo escriba y ejecute Python, R o SQL para analizar un conjunto de datos, generar gráficos o hacer cálculos pesados bajo demanda. Los navegadores headless dan a un agente un lugar contenido para rastrear páginas, hacer capturas de pantalla y automatizar flujos web. Y el código enviado por usuarios de siempre (plugins, scripts, envíos a concursos) puede ejecutarse sin convertirse en un punto de apoyo hacia su servicio. Los sandboxes se están integrando también en el Agent Development Kit (ADK) de Google: un nuevo CloudRunSandboxCodeExecutor permite que un agente de ADK que se ejecuta en Cloud Run ejecute código en una sola línea, y las aplicaciones también pueden crear sandboxes directamente con llamadas de subproceso estándar.
¿Cómo funciona el aislamiento?
El modelo de seguridad se apoya en tres límites, y conviene entenderlos con precisión porque definen lo que la función protege y lo que no. El primero es el aislamiento de credenciales: un sandbox no puede leer las variables de entorno del servicio de Cloud Run ni llamar al servidor de metadatos de Google Cloud. Eso importa porque el servidor de metadatos es la vía habitual por la que una carga de trabajo obtiene los tokens de su cuenta de servicio; sin acceso a él, el código que se ejecuta en el sandbox no tiene camino hacia su identidad ni hacia sus secretos aunque los busque.
El segundo es la salida de red, denegada por defecto. De fábrica, un sandbox tiene cero acceso de red saliente; si el código necesita llegar a una API, usted habilita la salida de forma explícita para esa llamada en lugar de dejar una puerta abierta. Para quien haya visto a un código malicioso intentar exfiltrar datos o «llamar a casa», una postura de red de denegación por defecto es exactamente la adecuada. El tercero es una capa superpuesta segura del sistema de archivos: el sandbox ve el sistema de archivos de su contenedor en solo lectura (de modo que puede usar sus paquetes, runtimes y binarios instalados), pero escribe todo en una capa superpuesta temporal y aislada en memoria que se descarta cuando termina la ejecución. Nada de lo que el código escribe sobrevive, y nada de lo que hace modifica su servicio en ejecución.
Dos hechos operativos completan el cuadro. En cuanto al rendimiento, los sandboxes arrancan en milisegundos, y la demostración de Google ejecutó 1,000 de ellos en un ciclo completo de arranque, ejecución y parada con una media de 500ms cada uno: lo bastante rápido como para que el sandbox por petición sea realista y no un truco solo para lotes. En cuanto al coste, como se ejecutan sobre la CPU y la memoria ya asignadas a su instancia y no sobre VM dedicadas, Google afirma que no hay sobrecoste adicional por usar la función y que es gratuita durante la vista previa pública. Ese modelo de precios es el titular silencioso: ejecutar código aislado ha significado históricamente pagar por invocación a un host de sandbox especializado, e integrarlo en el cómputo serverless que ya paga cambia la economía.
¿Por qué importa ahora?
La ejecución segura de código se ha convertido discretamente en uno de los problemas estructurales de la era de los agentes. Todo framework de agentes serio acaba chocando con el mismo muro: para ser útil, el agente tiene que ejecutar código, y ejecutar código arbitrario junto a su aplicación es la forma de perder sus datos o su cuenta cloud. Los equipos lo han resuelto con gVisor, micro-VM de Firecracker, startups especializadas en sandboxes o un aislamiento elaborado en Kubernetes: todo funciona, y todo supone ingeniería real y coste operativo real. Un sandbox gestionado que vive dentro de su runtime serverless actual reduce esa barrera para una amplia clase de aplicaciones.
También forma parte de una tendencia visible entre las grandes nubes. Google viene lanzando primitivas de aislamiento para agentes en ambos extremos de su espectro de cómputo: un GKE Agent Sandbox para cargas muy basadas en Kubernetes y, ahora, los sandboxes de Cloud Run para el lado serverless. Si su estrategia de plataforma se apoya en Kubernetes, quizá encaje el camino de GKE; si ya es serverless-first en Cloud Run, los nuevos sandboxes le encuentran donde está. En cualquier caso, la señal es que los hiperescaladores tratan ahora «ejecutar este código no confiable de forma segura» como una capacidad de plataforma de primera clase y no como algo que cada equipo reinventa.
Qué significa para los equipos de software de EE. UU. y la UE
Si se deja de lado el lanzamiento, quedan tres implicaciones duraderas. La primera es que la ejecución en sandbox es ya el valor por defecto esperado para los agentes que ejecutan código. Si construye una función de IA que escribe y ejecuta código, dejar que se ejecute dentro del propio proceso ya no es defendible: las herramientas para aislarlo son baratas y están disponibles. Diseñe el límite de ejecución desde el principio; reforzar el aislamiento después de un incidente es el camino caro, y el incidente es de los que acaban en un informe de brecha.
La segunda es que el aislamiento es un control, no un certificado de cumplimiento. Los sandboxes de Cloud Run cortan las credenciales, la red y la persistencia, lo que cierra los agujeros más peligrosos, pero si opera en FinTech o maneja datos regulados, siguen siendo suyas las preguntas más difíciles: qué datos deja entrar en el sandbox, adónde puede dirigirse la salida de red, cómo registra y revisa lo que ejecutó el agente y cómo se corresponde todo eso con el RGPD, SOC 2 o las normas de su sector. Trate el sandbox como una capa más de un diseño de defensa en profundidad y manténgalo dentro de su revisión de seguridad habitual, sin suponer que una función gestionada hace desaparecer el modelo de amenazas.
La tercera es arquitectónica y atraviesa a los proveedores: mantenga intercambiable la capa de ejecución. Los sandboxes de Cloud Run son atractivos, pero también lo son las alternativas, y el panorama del aislamiento cambia deprisa. Ponga la ejecución de código del agente detrás de una interfaz limpia para poder ejecutarla hoy en Cloud Run y moverla (a GKE, a otra nube, a un sandbox autoalojado) sin reescribir el agente. Esa portabilidad es barata de construir ahora y dolorosa de añadir después, y es la misma disciplina que mantiene sostenible cualquier plataforma cloud cuando los proveedores cambian condiciones y capacidades.
Qué hacer ahora
Esta es la versión accionable. Trate los sandboxes de Cloud Run como una señal para plantear bien cómo ejecuta código su agente, adopte o no esta función concreta.
- Aísle la ejecución de código por defecto. Si un agente o un usuario puede ejecutar código, nunca debería ejecutarse en el proceso de su aplicación con acceso a sus credenciales.
- Deniegue red y secretos, y conceda después de forma acotada. Parta de cero salida de red y ningún acceso a credenciales; abra solo las vías concretas que una tarea necesite de verdad.
- Mantenga intercambiable la capa de sandbox. Ponga la ejecución detrás de una interfaz para que Cloud Run, GKE u otro sandbox pueda respaldarla sin reescribir el agente.
- Registre lo que ejecutó el agente. Capture entradas, código y salidas para auditoría y revisión de incidentes; una capa superpuesta descartada es buena higiene, pero no un registro de auditoría.
- Intégrelo en su modelo de amenazas. Un sandbox gestionado es un control; revíselo junto con los flujos de datos, las reglas de salida de red y sus obligaciones de cumplimiento.
- Haga un piloto antes de comprometerse. Las funciones en vista previa cambian; valide la latencia, los límites y el comportamiento con su carga real antes de que quede en una ruta crítica.
Nada de esto es asesoramiento jurídico, y sus obligaciones exactas dependen de su sector y de su jurisdicción. Pero la señal estratégica es clara: ejecutar con seguridad código escrito por IA se está convirtiendo en un valor por defecto resuelto y barato en las grandes nubes, y los equipos que ganan son los que diseñan el aislamiento desde el principio, lo mantienen intercambiable y tratan el sandbox como un control más dentro de una postura de seguridad más amplia.
Preguntas frecuentes
¿Qué son los sandboxes de Cloud Run?
Los sandboxes de Cloud Run son límites de ejecución ligeros y aislados que se crean casi al instante dentro de una instancia de servicio de Google Cloud Run existente para ejecutar de forma segura código no confiable o generado por IA. Google los puso en vista previa pública el 10 de julio de 2026. Un sandbox no tiene acceso a las variables de entorno del servicio, no puede llamar al servidor de metadatos de Google Cloud y, por defecto, no tiene acceso de red saliente, de modo que el código que escribe un LLM no puede alcanzar sus credenciales ni sus datos salvo que usted lo permita de forma explícita.
¿Qué velocidad y qué coste tienen los sandboxes de Cloud Run?
Los sandboxes arrancan en milisegundos. En la demostración de Google, un único servicio de Cloud Run arrancó, ejecutó y detuvo 1,000 sandboxes con una latencia media de 500ms. En cuanto al coste, los sandboxes se ejecutan sobre la CPU y la memoria ya asignadas a su instancia de Cloud Run en ejecución y no sobre VM dedicadas aparte, por lo que no hay sobrecoste adicional por usar la función, y es gratuita durante la vista previa pública.
¿Por qué necesitan los agentes de IA un sandbox de código?
Los agentes de IA escriben y ejecutan cada vez más su propio código, o ejecutan código y scripts enviados por usuarios. Ejecutar ese código no confiable en el mismo proceso que su aplicación expone su host, sus datos y sus credenciales cloud si el código es malicioso o simplemente erróneo. Un sandbox aísla la ejecución, de modo que un intérprete de código de LLM pueda ejecutar Python, R o SQL, o un navegador headless pueda rastrear una página, sin poder leer secretos ni acceder a la red salvo que usted lo permita.
¿Cómo aíslan los sandboxes de Cloud Run el código no confiable?
Tres límites. Primero, credenciales: los sandboxes no pueden leer las variables de entorno del servicio de Cloud Run ni llamar al servidor de metadatos de Google Cloud, así que no pueden obtener los tokens de su cuenta de servicio. Segundo, red: el acceso saliente se deniega por defecto y debe habilitarse de forma explícita en cada llamada. Tercero, sistema de archivos: el sandbox ve el sistema de archivos de su contenedor en solo lectura y escribe los cambios en una capa superpuesta temporal en memoria que se descarta cuando termina la ejecución, de modo que nada de lo que hace persiste en su servicio.
¿Cómo se usan los sandboxes de Cloud Run en un agente?
Su aplicación puede crear sandboxes de forma programática con llamadas de subproceso estándar, y el Agent Development Kit (ADK) de Google incluye un CloudRunSandboxCodeExecutor para que un agente de ADK que se ejecuta en Cloud Run pueda ejecutar código en una sola línea. La función se dirige a tres patrones habituales: intérpretes de código de LLM para análisis de datos, navegadores headless para tareas web de agentes y ejecución segura de scripts o plugins enviados por usuarios.
Fuentes
Google Cloud Blog — Google Cloud Run sandboxes are in public preview (en inglés)
SecurityBrief Australia — Google Cloud puts Cloud Run sandboxes into preview (en inglés)
Google Cloud Documentation — Code execution in Cloud Run (en inglés)