Secrets storage and encryption expose the real NHI governance gap

At a glance

What this is: This is an NHI governance analysis of secrets storage, encryption, vaults, and vaultless models, with the central finding that encryption alone does not close lifecycle and visibility gaps.

Why it matters: It matters because IAM, PAM, and NHI teams need control over discovery, access, rotation, and revocation, not just stronger cryptography, to reduce secret-driven blast radius.

By the numbers:

• 24,008 unique secrets were exposed in MCP configuration files in 2025 alone, the protocol's first year of widespread adoption, according to the State of Secrets Sprawl 2026.

Context

Secrets storage is the control problem behind many NHI failures. A secret can be encrypted and still be poorly governed if teams cannot see where it exists, who can use it, how long it stays valid, or whether it has been copied into repositories, CI/CD systems, or application files.

For non-human identities, encryption reduces exposure but does not manage lifecycle. The real gap is operational: discovery, access control, rotation, revocation, and auditability must all work together or the encrypted secret simply becomes a harder-to-see standing credential.

Vaults and vaultless models both address storage, but they do so with different tradeoffs in visibility, decentralisation, and control. That makes this a governance decision as much as a technical one, because the operating model shapes how secrets are owned and offboarded.

Key questions

Q: What breaks when secrets are encrypted but not governed end to end?

A: Encryption can hide a secret without limiting its operational reach. When discovery, ownership, rotation, and revocation are missing, the secret can still be copied into code, pipelines, and configuration files, then reused as a standing credential. The failure is governance continuity, not cryptographic strength.

Q: Why do long-lived secrets increase identity risk in cloud and SaaS environments?

A: Long-lived secrets remain reusable until someone revokes them, which gives attackers a durable target. In cloud and SaaS environments, that means one leaked token or key can be replayed across systems, copied into automation, or reused after the original exposure has faded from view. Short-lived identity reduces that persistence.

Q: How do organisations know if secrets management is actually working?

A: Secrets management is working only when credentials are absent from endpoints, build logs, environment variables, and source-controlled configuration. If secret scanners still find high-value tokens in routine developer paths, the control is not operating as designed, regardless of policy statements or vault adoption.

Q: What is the difference between vault-based and vaultless secrets management?

A: Vault-based secrets management centralises storage, access, and auditing in one control point. Vaultless approaches spread encrypted secrets closer to the application, which can simplify delivery but often weakens organisation-wide visibility, standardisation, and revocation confidence across the estate.

Technical breakdown

Why encrypted secrets still create governance risk

Encryption protects a secret at rest or in transit, but it does not answer the governance question of where that secret exists, who can retrieve it, or whether copies persist in code, pipelines, and configuration files. In NHI terms, the control problem is not the cryptographic wrapper alone, but the full lifecycle around issuance, storage, access, rotation, and revocation. A vaulted secret can still be overexposed if teams lack inventory and access telemetry. That is why secret security is fundamentally an identity governance problem, not just a cryptography problem.

Practical implication: Treat encryption as a containment layer and govern the secret lifecycle separately.

Vaults versus vaultless secrets management

A vault centralises secrets so access control, auditing, and rotation can be applied consistently, while a vaultless model places encrypted secrets closer to the application and spreads responsibility across services. The tradeoff is not convenience versus security, but central visibility versus decentralised operational control. Vaults make governance easier to standardise, but they also create dependency on the vault itself and on clean integration. Vaultless designs can reduce infrastructure overhead, yet they often weaken the organisation's ability to answer basic ownership and access questions across the estate.

Practical implication: Choose the model that preserves verifiable ownership and revocation across the widest set of NHI use cases.

How rotation and lifecycle control change the risk equation

Secrets become materially safer when rotation, expiry, and revocation are enforced as lifecycle controls rather than manual hygiene tasks. Automated rotation narrows the window in which a leaked secret remains valid, but it only works if discovery and ownership are complete enough to know what must be rotated. The article's strongest signal is that storage without lifecycle management leaves organisations with long-lived access paths hidden inside modern delivery pipelines. That is a governance failure because the secret remains usable even when the original business need has changed.

Practical implication: Tie rotation schedules and expiry policies to discovered secret inventory, not to isolated platform settings.

Threat narrative

Attacker objective: The objective is to turn one exposed secret into persistent access across applications, cloud services, or CI/CD workflows.

1. Entry occurs when developers hardcode secrets into source code, configuration files, or CI/CD-connected systems, creating a recoverable secret surface for attackers or insiders.
2. Credential access follows when those secrets are discovered in repositories, logs, or deployment assets and then reused to authenticate into cloud services or application environments.
3. Escalation happens when the exposed secret grants broader platform or service access than intended, allowing the attacker to move from one application boundary to related systems.
4. Impact is compromise of the wider environment because the secret functions as a standing credential rather than a tightly governed, short-lived identity artefact.

