The parent-child trust gap is the difference between what a sandboxed child process is supposed to be able to do and what the parent process still can do on its behalf. This gap often creates leakage paths through shared state, output files, or inherited privileges.
Expanded Definition
A parent-child trust gap describes a security mismatch between the limits imposed on a sandboxed child process and the broader authority the parent process still retains. In practice, the child may be constrained by policy or runtime isolation, while the parent can still read, write, invoke, or broker actions that affect the child’s output and surrounding state.
This matters because the effective trust boundary is often wider than the sandbox itself. Shared working directories, inherited handles, ambient environment variables, temporary files, and parent-managed orchestration can all become indirect control paths. The child may look isolated, yet the parent can still influence the same data flow or execution outcome.
Usage is fairly consistent across secure systems engineering, although vendors and platforms differ in how they implement process isolation. A common misunderstanding is treating “sandboxed” as equivalent to “fully separated.” The correct boundary question is not whether the child is restricted, but whether the parent can still act on its behalf in ways that change confidentiality, integrity, or privilege.
Examples and Use Cases
- A browser renderer runs with reduced permissions, but the browser process still writes downloaded content or intermediate files into shared locations.
- A build worker is locked down, yet the orchestrator retains access to artifacts, logs, and cached credentials used during the job.
- A plugin executes in a constrained runtime, while the host application can still forward requests, open files, or submit data on the plugin’s behalf.
- A containerised child process is isolated from direct host access, but the parent service can mount volumes or pass inherited descriptors that reopen a control path.
These examples show the same trade-off: tighter child restrictions can improve containment, but they do not automatically remove the parent’s ability to become an indirect trust bridge. The boundary is only as strong as the shared state and delegation paths around it.
Security Implications
When the parent-child trust gap is ignored, teams can overestimate isolation and underprotect the channels that still cross the boundary. That can lead to data leakage through shared files, unintended privilege reuse, confused-deputy behaviour, and integrity loss when the parent processes or rewrites output that the child was meant to control.
The practical failure mode is usually not a dramatic bypass of the sandbox. It is a gradual erosion of separation through orchestration, helper services, temporary state, or inherited permissions. Once the parent can modify the child’s artifacts, the sandbox becomes a control point rather than a hard boundary.
This is especially visible in systems that rely on process chaining, task runners, or privileged supervisors. If an attacker can influence the child, they may reach the parent through output handling, whereas if the parent is compromised, the child’s restrictions no longer provide meaningful containment.
For a wider identity and credential-management perspective, the NHI-linked pattern behind this class of exposure is reflected in Ultimate Guide to NHIs, which highlights how weak control of non-human access paths drives leakage and excess privilege.
Security, Operational and Governance Implications
From a security architecture standpoint, the gap is a reminder that process isolation is only one layer of trust design. The parent process, supervisor, broker, and file system context often define the real attack surface, so controls must cover delegation paths, not just child-process permissions.
Operationally, teams should expect this issue to surface in build systems, browsers, automation workers, and plugin ecosystems where parent-owned state is reused across multiple execution steps. The key governance question is who owns the parent’s authority and whether that authority is deliberately bounded, audited, and revocable.
Where the parent can still act on behalf of the child, least-privilege design should extend to the orchestration layer as well as the sandbox. That includes reducing shared mutable state, tightening inherited access, and documenting which actions remain parent-mediated. The OWASP Non-Human Identity Top 10 is useful here because it reinforces how delegated machine-side authority can expand beyond the obvious execution context.
Practitioners should treat the trust gap as a design property, not an implementation bug. If the parent can still alter the child’s outcomes, then the security question is how that delegation is controlled, monitored, and constrained over time.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
CIS Controls v8 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CIS Controls v8 | 6 — Access Control Management | Covers limiting and reviewing effective access paths between parent and child processes. |
| Recommendation — Apply Control 6 to remove unnecessary inherited access and narrow parent-mediated authority. | ||
| NIST CSF 2.0 | PR.AC-4 — Access Permissions and Authorizations | Applies because the gap is about who can act on behalf of a constrained process. |
| PR.DS-1 — Data-at-Rest Protection | Applies when shared files or artifacts let the parent influence child-controlled data. | |
| DE.CM-8 — Monitoring for Unauthorized Activity | Applies because parent-child leakage often shows up in abnormal file, handle, or process activity. | |
| Recommendation — Use PR.AC-4 to enforce least privilege across parent-child delegation paths. Use PR.DS-1 to protect shared state and output files that cross the trust boundary. Use DE.CM-8 to monitor process relationships and shared-state access for abuse. | ||
