Cloud Run Sandboxes — Google's Agent Jail Is a Velvet Handcuff

Google announced Cloud Run Sandboxes in public preview on July 10 at WeAreDevelopers World Congress in Berlin — a native, serverless-isolated execution environment for AI-generated code that starts in milliseconds and costs nothing beyond your existing Cloud Run instance allocation. The pitch is security. The product is infrastructure capture.

TL;DR

• What: Cloud Run Sandboxes — one deployment flag gives you isolated execution for LLM-generated code, no additional charge, 500ms average cold-start
• Correction: Google is NOT first — Azure Container Apps Sandboxes entered public preview June 2, five weeks earlier
• Lock-in vector: ADK’s CloudRunSandboxCodeExecutor wires agent execution directly to GCP with zero friction
• Action: Evaluate Azure’s equivalent before committing; both are single-flag primitives, but choosing now means choosing a cloud

What Happened

Google shipped a sandbox primitive baked directly into Cloud Run. Enable a single deployment flag, and every container instance gains the ability to spawn isolated execution environments for untrusted code — the kind LLM agents generate on the fly. The runtime enforces three security boundaries: credential isolation (no access to the Cloud Run service’s environment variables or the GCP metadata server), deny-by-default network egress (outbound traffic blocked unless explicitly enabled), and a read-only filesystem overlay where writes go to a temporary in-memory layer, not the container’s actual filesystem.

Google’s own benchmark: 1,000 sandboxes started, executed, and stopped at an average of 500ms latency. That is comparable to Firecracker microVM cold-starts (typically 125–500ms for a raw VM), but without the infrastructure management overhead Firecracker demands. And because sandboxes share the CPU and memory already allocated to your running Cloud Run instances, there is no separate line item on your bill.

Here is the part that matters for lock-in: the next version of Google’s Agent Development Kit ships a CloudRunSandboxCodeExecutor class. If your agents already use ADK, running untrusted code in a sandbox becomes a one-line integration. ADK → Cloud Run → Sandbox. That is a three-layer dependency chain where every layer is Google.

# ADK integration — one-line sandbox execution
from google.adk.executors import CloudRunSandboxCodeExecutor

executor = CloudRunSandboxCodeExecutor(service="my-agent-service")
result = executor.run(code=agent_generated_code)

Google also added Cloud Run Sandboxes to ComputeSDK, which they frame as a “vendor-agnostic” SDK for running sandboxes. On launch day, the only production-ready implementation is Cloud Run. Treat that “vendor-agnostic” label with the skepticism it deserves until a second backend exists and actually works.

Why This Matters

The question I keep returning to when I track this space is simple: follow the infrastructure layer, because that is where lock-in actually lives. Model APIs are increasingly commoditized. Orchestration frameworks are swappable. But the execution environment — where your agent’s generated code physically runs — that is the layer where switching costs compound fastest.

Cloud Run Sandboxes are precisely this kind of infrastructure capture, and they are effective because they are genuinely well-designed. Three hard security boundaries, sub-second cold-starts, zero marginal cost, one deployment flag. If I am a tech lead evaluating where to safely run LLM-generated code, the Cloud Run answer is the obvious one. That is the problem.

But Google did not get there first. The initial framing around this announcement suggested Google was the first major hyperscaler with a native agent sandbox primitive. That is wrong. Azure Container Apps Sandboxes entered public preview on June 2, 2026 — five weeks before Google’s July 10 announcement. Microsoft’s offering uses hardware-isolated environments, starts from OCI disk images in under a second, and is the infrastructure layer beneath GitHub Copilot’s cloud sandboxes and Foundry Hosted Agents. Both Google and Azure now offer single-flag sandbox primitives for agent workloads.

The CloudRunSandboxCodeExecutor in ADK creates a hard runtime dependency on GCP. If you adopt it, migrating your agent execution to another cloud means rewriting your code execution layer — not just changing an API endpoint.

AWS occupies a different position. AgentCore includes sandboxed code execution via Code Interpreter and a Firecracker-based Runtime with interactive shell sessions and up to 10 concurrent sessions per agent, but these are components of a broader orchestration harness, not standalone isolation flags you add to existing compute. The difference matters operationally: Cloud Run Sandboxes and Azure Container Apps Sandboxes augment infrastructure you already run; AWS AgentCore asks you to adopt a new platform.

The competitive dynamics here are straightforward. Google and Azure are racing to make their compute layer the default home for agent execution. Both chose the same strategy: make sandbox isolation so trivially easy to enable that evaluating alternatives feels like unnecessary work. And both chose the same lock-in mechanism: wire the sandbox directly into their respective agent frameworks (ADK for Google, Foundry for Azure), so the path of least resistance is also the path of deepest dependency.

What neither vendor offers is a credible multi-cloud story. Google’s ComputeSDK claims vendor-agnosticism but ships with only one backend. Azure’s sandbox is tightly coupled to Container Apps and the broader Microsoft agent stack. If you want genuine portability for agent code execution, you are still looking at self-managed Firecracker, gVisor, or Wasm-based isolation — all of which work, but none of which are one-flag easy.

If you are comparing sandbox options, benchmark tail latency (p99), not averages. An agent that waits 2 seconds for one out of every hundred code executions will frustrate users in ways the 500ms average number hides.

The 500ms benchmark deserves scrutiny too. Google measured start-execute-stop latency across 1,000 sandboxes, which is a solid throughput test. But 500ms average means some sandboxes took longer, and in agent workflows where code execution is on the critical path, tail latency matters more than averages. Raw Firecracker can hit 125ms cold-starts. Google’s number is competitive but not exceptional — the value proposition is operational simplicity, not raw speed.

The Take

This is infrastructure-layer vendor capture dressed up as a security feature, and I say that as someone who thinks the security feature genuinely works. The three isolation boundaries are the right ones. The zero-cost model removes the budget objection. The one-flag deployment removes the effort objection. Every barrier to adoption has been deliberately eliminated — which is exactly how effective lock-in operates.

The real question is not whether Cloud Run Sandboxes work. They almost certainly do. The question is whether you want your agent’s blast radius defined by a flag Google controls, wired into a framework Google maintains, running on infrastructure only Google provides. Today that flag gives you isolation. Tomorrow it could give you telemetry requirements, model routing preferences, or pricing changes you cannot escape because your execution layer is not portable.

My recommendation: if you are already deep in GCP and using ADK, Cloud Run Sandboxes are the pragmatic choice and fighting that reality wastes energy. If you are early in your agent infrastructure decisions, evaluate Azure Container Apps Sandboxes side by side — they launched first, offer comparable isolation, and at minimum give you negotiating leverage. If portability matters to you (and for agent workloads that will run for years, it should), invest the upfront cost in self-managed isolation now. The one-flag convenience is real, but so is the switching cost it creates.

Every hyperscaler wants to be the place where your agents execute code. The one you choose in 2026 is the one you are stuck with in 2028.

Related

• AWS AgentCore — Managed Harness, Managed Lock-In — AWS’s broader agent orchestration play, including sandboxed code execution as one component of a larger harness
• Microsoft MXC — Windows Agent Sandbox — Microsoft’s approach to agent isolation on the desktop side, complementing Azure Container Apps Sandboxes on the server side
• Agent Production Observability Stack — The monitoring layer you need regardless of which sandbox primitive you choose