Secret propagation is the spread of tokens, API keys, or certificates from one workflow into another through code, configuration, or automation. In AI-heavy development, generated code can copy or preserve credentials faster than human reviewers can notice, increasing exposure across environments.
Expanded Definition
secret propagation is broader than a single leaked token. It describes how credentials, API keys, certificates, and related authentication material move from one system boundary into another through source code, templates, CI/CD variables, generated artifacts, container images, logs, or infrastructure-as-code. In NHI security, the concern is not only where the secret started, but every place it can be copied, cached, inherited, or re-emitted by automation. That makes propagation especially dangerous in AI-heavy development, where generated code or agentic workflows can reproduce sensitive values faster than reviewers can inspect them.
Definitions vary across vendors, but the practical boundary is clear: if a secret can be replayed outside its intended trust domain, it has propagated. This aligns closely with the OWASP Non-Human Identity Top 10 focus on secret handling and exposed machine credentials, and with NHIMG guidance on the difference between Ultimate Guide to NHIs — Static vs Dynamic Secrets. The most common misapplication is treating a secret as “removed” after one file is cleaned up, when copies still exist in build outputs, forks, tickets, or pipeline history.
Examples and Use Cases
Implementing secret propagation controls rigorously often introduces friction in developer workflows, requiring organisations to weigh delivery speed against the cost of tighter scanning, rotation, and redaction.
- A developer pastes a cloud API key into a prompt, and an AI coding assistant regenerates the key in example code, tests, and deployment manifests.
- A CI/CD pipeline injects a token into environment variables, then exports it into logs or artifacts that are later shared across teams, creating secondary exposure.
- A certificate bundled into a base container image is reused by multiple services, so a single compromise spreads across environments instead of staying isolated.
- A dependency update or supply-chain event mirrors the pattern seen in the Reviewdog GitHub Action supply chain attack, where automation amplified secret exposure at scale.
- An internal audit traces leaked credentials from source control into build caches, mirrors, and archived release bundles, showing propagation beyond the original repository.
These scenarios are best understood alongside the Guide to the Secret Sprawl Challenge and the operational controls described by the OWASP Non-Human Identity Top 10. In practice, propagation often begins with convenience shortcuts, not malicious intent.
Why It Matters in NHI Security
Secret propagation turns one weak handling event into a multi-environment exposure problem. For NHIs, that matters because tokens and certificates are often the real identity, not just a supporting mechanism. Once a secret spreads into code, automation, or third-party tooling, revocation becomes harder, blast radius grows, and incident response must account for every replica. NHIMG reports that 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools, which makes propagation a common operational condition rather than an edge case.
Propagation also undermines least privilege and short-lived credential strategies because copied secrets outlive their intended scope. Even when a team believes a token has been rotated, valid remnants may remain in caches, backups, forks, or generated code. That is why secret propagation is a governance issue as much as a technical one. Organisationally, it becomes visible only after a leak, compromise, or unexpected reuse event, at which point propagation is 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 address the attack and risk surface, while NIST CSF 2.0 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 across NHI workflows. |
| NIST CSF 2.0 | PR.AA-01 | Credential lifecycle and authentication assurance are affected when secrets propagate. |
| NIST Zero Trust (SP 800-207) | SC-3 | Secret propagation increases trust boundaries that Zero Trust aims to minimise. |
Eliminate copied secrets from code, CI/CD, and artifacts, then verify only controlled sources can issue credentials.
