Cloud Run Sandboxes: The Safest Way to Run AI-Generated Code in Production

Generative AI applications and autonomous agents (AI agents) are revolutionizing how software interacts with code, thereby creating a new challenge. Modern AI agents no longer just generate static text, these agents have evolved, dynamically generating codes, write and execute Python scripts, parse datasets, run web scrapers, and invoke external webhooks in real time. If an untrusted code executes inside your main application container, an attacker or a hallucinating LLM could access environment variables, steal service account tokens from the cloud metadata server, or compromise internal networks; this posses massive security risk.
The question becomes, how do you let a language model execute code without putting your infrastructure at risk?

Google recently answered the question above by addressing one of the hardest challenge in AI engineering, which is a fundamental change in how you can safely build AI agents that execute code and it is deeply integrated into the serverless model you already know. Google Cloud introduced Cloud Run Sandboxes in public preview. Woohoo!

What is Google Cloud Run Service Sandbox?

Cloud Run Sandboxes are lightweight, isolated execution boundaries that you spawn near-instantly within your existing Cloud Run service instances. Cloud Run Sandboxes give you a secure, isolated sandbox to run these tasks without leaving your serverless environment.

The key phrase is within your existing Cloud Run service instances. You do not spin up a separate Cloud Run service to act as a sandbox host. You do not provision a new VM. The sandbox runs inside the same instance that is already executing your agent code, isolated from it by two layers of security boundaries, but co-located with it for speed.

When you enable the feature on a Cloud Run service, a sandbox command-line tool is mounted into your execution environment (container), allowing applications to safely start sandboxes through standard subprocess calls without risking the host system.
Think of it as giving your agent a locked room inside your locked building. The agent can go into that room, execute whatever code it needs to, and come back out, but nothing that happens in the room can touch the building's keys, wiring, or front door.

Key Capabilities:

• Millisecond Startup: Spawns fresh execution environments in roughly ~500ms directly inside the active host container.
• Shared Resource Pricing: Runs on your instance’s already-allocated CPU and memory, meaning there are no additional cloud VM charges or specialized third-party vendor markups.
• Strict Ephemerality: Once execution completes, the sandbox process and its filesystem changes are discarded.

Why Use It? (The Security & Operational Benefits)

Historically, sandboxing dynamic code required complex infrastructure setups. Cloud Run Sandboxes are engineered to protect your host application and cloud resources from malicious or erroneous code execution, by establishing three strict Zero-trust security boundaries out of the box:

1. Credential, identity protection and environment isolation: By default, sandboxes do not have access to the parent workload, cannot read host environment variables, secrets, or the Google Cloud metadata server, thereby preventing unauthorized access to project service account tokens. All sandboxes are completely isolated from each other.
This is the boundary that matters most for AI agent workloads. A prompt injection attack that convinces your agent to run malicious code gains nothing, the sandbox has no access to your service account, your Secret Manager values, or the metadata server that would give it a token to act on your behalf.

2. Network Egress Blocked by Default: By default, sandboxes have zero outbound network access from inside the sandbox. If your agent is tricked into running a script that attempts to exfiltrate data to a malicious server, the network request is blocked at the system layer.
Egress is only possible when you explicitly enable it per execution:

# Egress disabled (default) — any outbound network call is blocked
sandbox do -- python3 /tmp/generated_script.py

# Egress enabled — for sandboxes that need to call external APIs
sandbox do --allow-egress -- curl https://api.github.com

This is a meaningful security default. Most code interpretation tasks, data analysis, calculation, text processing, chart generation; require no outbound connectivity. Locking it down by default means a compromised prompt cannot phone home, even if it tries.

3. Safe filesystem overlay (Zero-Trust Process Isolation): Code inside the sandbox operates with limited system permissions and is strictly isolated from neighboring sandboxes and the host process. The sandbox runs with a read-only view of your container's filesystem (allowing it to use your installed packages, Python runtimes, and binaries) but writes all changes to an isolated, temporary memory overlay. Once the sandbox execution ends, all generated files are discarded.

