Identity Incident

Expanded Definition

An identity incident is broader than a stolen password or a single bad login. It includes abuse of credentials, sessions, approvals, tokens, service accounts, or delegated workflows when identity becomes the path to harm. In NHI security, that means the incident can start in code, CI/CD, a vault, an API gateway, or an AI agent with tool access.

The term is especially useful because traditional incident labels often focus on malware, phishing, or message compromise and miss the identity layer that enabled the event. Guidance varies across vendors, but the operational meaning is consistent: if an attacker or malicious insider uses trusted identity controls to act as an authorised entity, the event should be treated as an identity incident. That framing aligns with Zero Trust thinking and with identity-centric governance in frameworks such as NIST SP 800-207 Zero Trust Architecture.

Identity incidents are also common in agentic systems, where an AI agent may have legitimate execution authority but still be coerced, over-permissioned, or misrouted into unsafe actions. The most common misapplication is treating the event as a generic application outage, which occurs when teams fix the symptom without revoking the abused identity path.

Examples and Use Cases

Implementing identity-incident response rigorously often introduces faster containment demands, requiring organisations to weigh operational continuity against immediate credential and session disruption.

• A service account is used to exfiltrate data after its long-lived API key is found in a repository, matching the credential abuse patterns described in the Ultimate Guide to NHIs.
• An attacker hijacks an OAuth session and uses delegated access to approve a payment workflow, showing why identity incidents extend beyond password resets and into approval chains.
• An AI agent with tool permissions is prompted into issuing privileged actions it was allowed to execute, a scenario increasingly discussed in Anthropic research on AI-enabled abuse and agentic security guidance.
• A third-party integration is compromised, and the resulting token abuse creates lateral movement into internal systems, a pattern repeatedly surfaced in the 52 NHI Breaches Analysis.
• A human administrator approves an access request that was silently manipulated through a trusted workflow, turning a normal change process into an identity incident.

These cases show why identity incidents are not limited to authentication failures. They also include authorised paths that were misused, replayed, overextended, or delegated in ways the original control design did not anticipate.

Why It Matters in NHI Security

Identity incidents are costly because they undermine the trust model that non-human identities depend on. When credentials, sessions, and approvals are abused, defenders may see only legitimate-looking activity until data leaves the environment or automated actions cascade across systems. NHIMG research shows that 80% of identity breaches involved compromised non-human identities such as service accounts and API keys, and only 5.7% of organisations have full visibility into their service accounts according to the Ultimate Guide to NHIs.

That visibility gap matters because identity incidents demand more than endpoint cleanup. Teams need to trace token issuance, revoke standing access, inspect approval histories, and assess whether automation has inherited unsafe privileges. The same discipline appears in CISA Zero Trust maturity guidance, where identity is treated as a control plane rather than a login event. This is also why the 52 NHI breaches work is useful: it shows how often the abuse path is the identity workflow itself, not just a compromised host.

Organisations typically encounter the full business impact only after a trusted account has already issued bad actions, at which point identity incident response becomes operationally unavoidable to address.

Related resources from NHI Mgmt Group

• Identity Blast Radius
• When does a dependency compromise become an identity incident?
• When should organisations treat an identity incident as an operational crisis?
• When should organisations treat a VM compromise as an identity incident?