Sandboxing / Containment

Security Objective

Sandboxing and containment limit the effects of code, tools, interpreters, browsers, document processors, sub-agents and other potentially influenced execution by placing them behind deterministic isolation and resource boundaries outside the model. The objective is not to prevent influence. It is to make sure that influenced execution can only touch what the boundary allows.

Threat Model

Prompt injection can change what an agent proposes, and some proposals lead to execution: a generated script, a parser run on an untrusted file, a browser session on an unknown page, or a delegated sub-agent. Detection may miss the influence, and authorization may correctly allow the execution because the task legitimately requires it. Containment assumes that some influenced execution will run and limits what it can reach.

A contained denial does not prove malicious intent. It proves that the attempted effect was outside the boundary.

What a Sandbox Is and Is Not

Separate Control Planes

Keep these as separate decisions with separate evidence. Do not collapse trust, authorization, reachability, information flow and containment into one score.

Architecture Placement

Place containment around components that execute or interpret content whose behavior the application cannot fully predict: code interpreters, generated scripts, shell-like tools, browsers and renderers, document and archive processors, media decoders and delegated sub-agents or tool workers.

The execution itself stays untrusted even inside the boundary. The boundary, its policy and its release gate are application-owned.

Isolation Choices and Trade-offs

No single technology is universally sufficient. A container is not a virtual machine, and a virtual machine with broad mounts, credentials and networking can still expose far more than intended. The configuration and the surrounding controls determine the effective boundary.

Per-Task and Per-Run Isolation

Where practical, provision a fresh environment per task or run. Never share a sandbox, workspace or cache across users or tenants. Shared long-lived sandboxes let influenced execution in one task leave state that affects another.

Filesystem Containment

A path that is not mounted does not exist for the workload. That is stronger than a rule that tells the workload not to read it.

Process and Operating System Containment

Run workloads as a non-root or otherwise unprivileged identity with reduced capabilities. Apply system-call or process policy where the platform supports it, use a separate process namespace where applicable and do not let the workload inherit host environment variables, credentials or handles. NIST SP 800-53 SC-39 describes maintaining separate execution domains for processes; this page applies that general principle to agent execution.

Resource Limits

Exhaustion should terminate the task with evidence, not take down the host or neighbouring workloads. Exhaustion alone is not evidence of malicious intent.

Network Posture

Workloads that do not need a network get none. Where networking is required, route it through brokered, separately controlled network and egress restrictions. A sandbox must not provide a direct path around the egress layer, and having networking inside a sandbox does not decide which destinations are reachable.

Secrets and Credentials

Do not place broad production secrets in the sandbox, its environment, its filesystem or the model context. When a task genuinely needs a credential, issue a task-scoped, short-lived one and revoke or let it expire when the task ends. A credential that was never provided cannot be exposed by influenced execution. This is engineering guidance that follows from least privilege, not a quotation from a cited source.

IPC, Local Services, Metadata and Management Planes

Isolate or block inter-process channels, local host services, cloud metadata endpoints and management planes unless the workload explicitly requires them. These interfaces often carry credentials or control functions and can turn a contained workload into an uncontained one.

Browser and Document-Processing Workers

Browsers, renderers and document or archive processors handle content whose origin the application does not control, including documents and retrieved pages. Run them in isolated workers and treat rendered content, extracted text and produced artifacts as untrusted. Browser isolation limits what rendering can affect; it is not authorization for anything the page asks the agent to do.

Sub-Agent and Tool-Worker Containment

Delegated workers run with their own bounded environment and cannot inherit broader capabilities than the delegation intended. Their results return as variable data, the same as tool output, and do not carry the parent's authority.

Artifact Export and Release Boundary

Anything leaving the sandbox crosses a separate release boundary. Export requires independent authorization for the resulting action, information flow checks for the data, output validation of structure and format and, where applicable, content scanning. Containment does not make outputs semantically safe.

Lifecycle and Reset

Start from a fresh or reliably reset state, clean up after completion and destroy ephemeral environments. Persistence across runs is avoided unless explicitly required, scoped and governed, and even then it is treated as untrusted input for the next run.

Fail-Closed Behavior

If required containment cannot be provisioned or its policy cannot be enforced, protected execution does not run. It never silently falls back to unrestricted host execution. Record SANDBOX_UNAVAILABLE and surface the failure.

Relationship to Other Controls

Tool-chain analysis and plan drift detection may flag suspicious sequences or deviations, but the containment boundary remains deterministic and enforceable without them.

Policy, Versioning and Exceptions

Containment policy is versioned configuration: image or runtime version, mounts, network mode, limits and credential rules. Exceptions carry an explicit owner, scope and expiry. Model output never grants an exception or widens a sandbox.

Observability, Evidence and Reason Codes

Example reason codes, as engineering guidance and not a standard: FILESYSTEM_PATH_DENIED, NETWORK_DISABLED, RESOURCE_LIMIT_EXCEEDED, PROCESS_POLICY_DENIED, SECRET_NOT_AVAILABLE, EXPORT_REQUIRES_RELEASE and SANDBOX_UNAVAILABLE.

Worked Scenario A: Read-Only Document Processing

A user asks for a summary of an archive, quarterly-report.example.zip. Extraction and parsing run in an ephemeral workspace with the archive mounted read-only, no network and bounded scratch space. Execution is allowed inside the sandbox. The extracted text remains untrusted, and any file meant to leave waits for release checks.

Worked Scenario B: Generated Helper Script

The agent generates a helper script to reformat a table. It runs in a no-network worker with read-only input and bounded scratch space. It is allowed to run inside the sandbox. This does not mean the script is trusted, correct or safe to run elsewhere.

Worked Scenario C: Host-Only Secret Path Denied

Code in the sandbox attempts to read a host-only path, represented as /host-secrets/service.example, that is not mounted. The access fails at the filesystem and capability boundary with FILESYSTEM_PATH_DENIED. No secret was exposed, and the event alone does not establish intent.

Worked Scenario D: Resource Quota Exceeded

A workload exceeds its memory or process quota, or its wall-clock timeout. It is terminated with RESOURCE_LIMIT_EXCEEDED and the limit that triggered. The host and other workloads continue. The run is not labeled malicious solely because it exhausted resources.

Worked Scenario E: Export Held for Release

The sandbox produces report-draft.example.csv and proposes sending it to records.partner.example.test. Export is held with EXPORT_REQUIRES_RELEASE until independent authorization, information flow control, output validation and release policy pass. Nothing has been exported while it is held.

What the Scenarios Prove and Do Not Prove

Testing and Validation

These tests verify that the boundary holds. They are not a catalogue of isolation-escape techniques, and this page intentionally contains none.

Metrics

These are operational measures, not proof of security. Do not combine them into one score.

Common Mistakes

Implementation Checklist

Standards and Sources

Source scope: NIST SC-39 is general process-isolation guidance, and AC-6 and SC-7 are cited only to mark the boundaries to least privilege and network boundary protection. NIST SP 800-190 is general container security guidance published in 2017; it predates modern LLM agents and does not address them. The OWASP agentic list provides risk context for agent and tool misuse, and LLM01:2026 is prompt-injection risk context only. No cited source defines sandboxing / containment as a complete AI-agent control standard. Isolation choices, reason codes, record fields, scenarios and metrics on this page are engineering guidance.

Frequently Asked Questions