AI Agent Sandboxes: Where Your Agent Runs Its Code Decides Everything

Ask an agent to analyze a spreadsheet and watch what it actually does. It does not “think” about the numbers. It writes a small Python script, runs it, reads the output, and writes another. The intelligence you are paying for produces code, and that code has to run somewhere. That somewhere is the part almost nobody designs on purpose, and it is the part that decides whether your agent is a demo or a product.

Here is the uncomfortable version. The code your agent writes is untrusted code. Not because the model is malicious, but because it is non-deterministic, occasionally wrong, and steerable by anything it reads. A web page it scrapes can carry an instruction. A file a user uploads can carry a payload. The model will sometimes do exactly what that hostile text says. So the question “where does the agent run its code” is really the question “what happens on the worst day,” and the answer is your entire security posture.

This is why sandboxes, the boring-sounding infrastructure for running untrusted code in a box it cannot escape, quietly became the thing that determines whether agents scale. Google just put Cloud Run sandboxes into public preview, and it is a good excuse to explain the whole layer, because the field is converging on one idea from several directions at once.

Why every real agent ends up executing untrusted code

The first time you build an agent, you give it a few clean tools: search, a database query, a calculator. It feels safe because you wrote every tool. Then the tasks get real. A user wants a chart from their data. Another wants a script that reconciles two CSVs. Another wants the agent to drive a headless browser and fill a form. You cannot pre-write a tool for every one of these. So you give the agent the universal tool: the ability to write and run code.

The moment you do that, three things become true at once, and they compound.

• The code is generated, so it is untrusted by definition. You are not reviewing each script before it runs; that would defeat the point. You are trusting a probabilistic system to produce safe code every single time, which it will not. A hallucinated shell command, an infinite loop, a library that phones home. These are not edge cases at scale. They are Tuesday.
• The code is exposed to hostile input. Agents read the outside world: web pages, emails, documents, tool outputs. Prompt injection is real, and its goal is usually to make the model run something on the attacker’s behalf. If the model’s code has your cloud credentials in its environment, a single successful injection is an exfiltration.
• The volume is enormous and ephemeral. One agent session can spawn dozens of executions. A product with real traffic runs thousands concurrently, each one short-lived, each one needing to start fast and leave no trace. This is a very different shape from “deploy a long-running service.”

So the requirement is specific and harsh. You need a place to run arbitrary, untrusted, possibly-hostile code that starts in milliseconds, cannot reach your secrets or your network unless you say so, leaves nothing behind, and costs almost nothing per run because you will do it a billion times. That is a sandbox, and building a good one is genuinely hard, which is why it is becoming a platform primitive instead of something every team rolls itself.

What Cloud Run sandboxes actually are

Google’s take is interesting because of where it puts the boundary. A Cloud Run sandbox is a lightweight isolated execution environment that spawns inside an existing Cloud Run service instance. You are not provisioning a separate VM or a separate cluster. Your agent service is already running; when it needs to execute untrusted code, it opens a sandbox next to itself, runs the code in the silo, and throws the silo away.

The design is zero-trust by default, which is exactly right for this job:

• Startup is in the milliseconds. Google’s example figure is around 500ms average across a thousand full start-execute-stop cycles. Fast enough that the isolation does not dominate a tool call.
• Per-execution isolation. Each sandbox is separate, and every change it makes is discarded when it ends. No state leaks from one run to the next.
• No credentials, no metadata. Code in the sandbox cannot read the service’s environment variables and cannot reach the Google Cloud metadata server, which is the usual path to steal cloud credentials. This single property kills the most common agent exfiltration.
• Deny-by-default networking. Outbound network access is off unless you explicitly grant it per command, so a script cannot silently call home.
• A disposable filesystem. The sandbox gets a read-only view of the container’s filesystem (so it has the language runtimes and packages) and writes into a temporary in-memory overlay that vanishes afterward. You move real work in and out deliberately, by exporting or importing a tar archive.

gcloud beta run deploy my-agent-service \
  --image=gcr.io/my-project/agent-image \
  --sandbox-launcher

# no network, discarded filesystem, no access to env or metadata
sandbox do -- python3 /tmp/generated_script.py

# explicitly allow one call out when the task needs it
sandbox do --allow-egress -- curl https://api.github.com

Google has not spelled out the exact kernel-isolation technology in the preview post, so I will not put words in their mouth. What matters for understanding the field is the shape of the guarantee (no credentials, no network, no persistence, fast, cheap) and where different products get that guarantee from. That is the isolation spectrum, and it is the thing worth actually understanding.

The isolation spectrum: containers, userspace kernels, microVMs

Every sandbox is a bet on the same tradeoff triangle: security, speed, and cost. You cannot max all three, and each technology sits at a different corner. Understand this and every product on the market snaps into place.

