Is a separate working directory enough sandboxing?

No. A working directory limits where files are placed by convention, not what the process can do. Code may still read environment variables, access home-directory credentials, inspect processes, open network connections, run package install hooks, or delete files outside that directory if permissions allow. A sandbox must enforce limits at the operating environment or runtime level.

Should agent-written code ever receive credentials?

Sometimes, but only as an explicit exception. Prefer no credentials, then scoped credentials with the smallest useful permissions, short lifetime, and audit trail. Do not rely on ordinary environment variables as a secret store, because child processes can usually read them. If access is needed, route it through a narrow proxy or capability-specific interface.

Are containers, virtual machines, and WebAssembly sandboxes interchangeable?

They solve the same class of problem but differ in isolation strength, compatibility, startup cost, and operational complexity. Containers are convenient for typical developer tooling, virtual machines provide a harder boundary, and WebAssembly can be a compact runtime for constrained code. The choice depends on what must run, what it may access, and what failure would cost.

Sandboxing what it runs

Sandboxing what it runs is isolating model-authored or model-selected code inside a restricted execution environment instead of letting it run on your machine or service. The sandbox supplies only the files, tools, network routes, credentials, CPU, memory, and time you explicitly grant, then discards the environment afterwards.

The need comes from treating agent execution as untrusted input. A model may generate a script, select a dependency, follow a malicious instruction in retrieved text, or run a command whose side effects it does not understand. The danger is not intent, but authority. If that process inherits your shell, filesystem, network, tokens, and cloud configuration, a small mistake can become data loss, credential leakage, or production impact.

A sandbox works by creating a deliberately narrow world for the code. The host copies in only the required inputs, mounts a temporary filesystem, blocks or proxies network access, applies CPU, memory, and time limits, and exposes capabilities through explicit interfaces rather than ambient access. Implementations vary: containers, virtual machines, WebAssembly runtimes, serverless workers, and remote execution services all build versions of the same controlled workshop.

The trade-off is that stronger isolation usually costs convenience. Startup may be slower, debugging can be less direct, filesystem and network assumptions may break, and you need plumbing for logs, artefacts, package installation, and cleanup. Security also depends on details: a container with broad mounts and host credentials is not much of a boundary. The honest answer is that the right sandbox depends on the code, data sensitivity, and required capabilities.

Engineers meet this when agents run tests, edit repositories, execute generated migration scripts, call command-line tools, or evaluate code snippets. A safe path creates a fresh sandbox per task, grants scoped and short-lived credentials only when unavoidable, records commands and outputs, collects artefacts, and destroys the environment. Prompt rules and hidden environment variables are commonly mistaken for protection, but enforcement must live in the runtime boundary.

Go deeper

Agents & MCPSandboxing what it runsRun model-authored code without giving it your environment.Open the lesson

Common questions

Is a separate working directory enough sandboxing?: No. A working directory limits where files are placed by convention, not what the process can do. Code may still read environment variables, access home-directory credentials, inspect processes, open network connections, run package install hooks, or delete files outside that directory if permissions allow. A sandbox must enforce limits at the operating environment or runtime level.
Should agent-written code ever receive credentials?: Sometimes, but only as an explicit exception. Prefer no credentials, then scoped credentials with the smallest useful permissions, short lifetime, and audit trail. Do not rely on ordinary environment variables as a secret store, because child processes can usually read them. If access is needed, route it through a narrow proxy or capability-specific interface.
Are containers, virtual machines, and WebAssembly sandboxes interchangeable?: They solve the same class of problem but differ in isolation strength, compatibility, startup cost, and operational complexity. Containers are convenient for typical developer tooling, virtual machines provide a harder boundary, and WebAssembly can be a compact runtime for constrained code. The choice depends on what must run, what it may access, and what failure would cost.

Every term