# Why, and how you need to sandbox AI-Generated Code?

Harshil Agrawal, Cloudflare | AI Engineer Europe 2026 | 38:27

Source: https://www.youtube.com/watch?v=AHtGAgQ0Q_Q
Channel: AI Engineer (https://www.youtube.com/@aiDotEngineer). Summarised by AIE Talks.
Page: https://aietalks.com/talks/why-and-how-you-need-to-sandbox-ai-generated-code
Published: 2026-04-08
Tags: computer-use, deployment, security

## TL;DR
- AI-generated code is untrusted code because it can be wrong, expose secrets, or follow adversarial instructions while running with application privileges.
- Capability-based security limits code by granting only the specific bindings, network access, files, and resources it needs.
- V8 isolates fit short-lived JavaScript, TypeScript, Python, and WebAssembly tasks, while containers fit applications that need files, processes, package installation, or servers.

## Summary
Harshil Agrawal argues that AI-generated code should be treated like code copied from an unknown website. An LLM can produce an infinite loop, read credentials while trying to configure a service, or follow direct or indirect prompt injection. If that code runs inside the application, it may inherit access to files, networks, databases, and API keys. Agrawal recommends capability-based security: deny access by default and explicitly provide only the capabilities a task needs. He compares V8 isolates with containers. Isolates are fast and constrained, making them suitable for tool calls, plugins, interpreters, and data transformation. Containers provide Linux, files, processes, package managers, and long-running servers for building applications. He also covers per-user isolation, proxying secrets through the host application, resource limits, cleanup, logging, and input checks. The talk gives a practical way to choose an execution environment without treating sandboxing as an afterthought.

## Key ideas
### AI-generated code is untrusted internet code
[01:41](https://www.youtube.com/watch?v=AHtGAgQ0Q_Q&t=101s)
Agrawal asks engineers to remove the AI framing and see what is happening: an opaque system receives a prompt, returns code, and that code may run without line-by-line review. He compares this with finding a code snippet on a random website and putting it into production, which most teams would reject. The model has no loyalty or intention. It produces text that looks like code. That code may be correct, subtly wrong, or dangerous because of hallucination, over-helpfulness, or adversarial manipulation. The risk becomes much larger when the code runs with the application's real privileges, including access to the file system, environment variables, networks, databases, and API keys.

### Three ordinary failure modes can become security incidents
[03:03](https://www.youtube.com/watch?v=AHtGAgQ0Q_Q&t=183s)
The first threat is hallucination. A model can import a package that does not exist, omit a recursive function's base case, or generate a non-terminating loop. The result can be crashed processes, exhausted compute, or a stack overflow. The second threat is the over-helpful model. While configuring a database, it might inspect environment variables and process API keys or credentials. It does not need malicious intent for the effect to be dangerous. The third threat is prompt injection. A user can ask the model to send environment variables to a URL, or a web page and document can contain hidden instructions that the model consumes indirectly. In each case, the agent's privileges determine the damage.

### Capability-based security starts with default denial
[08:09](https://www.youtube.com/watch?v=AHtGAgQ0Q_Q&t=489s)
Agrawal says browsers, operating systems, and phones already isolate untrusted activity. The shared principle is capability-based security: enumerate what code may use instead of trying to list every operation to block. A block list gives code broad access and depends on finding every dangerous call. An allow list gives it only the capabilities explicitly granted. If a capability is not granted, it does not exist for that code. In practice, this means starting with no network, file system, secrets, or broad platform access, then adding narrowly scoped interfaces such as a database method or logger. The model's generated code should receive the smallest surface that lets its task finish.

### Isolates provide fast execution with strong constraints
[10:05](https://www.youtube.com/watch?v=AHtGAgQ0Q_Q&t=605s)
V8 isolates are lightweight sandboxes built on the engine used by Chrome. Agrawal says they start in a quarter millisecond and can run JavaScript, Python, TypeScript, and WebAssembly. They have no file system or process model, so the code cannot install packages, start a server, or access the host's memory and environment unless the application passes a capability. In his example, a dynamic worker isolate receives a restricted database binding and a logger. Network access is set to null, which blocks fetch, WebSocket, and HTTP requests. The limits fit short-lived functions, tool calls, plugins, skills, and data transformation. State must be stored outside the isolate through an explicit binding.

### Containers are needed for full application workspaces
[21:37](https://www.youtube.com/watch?v=AHtGAgQ0Q_Q&t=1297s)
Agrawal's video-generation application needs to clone a repository, install NPM dependencies, run a build, start a development server, and expose a preview URL. Isolates cannot meet those requirements because they lack a file system, processes, and the needed networking model. A container provides a Linux environment with tools such as Bash, Node.js, Git, and NPM. The application gets a sandbox for a user, clones the repository inside it, installs packages there, starts the server as a background process, and returns a URL. The worker does not handle those files or packages directly. Containers take seconds to start, cost more, and add orchestration and networking components, but those costs match workloads that need real files and long-running processes.

### Every user needs a separate sandbox
[26:16](https://www.youtube.com/watch?v=AHtGAgQ0Q_Q&t=1576s)
For the container-based application, Agrawal makes the user ID the isolation boundary. User A and User B receive separate containers with separate file systems and processes. User A's workspace is not merely hidden from User B's code. It does not exist in User B's container. Sharing a sandbox would allow one user to read another user's code, data, or potentially secrets. He warns that this decision becomes difficult to reverse after the architecture is established. The rule is direct: one user, one sandbox, with no shared execution environment between tenants, even when the applications being built seem harmless.

### Secrets should stay in the host application
[27:39](https://www.youtube.com/watch?v=AHtGAgQ0Q_Q&t=1659s)
Agrawil describes passing an API key into a sandbox as a common mistake. Once the key is an environment variable inside the container, any code there can read it. That includes generated code affected by prompt injection and buggy code that logs its environment. His default is a proxy: the sandbox calls an endpoint owned by the worker, the worker adds the real authentication header, forwards the request to the external service, and returns the response. The secret remains in the worker's environment and never enters the sandbox. The same pattern gives the host control over allowed services, authentication, logging, and rate limits when generated code genuinely needs an external API.

### A combined architecture can use isolates and containers
[31:12](https://www.youtube.com/watch?v=AHtGAgQ0Q_Q&t=1872s)
Agrawal's decision rule is based on the execution requirements. If code needs a file system, processes, or package installation, use a container. Otherwise, an isolate is faster, cheaper, and simpler. Tool calls, code interpreters, and data transformation fit isolates. Application builds, test suites, package installation, file creation, and development servers fit containers. The two environments can appear in one agent workflow. The agent can use isolates for fast function calls and repeated model iterations, then switch to a container when it decides to build and deploy an application. The choice is made for each step rather than once for the entire system.

### The sandbox must have limits, cleanup, and an audit trail
[32:59](https://www.youtube.com/watch?v=AHtGAgQ0Q_Q&t=1979s)
Agrawal's checklist applies across sandbox technologies. Network access should be denied unless it is explicitly needed. Capabilities should be narrow, and each tenant should have its own environment. Timeouts, memory caps, and CPU limits stop infinite loops and unbounded allocations from consuming resources. Secrets stay outside the sandbox and sensitive operations go through application code. Containers should be destroyed in a finally block after a build or session, including when an exception occurs, and maximum lifetimes should remove idle environments. The system should log what code ran, when it ran, who triggered it, and what it did. Input checks such as length limits, syntax validation, and dangerous-pattern detection add another layer before execution.

## Notable quotes
- "What we are actually doing is running untrusted code from the internet." (01:41)
- "Don't enumerate what to block. Enumerate what to allow." (08:09)
- "The secret never enters the sandbox." (28:06)
- "One user, one sandbox, no exception." (27:17)
- "AI-generated code is untrusted code." (35:59)

## Tools & references mentioned
- Cloudflare
- V8 isolates
- Chrome
- Open Claw
- Hacker News
- Cloudflare Dynamic Worker Isolates
- Cloudflare Sandbox SDK
- Cloudflare Durable Objects
- Prompt Motion
- NPM
- Git
- WebAssembly
- Code Mode

## Who should watch
- You are building an agent that executes generated functions, plugins, or code interpreters and need a practical access-control model.
- Your product lets users generate applications, install dependencies, or run development servers, and you need to choose between isolates and containers.
- You are passing API keys or shared workspaces into generated-code environments and want to understand the data-leak paths before shipping.

## Editor's note

From the pack [Security for agents](https://aietalks.com/packs/security):

Guercio wants every request visible, while Palma sends findings into an existing security process. Both depend on evidence from a specific run rather than the agent's account of what happened. Kitaru records agent runs so a team can inspect and replay the sequence that reached a dangerous tool call, including the inputs and tool results around it.

Written by the AIE Talks editors (the Kitaru team), not by the speaker.

## Related talks

- [Securing Code-Executing AI Agents](https://aietalks.com/talks/securing-code-executing-ai-agents) (Fouad Matin, OpenAI, 14:00)
- [How to Add Secure Code Interpreting in Your AI App](https://aietalks.com/talks/how-to-add-secure-code-interpreting-in-your-ai-app) (Vasek Mlejnsky, E2B.dev, 1:48:16)
- [Beyond the Prototype: Using AI to Write High-Quality Code](https://aietalks.com/talks/beyond-the-prototype-using-ai-to-write-high-quality-code) (Josh Albrecht, Imbue, 17:59)
- [Code Mode: Let the Code do the Talking](https://aietalks.com/talks/code-mode-let-the-code-do-the-talking) (Sunil Pai, Cloudflare, 19:40)
- [Security Track Intro](https://aietalks.com/talks/security-track-intro) (Randall Degges, Snyk, 04:16)