Vaults alone do not solve secrets sprawl and exposure risk

At a glance

What this is: This is a secrets-management analysis arguing that vaults store secrets but do not provide end-to-end visibility, usage intelligence, or containment once credentials are issued.

Why it matters: It matters because IAM and NHI teams cannot treat vault adoption as full secrets governance when access, rotation, exposure detection, and least-privilege enforcement still need separate control design.

Context

Vaults are storage controls, not full secrets governance. In this article, the core gap is that a secret can be kept in a secure repository and still remain exposed, overprivileged, or invisible once an application, service, or user retrieves it.

The secrets-management problem is broader than safe storage. It includes inventory, access control, auditing, exposure detection, and rotation, especially where API keys, tokens, and certificates move across multiple applications and cloud services.

For IAM and NHI programmes, that means the governance question is not whether a vault exists. The question is whether the organisation can see where secrets are used, who can use them, and what happens when they leak or are overprovisioned.

Key questions

Q: What breaks when secrets are still stored outside managed vaults?

A: Secrets become easy to reuse across humans, scripts, and agents without a consistent audit trail. That increases the chance of exposure, weakens revocation, and makes it unclear which identity used the credential. A vault is only useful if it is the normal access path, not an optional store.

Q: Why do over-privileged cloud entitlements increase breach impact?

A: They increase breach impact because a stolen credential or compromised integration can inherit far more access than the underlying task requires. That turns a single identity into a broad attack path for data access, configuration changes, and persistence, especially when permissions are inherited through roles and group membership.

Q: How can security teams tell whether secret management is actually working?

A: Look for fewer plaintext secrets, narrower reuse, faster rotation, and a shrinking set of credentials that remain valid across multiple systems. If the same password or API key can still unlock several services, secret management is not yet reducing blast radius in practice.

Q: How should security teams respond when a secret is exposed in code or logs?

A: Start by identifying what the secret can access, not by rotating it immediately. Then isolate affected systems, revoke the credential, update dependent configurations, and verify the replacement works. A safe response sequence depends on blast radius, because the same secret may unlock multiple services or environments.

Technical breakdown

Why vault storage does not equal secrets governance

A vault is a controlled repository for secrets such as API keys, tokens, and connection strings. It protects data at rest and can enforce access permissions, but it does not inherently know whether a secret is overexposed, reused, or still needed by the application that requested it. That distinction matters because secrets become operational identities once issued. The security boundary is therefore not the vault alone but the full lifecycle of creation, distribution, use, and revocation. Practical implication: treat the vault as one control point inside a broader secrets-management architecture, not as the governance layer itself.

Practical implication: define controls for issuance, usage visibility, and revocation, not just storage.

Secrets sprawl and the inventory problem

Secrets sprawl appears when credentials proliferate across teams, vaults, applications, and cloud services faster than governance can track them. If organisations do not know how many active secrets they have, they cannot reliably rotate, revoke, or recertify them. The article’s point is that multiple vaults can actually deepen fragmentation when each vault is managed as an isolated store. In practice, this creates a hidden inventory problem: unused secrets persist, duplicated secrets appear across systems, and ownership becomes unclear. Practical implication: build a single view of active secrets across vaults and applications before trying to optimise rotation or policy enforcement.

Practical implication: create a unified secret inventory across all vaults and connected services.

Least privilege for secrets is decided at creation time

The article highlights a common failure mode: teams often overprovision secret permissions during creation because they want the credential to work everywhere it might be needed. That approach turns least privilege into a guess, not a control. Once a secret is issued with broad access, the vault may still store it securely, but the damage radius is already defined by the original permission set. This is especially risky when secrets are consumed by services rather than humans, because usage patterns are harder to inspect manually. Practical implication: bind permission scope to the narrowest verified use case and revisit it whenever the consuming workload changes.

Practical implication: constrain secret permissions at issuance and revisit scope when workloads change.

Threat narrative

Attacker objective: Use a single exposed secret to gain access to downstream systems, data, or cloud services beyond the secret’s intended scope.

1. Entry occurs when an attacker or insider obtains a valid secret from a cloud application, repository, or transmission path rather than from vault compromise itself.
2. Escalation follows when the exposed secret grants access beyond the intended workload scope because permissions were overprovisioned at creation time.
3. Impact occurs when the attacker uses the credential to reach connected services or customer data while the organisation lacks visibility into secret usage and exposure.
4. The objective is to turn one leaked secret into broader unauthorised access before the organisation detects or revokes it.

Breaches seen in the wild

