By ByteBot
Google put Cloud Run sandboxes into public preview at WeAreDevelopers World Congress last week. The feature lets Cloud Run services execute untrusted, AI-generated code inside isolated environments — no additional infrastructure required, no separate billing line. If you’re already running on Cloud Run, you’re one deployment flag away from production-safe agent code execution.
The Problem Every AI Agent Builder Is Ignoring
Here’s the uncomfortable truth: most AI agents that write and execute code are running untrusted software directly on live infrastructure. Prompt injection attacks are up 340% in 2026, and OWASP still lists prompt injection as the #1 LLM risk — unsolved after two years of awareness campaigns.
The attack path is straightforward. An agent reads external content — a web page, a user message, a document. That content contains injected instructions. The agent generates a Python script and runs it. That script, executing inside your Cloud Run service, can read your environment variables, call the GCP metadata server to grab IAM credentials, and exfiltrate data to an attacker-controlled server. Zero exploits needed. Just an LLM that does what it’s told.
Cloud Run sandboxes are the architectural answer to this pattern.
Three Isolation Layers That Actually Matter
Google’s sandboxes enforce three hard boundaries between untrusted code and your host service:
Credential isolation. Sandboxes cannot read the host service’s environment variables. They also have no access to the GCP metadata server, which means no IAM token theft via the instance identity endpoint. A compromised script can’t pivot to your other GCP resources.
Network deny-by-default. Outbound network access is blocked at the system layer. If a prompt-injected script tries to exfiltrate data to an external server, the connection doesn’t happen. You can selectively open egress if your use case requires it, but the default is safe.
Filesystem overlay. The sandbox has a read-only view of your container’s filesystem — it can use your installed Python packages, binaries, and runtimes — but all writes go to an isolated, temporary memory overlay. When the sandbox ends, everything it wrote is discarded.
The underlying technology is gVisor, the same kernel isolation layer Google uses in GKE Agent Sandbox. Performance benchmark from the announcement: 1,000 sandboxes started, executed, and stopped with an average of 500ms latency.
How to Enable Cloud Run Sandboxes
Enabling sandboxes is a single flag:
# New service
gcloud beta run deploy my-agent-service --image gcr.io/my-project/agent-image --sandbox-launcher
# Existing service
gcloud beta run services update my-agent-service --sandbox-launcherOnce deployed, a lightweight sandbox CLI binary is automatically mounted into the execution environment. Your application invokes sandboxes through standard subprocess calls. The official documentation covers the full API, including how to pass files in and retrieve outputs.
The next version of Google’s Agent Development Kit will add a CloudRunSandboxCodeExecutor — one line of configuration for ADK agents already running on Cloud Run. Cloud Run sandboxes are also available through ComputeSDK, a vendor-agnostic sandbox SDK, for invoking them from outside a Cloud Run environment.
Cloud Run Sandboxes vs E2B and Modal
| Cloud Run Sandboxes | E2B | Modal | |
|---|---|---|---|
| Cold start | ~500ms avg | <100ms | Fast |
| Extra cost | None (your alloc) | Paid per use | Paid per use |
| GPU support | No | No | Yes |
| Native GCP | Yes | No | No |
E2B’s Firecracker-based sandboxes boot in under 100ms — meaningfully faster than Cloud Run’s 500ms average, which matters for interactive agents waiting on a user. Modal’s advantage is GPU access, critical if your agent needs to run inference or ML workloads inside the sandbox. Cloud Run sandboxes win on cost and ecosystem integration for teams already on GCP.
Limitations Worth Knowing
The 500ms latency is fine for batch or background agent tasks; it’s noticeable for interactive workflows. There’s no GPU support at the Cloud Run layer — for ML-heavy agent workloads, GKE Agent Sandbox is the right tool. That’s also where long-running agent processes belong. And this is still public preview, so the API surface can change before GA.
Who Should Enable This Now
If your team is running AI agents on Cloud Run and executing LLM-generated code today — without sandboxing — this is worth enabling immediately. The cost argument is hard to argue with: a legitimate security primitive at zero incremental spend, on infrastructure you’re already paying for. The ADK integration in the next release will make it even simpler to wire in.
If you’re on a different cloud or need sub-100ms cold starts, E2B or Modal are still the better fit. But for GCP shops, the calculus just shifted. Google’s bet is that “already in your stack, no extra cost” beats “faster but requires a separate vendor.” For most teams running agents on Cloud Run today, that bet is worth taking.
