The interception of credentials, keys, or recovery material while an application is actively using them, rather than at install or build time. This matters because the secret can be valid, decrypted, and in memory exactly when the attacker reads it, making the compromise hard to detect with static checks alone.
Expanded Definition
Runtime secret capture describes the theft or interception of credentials, API keys, certificates, recovery codes, or session material while an application, agent, or automation job is actively using them. That timing matters: the secret is often decrypted, loaded into memory, or attached to a live process, which makes it more useful to an attacker and harder to spot with repository scanning or build-time controls alone.
In NHI operations, this term sits between secret storage and secret use. It overlaps with memory scraping, process injection, debug interface abuse, container escape paths, and pipeline compromise, but it is narrower than generic secret exposure because the attacker is targeting the working state of the secret, not just where it is saved. Guidance varies across vendors, but the operational distinction is consistent: runtime capture defeats controls that only check code, vault configuration, or static images. The OWASP Non-Human Identity Top 10 treats secret handling as a core NHI risk area, while runtime-focused safeguards are also aligned with modern zero-trust thinking in NIST SP 800-207.
The most common misapplication is treating runtime secret capture as a storage-only problem, which occurs when teams assume vaulting alone prevents theft even though the secret must still exist in memory during use.
Examples and Use Cases
Implementing runtime secret protections rigorously often adds latency, observability overhead, or operational friction, so organisations must weigh tighter containment against the cost of more complex deployment and debugging.
- A containerised agent fetches a short-lived token from a vault, but a sidecar or compromised process reads the token from memory before it expires.
- A CI/CD job injects an API key into environment variables, and an attacker with pipeline access exfiltrates it during execution, similar to patterns discussed in the Reviewdog GitHub Action supply chain attack.
- An LLM tool-calling agent retrieves cloud credentials at task time, and malicious prompt injection causes those credentials to be surfaced through logs or tool output.
- A production service unwraps a certificate private key for mutual TLS, and runtime inspection on a host with weak isolation captures the key while the process is active.
- A malware-laced package monitors process memory and intercepts tokens used by developer automation, echoing the techniques seen in the Shai Hulud npm malware campaign.
These scenarios are easier to understand when paired with the Ultimate Guide to NHIs—Static vs Dynamic Secrets, because the attack window changes depending on how long the secret stays valid and where it is loaded for use. The same threat model also maps to CISA secure secrets management guidance, which emphasises limiting exposure during execution rather than only at rest.
Why It Matters in NHI Security
Runtime secret capture is dangerous because it bypasses many controls that organisations rely on to prove maturity: secret scanning, vault adoption, and code review. If the application or agent can legitimately retrieve the secret, then an attacker who can observe the runtime can often steal the same material with no need to break the cryptography. That turns a narrow compromise into broad lateral movement, especially where service accounts, automation tokens, or signing keys are overprivileged.
NHI Mgmt Group research shows that 79% of organisations have experienced secrets leaks, with 77% resulting in tangible damage, which is why runtime controls cannot be treated as optional hardening. The issue also intersects with the Guide to the Secret Sprawl Challenge, because broad secret distribution increases the number of places where live credentials can be observed, copied, or replayed. Practitioners should pair short-lived credentials, strict process isolation, attestation, and aggressive rotation with monitoring that can detect abnormal secret use in real time.
Organisations typically encounter the operational cost of runtime secret capture only after a live incident, at which point secret handling becomes 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 Zero Trust (SP 800-207) and NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 | Addresses improper secret handling and exposure paths for non-human identities. |
| NIST CSF 2.0 | PR.AC-1 | Identity and credential management govern how runtime secrets are issued and protected. |
| NIST Zero Trust (SP 800-207) | SC-7 | Zero trust assumes credentials may be observed and requires continuous verification of access. |
| NIST AI RMF | AI risk management covers exposure of agent credentials during execution and tool use. | |
| OWASP Agentic AI Top 10 | A2 | Agentic systems can leak credentials during tool calls, memory access, or prompt injection. |
Reduce live secret exposure with short-lived credentials, isolation, and continuous secret-use monitoring.
Related resources from NHI Mgmt Group
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
