Google shipped Cloud Run sandboxes into public preview this week at WeAreDevelopers World Congress — lightweight, isolated execution environments that let AI agents safely run untrusted code inside your existing Cloud Run instances, at no extra cost. If you are building agents that execute LLM-generated scripts, this changes the math on your infrastructure.
The Problem Every Agent Builder Hits #
Your AI agent writes a Python script. Now where do you run it safely? That question has been quietly expensive. Dedicated sandbox services like E2B charge per compute-second (roughly $0.0001/s), Modal charges even more for its gVisor-based sandboxes (~$0.0036/s), and rolling your own container cluster requires ops work most teams do not have bandwidth for. Simply dropping untrusted code into a plain Cloud Run function is not safe — environment variables and the Google Cloud metadata server remain exposed, which means a malicious or misbehaving LLM-generated script can exfiltrate credentials.
Cloud Run sandboxes collapse that complexity into a single deployment flag.
Three Security Walls Built Into Cloud Run Sandboxes #
Enable sandboxes by adding --sandbox-launcher
to your Cloud Run deploy command. From there, every sandbox invocation enforces three isolation boundaries:
No credentials. Sandboxes cannot read the host service’s environment variables and cannot reach the Google Cloud metadata server. A compromised script cannot steal your service account key or database password.No outbound network by default. Zero egress unless you explicitly pass--allow-egress
per invocation. Data exfiltration is blocked at the system layer, not by policy you might forget to enforce.No persistent writes. The container filesystem appears read-only. Any writes go to an isolated in-memory overlay that evaporates when the sandbox exits. Nothing lingers.
Performance holds up at scale. According to the Google Cloud Blog announcement, a benchmark of 1,000 sandboxes run sequentially averaged 500ms per cycle — start, execute, stop. Startup alone is milliseconds.
Using It in Practice #
Once you deploy with sandboxLauncher: true
, a sandbox
binary is mounted automatically at /usr/local/gcp/bin/sandbox
. Invoke it from any language via subprocess:
import subprocess
result = subprocess.run(
["sandbox", "do", "--", "python3", "/tmp/generated_script.py"],
capture_output=True,
text=True,
timeout=10,
)
print(result.stdout)
If you are using Google’s Agent Development Kit, the integration drops to a single line — pass CloudRunSandboxCodeExecutor()
as the code_executor
argument to your agent, and the ADK handles file staging, output capture, and sandbox lifecycle automatically.
For multi-step agents that need to pass data between sandboxes, Cloud Run supports tar archive import and export flags. It works, though it is more manual than the native persistent filesystems that E2B and Fly.io Sprites offer out of the box. The ComputeSDK provides a vendor-agnostic alternative if you want to invoke sandboxes from outside your Cloud Run service.
The Pricing Model Is Genuinely Different #
Sandboxes share the CPU and memory already allocated to your running Cloud Run instance. Google charges no per-sandbox premium. For teams already running workloads on Cloud Run, this is effectively free isolation — your idle instance hours cover it.
The comparison sharpens if you are already on GCP. A Cloud Run instance sitting idle costs nothing extra to run sandboxes from. Dedicated sandbox platforms charge per-second regardless. At any meaningful volume of agent invocations, that cost difference compounds quickly. For a broader look at how Cloud Run sandboxes stack up against E2B, Modal, and Daytona, the AgentMarketCap sandbox infrastructure comparison is worth reading before you commit to a platform.
Where It Falls Short #
Cloud Run sandboxes use container-namespace isolation, not full hardware-level microVM isolation. E2B and Fly.io Sprites run Firecracker — each sandbox gets its own Linux kernel, so a kernel exploit inside one cannot escape to the host or affect other sandboxes. Cloud Run’s model is sufficient for the vast majority of AI agent workloads (Python data analysis, SQL queries, headless browsers), but if your threat model includes sophisticated sandbox escape attempts, that weaker isolation boundary matters.
The network-off-by-default design is a security feature, but it creates friction in agent tool-calling patterns. An agent that needs to fetch a URL mid-execution must explicitly opt into egress — you have to think through that at design time rather than having it work transparently. This is the right default for security, but it is also a real cost for agents with outbound data needs. It is worth noting that these same agentic patterns are reshaping developer tooling more broadly — VS Code 1.128 parallel agent sessions are already pushing teams to rethink how isolated execution fits into their workflows.
Moreover, this is still public preview, which means no GA SLAs, undocumented limits on sandbox execution time and memory, and a surface area that can change. Do not build production critical paths on this today.
Who Should Move First #
If your stack is already on GCP and you are building Gemini-powered agents with the ADK, Cloud Run sandboxes are the obvious first choice. The integration is tight, the marginal cost is zero, and the security model covers the common cases. See the official Cloud Run sandbox docs to enable it today.
However, if you need true microVM-level kernel isolation, GPU access inside your sandboxes, or native persistent filesystem state across multi-step agent runs, E2B and Modal remain the better fit. They were built for this exact use case and carry the ecosystem maturity to show for it.
Either way, the era of hoping your Cloud Run function is isolated enough is over. Sandboxed execution is now table stakes for any agent that touches user-provided or LLM-generated code — and Google just made it free for a large chunk of the market.