Cloud Run sandboxes

Cloud Run sandboxes (Google Cloud, public preview, announced at Cloud Run’s Next ‘26) are “a fast, secure, and isolated environment to execute untrusted code or run tools, such as AI agents, within your existing service.” They are the managed-cloud answer to the question the spoke’s containment thread keeps hitting: where do you run code an agent just wrote, without trusting it?

What it is

A sandbox runs inside the same Cloud Run instance as your container — sharing its allocated CPU and memory — in the second-generation execution environment, and is “highly optimized for latency.” In-instance colocation is the design bet: no separate VM to spin up per call, so the untrusted-code round-trip stays cheap enough to sit inside an agent’s tool loop. The trade is resource accounting — sandboxes draw from the host container’s limits, so you size the container to hold “both your application and any active sandboxes.”

You enable it per service with gcloud beta run deploy … --sandbox-launcher (or sandboxLauncher: true in YAML). At runtime a launcher binary at /usr/local/gcp/bin/sandbox runs commands inside the boundary — sandbox do -- /bin/echo "Hello" — with Node.js / Python / Go integration examples. A higher-level built-in sandbox tool that spins up an ephemeral sandbox “strictly isolated from your agent code” is flagged as coming soon.

The preview docs do not name the isolation mechanism (gVisor / microVM / kernel isolation) — a gap worth noting rather than guessing, since the security claim rests on it. Per-sandbox resource limits are likewise unspecified beyond “must fit the container’s allocation.”

Why it matters here

This is a cloud-platform vendor shipping agent-code sandboxing as a managed primitive — the clearest instance yet that the spoke’s “governance/containment is becoming agent-agnostic infrastructure” thread reaches the serverless layer. It sits alongside nemoclaw (NVIDIA sandboxing openclaw/hermes-agent/LangChain harnesses) and microsoft-scout (sandbox + identity) as a third shape of external containment — but from beneath the harness, as a substrate feature rather than a wrapping control plane. It’s the server-side, coarser-grained sibling of arrow-js‘s WASM sandbox (which contains agent-generated UI in the browser): both answer “run this untrusted, model-written code safely,” at opposite ends of the stack. And it closes a loop with the two existing Cloud-Run agent-ops pages — agent-starter-pack (deploy an agent on Cloud Run) and claude-apps-gateway (govern a Claude Code fleet on Cloud Run) — adding the missing execution- isolation rung to Google Cloud’s deploy → govern → sandbox agent story on one substrate.

Tier T2 / caveats. First-party Google Cloud docs + announcement — authoritative for the mechanics (in-instance model, CLI/YAML surface), but the “fast … secure” framing and the unstated isolation mechanism are the vendor’s own; no independent latency or escape-resistance evaluation yet. Preview, so surface and limits are volatile.

Cross-spoke context

• ../cloud-wiki (runner-up) — Cloud Run is a Google Cloud serverless offering; the hosting/pricing/region angle of this feature belongs there if it grows. Routed here because the substance is agent-code execution isolation, not a hosting/pricing story.
• ../platform-ops-wiki — extends the verification-runtime seam (agent-loops-verification): running/verifying agent-written code against a live, isolated environment is the ephemeral-environment problem that spoke owns; Cloud Run sandboxes is a productized instance of it.

Related

agent-guardrails · nemoclaw · microsoft-scout · arrow-js · claude-apps-gateway · agent-starter-pack · google