This means your agent's dependencies, runtimes, and tools are available inside the sandbox, it can run python3, use numpy, call playwright; but any files written during execution disappear when the sandbox closes. If you need to persist output across sandboxes, you do so explicitly:

# Write sandbox output to a tar archive that persists outside the sandbox
sandbox do --write --export-tar=/tmp/work.tar \
  -- /bin/bash -c "mkdir -p /tmp/work && echo 'task-complete' > /tmp/work/status.txt"

# Import the archive into a new sandbox
sandbox do --write --import-tar=/tmp/work.tar \
  -- /bin/bash -c "cat /tmp/work/status.txt"

How to Use Cloud Run Sandboxes: Step by step

Step 1: Enabling the feature (sandbox launcher) at deploy time

To use Cloud Run Sandboxes, you need to deploy a Cloud Run service with the feature enabled. Enabling sandboxes on your Cloud Run service is as simple as adding a single flag to your deployment.

gcloud beta run deploy my-app-agentic-service \
  --image=gcr.io/my-project/agent-image \
  --region=africa-south1 \
  --sandbox-launcher \
  --min-instances=1 \
  --concurrency=10

Or via a YAML configuration:

apiVersion: serving.knative.dev/v1
kind: Service
metadata:
  name: my-app-agentic-service
spec:
  template:
    metadata:
      annotations:
        run.googleapis.com/sandbox-launcher: "true"
    spec:
      containers:
      - image: gcr.io/my-project/agent-image
        resources:
          limits:
            cpu: "2"
            memory: 2Gi

Step 2: Spawn sandboxes from your agent code

Once the sandbox launcher is enabled, the sandbox binary automatically becomes available inside your container. Your agents code calls it via standard subprocess execution.
Key subcommands include:

Command	Description
sandbox do	Creates a temporary sandbox, executes a command, and destroys it
sandbox run	Starts a sandbox
sandbox exec	Executes a command in a running sandbox
sandbox tar	Takes a snapshot of the sandbox's filesystem
sandbox delete	Deletes a sandbox

Sample: Executing a Python code or Nodejs code or Go code

Here's a practical example showing how an AI agent uses the sandbox to execute generated code

import subprocess

def run_llm_generated_code(llm_code: str) -> str:
    """
    Safely execute code generated by an LLM inside an isolated sandbox.
    The sandbox has no access to env vars, secrets, or network by default.
    """
    # Write the generated code to a temp file in the host container
    with open("/tmp/generated_script.py", "w") as f:
        f.write(llm_code)

    result = subprocess.run(
        ["sandbox", "do", "--", "python3", "/tmp/generated_script.py"],
        capture_output=True,
        text=True,
        timeout=30   # hard timeout, the sandbox is killed after this
    )

    if result.returncode == 0:
        return result.stdout
    else:
        return f"Execution failed:\n{result.stderr}"

// Node.js agent example
const { execSync } = require('child_process');
const fs = require('fs');

function runUntrustedCode(llmCode) {
  fs.writeFileSync('/tmp/generated_script.py', llmCode);

  try {
    const output = execSync(
      'sandbox do -- python3 /tmp/generated_script.py',
      { timeout: 30000, encoding: 'utf8' }
    );
    return { success: true, output };
  } catch (err) {
    return { success: false, error: err.stderr };
  }
}

// Go agent example
package main

import (
    "bytes"
    "os"
    "os/exec"
)

func runInSandbox(code string) (string, error) {
    // Write code to temp file
    if err := os.WriteFile("/tmp/script.py", []byte(code), 0644); err != nil {
        return "", err
    }

    cmd := exec.Command("sandbox", "do", "--", "/usr/bin/python3", "/tmp/script.py")
    var out, errBuf bytes.Buffer
    cmd.Stdout = &out
    cmd.Stderr = &errBuf

    if err := cmd.Run(); err != nil {
        return "", fmt.Errorf("sandbox error: %s", errBuf.String())
    }
    return out.String(), nil
}

