Google puts Cloud Run sandboxes into preview for AI-generated code

Now that generative coding tools push draft code into pull requests and pipelines directly, the question of where the resulting artefact actually runs has stopped being a design exercise. On July 9, Google Cloud announced that Cloud Run sandboxes are in public preview, framed on the Google Cloud developers-and-practitioners blog around a single question: how do you run AI-generated code or untrusted binaries without exposing the host application, the data, and the cloud credentials that sit next to them.

The change

The pitch, in Google's own framing, is a place to run code that you do not fully trust. The post positions Cloud Run sandboxes as an isolation primitive for AI-written programs and untrusted binaries, distinct from the general-purpose Cloud Run service where you would typically deploy an application you wrote and reviewed yourself. What the announcement commits to publicly is the preview status and the intended use. Anything more specific about limits, quotas, isolation internals, or the exact API surface is out of scope for this article and belongs to the Google Cloud documentation.

Where this fits in a CI/CD pipeline

The pipeline-side problem is simple. A code-writing agent produces a function, a script, or a container recipe, and something has to execute it to know whether it works. The convenient option is the same runner that already has read access to your registry, your artifact bucket, and often a workload identity that can call into production. Convenient, and exactly the wrong place: if the generated code is buggy, you break the runner; if it is hostile, you have handed a stranger a set of long-lived credentials.

A dedicated sandbox with no coupling to the host runner turns that from a security-review argument into a routing decision. The generator emits code, a stage ships that code to the sandbox, the sandbox executes and returns results, and only reviewed output ever comes back into the trusted side of the pipeline. The credentials the sandbox holds are the credentials you are willing to lose.

What the announcement leaves open

Google's post is a preview note, not a runbook. In the passages the release lede highlights, it does not spell out the isolation technology, the startup latency, the pricing model, or the concurrency ceiling. Those are the numbers that decide whether the service lands in a pipeline or stays on a wish list. Preview also means the API and defaults can move; a wiring diagram drawn this week may need a revision after GA.

The second-order question the announcement does not address is the one on-call actually cares about. When the sandbox misbehaves, what does the failure look like from the caller's side, and does it degrade gracefully or block the pipeline. Treat that as a load-test item, not an assumption.

How other platforms handle untrusted execution

Cloud Run sandboxes join a crowded field of "run this code somewhere it cannot hurt anyone" primitives, and it helps to see the shape of the field before adopting anything.

• AWS Lambda / Firecracker microVMs. The best-documented approach in the wild. Each invocation gets a fresh microVM. If your workload is short, event-shaped, and you are already an AWS shop, this is the path of least resistance.
• E2B. A focused product for AI-generated code execution, with SDKs aimed at agent frameworks. If the sandbox is a persistent notebook that an agent is iterating inside, rather than a one-shot pipeline step, E2B is the more targeted option than a generic cloud sandbox.
• Kata Containers / gVisor. Open-source isolation runtimes you can slot under an existing Kubernetes cluster. Higher operational cost, but keeps the compute on infrastructure you already run.
• Docker rootless plus user namespaces. The cheapest option, and enough for many test workloads. It will not stop a determined attacker, and it does not solve the credential-leakage problem on its own, but it is a reasonable first fence.
• Buddy sandboxes. In Buddy, the pipeline itself owns an ephemeral sandbox environment per branch, which some teams point at agent-generated code so it never lands on the shared runner. One option among several; it fits when the code you want to isolate is code the same pipeline just produced, less well when the sandbox is a long-running scratchpad an agent talks to across many turns.

Every option here has a real use case, and the honest read is that Cloud Run sandboxes will make sense for teams already routing traffic through Cloud Run, and awkward for teams that are not. The preview label is doing real work.

The residual caveat

Preview is preview. The isolation guarantees, the failure modes, and the price of running a lot of untrusted code through the service are the three numbers that turn this into an operational choice, and they are the three numbers a preview blog post does not have to publish. Kick the tires with something disposable before you route production agent output through it.