Every AI agent that writes code eventually has to run it somewhere it can't do damage. Until last week, the clean answer for most founders was a specialist: E2B on Firecracker microVMs, Modal on gVisor, Cloudflare or Fly.io if you lived at the edge. On July 9, at WeAreDevelopers World Congress, Google added a fourth shape to the market — and it's the one that ships bundled with a cloud millions of teams already run on.
Cloud Run sandboxes are now in public preview. They are, in Google's words, "lightweight, isolated execution boundaries that you can spawn near-instantly within your existing Cloud Run service instances." The pitch is narrow and specific: a place to run untrusted, model-generated code that starts in milliseconds and can't touch anything it shouldn't.
The security model is deny-by-default#
The interesting part isn't speed — everyone claims milliseconds now. It's what the sandbox can't do out of the box:
- No credentials. Sandboxed code has no access to the Cloud Run service's environment variables and cannot call the Google Cloud metadata server. The two most common ways a prompt-injected agent steals your keys are both closed at the system layer.
- Zero network egress by default. "If your agent is tricked into running a script that attempts to exfiltrate data to a malicious server, the network request is blocked at the system layer." You opt back in per call —
sandbox do --allow-egress -- curl https://api.github.com— rather than opting out. - Throwaway filesystem. The sandbox gets a read-only view of your container (so your installed packages, Python runtime, and binaries are all there) and writes every change to an isolated, temporary memory overlay. When execution ends, the generated files are discarded.
That's the posture security teams have been bolting on by hand for two years — because a container alone was never a sandbox — shipped as the default.
The number that moves the market is $0#
Google is blunt about pricing: "there is no additional cost or premium to use this feature." Sandboxes run directly on the CPU and memory you've already allocated to your Cloud Run service. There is no per-sandbox meter.
Compare that to the specialist model, where the sandbox is a separate product billed per second of CPU and RAM. For an agent that already lives on Cloud Run, the marginal cost of adding isolated code execution just went to roughly zero. Google demonstrated the ceiling too: 1,000 sandboxes spawned with an average start latency of about 500ms. That's fan-out territory, not a toy.
What it means for founders#
If your agent already runs on GCP, adopt it this week. The integration surface is small — a --sandbox-launcher flag at deploy time, then a sandbox CLI binary that's auto-mounted into your instance, callable from a plain subprocess.run(...). The next Agent Development Kit release adds a one-line CloudRunSandboxCodeExecutor, and it's already wired into the vendor-agnostic ComputeSDK. The whole loop is short enough to show here.
Try it: the 10-minute path#
Turn sandboxing on at deploy time — one flag, and the sandbox binary mounts itself into your instance:
gcloud beta run deploy my-agent-service \
--image=gcr.io/my-project/agent-image \
--sandbox-launcher
Then wrap every piece of model-generated code in sandbox do --. From your agent, that's a plain subprocess call — no SDK:
import subprocess
with open("/tmp/generated_script.py", "w") as f:
f.write(generated) # the code your model just produced
result = subprocess.run(
["sandbox", "do", "--", "python3", "/tmp/generated_script.py"],
capture_output=True, text=True, timeout=10,
)
That process can't read your env vars, can't reach the metadata server, and has no network. When a task genuinely needs one outbound call, grant it narrowly — sandbox do --allow-egress -- curl https://api.github.com — and treat --allow-egress the way you'd treat sudo. Files land in a throwaway memory overlay and vanish on exit; add --export-tar=/tmp/work.tar to keep an artifact. For agent frameworks, the next ADK release drops in as code_executor = CloudRunSandboxCodeExecutor().
If you're not on GCP, the specialists still win. The trade you're making with Cloud Run sandboxes is lock-in and a hyperscaler's isolation boundary in exchange for zero marginal cost. E2B's Firecracker microVM is a harder wall than a shared-instance boundary, and both E2B and Modal are portable across clouds. If a microVM guarantee or provider independence is load-bearing for you, the three-way specialist decision still stands, and it comes down to the same isolation-primitive question it always was.
The larger signal: this is the second sandbox Google has shipped for agents in two months, after GKE Agent Sandbox at Next '26. The hyperscalers have decided that "run the agent's code safely" is table-stakes infrastructure they give away to keep you on the platform — not a specialist product you leave to buy. For a solo founder, that's a cost line falling to zero while you sleep. For E2B and Modal, it's the moment the incumbents showed up.



