A dangling commit is a Git object that still exists in the repository database but is no longer referenced by a branch or tag. It may be invisible in normal history views, yet still recoverable until garbage collection removes it or a hosting platform discards it.
Expanded Definition
A dangling commit is a Git object that remains in the repository database after losing its branch or tag reference. In normal developer workflows it is invisible, but until garbage collection or hosting retention policies remove it, the object can still be inspected or recovered.
In NHI and agentic AI engineering, the term matters because detached history can preserve secret-bearing snapshots, stale token references, or policy-bypassing changes that are no longer obvious in the active code path. The concept is adjacent to abandoned branches and unreachable objects, but it is not the same as deleted source code. A file can be gone from the branch tip while the commit that introduced it still exists in object storage. Definitions vary across vendors when platform retention, packfile expiry, and garbage collection timing are discussed, so practitioners should treat the repository as a data store with lifecycle controls rather than as a simple revision list. For baseline identity and lifecycle governance, NHI Management Group recommends pairing repository hygiene with the Ultimate Guide to NHIs and least-privilege process discipline described in NIST Cybersecurity Framework 2.0.
The most common misapplication is assuming a commit is harmless once it disappears from branch history, which occurs when teams ignore unreachable objects that still contain secrets, tokens, or deployment logic.
Examples and Use Cases
Implementing strict repository retention and rewrite controls often introduces operational friction, requiring teams to balance recoverability against the need to eliminate hidden sensitive material quickly.
- A developer force-pushes a branch after accidentally committing an API key, but the original commit remains dangling until garbage collection runs.
- A release pipeline rewrites history to remove a service account token, yet hosted repository snapshots preserve the unreachable object for a retention window.
- An AI agent generates a patch, the patch is reverted, and the underlying commit becomes dangling while still exposing prompt or tool configuration details.
- A security team reviews a post-incident repository and recovers a dangling commit to confirm when a secret first entered source control.
- During a cleanup exercise, engineers identify unreachable commits before rotating credentials, informed by the control expectations in the Ultimate Guide to NHIs and the identity governance posture reflected in NIST Cybersecurity Framework 2.0.
Why It Matters in NHI Security
Dangling commits create a false sense of cleanup. A secret removed from the visible branch can still be recovered from repository storage, logs, mirrors, or cached artifacts, which means compromise paths may remain open long after a fix is merged. This matters for NHI because service account keys, CI/CD tokens, and agent credentials are frequently embedded in code during testing and automation. NHI Management Group data shows that Ultimate Guide to NHIs reports 96% of organisations store secrets outside of secrets managers in vulnerable locations, which makes unreachable history especially dangerous when remediation is incomplete.
Practically, the risk is not only exposure but also delayed containment. If a dangling commit includes a credential that maps to production automation, the team may believe the exposure was removed while the token remains valid. That is why repository controls should be coupled with secret rotation, branch protection, and evidence-driven cleanup aligned to NIST Cybersecurity Framework 2.0. Organisations typically encounter the real impact only after a leaked token is used in an incident review, at which point dangling commit analysis 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, NIST SP 800-63 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-02 | Covers improper secret handling, including secrets left recoverable in source history. |
| NIST CSF 2.0 | PR.DS-6 | Addresses data in transit and storage protection, relevant to lingering repository artifacts. |
| NIST SP 800-63 | Identity assurance depends on revocable credentials, including those exposed in old commits. | |
| NIST Zero Trust (SP 800-207) | SA-3 | Zero trust requires continuous verification of software supply chain artifacts and identities. |
| OWASP Agentic AI Top 10 | A02 | Agentic systems can leak tool credentials or prompts into commits that later become unreachable. |
Scan and purge unreachable commits that may still contain credentials before closing remediation.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on August 28, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
