# Cloud Run sandboxes now work inside jobs and worker pools Google has extended Cloud Run’s sandbox preview beyond request-serving services to jobs and worker pools, so batch and continuous background workloads can execute untrusted or agent-generated code inside isolated same-instance sandboxes. Cloud Run sandboxes now cover all resource types. The August 5 expansion matters for builders whose agents or automation run in batch jobs or continuously pulling workers rather than HTTP services, while the feature remains pre-GA and shares CPU and memory with the host container. - Status: Active - Published: 2026-08-22T22:55:51+12:00 - Updated: 2026-08-22T22:55:51+12:00 - Categories: Artificial Intelligence, Cloud & Infrastructure, AI Agents, Cloud Platforms, Compute & AI Infrastructure - Tags: AI agents, Cloud Run, Google Cloud, sandboxing - Canonical HTML: https://beyondthe.news/dossiers/cloud-run-sandboxes-jobs-worker-pools-untrusted-code ## What changed Google Cloud extended Cloud Run sandboxes to jobs and worker pools on August 5, 2026. Sandboxes had entered public preview for Cloud Run services in July; the expansion means the same isolated code-execution primitive can now be used in run-to-completion jobs and continuous pull-based worker pools. Google documents the sandbox as running inside the same Cloud Run instance as the trusted container while maintaining an isolation boundary for untrusted code. ## Why it matters Many agent and automation workloads do not fit an HTTP request model. Code-generation tasks, data transforms and evaluation runs may be batch jobs, while queue consumers and long-running agents often live in worker pools. Extending the sandbox to those resource types reduces the need to operate a separate microVM or container-cluster isolation layer just to execute untrusted payloads. The trade-offs are important: the feature is still Preview, shares the host instance’s CPU and memory allocation, and does not remove the need to control the trusted container’s own IAM and external credentials. ## The sandbox is no longer limited to request-serving services Google announced Cloud Run sandboxes in public preview in July for services, positioning them as an isolation layer for AI-generated code and other untrusted binaries. On August 5, Cloud Run release notes expanded sandbox support to all resource types, including jobs and worker pools. That opens the primitive to scheduled or run-to-completion work and to continuous non-HTTP workers. ## Jobs gain isolated code execution inside batch workloads Cloud Run jobs can enable the sandbox launcher through gcloud or YAML. Google explicitly calls out agent code, data transformations and scripts as use cases. The sandbox runs within the job instance and shares its allocated CPU and memory, so builders need to size the host for both trusted orchestration and sandboxed execution. ## Worker pools bring the same boundary to continuous agents Worker pools are designed for continuous pull-based work such as queue consumers and other non-HTTP workloads. Sandboxes can now be enabled on those pools as well, allowing an always-on trusted worker to launch isolated executions for untrusted payloads without handing those payloads the worker process itself. ## Isolation does not make the whole workload low-risk The sandbox boundary is only one layer. The host container still has its Cloud Run service identity, networking and any external credentials the application gives it. Builders should keep sensitive orchestration and secret-bearing logic in the trusted container, expose the minimum interface to sandboxed code and treat Preview semantics and support guarantees as changeable. ## Key details - Cloud Run added sandbox support for jobs and worker pools on August 5, 2026. - The original Cloud Run sandbox public preview was announced July 9 for service workloads. - Google describes sandboxes as isolated environments for agent workflows, untrusted payloads and code execution. - Sandboxes run inside the same Cloud Run instance as the host container and share its CPU and memory allocation. - Cloud Run jobs can enable the feature with the sandbox launcher flag or YAML configuration. - Cloud Run worker pools can enable the same sandbox launcher in their revisions. - The feature is subject to Google Cloud Pre-GA terms. ## Builder takeaways - Use the expanded resource support when an agent workload is naturally batch-oriented or continuously pulls work; do not force it into an HTTP service only to obtain a sandbox. - Size job and worker-pool instances for both the trusted host process and concurrent sandbox activity because the resources are shared. - Keep cloud credentials and privileged orchestration in the host process and pass only the minimum inputs into the sandbox. - Exercise failure, timeout and resource-exhaustion behavior before production use because the sandbox remains a Preview feature. - Compare the operational simplicity and economics with dedicated sandbox or microVM providers if isolation is a core product dependency rather than an auxiliary safeguard. ## What to watch - General availability timing and any change to the sandbox isolation or support model. - Dedicated pricing or metering if Google separates sandbox usage from ordinary Cloud Run instance billing. - Concurrency and resource-governance controls for multiple sandboxes inside one job or worker instance. - Additional network, filesystem and IAM controls exposed specifically for sandboxed processes. - Independent security evaluation or production evidence for the isolation boundary. ## Uncertainties - Google's public material describes the isolation model and intended security properties, but BTN did not find an independent security assessment of the Preview implementation. - Because sandboxes share the host instance’s CPU and memory, workload-specific contention and cost behavior will depend on execution patterns. - Pre-GA terms mean API, limits and support guarantees can change before general availability. ## Sources - [Cloud Run release notes](https://docs.cloud.google.com/run/docs/release-notes) — Google Cloud · primary · 2026-08-05T00:00:00+12:00. Official release note confirming sandbox support for all Cloud Run resources, including jobs and worker pools. - [Configure sandboxes for jobs](https://docs.cloud.google.com/run/docs/configuring/jobs/sandboxes) — Google Cloud · primary. Official documentation for enabling sandboxes in Cloud Run jobs, including Preview status and shared-resource behavior. - [Configure sandboxes for worker pools](https://docs.cloud.google.com/run/docs/configuring/workerpools/sandboxes) — Google Cloud · primary. Official documentation for enabling sandboxes in Cloud Run worker pools and the intended untrusted-code use cases. - [Safely run AI-generated code in Cloud Run sandboxes](https://cloud.google.com/blog/topics/developers-practitioners/google-cloud-run-sandboxes-are-in-public-preview/) — Google Cloud · primary · 2026-07-09T00:00:00+12:00. Original public-preview announcement describing the isolation use case and positioning.