The credential remains valid even though the file is gone, which means the attacker can still use it until the owning system invalidates it. Deletion reduces visibility, but it does not remove authority. Teams need an explicit revocation step and a verification step for every exposed secret, including keys embedded in infrastructure code and archived copies.
Why This Matters for Security Teams
When a leaked NHI is deleted from GitHub but not revoked, the file disappears while the authority remains intact. That is the dangerous part: the attacker does not need the repository once the token, key, or certificate is already valid. Current guidance from the OWASP Non-Human Identity Top 10 treats exposed secrets as a lifecycle problem, not a source-control problem, and NHIMG data shows why. In the Ultimate Guide to NHIs, 91.6% of secrets remain valid five days after notification, which leaves a long window for abuse after a leak is discovered.
This fails teams that equate “removed from GitHub” with “contained.” In practice, the attacker can reuse the same credential from another environment, automate calls, and pivot into connected systems until the owning service explicitly invalidates it. The issue is not visibility alone. It is stale authority, weak offboarding, and missing verification that revocation actually took effect. In practice, many security teams encounter abuse only after lateral movement has already occurred, rather than through intentional detection.
How It Works in Practice
A leaked NHI usually fails in three places: detection, revocation, and confirmation. Detection tells the team that a secret appeared in code, logs, or an artifact. Revocation is the control that matters next, because deleting the repository entry does not invalidate the token at the provider, in the vault, or in the target application. Confirmation closes the loop by proving the credential can no longer authenticate. The Guide to the Secret Sprawl Challenge highlights why this is so common: secrets are often copied into CI/CD, config files, and archived builds where one deletion action misses multiple active copies.
Operationally, the response should be explicit and fast:
- Revoke the credential at the source system, not just in GitHub.
- Rotate or reissue downstream credentials that were derived from the leaked secret.
- Search for duplicates in repositories, build logs, tickets, images, and backups.
- Verify that the old secret fails authentication, then document the time to invalidation.
This is especially important for API keys, service accounts, and certificates because they often have broad reach and long TTLs. The safest pattern is short-lived credentials plus automated revocation workflows, which aligns with the lifecycle approach in the NHI Lifecycle Management Guide. These controls tend to break down when teams rely on manual pull request cleanup in repositories with mirrored forks, cached build artifacts, or delayed deployment pipelines because the leaked secret can remain usable outside the source code system.
Common Variations and Edge Cases
Tighter secret handling often increases operational overhead, requiring organisations to balance fast developer workflows against stronger revocation discipline. The tradeoff is real: aggressive rotation can break integrations, while slow rotation gives attackers more time. Best practice is evolving, but current guidance suggests treating exposed secrets as compromised until proven otherwise, not as harmless once removed from version control. NHIMG’s Top 10 NHI Issues consistently points to the same pattern: the failure is usually governance, not tooling.
Edge cases matter. A secret may be embedded in a container image, hard-coded in infrastructure as code, or stored in an old release tag where GitHub deletion has no effect. Archived clones, package registries, and CI runners can also retain copies long after the original commit is gone. For regulated or high-impact environments, teams should add a verification step that checks both the target system and any dependent workload for failed authentication after revocation. There is no universal standard for this yet, but the operational expectation is simple: if a leaked NHI cannot be proven dead, it should still be treated as live.
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, OWASP Agentic AI Top 10 and CSA MAESTRO address the attack and risk surface, while NIST AI RMF and 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-01 | Exposed secrets require immediate revocation and lifecycle control. |
| OWASP Agentic AI Top 10 | Dynamic runtime trust and short-lived credentials reduce blast radius. | |
| CSA MAESTRO | Agentic and automated workloads need explicit revocation and verification. | |
| NIST AI RMF | GOVERN | Governance must assign accountability for leaked credentials and response. |
| NIST CSF 2.0 | PR.AC-1 | Access enforcement must stop stale credentials from retaining authority. |
Treat every leaked NHI as active until source-side revocation and authentication failure are verified.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on July 14, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
