Google embeds code isolation directly into Cloud Run
Google announced Cloud Run sandboxes in public preview at WeAreDevelopers World Congress on July 9, 2026. The Cloud Run release notes entry is dated July 8, 2026. The feature lets developers create isolated execution environments within existing Cloud Run service instances.
Cloud platform engineers and security leads running AI agents are the direct audience. So are platform teams whose products execute user-submitted scripts, plugins, or webhooks.
What the sandboxes do
A developer enables the feature by adding a single flag to a Cloud Run deployment. A lightweight sandbox CLI binary is then mounted automatically. Applications spawn sandboxes through standard subprocess calls.
Three security boundaries define the isolation. Sandboxes do not have access to the Cloud Run service's environment variables and cannot call the Google Cloud metadata server. That removes credential theft as an attack path. Outbound network access is blocked by default. Egress must be explicitly requested.
The filesystem boundary is hard as well. The sandbox runs with a read-only view of the container's filesystem. Writes go to an isolated, temporary memory overlay. Those changes are discarded when execution ends. Developers can still import and export archive files to move data between runs.
On throughput, in one example a Cloud Run service started, executed, and stopped 1,000 sandboxes with an average of 500ms latency. That figure covers the full cycle. It is a specific demonstration, not a general performance guarantee.
Use cases and agent tooling
Core use cases include LLM code interpreters, headless browsers for automated web workflows, and execution of plugins, scripts, or webhooks supplied by end users of platforms hosted on Cloud Run.
The feature connects to Google's agent stack. The next version of Agent Development Kit will include a CloudRunSandboxCodeExecutor. ADK agents can invoke sandboxes in a single line of code. Cloud Run sandboxes have also been added to ComputeSDK, which Google describes as a vendor-agnostic SDK for running sandboxes. That SDK allows sandboxes to be invoked remotely or used directly inside the service.
Cost and capacity
Cloud Run sandboxes run on existing allocated CPU and memory, with no additional cost. That distinguishes the feature from microVM platforms that bill separately per execution.
One constraint follows. Sandboxes share the CPU and memory allocated to the host container. Teams must size their main container limits to cover both the application and any concurrent sandboxes. Analysis: undersized instances become a capacity problem rather than a billing line item, so capacity planning should happen before any production rollout.
The decision that changes now
The feature is subject to the Pre-GA Offerings Terms and might have limited support. That matters directly for production risk decisions.
Cloud Run sandboxes can reduce the need for separate sandboxing systems with container clusters or using specialist microVM services. Whether they replace every sandboxing path depends on each team's existing architecture.
Analysis: treat this as a controlled pilot, not a production default. The concrete audit question for security and platform leaders: do your AI agent workloads execute generated code with access to environment variables or outbound network? If yes, Cloud Run sandboxes offer a direct, low-cost path to removing both exposures inside your existing serverless footprint.