Google embeds code isolation directly into Cloud Run
IT Brief reported that Google Cloud has put Cloud Run sandboxes into public preview. Google's own blog confirms the announcement at WeAreDevelopers World Congress on July 9, 2026, and the Cloud Run release notes entry is dated July 8. 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
Enabling the feature requires 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 blocks credential access via environment variables and the metadata server. 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 and 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 and 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, letting ADK agents running on Cloud Run execute code through the sandbox feature in a single line of configuration. 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. Google says that distinguishes the feature from dedicated sandbox hosting platforms that charge high premiums for on-demand virtual machines.
One constraint follows directly from that model. 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. Teams that undersize instances may find this becomes a capacity problem rather than a billing line item, so capacity planning is worth completing 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 specialist microVM services. Whether they replace every sandboxing path depends on each team's existing architecture.
For security and platform leaders, the concrete audit question is whether 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. Given the pre-GA support terms, treating adoption as a controlled pilot rather than a production default is a reasonable starting position.