Isolation Is Key: Run AI-Generated Code Safely

The Code Looks Fine. That Is the Problem.

A developer asks an AI assistant to generate a Python script that processes uploaded files. The assistant produces clean, readable code. It runs on the first attempt. Three days later, a security review flags that the script writes to arbitrary filesystem paths when the input filename contains directory traversal characters. The code looked fine because it was plausible, not because it was safe.

This is the structural challenge with code that AI produces. The output is confident and syntactically correct. The mistakes are the kind that require security expertise to catch, not the kind that produce obvious failures.

What the Research Shows About AI Code Security

The vulnerability rate in code produced by AI models is not a hypothetical. Researchers at the University of Luxembourg, Royal Holloway, and other institutions analyzed 331,000 compilable C programs generated by nine leading models in a study published to arXiv in December 2024 (arXiv:2404.18353). At least 62.07 percent of those programs contained vulnerabilities, detected through formal verification using ESBMC. The models tested included GPT-4o-mini, Gemini Pro 1.0, Falcon 180B, and Code Llama 13B. They performed comparably to each other, with only slight variation in error rates.

A separate empirical study examined code generated by Copilot and two similar tools across real GitHub projects (arXiv:2310.02059v4, Fu et al., updated February 2025). It found security weaknesses in 29.5 percent of Python snippets and 24.2 percent of JavaScript snippets. The issues spanned 43 distinct CWE categories, eight of which appear in the CWE Top-25. When the researchers gave Copilot Chat the static analysis warnings and asked it to fix them, it resolved up to 55.5 percent of the identified issues. That means more than four in ten flagged vulnerabilities remained even after the model was explicitly told about them.

The implication is direct: reviewing code manually is necessary, but not sufficient by itself. Code that passes a review can still execute in ways that the reviewer did not anticipate, especially when inputs are dynamic or when the code runs in an agentic context where it can call external services, write files, or spawn processes.

How Sandboxing Closes the Gap

Sandboxing means running code inside a controlled execution boundary that limits what the code can do even if it behaves badly. The boundary is not a replacement for code review. It is a second control that catches what review misses.

The question is which boundary to use. The options have meaningfully different tradeoffs.

Standard containers, such as those run by Docker with default settings, use Linux namespace and cgroup isolation. They restrict the process to its own filesystem view and limit resource usage, but they share the host kernel. A kernel vulnerability can enable a container escape. CVE-2024-21626, known as “Leaky Vessels,” demonstrated this in early 2024: a file descriptor leak in runc gave a container access to the host filesystem.

gVisor adds a user space application kernel between the container process and the host. Its Sentry component intercepts system calls from the workload and handles them internally, exposing only about 68 host syscalls instead of the more than 350 that a standard Linux process can invoke. This substantially reduces the kernel attack surface. The cost is latency on operations that make many system calls: file I/O and network calls run slower. Workloads that rely mostly on computation see less impact.

Firecracker microVMs use hardware virtualization to run each workload in a genuine virtual machine, with its own kernel, while keeping the startup time under 125 milliseconds and memory overhead below 5 MB per instance. This is the approach Amazon uses for AWS Lambda. The isolation is strong because host and guest kernels are separate. Kata Containers takes a similar approach, wrapping each container in a lightweight VM while keeping a container API.

For teams building agentic test automation, the choice of sandbox matters more than it does for a simple script runner. An AI agent that can generate and execute code, read files, query databases, and call APIs needs boundaries that match its actual capabilities. NVIDIA’s AI Red Team has documented remote code execution through prompt injection in unsandboxed agentic workflows. The attack surface is the agent’s tool list, and the attacker’s payload arrives through the same channel as legitimate input.

What to Enforce Regardless of Which Sandbox You Choose

The sandbox sets the outer boundary. The inner configuration determines what actually runs safely within it.

Start by disabling network access by default. Code from an AI assistant that needs to reach an external endpoint should declare that dependency explicitly. Code that silently attempts outbound connections during test execution is either making an unintended call or has been manipulated. Either way, the call should fail at the network layer, not escape undetected.

Set hard limits on filesystem writes. A sandboxed process should write only to a designated output directory. It should not have write access to the directory containing the script itself, the test configuration, or anything that persists beyond the current execution session.

Apply resource caps. CPU time limits terminate runaway loops without operator intervention. Memory caps prevent a single rogue execution from exhausting the host. Storage quotas prevent attacks that fill the disk. These limits belong in the container or VM configuration, not as checks inside the generated script, since the script itself cannot be trusted to enforce them.

Log every execution. The log should record what the code did and how it behaved, not only whether it passed or failed. When a security review happens after the fact, the execution log is what makes it possible to determine whether a flagged snippet was ever run, in what context, and with what inputs.

The Agentic AI for QA and SDET course covers how to structure tool use boundaries in agentic test pipelines, including how to constrain what an AI agent can execute and which outputs it can write to disk.

Choosing a Sandbox for Your Testing Workflow

For most test automation teams, the practical decision is between hardened containers and microVMs. If the test environment runs in a CI pipeline where startup latency matters but the code being executed is reasonably trusted output from a controlled prompt, a container backed by gVisor gives a good balance of performance and protection at the kernel level. If the environment runs agentic code that generates and executes further code at runtime, the additional isolation of Firecracker or Kata Containers is worth the overhead.

The one configuration that is never acceptable is running code produced by an AI model with no sandbox at all on a developer workstation or a shared CI runner. The vulnerability data is clear, and the number of ways untrusted code execution goes wrong grows with every additional tool and service the host environment has access to.

The Generative AI and AI Agents for QA SDET Masterclass covers how to build pipelines that incorporate AI code generation responsibly, including the execution environment design decisions that keep the rest of your infrastructure safe.