Recursive identity creation happens when an automated system, script, or AI agent provisions additional identities as part of its own workflow. This creates governance pressure because access issuance can spread faster than manual review or traditional directory-based controls can track.
Expanded Definition
Recursive identity creation describes a control failure pattern in which an automated workflow, script, CI/CD pipeline, or NHI provisions more identities as part of its own execution path. In practice, the system is creating the very access it later depends on, which makes governance harder and audit trails noisier.
Definitions vary across vendors, especially when an AI agent is involved. Some tools treat every token mint, service account spawn, or workload registration as simple automation, while others classify the same event as agentic authority expansion. The core security concern is the same: identity issuance is no longer a discrete human-approved event, so NIST Cybersecurity Framework 2.0 principles such as access control, auditability, and risk management become harder to sustain at machine speed.
Recursive identity creation is usually discussed alongside JIT, PAM, RBAC, ZSP, and ZTA, but it is not identical to any of them. JIT may reduce standing access, yet recursion can still occur if the provisioning step itself is unconstrained. The most common misapplication is assuming an approval workflow is sufficient, when the condition that causes risk is an automated identity chain that can continue without fresh human review.
Examples and Use Cases
Implementing recursive identity creation rigorously often introduces latency and orchestration overhead, requiring organisations to weigh machine autonomy against reviewability and blast-radius containment.
- A deployment pipeline spins up a temporary service account, which then requests another token to access a secrets manager and register a downstream job runner.
- An AI agent opens a ticket, triggers a provisioning workflow, and receives a new API key that it later uses to create additional helper identities for task execution.
- A multi-stage CI/CD process clones a build identity per repository, then allows each clone to issue more credentials during release promotion.
- A cloud integration account uses delegated permissions to create tenant-scoped identities, but no rate limits or policy checks exist to stop identity multiplication.
- An internal automation platform follows least-privilege intent, yet its bootstrap path depends on a parent account that can mint child accounts without time bounds.
These patterns are easier to spot when teams map identity issuance flows against the broader lifecycle guidance in the Ultimate Guide to NHIs and compare them with documented breach patterns in the 52 NHI Breaches Analysis. A related lens comes from the NIST Cybersecurity Framework 2.0, which helps teams ask whether each issuance step is governed, logged, and bounded.
Why It Matters in NHI Security
Recursive identity creation is dangerous because it can hide privilege expansion inside ordinary automation. Once one identity can create another, the environment may develop identity sprawl faster than manual reviewers or directory controls can detect. That makes revocation, ownership mapping, and incident scoping much harder, especially when credentials are stored outside a central vault or embedded in pipelines.
NHI Mgmt Group research shows that Ultimate Guide to NHIs reports that 97% of NHIs carry excessive privileges, which is exactly the kind of condition recursion amplifies. When identity creation can cascade, one over-permissioned service account can become a factory for more over-permissioned identities. That pattern also intersects with the incidents profiled in Cisco DevHub NHI breach and JetBrains GitHub plugin token exposure, where automation and credential handling created outsized exposure.
Practitioners should treat recursive creation as a governance boundary, not just an implementation detail. The term becomes operationally unavoidable after an unexpected credential chain, a leaked token, or a failed offboarding event reveals that machine-created identities can outlive the workflow that spawned them.
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 and OWASP Agentic AI Top 10 address the attack and risk surface, while 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-02 | Covers secret and credential management risks that enable runaway identity creation. |
| OWASP Agentic AI Top 10 | A-03 | Agentic workflows can expand authority by creating new identities during execution. |
| NIST Zero Trust (SP 800-207) | 3.1 | Zero Trust requires continuous verification before any new access is granted. |
Constrain agent tool access so no agent can mint identities without explicit policy checks.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on May 30, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
