Why is model-generated code treated as untrusted?

Because the model is not the only influence on what runs. Prompts, retrieved content, dependencies, package scripts, and tool outputs can all affect execution. The risk is not human intent, but unpredictable control flow with access to real credentials, files, processes, or network services.

Is a separate working directory enough isolation?

No. A different directory limits accidental file writes, but it does not block network access, environment variable reads, credential discovery, process inspection, dependency install hooks, or destructive commands elsewhere. Isolation has to be enforced by the runtime and operating environment, not just by file layout.

What should an agent code sandbox allow?

It should allow only the inputs, tools, credentials, and network paths required for the specific task. Use a fresh environment, copy in selected files, apply CPU, memory and time limits, capture logs and artefacts, then destroy it. Credentials should be scoped and short-lived when they cannot be avoided.

Permissions and sandboxing

08.02 · Concept

Sandboxing what it runs

Run model-authored code without giving it your environment.

Model-authored code should run inside a disposable, tightly constrained environment with no access to your ambient credentials, local files, or unrestricted network. A good sandbox gives it only copied inputs, explicit capabilities, resource limits, observable output, and a short lifetime, so unexpected behaviour stays outside your real environment.

What this lesson answers

how to sandbox code written by an agent
why environment variables are unsafe for agent code
best runtime boundary for untrusted model code

Notes

When a model writes or chooses code to run, treat that code as untrusted input. The problem is not that the model is malicious in the human sense; it is that prompts, retrieved documents, dependencies, and generated scripts can all steer execution in surprising ways. Sandboxing means giving the code a deliberately small world: a temporary filesystem, limited network access, bounded CPU and memory, no ambient credentials, and only explicit capabilities you intended to expose.

A useful mental model is sending the model’s code into a clean workshop instead of letting it into your house.

Common questions

Why is model-generated code treated as untrusted?: Because the model is not the only influence on what runs. Prompts, retrieved content, dependencies, package scripts, and tool outputs can all affect execution. The risk is not human intent, but unpredictable control flow with access to real credentials, files, processes, or network services.
Is a separate working directory enough isolation?: No. A different directory limits accidental file writes, but it does not block network access, environment variable reads, credential discovery, process inspection, dependency install hooks, or destructive commands elsewhere. Isolation has to be enforced by the runtime and operating environment, not just by file layout.
What should an agent code sandbox allow?: It should allow only the inputs, tools, credentials, and network paths required for the specific task. Use a fresh environment, copy in selected files, apply CPU, memory and time limits, capture logs and artefacts, then destroy it. Credentials should be scoped and short-lived when they cannot be avoided.

Short definition: what is Sandboxing what it runs?

08.01 · Permissions and sandboxingLeast privilege, for a loop 08.03 · Permissions and sandboxingHuman in the loop, where it counts