The sandbox do command creates a temporary sandbox, runs the Python code, and returns the output. Because sandboxes don't inherit host environment variables, you must use absolute paths for commands

Step 3: Use the ADK integration (for Gemini-based agents)

Cloud Run Sandboxes are supported in the Agent Development Kit (ADK) with a new CloudRunSandboxCodeExecutor. This integration gives ADK agents running on Cloud Run the ability to execute code in a single line.

from google.adk.agents import Agent
from google.adk.integrations.cloud_run import CloudRunSandboxCodeExecutor

analyst_agent = Agent(
    name="data_analyst",
    model="gemini-3.1-pro-preview",
    system_instruction=(
        "You are an expert data analyst. Write and execute Python code "
        "to answer user questions and process data safely."
    ),
    code_executor=CloudRunSandboxCodeExecutor(),
)

This is the cleanest integration path if you are already building on ADK. The executor handles the sandbox do invocation, output capture, error handling, and result formatting automatically, your agent just writes code and gets results.

Step 4: Use ComputeSDK for vendor-agnostic integration

Cloud Run Sandboxes are also available via ComputeSDK, a vendor-agnostic SDK for running sandboxes. This SDK allows you to either invoke sandboxes remotely from outside the Cloud Run service or use them directly as a local tool on the service.

# Using ComputeSDK with Cloud Run Sandboxes
npm install @computesdk/cloud-run

CLOUD_RUN_SANDBOX_URL=https://your-gateway-xyz.run.app
CLOUD_RUN_SANDBOX_SECRET=your_shared_secret
# Optional: Google-signed identity token for IAM-authenticated services
CLOUD_RUN_AUTH_TOKEN=your_identity_token

# Use the Cloud Run provider
import { cloudRun } from '@computesdk/cloud-run';

const compute = cloudRun({
  sandboxUrl: process.env.CLOUD_RUN_SANDBOX_URL,
  sandboxSecret: process.env.CLOUD_RUN_SANDBOX_SECRET,
});

// Create sandbox
const sandbox = await compute.sandbox.create();

// Run a command
const result = await sandbox.runCommand('echo "Hello from Cloud Run!"');
console.log(result.stdout); // "Hello from Cloud Run!"

// Clean up
await sandbox.destroy();

ComputeSDK is the right choice when you want your agent code to be portable across sandbox providers — you can swap between Cloud Run Sandboxes, E2B, Modal, and others by changing the provider parameter. Read more about ComputeSDK and CloudRun integration.

Core use cases

- LLM code interpreters and data analysis

This is the flagship use case. You can build advanced data analysis features into your AI products, let your models write and execute Python, R, or SQL code to analyse datasets, generate charts, and perform complex maths securely.

A financial reporting agent that writes and executes pandas code to process a user's uploaded CSV. A scientific assistant that writes numpy code to run statistical analysis. A business intelligence tool where users ask natural language questions and the agent writes the SQL or Python to answer them. All of these involve LLM-generated code that could theoretically be malicious, and Cloud Run Sandboxes isolate every execution.

- Headless browser automation

You can give your agents a secure environment to run browsers, safely scraping web pages, taking screenshots, and automating web workflows without risking your host machine.

# Launch a headless Playwright browser inside a sandbox
def web_research(url: str) -> str:
    script = f"""
from playwright.sync_api import sync_playwright

with sync_playwright() as p:
    browser = p.chromium.launch()
    page = browser.new_page()
    page.goto('{url}')
    content = page.content()
    browser.close()
    print(content[:5000])  # Return first 5000 chars
"""
    with open("/tmp/browse.py", "w") as f:
        f.write(script)

    result = subprocess.run(
        ["sandbox", "do", "--allow-egress", "--", "python3", "/tmp/browse.py"],
        capture_output=True, text=True, timeout=30
    )
    return result.stdout

Note that browser automation requires --allow-egress since it needs to reach the target URL. This is a deliberate choice, you are explicitly granting network access for this specific execution only.

- User-submitted code and plugins

