Why do secrets managers fail as access governance for workloads?

Why This Matters for Security Teams

Secrets managers are excellent delivery mechanisms, but access governance is a different problem. Governance asks whether a workload should keep access right now, under current context, posture, and intent. A vault usually answers only whether a credential can be issued or retrieved. That gap is why leaked, reused, or over-scoped secrets keep turning into real incidents, as shown in NHIMG’s Guide to the Secret Sprawl Challenge and breach analysis such as the 52 NHI Breaches Analysis.

The practical weakness is that secret possession becomes the trust model. Once a token exists, a manager cannot tell whether the workload has shifted tasks, whether the runtime has been tampered with, or whether the credential is now being replayed elsewhere. That is why modern guidance increasingly pairs secrets handling with workload identity and runtime policy, as reflected in the SPIFFE workload identity specification and the OWASP Non-Human Identity Top 10.

In practice, many security teams only discover the difference after a leaked secret has already been reused across a pipeline, service mesh, or AI toolchain.

How It Works in Practice

A secrets manager still has a place, but it should be treated as one control in a larger access stack. The better pattern is: prove the workload’s identity, evaluate policy at request time, issue a short-lived credential only for the task, and revoke it as soon as the task ends. That is the operational difference between storage and governance. For workload identity, SPIFFE-style cryptographic identity is a stronger primitive than a long-lived shared secret because it identifies what the workload is, not merely what it knows.

This becomes more important in NHI environments where access is dynamic. A CI/CD runner, for example, may need production access for a deployment window and zero access minutes later. A secrets manager can deliver the token, but it cannot decide whether that runner is still authorised. Current best practice is to combine JIT credential issuance with policy-as-code, then validate context such as host posture, workload attestation, environment, and destination sensitivity before release. NHIMG’s Guide to SPIFFE and SPIRE and CI/CD pipeline exploitation case study show why pipeline identity and runtime integrity matter as much as secret storage.

• Use the secret manager for issuance, not for final authorisation.
• Bind access to workload identity and runtime context, not static roles alone.
• Prefer short TTLs, automatic revocation, and task-scoped credentials.
• Log every grant against policy decisions so reuse and drift are visible.

These controls tend to break down when workloads are highly ephemeral and distributed across multiple orchestration layers, because identity, policy, and revocation signals do not arrive in one place at the same time.

Common Variations and Edge Cases

Tighter governance often increases operational overhead, so organisations have to balance control against deployment friction. That tradeoff is real, especially when teams rely on legacy apps, human-operated break-glass paths, or vendor systems that cannot yet support workload attestation. There is no universal standard for this yet, but current guidance suggests using secrets managers for bootstrap and escrow while shifting steady-state authorisation to runtime controls.

One edge case is non-code secret exposure. NHIMG research shows that a meaningful share of incidents now originates in collaboration tools, not repositories, which means governance must extend beyond code scanning into chat, ticketing, and documentation workflows. Another edge case is agentic AI. Autonomous agents can chain tools, reuse credentials across steps, and act on changing goals, so static RBAC and long-lived tokens age badly. For those systems, runtime authorisation, ephemeral secrets, and workload identity become mandatory design choices rather than nice-to-haves. See also the Top 10 NHI Issues and the Ultimate Guide to NHIs — Lifecycle Processes for Managing NHIs for lifecycle-oriented controls.

For framework alignment, the direction is consistent: use NIST Cybersecurity Framework 2.0 for access governance discipline and OWASP Non-Human Identity Top 10 for NHI-specific failure modes, then extend to agentic controls when autonomous behaviour is involved. In practice, secrets managers fail most often where teams mistake credential distribution for continuous authorisation.

Related resources from NHI Mgmt Group

• What breaks when secrets are used as the default for workload access?
• How should security teams handle AI client access to governed data without shared secrets?
• How should security teams replace shared secrets for workloads that span multiple clouds?
• Why do secrets create disproportionate risk in NHI environments?