The act of a workload, user, or agent asking Vault for credentials, tokens, or configuration needed to complete a task. The retrieval itself may be allowed, but governance depends on whether the requester still matches the approved identity, purpose, and scope for that secret.
Expanded Definition
Secret retrieval is the governed act of a workload, user, or agent requesting credentials, tokens, API keys, certificates, or configuration from a secret manager or vault so it can complete an authorised task. In NHI security, the important question is not whether the secret was fetched, but whether the requester still satisfies the approved identity, purpose, scope, and timing for that access.
Definitions vary across vendors on how much context should be checked at retrieval time, but the industry direction is clear: retrieval should be treated as a policy decision, not a simple read operation. That means the request may be bound to workload identity, session state, environment, and intended use. This aligns with the risk patterns described in the OWASP Non-Human Identity Top 10, where weak secret handling becomes an identity control failure rather than a storage issue.
Retrieval is distinct from storage, rotation, and revocation. A secret can be stored securely yet still be exposed if retrieval is overly broad, lacks authorization checks, or allows dormant identities to continue receiving valid material. The most common misapplication is treating any authenticated caller as eligible for any secret, which occurs when policy is tied only to vault membership and not to the current workload context.
Examples and Use Cases
Implementing secret retrieval rigorously often introduces latency and policy complexity, requiring organisations to weigh faster application startup against tighter identity validation at every request.
- A CI/CD job requests a short-lived deployment token only after its pipeline identity, branch, and environment match the approved release policy.
- An AI agent fetches an API key for a tool call, but the vault checks whether the agent’s task scope still permits that external action.
- A database service retrieves TLS material from a vault at startup and again on renewal, rather than keeping long-lived secrets on disk.
- A contractor session is denied access to production credentials because the retrieval policy requires a current just-in-time approval and device posture check.
- A leaked service account still authenticates to the vault, but retrieval is blocked because the account has been removed from the permitted workload set.
These patterns are visible in incidents such as the Guide to the Secret Sprawl Challenge and the Reviewdog GitHub Action supply chain attack, where retrieval paths and distribution trust became part of the attack surface. The secret manager is only as safe as the policy that governs who may ask for what, when, and for which purpose.
Why It Matters in NHI Security
Secret retrieval is where identity governance turns into real-world exposure. If retrieval checks are weak, an attacker who compromises a service account, build runner, or agent can obtain live credentials even when storage is encrypted and rotation exists on paper. That is why NHI Mgmt Group highlights that 79% of organisations have experienced secrets leaks, and 77% of those incidents caused tangible damage, with the full analysis available in the Ultimate Guide to Non-Human Identities.
In practice, secret retrieval is a Zero Trust decision point. It should verify current identity, constrain scope, and log purpose so that access can be explained during incident response and audit review. The same logic applies whether the requester is a service account, a CI job, or an autonomous agent. When retrieval is not governed, vault access becomes a path to broad lateral movement, secret sprawl, and silent privilege reuse. Guidance from the OWASP Non-Human Identity Top 10 and the CI/CD pipeline exploitation case study reinforces that retrieval controls must be as strict as the secrets themselves.
Organisations typically encounter the consequences only after a token is reused in an unexpected pipeline, at which point secret retrieval becomes 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 Zero Trust (SP 800-207) and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 | Secret retrieval is part of improper secret management and access governance. |
| NIST Zero Trust (SP 800-207) | DP-3 | Zero Trust treats every secret request as a policy-enforced access decision. |
| NIST CSF 2.0 | PR.AC-4 | Access permissions for retrieval should reflect least privilege and controlled authorization. |
Bind each secret request to current workload identity, scope, and purpose before issuing credentials.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on June 10, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org