Cloud Run sandboxes: Lightweight isolation for AI agents
Google Cloud announces the public preview of Cloud Run sandboxes, a native, secure, and ultra-fast runtime environment for executing untrusted code and agent workloads, starting in milliseconds. It supports use cases like LLM code interpreters, headless browsers, and user-submitted code execution, with zero-trust security through credential isolation, default-deny egress, and read-only filesystem overlay.
Developers & Practitioners
Safely run AI-generated code in Cloud Run sandboxes
July 10, 2026
Ryan Pei
Product Manager
Greg Block
Software Engineer
Try Gemini Enterprise Business Edition today
The front door to AI in the workplace
Try now
Here’s a question we hear often at Google Cloud: How do you safely run AI-generated code or untrusted binaries without putting your host application, data, and cloud credentials at risk? In other words, how do you give AI-written programs a safe space to run — one that keeps them completely separate from your trusted programs with higher privileges?
Until now, developers had to build complex sandboxing infrastructure using container clusters or pay for specialized third-party microVM runtimes.
Today, at WeAreDevelopers World Congress, we are announcing Google Cloud Run sandboxes in public preview. Cloud Run sandboxes are a native, secure, and ultra-fast runtime environment built specifically for executing untrusted code and agent workloads, starting in milliseconds.
In the following example, we send requests to safely execute untrusted Python code on a Cloud Run service that starts, executes, and stops 1,000 sandboxes with an average of 500ms latency:
In this post, we’ll share more about the feature and core use cases.
What is a Cloud Run sandbox?
Cloud Run sandboxes are lightweight, isolated execution boundaries that you can spawn near-instantly within your existing Cloud Run service instances.
Whether you need to let an LLM run a dynamically generated Python script to calculate business margins or spin up a headless browser to perform web research, Cloud Run sandboxes give you a secure, isolated sandbox to run these tasks without leaving your serverless environment.
Core use cases
LLM code interpreters: Build advanced data analysis features into your AI products. Let your models write and execute Python, R, or SQL code to analyze datasets, generate charts, and perform complex math securely.
Headless browsers: Give your agents a secure environment to run browsers. Safely scrape web pages, take screenshots, and automate web workflows without risking your host machine.
User-submitted code execution: Beyond AI, platforms hosted on Cloud Run can use sandboxes to safely run custom scripts, plugins, or webhooks uploaded by their own end-users.
How it works: The developer experience
Enabling sandboxes on your Cloud Run service is as simple as adding a single flag to your deployment.
Step 1: Enable the sandbox launcher
When deploying your Cloud Run service, enable the sandbox launcher via gcloud or your YAML configuration:
Loading...
Step 2: Spawn a sandbox natively in your code
Once enabled, a lightweight sandbox CLI binary is automatically mounted into your execution environment. Your agent application can spawn sandboxes programmatically using standard subprocess calls.
Here is how easily you can run an untrusted Python script generated by an LLM:
Loading...
Security by design: Zero-trust by default
Cloud Run sandboxes are engineered to protect your host application and cloud resources from malicious or erroneous code execution. The runtime enforces three critical security boundaries:
- Credential and environment isolation: These sandboxes do not have access to the Cloud Run service’s environment variables nor do they have the ability to call the Google Cloud metadata server.
- Locked-down network egress (deny-by-default): By default, sandboxes have zero outbound network access. 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 can be enabled only when explicitly requested:
Loading...
- Safe filesystem overlay: 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. Though you can still import and export files as needed for re-use across sandboxes:
Loading...
ADK and ComputeSDK built-in support
Cloud Run sandboxes will be supported in the next version of Agent Development Kit with a new CloudRunSandboxCodeExecutor. This integration gives your ADK agents running on Cloud Run the ability to execute code in one single line:
Loading...
Cloud Run sandboxes were also added to 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. You can learn how to use this SDK for Cloud Run sandboxes here.
Get started today
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. You can check out our documentation here.
Posted in
Developers & Practitioners
Related articles
Developers & Practitioners
Autopilot Clusters with GKE managed DRANET: GPUs and TPUs
By Ammett Williams • 4-minute read
Developers & Practitioners
A developer's guide to publishing agents in Gemini Enterprise and Google Cloud Marketplace
By Sunny Walia • 12-minute read
Networking
BGP route policies: Top 3 use cases by customer demand
By Olivier Vautrin • 4-minute read
Developers & Practitioners
Google Cloud Labs: Accelerate AI with Cloud Run
By Shir Meir Lador • 4-minute read