Identity collapse happens when the originating user’s identity is flattened into a generic service or agent identity during delegation. Downstream systems can still authenticate the request, but they lose the provenance needed to judge intent, assign accountability, or enforce context-specific authorization.
Expanded Definition
Identity collapse is not just a technical naming problem. It occurs when delegation removes the originating human, workload, or agent context and substitutes a shared service identity, leaving downstream systems unable to distinguish who initiated the action, why it was taken, or whether the request fits policy.
In NHI security, this matters because authentication alone does not preserve provenance. A request can still be valid under a service account, API key, or agent token while the true initiating identity is lost. That makes identity collapse different from simple impersonation or over-broad RBAC, because the core failure is the flattening of context across trust boundaries. Guidance is still evolving across vendors, but the operational pattern is well understood in NHI governance and aligns with the least-privilege and traceability goals described in the NIST Cybersecurity Framework 2.0 and NHIMG’s Ultimate Guide to NHIs.
The most common misapplication is treating a delegated action as safely attributable to the service identity alone, which occurs when teams log only the bearer token or account name and discard the original caller and intent.
Examples and Use Cases
Implementing delegation with full provenance often introduces extra logging, token propagation, and policy complexity, requiring organisations to weigh simpler integration against stronger accountability and contextual authorisation.
- An AI agent triggers a payment workflow using a shared integration token, but the downstream system records only the agent account and not the employee who approved the prompt.
- A CI/CD pipeline deploys infrastructure through a generic service principal, while the audit trail omits which pull request, maintainer, or approval step initiated the change.
- A microservice calls another service with a forwarded token, but the receiving API cannot tell whether the request came from a user session, a background job, or another agent.
- A third-party tool accesses customer data through delegated credentials, yet the organization cannot reconstruct which originating identity exercised the privilege during an incident review, a risk pattern reflected in NHIMG’s 52 NHI Breaches Analysis.
- Federated access using SPIFFE work-identity principles helps preserve workload identity, but only if teams still propagate caller context and not just the execution identity.
NHIMG’s Top 10 NHI Issues shows why this matters: identity collapse often appears where automation, delegation, and shared credentials overlap, especially in modern pipelines and agentic workflows.
Why It Matters in NHI Security
Identity collapse undermines attribution, approval controls, and incident response. When provenance is missing, security teams cannot reliably answer whether a service account acted within its intended scope, whether an agent exceeded instructions, or whether a user’s authorization should have expired before the action executed. That weakens Zero Trust enforcement and makes context-specific authorization almost impossible.
This is not a theoretical edge case. NHIMG reports that only 5.7% of organisations have full visibility into their service accounts, while 80% of identity breaches involved compromised non-human identities such as service accounts and API keys, according to the Ultimate Guide to NHIs. In environments with that level of visibility gap, flattening provenance turns normal delegation into an investigation blind spot. That risk is amplified when secrets are reused across workloads or when agentic systems reuse a shared execution identity without preserving caller context.
Practitioners typically encounter identity collapse only after a disputed transaction, failed audit, or breach investigation, at which point the missing provenance 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 CSF 2.0 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 | Identity collapse breaks NHI provenance, attribution, and delegated trust boundaries. |
| NIST CSF 2.0 | PR.AC-4 | Least-privilege access depends on knowing who initiated each delegated action. |
| NIST Zero Trust (SP 800-207) | Zero Trust requires continuous evaluation of request context, not blind trust in shared identities. |
Verify caller context at each hop and avoid authorizing solely on the downstream service identity.
