Runtime secret visibility is the ability to observe when and where secrets are accessed while systems are actively running. It matters because static inventories alone do not show whether a tool, workflow, or workload is reading credentials in memory, files, or logs.
Expanded Definition
Runtime secret visibility is the operational ability to detect when a secret is actually being read, passed, cached, or exposed during execution. It is narrower than inventory management and broader than simple log scanning, because it focuses on live access paths in agents, CI/CD jobs, containers, and application memory.
In NHI security, the term covers credentials, tokens, API keys, and certificates that may appear in process memory, environment variables, mounted files, debug output, or telemetry. The industry does not yet have a single standard that governs how runtime visibility should be implemented, so definitions vary across vendors and platform teams. That matters because a vault may show that a secret exists, while runtime visibility shows whether a workload is actively using it or leaking it into places that can be copied or replayed. The OWASP Non-Human Identity Top 10 places strong emphasis on secret handling, but practitioners still need operational telemetry to prove how secrets behave once execution begins.
The most common misapplication is treating a secret inventory as runtime visibility, which occurs when teams equate storage location with active access control.
Examples and Use Cases
Implementing runtime secret visibility rigorously often introduces telemetry overhead and privacy review work, requiring organisations to weigh faster detection against additional engineering and data-governance cost.
- Monitoring a CI/CD job to confirm whether an API key is loaded only for the build step, then discarded before artifact publishing. This helps distinguish approved use from unnecessary exposure, a pattern echoed in the CI/CD pipeline exploitation case study.
- Tracing a containerized agent to see whether it reads secrets from a mounted file or from environment variables that later appear in crash dumps. That distinction is central to the Ultimate Guide to NHIs — Static vs Dynamic Secrets.
- Detecting a GitHub Action that prints masked values into logs but still leaves a usable token in memory long enough for exfiltration, as seen in the Reviewdog GitHub Action supply chain attack.
- Watching for a service account secret that is read by an autonomous agent during tool execution, then reused outside its intended scope. That control point aligns with the runtime trust model described in the OWASP Non-Human Identity Top 10.
- Correlating secret access with unusual execution paths after a breach investigation, especially when secrets were buried in code or workflow files, a recurring theme in the Guide to the Secret Sprawl Challenge.
Why It Matters in NHI Security
Runtime secret visibility matters because compromised NHIs rarely fail at the inventory layer first; they fail where credentials are actually used. NHI programs often discover that a secret is present in many places but cannot answer whether it was accessed by an agent, leaked to logs, or copied by an attacker during execution. That gap weakens incident response, secret rotation, and Zero Trust enforcement.
NHIMG research shows that only 5.7% of organisations have full visibility into their service accounts, which makes runtime observation a practical necessity rather than a maturity bonus. When secrets remain valid after exposure, the operational impact can persist long after the first alert, especially in sprawling workflows and third-party integrations. Runtime visibility is also relevant to breach forensics in cases like the Emerald Whale breach and broader secret sprawl patterns documented in the 52 NHI Breaches Analysis. Organisations typically encounter the cost of poor runtime visibility only after an intrusion, when rotating a credential is no longer enough and investigators must reconstruct exactly how the secret was used.
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 | Covers improper secret handling and the need to observe secret exposure paths. |
| NIST CSF 2.0 | DE.CM-8 | Monitoring for anomalous activity supports detection of secret access in execution. |
| NIST Zero Trust (SP 800-207) | PA/EP | Zero Trust requires continuous verification of workload access, including secret use. |
Log and correlate runtime secret events so abnormal access is detected and investigated quickly.
