Coding agents do not produce perfect code on their first attempt. When an agent generates code, it depends on an iterative feedback loop: generate a candidate patch, run test suites, catch runtime errors, and refine the implementation.
This feedback loop introduces a hard systems-engineering problem: where do you execute the refactored code?
If you run model-generated scripts directly inside your main container, a single hallucinated line or prompt injection attack can delete local files, spawn background zombie processes, or query the Google Cloud metadata server to exfiltrate service account tokens.
If you spin up a fresh virtual machine or standard container for every test run, you add 1 to 5 seconds of cold-start latency per turn. In a four-turn repair cycle, the agent spends up to 20 seconds waiting for compute to initialize.
Google Cloud Run sandboxes eliminate this trade-off. They provide isolated execution boundaries that start in under 500 milliseconds directly inside your running Cloud Run instance.
Here is how the architecture works, how it neutralizes runtime threats, and how to build a self-correcting modernization loop with Google ADK 2.0 and Cloud Run Sandboxes.
The mechanics of a coding agent repair loop
Consider migrating legacy Python 2.7 analytics code to Python 3. The target file below contains three distinct traps:
Why sandboxing is necessary
Developers building agent harnesses have traditionally relied on two approaches to execute generated code:
Approach 1: The shared container subprocess
Running `subprocess.run([“pytest”, …])` directly inside the orchestrator container is fast (under 100ms), but it lacks security boundaries. The untrusted script runs with the same Linux permissions and environment variables as the orchestrator.
Approach 2: Container-per-task overhead
Spinning up an isolated Docker container or Cloud Run Job for each test run provides strong isolation, but the cold-start penalty is severe. Pulling layers, initializing namespaces, and starting runtimes takes several seconds.
The Cloud Run sandbox alternative
Cloud Run sandboxes run in a virtualized environment inside your existing Cloud Run instances. They share the pre-allocated CPU and memory of your service, removing VM provisioning delays, and eliminating separate infrastructure costs.
Cloud Run sandboxes enforce zero-trust isolation out of the box. Calls to the cloud metadata server are blocked, host environment variables are stripped, and all outbound network egress is denied by default, unless enabled with — allow-egress. Filesystem writes occur strictly in an ephemeral memory overlay on top of a read-only root (/), leaving the host container pristine after the process exits.
https://medium.com/media/14b573b2d4e12970d8639a32cea3186f/href
In the following example, we send requests to execute untrusted python code on 1000 Cloud Run sandboxes, which finishes at an average latency of 500ms.
Implementation: Sandbox execution module
Inside your Cloud Run container, the sandbox runtime is exposed via a lightweight CLI binary at /usr/local/gcp/bin/sandbox.
Here is the Python runner module that executes tests inside the micro-VM while providing an automated fallback for local development:
Walkthrough: Multi-turn repair loop
The repair loop ties the components together. In each cycle:
- The agent writes its candidate code to an isolated directory.
- execute_sandbox_command() runs pytest inside the Cloud Run sandbox.
- If tests fail, the harness captures stderr and formats a pruned feedback turn for model
- The loop repeats until tests pass or the iteration limit is reached.
Try it on your own
Enabling sandboxes on Cloud Run requires passing the — sandbox-launcher flag during service or job deployment.
First, clone the repository.
Create a .env file with these environment variables. Make sure to replace <YOUR_PROJECT_ID> with your project id before executing the command.
Then deploy the agent repair loop in Cloud Run with sandbox.
Once deployed, the /usr/local/gcp/bin/sandbox binary is mounted automatically, allowing your agent workflows to spawn sandboxes on demand. Because the sandboxes share the resources of your running instances, there is no additional cost or premium to use this feature.
Cloud Run sandboxes solve the core dilemma of coding agent harnesses by eliminating the trade-off between execution security and multi-turn iteration speed. By providing zero-trust isolation with sub-500ms startup times inside existing instances, they protect host systems from untrusted model outputs without adding painful cold-start delays. This enables fast, cost-effective, and self-correcting repair loops that are ready out of the box.
Solving the AI repair loop dilemma using sandboxes on Cloud Run was originally published in Google Cloud – Community on Medium, where people are continuing the conversation by highlighting and responding to this story.
Source Credit: https://medium.com/google-cloud/solving-the-ai-repair-loop-dilemma-using-sandboxes-on-cloud-run-f750af9922c9?source=rss—-e52cf94d98af—4
About the Author
