The short answer
Cloud Run sandboxes let you run untrusted or AI-generated code inside your existing Cloud Run service, isolated so it cannot read your environment variables, call the metadata server, or reach the network by default. Google announced the public preview on 10 July 2026 at the WeAreDevelopers World Congress. Sandboxes start in milliseconds; in a demo, one service started, executed, and stopped 1,000 of them at an average latency of 500ms. Because they share the CPU and memory already allocated to your instance, there is no premium to use them, and the preview is free.
The practical reading for engineering leaders: the hardest part of shipping an AI agent that writes and runs code — doing it without handing an LLM your cloud credentials — just got a managed, cheap default on Google Cloud. It does not replace threat modelling, but it removes a large piece of undifferentiated security plumbing teams were building by hand.
What did Google actually ship?
On 10 July 2026, at the WeAreDevelopers World Congress, Google Cloud put Cloud Run sandboxes into public preview. A sandbox is a lightweight, isolated execution boundary that you spawn near-instantly inside an existing Cloud Run service instance. Instead of standing up a separate cluster of containers or paying for a specialist micro-VM service, your application creates a throwaway, locked-down environment on the compute it already has, runs some untrusted code in it, and tears it down.
The problem it targets is specific and increasingly common: how do you safely run code that an LLM wrote, or that a user submitted, without putting your host application, your data, and your Google Cloud credentials at risk? Google frames this as a response to a shift it sees in application design, where letting a model write and execute code — for data analysis, browsing, or automation — is becoming a routine part of the product rather than an exotic edge case. That is the same pattern we keep meeting when clients ask us to build agentic features: the agent is only useful if it can act, and acting often means running code you did not write and cannot fully trust.
Google points at three concrete use cases. LLM code interpreters let a model write and run Python, R, or SQL to analyse a dataset, generate charts, or do heavy math on demand. Headless browsers give an agent a contained place to scrape pages, take screenshots, and automate web workflows. And plain old user-submitted code — plugins, scripts, competition submissions — can run without becoming a foothold into your service. The sandboxes are also being wired into Google's Agent Development Kit (ADK): a new CloudRunSandboxCodeExecutor lets an ADK agent running on Cloud Run execute code in a single line, and applications can also spawn sandboxes directly with standard subprocess calls.
How does the isolation work?
The security model rests on three boundaries, and they are worth understanding precisely because they define what the feature does and does not protect. The first is credential isolation: a sandbox cannot read the Cloud Run service's environment variables and cannot call the Google Cloud metadata server. That matters because the metadata server is the usual way a workload obtains its service-account tokens; cut off from it, code running in the sandbox has no path to your identity or your secrets even if it goes looking.
The second is network egress, denied by default. Out of the box a sandbox has zero outbound network access; if the code needs to reach an API, you enable egress explicitly for that call rather than leaving a door open. For anyone who has watched malicious code try to exfiltrate data or phone home, a deny-by-default network posture is exactly the right shape. The third is a safe filesystem overlay: the sandbox sees your container's filesystem read-only — so it can use your installed packages, runtimes, and binaries — but writes everything to an isolated, temporary in-memory overlay that is discarded when execution ends. Nothing the code writes survives, and nothing it does mutates your running service.
Two operational facts round it out. On performance, sandboxes start in milliseconds, and Google's demo ran 1,000 of them through a full start-execute-stop cycle at an average of 500ms each — fast enough to make per-request sandboxing realistic rather than a batch-only trick. On cost, because they run on the CPU and memory already allocated to your instance rather than on dedicated VMs, Google says there is no additional premium to use the feature, and it is free during the public preview. That pricing model is the quiet headline: isolated code execution has historically meant paying a specialist sandbox host per invocation, and folding it into serverless compute you already pay for changes the economics.
Why does this matter now?
Secure code execution has quietly become one of the load-bearing problems of the agent era. Every serious agent framework eventually hits the same wall: to be useful, the agent has to run code, and running arbitrary code next to your application is how you lose your data or your cloud account. Teams have solved it with gVisor, Firecracker micro-VMs, dedicated sandbox startups, or elaborate Kubernetes isolation — all of which work, and all of which are real engineering and real operational cost. A managed sandbox that lives inside your existing serverless runtime lowers that barrier for a large class of applications.
It is also part of a visible trend across the big clouds. Google has been shipping isolation primitives for agents on both ends of its compute spectrum — a GKE Agent Sandbox for Kubernetes-heavy workloads, and now Cloud Run sandboxes for the serverless side. If your platform strategy leans on Kubernetes, the GKE path may fit; if you are already serverless-first on Cloud Run, the new sandboxes meet you where you are. Either way, the signal is that the hyperscalers now treat "run this untrusted code safely" as a first-class platform capability rather than something every team reinvents.
What it means for US & EU software teams
Strip away the launch and three durable implications remain. The first is that sandboxed execution is now the expected default for code-running agents. If you are building an AI feature that writes and runs code, letting it execute in-process is no longer defensible — the tooling to isolate it is cheap and available. Design the execution boundary in from the start; retrofitting isolation after an incident is the expensive path, and the incident is the kind that ends up in a breach report.
The second is that isolation is a control, not a compliance certificate. Cloud Run sandboxes cut off credentials, network, and persistence, which closes the most dangerous holes — but if you operate in FinTech or handle regulated data, you still own the harder questions: what data you let into the sandbox, where egress is allowed to go, how you log and review what the agent ran, and how all of that maps to GDPR, SOC 2, or your sector's rules. Treat the sandbox as one layer in a defence-in-depth design, and keep it inside your normal security review rather than assuming a managed feature makes the threat model go away.
The third is architectural and cuts across providers: keep the execution layer swappable. Cloud Run sandboxes are attractive, but so are alternatives, and the isolation landscape is moving fast. Put agent code execution behind a clean interface so you can run it on Cloud Run today and move it — to GKE, to another cloud, to a self-hosted sandbox — without rewriting the agent. That portability is cheap to build now and painful to add later, and it is the same discipline that keeps any cloud platform maintainable as vendors change terms and capabilities.
What to do now
Here is the shippable version. Treat Cloud Run sandboxes as a prompt to get your agent's code-execution story right, whether or not you adopt this specific feature.
- Isolate code execution by default. If an agent or user can run code, it should never run in your application's process with access to your credentials.
- Deny network and secrets, then grant narrowly. Start from zero egress and no credential access; open only the specific paths a task genuinely needs.
- Keep the sandbox layer swappable. Put execution behind an interface so Cloud Run, GKE, or another sandbox can back it without rewriting the agent.
- Log what the agent ran. Capture inputs, code, and outputs for audit and incident review; a discarded overlay is good hygiene but not an audit trail.
- Fold it into your threat model. A managed sandbox is one control; review it alongside data flows, egress rules, and your compliance obligations.
- Pilot before you commit. Preview features change; validate latency, limits, and behaviour on your real workload before it sits on a critical path.
None of this is legal advice, and your exact obligations depend on your sector and jurisdiction. But the strategic signal is clear: running AI-written code safely is becoming a solved, cheap default on the major clouds, and the teams that win are the ones that design isolation in early, keep it swappable, and treat the sandbox as one control in a larger security posture.
Frequently asked questions
What are Cloud Run sandboxes?
Cloud Run sandboxes are lightweight, isolated execution boundaries that you spawn near-instantly inside an existing Google Cloud Run service instance to run untrusted or AI-generated code safely. Google put them into public preview on 10 July 2026. A sandbox has no access to the service's environment variables, cannot call the Google Cloud metadata server, and by default has zero outbound network access, so code an LLM writes cannot reach your credentials or your data unless you explicitly allow it.
How fast and how expensive are Cloud Run sandboxes?
Sandboxes start in milliseconds. In Google's demonstration, a single Cloud Run service started, executed, and stopped 1,000 sandboxes with an average latency of 500ms. On cost, sandboxes run on the CPU and memory already allocated to your running Cloud Run instance rather than on separate dedicated VMs, so there is no additional premium to use the feature, and it is free during the public preview.
Why do AI agents need a code sandbox?
AI agents increasingly write and run their own code, or execute code and scripts submitted by users. Running that untrusted code in the same process as your application exposes your host, your data, and your cloud credentials if the code is malicious or simply wrong. A sandbox isolates execution, so an LLM code interpreter can run Python, R, or SQL, or a headless browser can scrape a page, without the ability to read secrets or reach the network unless you grant it.
How do Cloud Run sandboxes isolate untrusted code?
Three boundaries. First, credentials: sandboxes cannot read the Cloud Run service's environment variables and cannot call the Google Cloud metadata server, so they cannot obtain your service account tokens. Second, network: outbound access is denied by default and must be explicitly enabled per call. Third, filesystem: the sandbox sees your container filesystem read-only and writes changes to a temporary in-memory overlay that is discarded when execution ends, so nothing it does persists into your service.
How do you use Cloud Run sandboxes in an agent?
Your application can spawn sandboxes programmatically with standard subprocess calls, and Google's Agent Development Kit (ADK) ships a CloudRunSandboxCodeExecutor so an ADK agent running on Cloud Run can execute code in a single line. The feature targets three common patterns: LLM code interpreters for data analysis, headless browsers for agent web tasks, and safe execution of user-submitted scripts or plugins.
Sources
Google Cloud Blog — Google Cloud Run sandboxes are in public preview
SecurityBrief Australia — Google Cloud puts Cloud Run sandboxes into preview
Google Cloud Documentation — Code execution in Cloud Run