Dagger sandboxes are isolated execution environments used by Dagger to run build and automation steps without affecting the host system. They separate files, processes and network access for each run, which helps keep pipeline actions reproducible and limits unintended changes to the local machine or CI runner.
Isolation boundaries in build sandboxes
Dagger sandboxes are designed to keep each build or automation step inside a constrained execution boundary. That boundary matters because pipeline code often handles untrusted inputs, dependencies and scripts, so separation reduces the chance that one run can alter another run or the host machine.
The practical security value is not just containment, but predictability. By isolating files, processes and network access, the sandbox turns a build step into a smaller trust domain, which makes it easier to reason about what the step can see, modify or exfiltrate.
How sandboxing changes pipeline behaviour
A sandbox changes the default assumptions of CI and local automation. Instead of inheriting broad access to the runner or workstation, the step receives only the resources the sandbox exposes, which helps prevent accidental state sharing, hidden dependencies and unexpected persistence between runs.
This is especially important for reproducibility. If a build succeeds only because it can read leftovers from a previous run or reach an external service opportunistically, the result is fragile. Sandboxing pushes the pipeline toward explicit inputs and declared dependencies.
Why file, process and network separation matter
Each isolation layer addresses a different failure mode. File isolation limits unwanted writes and leaks, process isolation reduces interference between tasks, and network restrictions narrow the opportunity for supply-chain abuse, data exfiltration or unplanned outbound calls. Together they reduce the blast radius of a compromised or misbehaving step.
For teams running third-party tooling, these boundaries are also a control against overreach. A seemingly harmless formatter, test harness or install script can still modify local state, scan the environment or contact remote endpoints if it is not constrained.
NIST SP 800-53 Rev 5 Security and Privacy Controls provides a control catalog that maps well to the access, isolation and monitoring concerns behind sandboxed execution.
Where Dagger sandboxes fit in modern delivery pipelines
Sandboxing is one layer in a broader delivery-security model, not a complete substitute for trust in code, dependencies or infrastructure. It works best when paired with explicit inventory of pipeline steps, review of imported tools and careful handling of artifacts that cross the sandbox boundary.
SLSA is relevant because reproducible, isolated execution supports stronger supply-chain integrity claims, especially when build provenance matters to downstream consumers.
NIST Cybersecurity Framework 2.0 also fits well here, since sandboxing contributes to protective controls, detection readiness and recovery from pipeline compromise.
Risk and Threat Considerations
The main risk is assuming that sandboxing alone makes build steps safe. A sandbox can still be weakened by excessive privileges, unsafe mounts, misrouted secrets or overly permissive network access, so isolation must be treated as a control boundary that needs design and verification.
Failure mechanism: If a sandbox leaks host access, shared state or credentials, malicious or buggy pipeline code can escape its intended scope and influence other jobs, local assets or external systems.
Impact: The result can be corrupted build outputs, secret exposure, compromised runners, unreliable release artefacts and a wider supply-chain blast radius.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5, NIST CSF 2.0 and SLSA set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | AC-6 — Least Privilege | Sandbox isolation depends on limiting what each step can access and modify. |
| Recommendation — Apply least-privilege constraints to each sandboxed step and deny unnecessary filesystem, process and network access. | ||
| NIST CSF 2.0 | PR.AA-05 — Identity Management, Authentication, and Access Control | Pipeline sandboxes rely on controlled access to resources, secrets and execution boundaries. |
| Recommendation — Restrict sandboxed pipeline access paths so each run receives only the resources it needs. | ||
| SLSA | Supply-chain provenance | Isolated builds support reproducible artifact creation and stronger provenance claims. |
| Recommendation — Use isolated, reproducible build execution to strengthen provenance and integrity for released artifacts. | ||
Practitioner Guidance
Why practitioners should care: Treat sandbox configuration as part of pipeline security architecture, not as a convenience feature. The important question is whether the sandbox actually constrains file, process, network and secret access in the way the workflow assumes.
What to watch for: Review any exception that lets a job pierce the sandbox, especially broad filesystem mounts, inherited environment variables, long-lived credentials or unrestricted outbound connectivity. Those exceptions usually define the real trust boundary more than the sandbox label does.
Related resources from NHI Mgmt Group
- How should security teams govern AI agents that have their own sandboxes?
- Why do AI agent sandboxes still leak secrets even when egress policies are enforced?
- How should security teams handle credentials inside AI coding agent sandboxes?
- What breaks when AI coding agents run in allow-default sandboxes?