Beyond AI, platforms hosted on Cloud Run can use sandboxes to safely run custom scripts, plugins, or webhooks uploaded by their own end-users.

SaaS platforms that allow user-defined automation scripts, webhook processors, custom plugin systems, or configurable data transformations, any of these involve running code you did not write, from users you may not fully trust. Cloud Run Sandboxes provide the isolation layer without requiring you to build and operate your own sandbox infrastructure.

- Sub-agent execution

AI systems that spawn sub-agents to complete tasks in parallel, each sub-agent running a different piece of generated code, benefit directly from Cloud Run Sandboxes' per-sandbox isolation. Each sub-agent's code runs in a completely separate sandbox with no access to sibling sandboxes' state, data, or credentials.

Why use Cloud Run Sandboxes specifically?

Speed that matters for agent responsiveness

Sandboxes are interactive and ready to execute commands almost instantly. By creating sandboxes within an existing Cloud Run resource where your agent runs, you reduce creation times when compared to creating a new Cloud Run resource for every task. This efficiency helps ensure that your agent remains responsive.

In testing, 1,000 sandboxes were started, executed, and stopped with an average of 500ms latency. At this speed, sandbox creation is not a bottleneck in your agent's response time, it is a negligible overhead compared to the LLM inference calls your agent is already making.

- No additional cost

Unlike dedicated sandbox hosting platforms that charge high premiums for on-demand virtual machines, Cloud Run Sandboxes run directly on your existing allocated CPU and memory. Because the sandboxes share the resources of your running instances, there is no additional cost or premium to use this feature.

This is the economics argument that is easy to underestimate. Specialised sandbox services charge per execution, per second of CPU time, or per GB of memory, and those costs compound quickly for agent workloads that execute code frequently. Cloud Run Sandboxes add no line item to your bill.

- Native GCP integration

Cloud Run Sandboxes work directly with the rest of your GCP stack. Your agent service already has its IAM service account, its Secret Manager access, its VPC configuration. The sandbox runs within that same resource, benefiting from all your existing security controls while being isolated from your agent's own context.

Where to use Cloud Run Sandboxes

Cloud Run Sandboxes are the right choice in the following scenarios:

AI agents that execute code. Any agent built with ADK, LangChain, LlamaIndex, or custom orchestration that uses code execution as a tool. The security boundaries are purpose-built for this use case.

Multi-tenant SaaS platforms. If your platform runs code on behalf of multiple customers, sandboxes ensure one tenant's execution cannot interfere with, read from, or affect another tenant's data.

Data analysis and scientific computing tools. Products that let users write or generate code to analyse their data, whether that code is human-authored or LLM-generated; benefit from sandbox isolation to protect the underlying platform.

Webhook and plugin processors. Systems that receive and execute code from external sources (third-party webhooks, user-uploaded plugins, custom integrations) need execution isolation that does not require a separate microservice per plugin.

Development and testing environments. CI/CD pipelines that need to execute user-submitted code samples as part of automated testing can use sandboxes to isolate each test execution.

Alternative options

Cloud Run Sandboxes are not the only way to run untrusted code. Understanding the alternatives clarifies where sandboxes sit in the market.

E2B (e2b.dev)

E2B provides an API-based sandbox service specifically designed for AI agents and code execution. It supports multiple runtimes, long-lived sandboxes, and a rich SDK with filesystem and terminal APIs. It is vendor-agnostic and integrates with any cloud. The trade-off: it is a third-party service with per-execution pricing, external API calls from your agent, and a dependency outside your GCP environment. For teams deeply invested in GCP, Cloud Run Sandboxes eliminate the external dependency entirely.

Modal

Modal provides on-demand serverless functions for Python workloads with strong isolation and fast cold starts. It is excellent for Python-heavy workloads and data science tasks. Like E2B, it is vendor-specific and adds an external billing relationship. Modal's container-level isolation is strong but does not provide the same per-execution zero-trust credential isolation that Cloud Run Sandboxes enforce by default.

Firecracker microVMs (self-managed)

