A secret is the credential that proves a non-human identity is allowed to act. In practice it may be an API key, token, password or certificate. If it is exposed, reused or left valid too long, the resulting compromise can look legitimate to downstream systems.
Expanded Definition
In NHI security, a secret is the credential material that lets a workload, agent, or service prove it is authorised to act. That can include API keys, passwords, tokens, private keys, and certificates. The term is broader than “password” and narrower than “identity,” because the secret is the proof mechanism, not the identity itself.
Definitions vary across vendors on whether certificates should be grouped with secrets, but no single standard governs this yet. Practically, the important distinction is whether the value can be replayed, copied, or embedded into automation. The OWASP Non-Human Identity Top 10 treats weak secret handling as a core risk because secrets often become the easiest path from exposure to impersonation.
Experienced operators usually care less about the label and more about the lifecycle: where the secret is stored, who can read it, how quickly it rotates, and what happens when it leaks. The most common misapplication is treating a static secret as a benign configuration value, which occurs when teams hard-code credentials into code, CI/CD variables, or shared documentation.
Examples and Use Cases
Implementing secrets management rigorously often introduces friction in deployment pipelines and incident response, requiring organisations to weigh automation speed against tighter issuance, storage, and rotation controls.
- A build service uses a short-lived token to pull artefacts from a registry instead of a long-lived API key, reducing the value of any intercepted credential.
- An AI agent receives scoped credentials for a single tool action, so compromise of the agent does not automatically expose broader platform access.
- A production service account stores its secret in a dedicated vault rather than in source code, which aligns with lessons from the Guide to the Secret Sprawl Challenge.
- A leaked GitHub token is revoked and rotated after repository scanning detects exposure, a pattern highlighted in the Reviewdog GitHub Action supply chain attack.
- A workload identity uses certificate-based authentication with bounded trust, reflecting the workload identity model described by SPIFFE/SPIRE.
These use cases show that a secret is not only a login artefact; it is an operational control that can either limit or amplify the blast radius of compromise.
Why It Matters in NHI Security
Secrets are a primary failure point because they tend to spread faster than organisations can inventory them. NHI Mgmt Group research shows that 91.6% of secrets remain valid five days after the targeted organisation is notified, which means exposure often persists long after detection. That delay is why secret management is inseparable from governance, rotation, and offboarding.
When secrets are reused across environments or left in code, attackers can move laterally while appearing legitimate to downstream systems. The same failure pattern appears in incidents such as the Shai Hulud npm malware campaign and the CI/CD pipeline exploitation case study, where leaked credentials turned trusted automation into an attack path. A well-run program also aligns with the OWASP Non-Human Identity Top 10 guidance on reducing secret exposure and enforcing least privilege.
Organisations typically encounter the operational impact only after a leak, failed audit, or suspicious automation event, at which point secret handling becomes an incident response priority rather than a policy topic.
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 Zero Trust (SP 800-207) and SPIFFE/SPIRE set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 | Addresses weak secret storage, exposure, and rotation as primary NHI risk drivers. |
| NIST Zero Trust (SP 800-207) | SC-7 | Zero Trust assumes credentials are scoped, ephemeral, and continuously verified. |
| SPIFFE/SPIRE | Defines workload identities that can replace brittle long-lived secrets with attested identities. |
Inventory secrets, eliminate hard-coded credentials, and enforce rotation and revocation workflows.
