If you ship an agent that runs code, you have exactly one hard problem: the model writes Python, and something has to execute it without that Python being able to read your secrets, phone home, or scribble on your disk. Until this month the cheap answers were bad (a try/except around exec() protects nothing) and the good answers cost money (a per-box microVM from a separate provider). On July 9, 2026, Google shipped a third option into public preview: a sandbox that lives inside a Cloud Run instance you are already running and paying for.

The one thing to know: a Cloud Run sandbox costs nothing beyond the instance it runs in, starts in milliseconds, and denies network egress by default — so if you are already on Cloud Run, safe code execution is now a one-liner, not a new bill.

The 30-second version#

Inside your Cloud Run service, executing a model's script is a single command:

sandbox do -- python3 /tmp/generated_script.py

Egress is denied by default. If a specific run genuinely needs the network, you opt in per call:

sandbox do --allow-egress -- curl https://api.github.com

That is the whole mental model: deny by default, allow by exception, and the blast radius stops at the sandbox wall.

Wiring it into an agent#

Most agents don't shell out from a terminal — they call the sandbox from application code. The direct way is a subprocess from inside your Cloud Run service:

import subprocess

result = subprocess.run(
    ["sandbox", "do", "--", "python3", "/tmp/generated_script.py"],
    capture_output=True, text=True, timeout=10,
)
print(result.stdout, result.stderr)

You get stdout, stderr, and a return code back — exactly what you feed to the model on the next turn when the code fails. If you are on Google's Agent Development Kit, it is even shorter: the ADK ships a code executor that targets the sandbox directly.

from google.adk.integrations.cloud_run import CloudRunSandboxCodeExecutor

# hand this to your ADK agent and generated code runs in the sandbox
code_executor = CloudRunSandboxCodeExecutor()

There is also a vendor-agnostic ComputeSDK if you want the same call to target Cloud Run in prod and something local in dev.

What the boundary actually stops — and what it doesn't#

This is the part to read twice, because "sandbox" is an overloaded word. Cloud Run sandboxes give you three concrete boundaries, per Google's documentation:

Google says the boundary is cheap enough to be disposable: they measured 1,000 sandboxes at roughly 500ms average for a full start-execute-stop cycle. You are meant to spin one up per execution and throw it away.

The honest limit: a Cloud Run sandbox shares its instance's kernel. It is a strong boundary, not a separate machine.

Here is where you have to be precise with yourself. Because the sandbox runs inside an existing Cloud Run instance, it does not give each execution its own kernel the way a Firecracker microVM does. Providers like E2B and Modal boot a genuinely separate kernel per box — a bigger blast-radius reduction, at the cost of a separate service and a per-box bill (E2B's Pro tier starts around $150/month plus usage). Cloud Run sandboxes trade some of that depth for $0 marginal cost and millisecond starts on infrastructure you already run.

So the decision is not "which is best" — it is "what is your threat model":

We walked through the microVM path in how to run untrusted AI-agent code in an E2B sandbox, and the broader field — Cloud Run vs E2B vs Modal vs Fly — in which agent sandbox should you actually use in 2026. If you want the isolation-tech nuance underneath all of this, your container is not a sandbox is the primer.

The takeaway for founders#

The pricing model is the story. Every other serious sandbox is a service you provision and pay for per box; a Cloud Run sandbox is a boundary inside compute you already bought. If your agent already deploys on Cloud Run, you can turn on safe, deny-by-default code execution today without adding a vendor, a bill, or a second thing to operate — as long as you remember that "inside my instance, no creds, no egress" is a different, lighter promise than "its own kernel on its own machine," and you choose with that difference in mind.