Secret reachability

Expanded Definition

secret reachability describes the practical path a running workload has to credentials, tokens, certificates, and sensitive configuration at execution time. In NHI security, the key question is not only whether a secret exists, but whether a process, container, or agent can read it, export it, or reuse it if execution is compromised. This makes secret reachability different from simple secret presence or inventory. It is about runtime exposure, privilege boundaries, and how far a compromise can move once code execution is achieved.

Definitions vary across vendors, but the operational meaning is consistent: if an AI agent, service account, or pipeline step can directly access a secret, the compromise radius increases sharply. That is why secret reachability is often discussed alongside least privilege, secret isolation, and zero standing privilege in the OWASP Non-Human Identity Top 10. NHI Management Group treats reachability as a runtime control concern, not just a storage concern. The most common misapplication is assuming a vaulted secret is safe when the application runtime still has immediate read access through environment variables, mounted files, or injected configuration.

Examples and Use Cases

Implementing secret reachability rigorously often introduces operational friction, because stronger isolation can require redesigning pipelines, workloads, and rotation flows, forcing organisations to weigh speed of delivery against reduced blast radius.

• A CI/CD runner can read cloud API keys from environment variables during deployment. If the runner is compromised, the attacker can reuse those keys immediately. The CI/CD pipeline exploitation case study shows why pipeline reachability must be treated as a production-risk issue, not a build-only issue.
• An AI agent is granted access to a secrets file so it can call downstream tools. If the agent receives malicious instructions, the reachable secret can become an exfiltration path rather than a helper input. This is why runtime authority must be constrained in line with the OWASP Non-Human Identity Top 10.
• A Kubernetes workload mounts a certificate bundle that is readable by the application container. If the pod is later escaped or tampered with, the certificate is immediately available for lateral movement.
• A service account in a cloud function inherits access to a secrets manager at startup. If the function is over-permissioned, the secret is reachable even when the underlying application logic never needed it in full.
• Secret sprawl often increases reachability by placing sensitive material in code, config files, and CI/CD tooling. The Guide to the Secret Sprawl Challenge frames this as an exposure problem, not just an inventory problem.

Why It Matters in NHI Security

Secret reachability determines whether a single code-execution flaw becomes an identity compromise, a data breach, or a supply chain incident. NHI Management Group reports that 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools, which means reachability is often broader than teams assume. In practice, the issue is not whether secrets are protected in theory, but whether a compromised workload can touch them before detection or revocation occurs.

This is especially important for service accounts, automation tokens, and agent credentials because these identities frequently operate with broad, persistent access. When reachability is high, rotation alone does not solve the exposure problem if the runtime can keep reading fresh secrets on demand. The Ultimate Guide to NHIs — Static vs Dynamic Secrets is useful here because static secret increase the window in which a reachable credential can be abused. Organisations typically encounter the impact only after a compromise, when secret theft and lateral movement reveal that runtime access paths were never constrained enough to begin with.

Related resources from NHI Mgmt Group

• Hardcoded Secret
• What is the difference between an identity, a credential, and a secret?
• Why is proactive secret scanning important for NHI security?
• What is the difference between privilege reduction and secret rotation?