• iOS apps leaking hard-coded secrets: Cybernews found 71% of 156,080 iOS apps leak hard-coded secrets, with open cloud storage and Firebase databases exposing user data.
• Dropbox Sign breach 2024: A compromised back-end service account gave attackers Dropbox Sign customer data, including API keys, OAuth tokens and MFA information.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Vaults are storage controls, not governance controls: A secret can be stored safely and still remain operationally dangerous once it is issued to a workload or user. The governing question is not where the secret sits, but whether the organisation can see how it is used and revoke it when the context changes. This is the line that separates storage from lifecycle control, and practitioners should design for the lifecycle.

Secrets sprawl is an inventory failure before it is a security failure: The problem compounds when organisations spread secrets across five or more vaults, because the control plane fragments with them. Without a current count of active secrets and ownership for each one, rotation and revocation become partial exercises. The practical conclusion is that inventory must precede policy tuning.

Least privilege for secrets is usually broken at creation: Overprovisioning at issuance is a design choice that makes later containment harder. The vault may authenticate and serve the secret correctly, but the original scope often exceeds what the workload actually needs. That means practitioners must treat secret creation as an access-design event, not an administrative afterthought.

End-to-end visibility is the missing control pattern: Vault-centric programmes often stop at issuance and miss the signals that show exposure, misuse, or abnormal access. A secrets programme that cannot tell who accessed a secret, when it was used, and whether it leaked is operating with blind spots. The implication is that secrets governance now sits across inventory, monitoring, and containment rather than in a single repository.

Ephemeral use does not reduce accountability for static secrets: Even if a secret is short-lived in the workflow, the organisation still owns its provenance, permissions, and revocation path. The weakness is not the vault but the assumption that storing credentials centrally automatically governs them end to end. Practitioners should treat this as a lifecycle discipline, not a storage problem.

From our research library:

• 73% of vaults are misconfigured, leading to unauthorised access and exposure of sensitive data, according to the Ultimate Guide to NHIs.
• DeepSeek alone generated 113,000 new exposed API keys in 2025, illustrating how new AI providers create credential exposure before security guardrails catch up, according to the State of Secrets Sprawl 2026.
• Read next: Guide to the Secret Sprawl Challenge

What this signals

Secrets governance now has to start with inventory, not vault adoption: Programmes that only count vaults miss the more important question of how many active secrets exist across applications, services, and cloud environments. If the organisation cannot see the population, it cannot manage the lifecycle.

Least privilege has to be enforced at issuance, not assumed later: Once a secret is created with excessive permissions, the vault simply stores a bad decision securely. IAM teams should review secret creation workflows with the same discipline they apply to privileged account provisioning.

Vaults do not remove exposure pathways: Secrets can leak through repositories, logs, transmission paths, and overbroad service access even when central storage is in place. That means monitoring and revocation have to sit alongside storage in the operating model.

For practitioners

• Map every active secret across vaults and applications Build an inventory that shows where each API key, token, certificate, and connection string exists, who owns it, and which workload consumes it.
• Separate storage from lifecycle control Define approval, rotation, revocation, and recertification steps for secrets outside the vault so a stored credential is not mistaken for a governed one.
• Reduce permissions at secret creation Issue each secret with the narrowest verified scope for the workload that will use it, then revalidate that scope when the workload changes.
• Monitor secret usage after issuance Track who accessed each secret, when it was used, and whether it was exposed so suspicious behaviour can be detected before the credential is abused.
• Automate revocation for exposed secrets Trigger containment workflows when a secret is detected in logs, repositories, or other exposed locations instead of waiting for manual review.

Key takeaways

• Vault adoption does not close the governance gap if organisations cannot inventory, monitor, and revoke secrets after they are issued.
• The article points to at least 5 vaults as a common operating pattern, which makes fragmentation and sprawl harder to control.
• Practitioners should treat secret creation, usage, and revocation as a single lifecycle problem, not a storage-only one.

Key terms

• Secrets Management: The discipline of securely storing, distributing, rotating, and auditing secrets across an organisation's systems and pipelines, typically implemented via a centralised secrets vault such as HashiCorp Vault, AWS Secrets Manager, or Akeyless.
• Vault: A vault is a protected storage system for secrets that controls who can retrieve them. It does not, by itself, govern where secrets are copied next, how they are used, or whether they remain valid after exposure, so it must be paired with lifecycle monitoring and revocation.
• Secrets Sprawl: The uncontrolled proliferation of sensitive credentials, API keys, tokens, passwords, certificates, across codebases, cloud environments, CI/CD pipelines, and configuration files. In 2024, over 50 million leaked secrets were found on the dark web.
• Least Privilege For Secrets: Least privilege for secrets means giving each credential only the permissions needed for its intended workload and nothing more. In practice, that requires revisiting access after deployment, because permissions chosen at creation time are often broader than the workload actually uses.

Deepen your knowledge

NHI governance, secrets management, and workload identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.