Breaches seen in the wild

• EmeraldWhale Git config credential theft: Tokens in exposed .git/config files let EMERALDWHALE clone private repositories and steal more than 15,000 cloud credentials.
• Hugging Face Spaces breach 2024: Unauthorised access to Hugging Face Spaces may have exposed secrets users stored for AI apps; tokens were revoked and org tokens removed.

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

NHI Mgmt Group analysis

Encrypted storage does not remove the NHI governance gap: the core failure is not whether a secret is protected by AES-256 or stored in a vault, but whether the organisation can prove where the secret exists and when it stops being valid. Encryption reduces exposure, yet it leaves ownership, discoverability, and revocation unanswered. Practitioners should treat the secret as an identity object with a lifecycle, not as a file to be hidden.

Secret blast radius is determined by governance, not just storage architecture: a vault centralises control, while vaultless distribution shifts responsibility into every application team. That changes auditability, offboarding, and incident response because the organisation must know which teams own which credentials and where each copy lives. The practical conclusion is that architecture choice directly shapes the blast radius of an exposed secret.

Long-lived secret trust debt: secrets that are encrypted, stored, and rarely revisited accumulate a form of trust debt that survives platform hardening. The control assumption behind many programmes is that a secret can remain safe if the storage layer is strong enough; that assumption fails when secrets are copied into code, CI/CD, and collaboration tools. The implication is that lifecycle governance must outrank storage preference.

This is a cross-domain IAM, PAM, and NHI issue, not a vault-only issue: access to secrets depends on identity policy, privilege boundaries, and revocation discipline across machine and human workflows. When teams only focus on the vault, they miss the downstream systems that consume the secret and the humans who can still retrieve it. Practitioners should govern secrets as part of the broader access model, not as a stand-alone tool choice.

From our research library:

• Internal repositories are 6x more likely to contain secrets than public ones (32.2% vs 5.6%), contradicting the assumption that private repos are safe, according to the State of Secrets Sprawl 2026.
• Only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap, according to the State of Secrets in AppSec.
• Read next: Guide to the Secret Sprawl Challenge

What this signals

Secret storage is only half the control: teams that can encrypt secrets but cannot discover them across repositories, CI/CD, and collaboration tools are still exposed to credential reuse and offboarding gaps. The governance problem is not the cipher, but the inventory and revocation model that sits around it.

Vault architecture changes the ownership model: centralised vaults can improve auditability, while vaultless designs push responsibility into every application team. That means the real decision is how much organisational discipline you can enforce when the secret is no longer managed in one place.

Internal repositories are 6x more likely to contain secrets than public ones (32.2% vs 5.6%), according to the State of Secrets Sprawl 2026. Private does not mean controlled, and this is exactly where discovery must outrank assumption in NHI programmes.

For practitioners

• Define a complete secret inventory Map every place secrets can exist, including repositories, CI/CD variables, configuration files, collaboration tools, and secret stores. No rotation policy is trustworthy until you know the full secret estate.
• Separate storage control from lifecycle control Use encryption and vaulting to reduce exposure, but manage rotation, expiry, and revocation as distinct governance controls with explicit ownership and audit evidence.
• Assign clear ownership for each secret class Tie every application secret, API key, certificate, and token to a named owner and an offboarding path so credential loss does not become organisational ambiguity.
• Measure where secrets actually appear Track secret discovery rates, rotation rates, and the proportion of secrets found outside approved stores so governance can be tested against reality rather than policy language.

Key takeaways

• Secrets encryption reduces exposure, but it does not by itself resolve where secrets are stored, who can use them, or when they should be revoked.
• The article's core governance point is that storage architecture and lifecycle control are separate decisions, and both affect the blast radius of a leaked credential.
• Practitioners should inventory secrets across code, pipelines, and tools before they rely on vaulting or rotation as a complete control story.

Key terms

• Secrets Lifecycle: Secrets lifecycle is the management of credentials from issuance through rotation, revocation, and offboarding. It matters because a secret that is technically valid can still be operationally unsafe if its owner, purpose, or downstream access paths are no longer current.
• Vaultless Secrets Management: Vaultless secrets management stores credentials closer to the applications that use them instead of placing everything in a central vault. It can reduce operational friction, but it also pushes more security responsibility into application teams and makes consistent governance harder to sustain.
• 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.
• Envelope Encryption: A two-layer encryption pattern that uses a short-lived data encryption key to protect the data and a longer-lived key encryption key to wrap that data key. It scales rotation, supports tenant separation, and keeps the primary key material out of direct data handling.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle 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.