Firecracker is the open-source microVM technology used by AWS Lambda and Fly.io. You can run your own Firecracker-based sandbox fleet on GCE. It provides genuine VM-level isolation and full control over the runtime environment. The cost is a significant operational overhead, because building, operating, scaling, and patching a Firecracker cluster is a meaningful engineering investment. Cloud Run Sandboxes give you comparable isolation without the operational surface.

Cloud Run Jobs (async execution)

For asynchronous execution, you can avoid disrupting the main application flow by executing tasks asynchronously using a Cloud Run Job for longer-running or background tasks. For example, execute a Cloud Run job that uploads code to Cloud Storage, installs the required dependencies, and then processes and stores the results back in Cloud Storage.

This pattern predates Cloud Run Sandboxes and still has its place for long-running tasks (batch analysis, video processing, model fine-tuning) where you need full job-level isolation and are not latency-sensitive. For interactive, sub-second code execution inside an agent request, sandboxes are faster and simpler.

Nsjail / gVisor (DIY)

Security-focused teams sometimes build custom sandboxes using gVisor (Google's container sandbox kernel, also used by Cloud Run itself) or nsjail (a Linux namespacing tool). These are powerful but require deep Linux security expertise to configure correctly; seccomp profiles, namespace configuration, capability dropping and are effectively engineering projects in their own right. Cloud Run Sandboxes encapsulate this complexity behind a single CLI command.

Current limitations to know

Cloud Run Sandboxes are in public preview as of July 2026. This means they are subject to the pre-GA terms, available as-is, with potentially limited support, and subject to change before GA (General Availability).

Practical limitations to factor into your architecture:

• Preview status. Do not build a production-critical system that cannot function without this feature until GA is announced. The API may change.
• Resource sharing. Sandboxes share the CPU and memory of your Cloud Run instance. A sandbox running computationally intensive code will consume resources from your service's allocated capacity. Size your instances accordingly when sandbox workloads are CPU or memory intensive.
• No persistent state. Everything written inside a sandbox is discarded unless explicitly exported via --export-tar. Design your agent to treat sandbox execution as stateless.
• Timeout enforcement. Your subprocess call's timeout parameter is what kills a runaway sandbox, there is no automatic execution time limit enforced by the platform independent of your code. Always set a timeout.
• Language support. The sandbox can run any language installed in your container image. Python, Node.js, Go, Ruby, and bash are all available if they are present in your Dockerfile. There is no built-in multi-language runtime, you provision what you need.

Get started today

# Enable the API if not already enabled
gcloud services enable run.googleapis.com

# Deploy your first sandbox-enabled service
gcloud beta run deploy my-sandbox-agent \
  --image=gcr.io/my-project/agent:latest \
  --region=africa-south1 \
  --sandbox-launcher \
  --allow-unauthenticated \
  --min-instances=1

# Test it with a simple curl
curl -X POST https://YOUR_SERVICE_URL/execute \
  -H "Content-Type: application/json" \
  -d '{"code": "print(1 + 1)"}'

The full documentation, quickstart samples, and the ADK integration guide are at docs.cloud.google.com/run/docs/code-execution.

The broader picture

Cloud Run Sandboxes land at a specific moment in AI engineering history. The question of how to safely let AI systems execute code, whether that means a Gemini model writing a Python script to analyse a spreadsheet, or an autonomous agent spinning up a browser to complete a research task; is one of the hardest practical problems in building production AI applications.

Until recently, the industry's answer was, build your own sandboxing infrastructure, pay for a specialised third-party service, or accept the risk. None of these are satisfying answers for teams that want to ship fast and operate responsibly.

Cloud Run Sandboxes offer a fourth answer, use the cloud infrastructure you already trust, with security boundaries designed for exactly this use case, at no additional cost. The 500ms sandbox startup time means this is practical for interactive agent workloads. The zero-trust-by-default credential isolation means the security model does not depend on your generated code being well-behaved.

For teams building AI agents on GCP and the number of such teams is growing rapidly, this removes one of the last credible reasons to use an external sandbox service.