Google Cloud puts Cloud Run sandboxes into preview

Google Cloud has put Cloud Run sandboxes into public preview. The service is designed to run untrusted code and AI agent workloads inside Cloud Run.

It lets developers create isolated execution environments within existing Cloud Run service instances, rather than building separate sandboxing systems with container clusters or using specialist microVM services.

The product is intended for cases where AI-generated code, user-submitted scripts, or untrusted binaries must run without exposing host applications, stored data, or cloud credentials. Google framed the launch around growing demand for safer ways to execute code written by large language models.

Main use cases include code interpreters for AI applications, headless browser sessions for automated web tasks, and execution of plugins, scripts, or webhooks supplied by end users of platforms hosted on Cloud Run.

How it works

Developers enable the feature on a Cloud Run service through a deployment flag. A sandbox command-line tool is then mounted into the execution environment, allowing applications to start sandboxes through standard subprocess calls.

That means a service can write AI-generated code to a local file, execute it inside the isolated environment, and return the output while keeping the code separate from the main application process. The sandbox can also run headless browsers and other tools already present in the container image.

Google says the environments start in milliseconds. In one example, a Cloud Run service started, executed, and stopped 1,000 sandboxes with average latency of 500 milliseconds.

Security controls

Google described the service as built around three security boundaries. First, sandboxes do not have access to a Cloud Run service's environment variables and cannot reach the Google Cloud metadata server, reducing the risk of exposing credentials.

Second, outbound network access is blocked by default. Developers can allow egress only when they explicitly request it, limiting the risk of code sending data to external systems.

Third, the sandbox sees the container file system as read-only, while any writes go to a temporary in-memory overlay. Those changes are discarded when execution ends, although developers can export and import archive files if they need to move data between sandbox runs.

Agent tooling

The launch also ties into agent development software. The next version of Google's Agent Development Kit will include a CloudRunSandboxCodeExecutor, allowing agents running on Cloud Run to execute code through the sandbox feature.

Cloud Run sandboxes have also been added to ComputeSDK, which Google described as a vendor-agnostic software development kit for running sandboxes. This allows sandboxes to be invoked remotely from outside a Cloud Run service or used directly inside the service itself.

Cost model

Google says the feature carries no separate premium because sandboxes use the CPU and memory already allocated to a running Cloud Run instance. That sets it apart from services that charge separately for on-demand virtual machine-based isolation.

The move reflects a broader effort by cloud providers to adapt infrastructure for AI software that increasingly generates code, runs tools, and performs automated tasks with a degree of autonomy. As those systems move closer to production workloads, the question of how to isolate their actions without adding complex operational overhead has become more pressing.

By embedding the feature within Cloud Run rather than requiring a separate product, Google is seeking to make isolation part of the default workflow for serverless developers. The launch also suggests the company sees code execution, browser automation, and other agent-driven functions as becoming routine parts of application design.

Google says the sandboxes run on existing allocated CPU and memory, with no additional cost to use the feature.