A compartmentalised identity is a credential or account limited to one business function or system boundary. It reduces blast radius by preventing a single machine identity from carrying mixed-purpose access across payment, administration, and security workflows.
Expanded Definition
Compartmentalised identity describes an NHI design pattern where one credential, account, or workload identity is intentionally restricted to a single business function, system boundary, or trust zone. It is narrower than simple role assignment because the identity itself is scoped to prevent cross-domain reuse.
In practice, this pattern supports Zero Trust Architecture by limiting what a service account, API key, or agent can reach if it is compromised. It is closely related to NIST Cybersecurity Framework 2.0 principles around access control, and it aligns with the broader lifecycle guidance in Ultimate Guide to NHIs. Definitions vary across vendors, because some tools describe compartmentalisation as workload isolation, while others treat it as entitlement segmentation or secret separation. For NHI governance, the useful definition is the one that can be verified operationally: one identity, one purpose, one blast radius.
The most common misapplication is creating a single shared service account and calling it compartmentalised, which occurs when teams reuse the same credential across multiple apps, environments, or teams.
Examples and Use Cases
Implementing compartmentalised identity rigorously often introduces more provisioning overhead and more policy objects, requiring organisations to weigh stronger containment against operational complexity.
- A payment-processing microservice uses a dedicated NHI that can write only to the settlement queue, while a separate identity handles fraud-scoring reads.
- An AI agent with tool access uses one identity for ticket creation and another for production deployment approval, reducing the chance that a single token can chain actions across systems.
- A CI/CD pipeline uses distinct identities per repository so a leak in one build path does not expose secrets across the entire engineering estate, a pattern echoed in JetBrains GitHub plugin token exposure.
- A database migration job receives a time-limited identity for schema changes only, instead of inheriting the long-lived admin account used by operators.
- A customer-support integration is isolated from billing and security workflows, so its API key cannot be reused to access privileged administrative functions.
This model is especially useful when teams need to segment access by function rather than by person, and the operational pattern is discussed further in the Ultimate Guide to NHIs and the NIST Cybersecurity Framework 2.0 guidance on least privilege.
Why It Matters in NHI Security
Compartmentalised identity matters because NHI compromise rarely stays local when one credential can authenticate to several systems. If a token is reused across admin, data, and automation workflows, the attacker inherits every boundary that token crossed. NHI security programs use this pattern to reduce lateral movement, simplify access reviews, and make revocation meaningful when incidents occur.
The risk is not theoretical. NHI Mgmt Group reports that Ultimate Guide to NHIs found 97% of NHIs carry excessive privileges, which makes broad identities especially dangerous when they are not compartmentalised. That exposure becomes more visible after incidents catalogued in 52 NHI Breaches Analysis and Top 10 NHI Issues, where over-scoped machine identities turned a single secret leak into a multi-system event. Compartmentalisation also supports zero standing privilege by making it easier to issue narrow, time-bound access instead of permanent access.
Organisations typically encounter the cost of poor compartmentalisation only after a credential leak, token replay, or agent misuse, at which point the term 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 Non-Human Identity Top 10 address the attack and risk surface, while NIST Zero Trust (SP 800-207) and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 | Compartmentalised identities reduce secret sprawl and over-broad machine access. |
| NIST Zero Trust (SP 800-207) | PDP/PEP | Zero Trust requires identities to be constrained by policy and trust boundaries. |
| NIST CSF 2.0 | PR.AC-4 | Least-privilege access control is the core operational fit for this term. |
Scope each NHI to one function and review secrets, permissions, and reuse paths.
