A low integrity process is a heavily restricted Windows process intended to limit damage if compromised. It cannot normally write to protected system locations or interact freely with higher-integrity components. However, if it can influence trusted IPC paths, it can still become a launch point for sandbox escape.
Expanded Definition
A low integrity process is a Windows security construct that confines an application to a tightly limited trust boundary. It is designed to reduce impact if the process is compromised, especially in browser sandboxes, preview handlers, and other untrusted execution contexts. In practice, integrity levels are part of Windows Mandatory Integrity Control, which complements discretionary access controls by restricting write access and some forms of interaction even when a process has valid credentials. For a useful external baseline, see the Microsoft overview of Mandatory Integrity Control.
In NHI and agentic environments, the term matters because a low integrity process can still handle content, parse input, or broker data into more trusted components. That means the security value comes from both isolation and disciplined IPC design. Industry usage is straightforward here: low integrity does not mean harmless, only more constrained. Definitions vary little across vendors, but implementation details differ depending on the application sandbox, the broker model, and what objects the process can still signal or influence. A process at low integrity may be blocked from direct writes, yet still reach higher-integrity code through named pipes, COM, window messages, or file handoff patterns if those channels are exposed. The most common misapplication is assuming low integrity is equivalent to full containment, which occurs when engineers ignore trusted IPC paths and broker permissions.
Examples and Use Cases
Implementing low integrity rigorously often introduces compatibility and orchestration overhead, requiring organisations to weigh stronger containment against more complex IPC and debugging constraints.
- A browser renderer runs at low integrity so untrusted web content cannot directly modify user files or registry locations, while a broker process mediates sensitive actions.
- A document viewer opens unknown attachments in a low integrity sandbox to reduce the blast radius of embedded scripts or parsing exploits.
- An agent tool execution wrapper uses a low integrity child process to inspect inbound data before a higher-trust service accepts it, lowering the chance of privilege crossover.
- A Windows application exposes a trusted IPC endpoint to a low integrity helper, but only after validating message origin and intent, because the helper still may influence privileged workflows.
- Security teams review patterns described in the Ultimate Guide to NHIs — Lifecycle Processes for Managing NHIs to ensure restricted components do not become persistent execution footholds.
These patterns align with NIST Cybersecurity Framework 2.0 thinking about reducing impact from compromise by segmenting trust and limiting lateral movement.
Why It Matters in NHI Security
Low integrity processes matter because NHI and agentic systems increasingly rely on local brokers, helper services, renderers, and automation shells that can be targeted even when the main identity is well managed. If the low integrity boundary is weakly designed, an attacker can pivot from a sandboxed foothold into token access, task execution, or tool invocation. That creates a path from execution containment to identity compromise. The NHI Mgmt Group notes that 80% of identity breaches involved compromised non-human identities such as service accounts and API keys, and 97% of NHIs carry excessive privileges, which makes any sandbox escape more consequential than it would be in a tightly minimized environment. See the Ultimate Guide to Non-Human Identities for broader lifecycle and governance context, including visibility and rotation practices.
In control terms, the important question is not whether a process is low integrity, but whether it can still influence trusted pathways that hand off secrets, sessions, or privileged commands. That is why this concept fits broader identity governance and Zero Trust thinking, including the NIST Cybersecurity Framework 2.0 and the principle of assuming compromise. Organisations typically encounter the true significance of low integrity processes only after a sandbox escape or broker abuse, at which point the boundary design becomes operationally unavoidable to address.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Agentic AI Top 10, OWASP Non-Human Identity Top 10 and CSA MAESTRO address the attack and risk surface, while NIST CSF 2.0 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.AC-4 | Access enforcement and segmentation limit what a low integrity process can reach. |
| NIST Zero Trust (SP 800-207) | SI | Zero Trust assumes constrained components still require explicit verification. |
| OWASP Agentic AI Top 10 | AI-03 | Agent tooling must prevent untrusted execution paths from escalating through helper processes. |
| OWASP Non-Human Identity Top 10 | NHI-05 | Restricted processes can still expose secrets if helper paths are not controlled. |
| CSA MAESTRO | M1 | Agentic workflows need boundary controls around execution and tool access. |
Ensure low-integrity helpers never become a route to tokens, keys, or privileged sessions.
Related resources from NHI Mgmt Group
- What breaks when low-integrity sandbox boundaries are composed with launch and URI handlers?
- Why do NHI programmes need stronger process ownership than many human identity programmes?
- Why do file integrity tools miss attacks like Copy Fail?
- What is the difference between code integrity risk and identity exposure risk in CI/CD?
