The practice of governing the identities, permissions, and action boundaries inside the software development lifecycle. It extends identity control to coding agents, integrations, and automation that can affect code, configuration, and delivery outcomes.
Expanded Definition
Development identity governance extends identity and access control into the software development lifecycle, where software agents, CI/CD automation, build systems, and integrations can create, read, modify, or deploy high-value assets. Unlike traditional IAM, it treats code pipelines and developer tooling as active identity surfaces that need explicit boundaries, review, and revocation discipline. That includes service accounts, API keys, machine tokens, bots, and agentic workflows that can change repositories, infrastructure, or release artifacts. The concept aligns closely with the NIST Cybersecurity Framework 2.0 idea of governing access and protecting assets, but no single standard governs development identity governance yet, so usage in the industry is still evolving. NHI Management Group treats this as a control plane for deciding which non-human actors may operate in dev, test, and delivery contexts, for how long, and under what approvals. The most common misapplication is limiting governance to human developer accounts, which occurs when teams ignore the identities embedded in pipelines, build tooling, and release automation.
Examples and Use Cases
Implementing development identity governance rigorously often introduces release friction, requiring organisations to weigh delivery speed against tighter control of code-changing identities.
- A CI/CD runner receives just enough permission to fetch secrets and publish artifacts, then its token is rotated after each pipeline execution.
- An AI coding assistant is allowed to suggest code but blocked from merging pull requests or editing deployment manifests without human approval.
- A repository bot can open dependency update pull requests, yet it cannot approve its own changes or access production credentials, consistent with the governance themes in Ultimate Guide to NHIs.
- A build integration uses scoped OAuth access to issue test-environment requests only, reflecting the access boundary concerns highlighted in Top 10 NHI Issues.
- A third-party deployment tool is onboarded through a defined approval path and monitored using the same lifecycle logic described in Ultimate Guide to NHIs — Lifecycle Processes for Managing NHIs.
These patterns are easier to operationalise when scoped with identity policy rather than ad hoc scripting, and they map cleanly to NIST Cybersecurity Framework 2.0 governance outcomes.
Why It Matters in NHI Security
Development environments are where over-privileged automation often spreads fastest, and the blast radius can extend from source code into production infrastructure. NHIMG research shows that 96% of organisations store secrets outside secrets managers in vulnerable locations, while 97% of NHIs carry excessive privileges, a combination that makes developer tooling and pipeline identities especially attractive targets. Once a build token, bot account, or agent credential is abused, attackers can alter code, inject dependencies, tamper with infrastructure-as-code, or create persistence through delivery systems. That is why development identity governance is inseparable from secret hygiene, entitlement reviews, and offboarding discipline discussed in the Ultimate Guide to NHIs and the breach patterns in 52 NHI Breaches Analysis. It also helps explain why the Cisco DevHub NHI breach and JetBrains GitHub plugin token exposure resonate so strongly in NHI governance discussions. Organisations typically encounter this consequence only after a pipeline compromise or release tampering event, at which point development identity governance 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 and OWASP Agentic AI Top 10 address the attack and risk surface, while 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 | Covers secret sprawl and unsafe non-human credential handling in pipelines. |
| NIST CSF 2.0 | PR.AA-01 | Supports identity and access management for non-human actors and automation. |
| OWASP Agentic AI Top 10 | AGENT-04 | Addresses agent tool access and execution boundaries in development workflows. |
Inventory pipeline identities, rotate secrets, and restrict build-time access to least privilege.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on June 7, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