Containers are the left corner: fastest and densest, weakest boundary. A container is not a little machine. It is one or more processes on the host, fenced off with Linux namespaces (so the process sees its own view of files, network, and process IDs) and limited with cgroups (so it cannot hog CPU or memory). Everything shares the host’s single kernel. That makes containers wonderfully cheap and quick, and it means a bug in that shared kernel can, in principle, let code in one container touch the host or its neighbors. For trusted workloads that is fine. For arbitrary agent code, a shared kernel is a real attack surface.

gVisor is the clever middle: a kernel written in userspace. This is Google’s long-standing answer, and it powers a lot of Google’s own multi-tenant execution. Instead of letting the sandboxed process call the host kernel directly, gVisor puts a second kernel, implemented as an ordinary user-space program, in between. The untrusted code makes a system call; gVisor intercepts it and services it itself, only talking to the real host kernel through a tiny, tightly controlled surface. You get most of the isolation of a virtual machine without booting one, so startups stay sub-second, and because it is software rather than hardware virtualization, GPU access stays practical, which matters for ML tools.

microVMs are the right corner: strongest boundary, more weight. Here each sandbox gets its own real, if minimal, Linux kernel, booted in a stripped-down virtual machine using hardware virtualization (KVM). Amazon’s open-source Firecracker is the archetype, built for exactly this: tiny, fast-booting VMs for running untrusted code at scale (it is the engine under AWS Lambda). A kernel exploit inside one microVM cannot reach another microVM or the host, because they do not share a kernel to exploit. The price is that a microVM is heavier to start and denser to pack than a container, though “heavier” here is still measured in low hundreds of milliseconds, not the minute a normal VM takes.

The field is converging on the sandbox as a primitive

Once you see the spectrum, the market makes sense. A cluster of platforms appeared in the last two years, all solving the same agent problem, each planting its flag at a different corner of the triangle.

The interesting signal is not any single product. It is that “a sandbox” is becoming a first-class thing you request, the way you request a database or a queue. Google’s GKE version literally adds new Kubernetes objects for it (a Sandbox workload, a SandboxTemplate blueprint, a SandboxClaim to request one). Frameworks like the Agent Development Kit and LangChain plug into these as a native code-execution backend. When an idea shows up simultaneously as a serverless feature, a Kubernetes primitive, a startup category, and a framework integration, it has stopped being a nice-to-have and become part of the substrate.

Why the sandbox decides whether agents scale

Pull it together. For an agent that executes code to work in production, and not just in a demo, three things have to be true at once, and the sandbox is where all three are won or lost.

It has to be safe, which means the blast radius of bad code is zero. This is the direct connection to the security failure mode everyone in agents worries about: the lethal trifecta, where an agent has access to private data, exposure to untrusted content, and the ability to take external actions. When all three overlap, a prompt injection becomes an exfiltration. A sandbox is how you break that overlap on the execution side: code runs with no credentials, no network, and no persistence, so even if the model is fully hijacked, there is nothing to steal and nowhere to send it.

It has to be instant, because isolation you can feel is isolation you will remove. An agent’s loop is chatty. If every code execution paid a multi-second cold start, developers would route around the sandbox to make the product usable, and you would be back to running untrusted code in your app. This is why the whole field obsesses over startup: Cloud Run’s sub-second silos, GKE’s warm pools and pod snapshots that restore a ready sandbox in seconds, Daytona’s tens-of-milliseconds containers. Fast isolation is the only isolation that survives contact with a product deadline.

It has to be cheap, because you will run it a preposterous number of times. Per-execution isolation that costs like a dedicated VM does not survive a spreadsheet of unit economics. This is the quiet genius of the Cloud Run approach, running the sandbox on the instance’s existing CPU and memory so isolation is free at the margin, and of Firecracker’s density, packing thousands of microVMs on a host. When safety is expensive, teams buy less of it. When safety is nearly free, they use it everywhere, which is the only way it actually protects anything.

The unglamorous layer that makes the magic safe

It is easy to be dazzled by the model and ignore the substrate. But the history of every computing platform is that the boring isolation layer is what let the exciting thing scale. Multi-user operating systems needed process isolation. The cloud needed the hypervisor. Mobile needed the app sandbox. Agents that write and run their own code need this: a place for untrusted code to do real work and touch nothing it should not.

Cloud Run sandboxes are one good answer, notable for folding the boundary into the compute you already have and making it cheap enough to use by default. E2B, Modal, Daytona, GKE Agent Sandbox and the Firecracker foundation underneath are the others, each betting a different corner of the same triangle. The winners in agents will not just have the smartest models. They will have made safe code execution so fast and so cheap that nobody on the team is ever tempted to skip it. The sandbox is not a detail under the agent. It is the floor the whole thing stands on.