"We wanted to make our internal quoting process more efficient, so we had AI build a tool for us. It runs, but is it really safe to put it on our production server and let it handle customer data? No one can say with confidence that it's secure, so we're stuck." We received this consultation from a person handling IT single-handedly at a manufacturing company. Having working code and being able to run that code in production with peace of mind are completely different matters. And this anxiety is an entirely correct intuition.
Code written by generative AI or AI agents is characterized by being produced at a volume and speed that humans cannot follow line by line with the naked eye. In some cases, code that attempts unauthorized external communications, rewrites unexpected files, or inadvertently reads credentials gets mixed in. Even without malicious intent, AI can introduce hazardous behavior with good intentions. That is precisely why you need an architecture where code written by AI runs inside a secure cage. In this article, using Google's Cloud Run sandboxes—which entered public preview in July 2026—as our subject, we organize this concept from the perspective of a client outsourcing development.
Why code written by AI needs to be run in isolation
First, let us examine what makes it risky. When code is written by human engineers, the authors can review it themselves and trace the intent. However, code generated by AI comes in large volumes, and its contents may not be finalized until the exact moment of generation. In particular, when delegating tasks to an AI agent by telling it to perform certain work, the agent may write code on the fly at runtime and execute it on the spot. In the first place, there is simply no room for prior human review.
What is dangerous in this scenario is that the code can reach into everything in the production environment. Database connection info, communications to other systems, files on the server—if it runs with the same permissions as regular programs, a single piece of code generated by AI gains the standing to touch the entire production environment. While we discussed how even introducing packages like npm can become arbitrary code execution in our article on the era of npm install as arbitrary code execution, AI-generated code broadens that risk even further. That is why an approach of "letting it run, but running it inside a tight room where it can do nothing" becomes necessary.
The "tight room" provided by Cloud Run sandboxes
In July 2026, Google began offering Cloud Run sandboxes in public preview. This is an isolated execution environment designed to run untrusted code and code generated by AI agents. The key point is that this "room" is thoroughly confined.
| Restriction point | Default behavior | Significance for clients |
|---|---|---|
| Outbound communication | Denied by default; permits only approved destinations | AI code cannot send data outside on its own |
| Environment variables and credentials | Invisible from within the sandbox | Prevents AI code from reading connection strings and keys |
| File system | Read-only; modifications restricted to temporary space | Cannot overwrite production files |
Furthermore, this room spins up in milliseconds. Under traditional methods where you prepare a separate isolated environment on standby around the clock, startup latency and costs added up. Sandboxes, however, boot up the moment they are called and disappear when finished. Even for use cases where an AI agent executes code repeatedly, you are not kept waiting, while security is maintained. Combining speed and isolation is the practical value of this mechanism. A similar concept also connects with our article on a secure execution platform using WASI, which covered isolated execution of plugins.
What clients must check is how thoroughly it is isolated
Here is the core point for clients outsourcing development. When commissioning an external party for an internal tool or system using AI, you must not simply accept the deliverable after verifying that it merely works. What you should verify is to what extent the code involving AI is designed to run in an isolated state.
Specifically, please ask the following when ordering: Does the code generated and executed by AI run in a state where it cannot access production credentials or other systems? Is outbound communication blocked by default, with a design that explicitly allows only necessary destinations? If that code were to malfunction, would the blast radius be contained within the sandbox? A development partner that can clearly answer these questions has properly designed execution environments for the AI era. Conversely, caution is warranted with partners who merely state, "It works, so it's fine." Delivering not just a finished build, but a design that safely keeps risky elements running, is today's acceptance criterion.
Case study: A company that relocated an AI-built internal tool to production after isolating it
Here is a concrete example. The manufacturing company mentioned at the outset (name withheld) was right on the verge of deploying an AI-built quoting assistance tool directly to its production server. Upon consultation, the first thing we halted was running the AI-generated parts with the same privileges as production.
Here is how we proceeded. From the tool, we decoupled only the parts where the AI generates code on the fly to perform calculations, and redesigned it to run in an isolated environment where outbound communications are blocked by default and production connection info is hidden. We separated the fixed parts that humans can verify in advance from the variable parts written on the fly by AI, recognized that the risk lay in the latter, and locked only that section into a tight room. As a result, without altering the usability of the tool itself, we severed the pathway through which AI-generated code touches sensitive production data. What worked was not abandoning AI. It was separating the parts written by AI from the parts verifiable by humans, and running only the risky parts in isolation. If you can achieve this separation, you can safeguard production security while leveraging AI productivity.
First, identify where AI writes code at runtime
Anxiety about running code written by AI in production is a sound intuition. The answer is not to avoid using AI, but to run the parts involving AI inside a tight room where they can do nothing. Mechanisms like Cloud Run sandboxes have become a practical choice for provisioning that room quickly and securely. If you are getting started, first map out where in your internal systems AI generates and executes code at runtime. That is the highest-priority area to isolate.
Whether you are unsure if an AI-built tool can safely be put into production, want to properly demand safe execution architectures for AI-generated code from an outsourcing partner, or want to map out which parts of existing systems should be isolated together, please feel free to reach out via the GleamHub development, AI, and automation consultation desk. From isolating risky components to designing sandboxed execution environments, we will work alongside you tailored to your systems.
Sources
- Google Cloud Run sandboxes are in public preview | Google Cloud Blog
- Code execution in Cloud Run | Google Cloud Documentation
- Google Cloud launches public preview of Cloud Run sandboxes, enabling instantaneous isolation and secure execution of generative AI code | Publickey
- Executing agent-generated code in Cloud Run sandboxes | G-gen Tech Blog
