Identity chain of custody is the record of how authority moves from initial authentication through each subsequent action, tool call, or delegated step. It helps practitioners determine which identity exercised access at each point and whether the resulting activity stayed within policy.
Expanded Definition
Identity chain of custody describes the traceable path of authority as an NHI, service account, API key, or Agent moves from authentication into each downstream action. It is the evidence needed to answer who, or what, exercised access at every step and whether delegation stayed inside policy. In practice, this sits between IAM, PAM, RBAC, JIT, and ZSP controls, because each handoff changes the risk profile.
Definitions vary across vendors when automated workflows, token exchange, and agent tool use are involved, so the safest working model is to treat chain of custody as an audit narrative, not just an access log. The NIST Cybersecurity Framework 2.0 provides a useful governance lens for identity accountability, while the deeper NHI context is covered in the Ultimate Guide to NHIs and the Ultimate Guide to NHIs — What are Non-Human Identities.
The most common misapplication is assuming a single login event proves authorization for all later tool calls, which occurs when short-lived tokens, delegated credentials, or agent actions are not correlated back to the original identity context.
Examples and Use Cases
Implementing identity chain of custody rigorously often introduces logging overhead and correlation complexity, requiring organisations to weigh stronger accountability against operational friction and storage cost.
- An AI Agent receives a scoped token, calls an internal API, then triggers a second tool through MCP. The chain must show whether the second action inherited the same authority or was separately approved.
- A CI/CD pipeline rotates a secret after deployment, but a cached credential still signs subsequent jobs. The chain of custody should reveal which job, runner, or service account retained usable authority.
- A privileged service account assumes a temporary role under PAM, performs a database migration, and then resumes normal access. The audit trail should distinguish standing privilege from JIT elevation.
- A developer checks in code that later invokes a cloud function with an embedded token. The JetBrains GitHub plugin token exposure and broader secret-handling lessons in the Top 10 NHI Issues show why provenance must follow the secret, not just the user who created it.
- In a federated environment, a workload identity exchanges a token across trust boundaries. The chain must preserve the original issuer, audience, and delegated scope so investigators can reconstruct authority accurately, consistent with the intent of NIST Cybersecurity Framework 2.0.
Why It Matters in NHI Security
Identity chain of custody matters because NHI incidents often look like legitimate automation until the full sequence is reconstructed. NHIs outnumber human identities by 25x to 50x in modern enterprises, and only 5.7% of organisations have full visibility into their service accounts, which makes weak provenance a practical blind spot. The 52 NHI Breaches Analysis and Cisco DevHub NHI breach illustrate how quickly token abuse and overbroad delegation can turn ordinary access into breach activity.
When chain of custody is missing, defenders can see that a secret was used but not which identity exercised it after the first hop. That breaks incident response, forensics, and policy enforcement across ZTA and RBAC environments. It also weakens zero standing privilege enforcement, because temporary authority cannot be proven to have expired if the downstream actions are not linked back to the originating grant. Organisational teams typically encounter this consequence only after suspicious automation, lateral movement, or a secret leak, at which point identity chain of custody 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-03 | Focuses on tracing NHI actions back to the identity and its delegated authority. |
| NIST CSF 2.0 | PR.AC-4 | Least-privilege access requires knowing which identity exercised each action. |
| NIST Zero Trust (SP 800-207) | SC-3 | Zero Trust depends on continuous verification of identity context across sessions and services. |
Correlate every NHI action to its originating identity, token, and scope before approving trust decisions.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on May 26, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
