Google Cloud Run Sandboxes: Free AI Code Execution Isolation

Google Cloud has introduced Cloud Run Sandboxes into public preview as of July 10, 2026, offering a new way to integrate isolated code execution directly into existing Cloud Run services. This development aims to simplify the process of running AI-generated code safely, addressing a common challenge for AI application teams. Source

Previously, setting up secure environments for code execution, especially for Large Language Model (LLM)-generated code, involved complex setups like E2B or Firecracker MicroVMs. Cloud Run Sandboxes eliminate this complexity by allowing in-service isolation.

What Cloud Run Sandboxes Offer

The core functionality of Cloud Run Sandboxes is to run isolated processes inside your existing Cloud Run instances. By adding a simple flag (--sandbox-launcher) at deployment, a lightweight sandbox binary is added to your execution environment. Your application can then use a sandbox do command to spawn an isolated process, execute commands, collect output, and then self-destruct. All this happens within the resources you're already allocating and paying for in Cloud Run.

Performance is a key highlight, with Google's benchmarks showing an average latency of 500ms for 1,000 sequential sandboxes. Cold starts are reportedly in milliseconds, ensuring that executing AI-generated snippets or commands doesn't create user experience delays.

Built-in Security Measures

The primary benefit for businesses is the robust security architecture. Cloud Run Sandboxes implement three default-deny isolation boundaries:

Credential Isolation

Sandboxes cannot access the host service's environment variables or the Google Cloud metadata server. This means IAM roles, API keys, and other sensitive information associated with your service are not visible to code running within the sandbox.

Network Isolation

By default, sandboxes have no outbound network access. This prevents AI-generated code from attempts to call external services or exfiltrate data. Egress requires an explicit --allow-egress flag per invocation.

Filesystem Isolation

The sandbox accesses the container's filesystem in a read-only mode. Any writes are directed to an ephemeral in-memory layer that disappears when the sandbox terminates, preventing the host environment from being modified.

These security boundaries offer a more secure alternative to simply running subprocesses, combining convenience with effective isolation for untrusted code.

How to Implement

Enabling sandbox support is straightforward during deployment using the gcloud beta run deploy command with the --sandbox-launcher flag. Once enabled, applications can call the sandbox using typical shell commands, creating a safe execution environment for arbitrary code.

For those already using Google's Agent Development Kit (ADK), a CloudRunSandboxCodeExecutor integration is available, simplifying adoption. Detailed documentation is provided on Google's Cloud Run code execution documentation. Source

Cost Efficiency

A significant advantage of Cloud Run Sandboxes is that there is no additional cost beyond your existing Cloud Run expenses. There are no per-sandbox fees, session-time billing, or separate managed service subscriptions. Sandboxes utilize the CPU and memory from your instance's current allocation, meaning you only need to size your instances appropriately for concurrent sandboxes.

This contrasts with alternatives like paid plans from E2B or separate billing for AWS Lambda MicroVMs, making it a cost-effective solution for many AI application teams.

Understanding the Tradeoffs

While highly beneficial, it's important to note the isolation level. Cloud Run Sandboxes provide process-level isolation. For scenarios involving highly adversarial code or extremely sensitive data that demand the strongest guarantees, kernel-level isolation (like Firecracker MicroVMs offered by AWS Lambda MicroVMs) might be more appropriate. AWS Lambda MicroVMs also provide 8-hour state persistence, which Cloud Run Sandboxes do not. Source

Google's broader strategy includes GKE Agent Sandbox, announced at Google Next in May, which uses gVisor for kernel-level isolation on Kubernetes. Cloud Run Sandboxes are designed for developers who prefer a serverless environment without managing Kubernetes clusters.

Business Impact

Cloud Run Sandboxes effectively remove barriers to securely executing AI-generated code, particularly concerning infrastructure costs and complexity. For businesses already using or planning to use Cloud Run for AI applications that generate and execute code, this feature streamlines development and deployment. It establishes a secure default for handling untrusted code, enabling businesses to focus on application logic and feature development rather than complex security infrastructure.

This public preview allows businesses to integrate advanced security for AI operations without overhauling existing Cloud Run architectures.