A persistence pattern where stolen tokens, keys, or secrets are stored in attacker-controlled source control or newly created repositories. This extends access beyond the original infected host and makes repository hygiene part of incident response and NHI governance.
Expanded Definition
credential persistence through repositories is an attacker tradecraft pattern in which stolen secrets are copied into source control, paste-like storage, or newly created repositories so access survives host cleanup, password rotation, or endpoint reimaging. In NHI security, the repository becomes a durable control plane for stolen tokens, API keys, certificates, and session material rather than a simple storage location. That makes the problem broader than source code review alone: it touches secret discovery, repository scanning, branch protections, artifact hygiene, and incident containment. Guidance varies across vendors on whether this belongs under secret sprawl, exfiltration, or post-compromise persistence, but the operational meaning is consistent: the attacker is trying to make credentials recoverable later, not merely usable once. This aligns closely with the risk patterns described in the OWASP Non-Human Identity Top 10 and the control logic in NIST SP 800-53 Rev 5 Security and Privacy Controls.
The most common misapplication is treating repository exposure as a developer-only code issue, which occurs when security teams do not investigate whether a leaked token was copied into attacker-controlled repos for later reuse.
Examples and Use Cases
Implementing detection and response rigorously often introduces noise and review overhead, requiring organisations to weigh faster containment against the cost of scanning every repository, fork, and issue attachment.
- An attacker steals a cloud token from a build host, then commits it to a private repository to preserve access after the original machine is isolated.
- Secrets are pasted into a freshly created repository as a staging point for resale or repeated use, which is why repository creation events matter during investigation.
- A compromised developer account pushes an attacker-controlled branch containing API keys, making the Secret Sprawl Challenge a live response problem rather than a governance abstraction.
- Credentials harvested during a supply chain compromise are mirrored into source control alongside tooling, similar to patterns seen in the Reviewdog GitHub Action supply chain attack and the Shai Hulud npm malware campaign.
- Teams use secret scanning and repository forensics to identify whether the same token appears in forks, gists, or mirrored repos, then rotate and revoke based on evidence of persistence.
Standards guidance is still evolving, but the defensive pattern is clear: compare repository exposure against the identity assurance expectations in NIST SP 800-63 Digital Identity Guidelines and against NHI-specific guidance in the Ultimate Guide to NHIs — Static vs Dynamic Secrets.
Why It Matters in NHI Security
Credential persistence through repositories turns a one-time compromise into a repeatable access path. In non-human environments, that is especially damaging because a single secret can unlock CI/CD systems, cloud APIs, orchestration layers, or downstream automation at machine speed. NHIMG research shows that 23.7% of organisations still share secrets through insecure methods such as email or messaging applications, which increases the chance that stolen material is easy to relocate into repositories and harder to trace once dispersed. The problem is not just theft but survivability: once credentials exist in a repo, revocation alone may not be enough if copies are cloned, forked, indexed, or reused by other actors. This is why repository hygiene belongs inside incident response, not outside it. It also reinforces the governance point raised in the The 2024 Non-Human Identity Security Report and the threat paths described in the LLMjacking: How Attackers Hijack AI Using Compromised NHIs.
Organisations typically encounter this consequence only after a token is still being used from a second location, at which point repository persistence 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 | Directly addresses improper secret handling and exposure paths used for persistence. |
| NIST CSF 2.0 | PR.DS-1 | Repository-stored secrets are data needing protection against unauthorized disclosure. |
| NIST SP 800-63 | Digital identity assurance informs how stolen credentials should be validated and invalidated. | |
| NIST Zero Trust (SP 800-207) | AC-4 | Zero trust limits lateral use when a secret persists beyond the original host. |
| OWASP Agentic AI Top 10 | A2 | Agentic systems often store or reuse secrets in repositories, creating persistence risk. |
Prevent agents from writing credentials to code repos and monitor agent output for secret leakage.
Related resources from NHI Mgmt Group
- Who should be accountable when an agent credential is issued through delegation?
- Who is accountable when password spraying succeeds through a weak credential path?
- Who is accountable when malware uses legitimate tools to hide persistence and credential theft?
- What breaks when a flat network is compromised through a single credential or edge device?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on August 2, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
