Akeyless and the shift to vaultless secrets governance

At a glance

What this is: This is an analysis of Akeyless's SaaS secrets-management model and its claim that vaultless, zero-knowledge architecture reduces operational burden while preserving control.

Why it matters: It matters because teams governing NHIs, service accounts, and AI agents need secrets controls that scale across hybrid estates without creating new infrastructure, lifecycle, and audit gaps.

By the numbers:

• 27 days
• Only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap.
• Only 44% of organisations are currently using a dedicated secrets management system.

👉 Read Akeyless's analysis of vaultless secrets management and zero-knowledge control

Context

Secrets management is not just a storage problem. It is a governance problem about how credentials, certificates, and keys are issued, rotated, revoked, audited, and made available to workloads without creating a second layer of infrastructure to secure. In hybrid and cloud-native environments, that control plane often becomes fragmented before teams notice it, especially when CI/CD, Kubernetes, and AI systems all need access.

Akeyless's model is relevant because it tries to remove the operational burden that usually sits around traditional vault deployments while keeping secrets under customer control. The real question for IAM and NHI programmes is whether a SaaS secrets platform reduces lifecycle complexity, or simply relocates trust, policy, and audit obligations into a different operating model.

For AI agents and other machine identities, the issue is sharper. If access is meant to be time-bound, policy-driven, and non-persistent, then secrets management has to serve runtime identity governance rather than static credential storage. That is where the article's claims intersect with NHI lifecycle design and cloud access control.

Key questions

Q: How should security teams handle exposed secrets in AI-driven environments?

A: Security teams should treat exposed secrets as active access paths and respond as though misuse can begin immediately. The right sequence is to identify the owning NHI, revoke the credential everywhere it is trusted, check downstream dependencies, and then validate whether the secret was copied into collaboration or CI systems.

Q: What do security teams get wrong about workload identity in cloud and CI/CD environments?

A: They often assume short-lived credentials automatically create good governance. In practice, the registration process, delegation semantics, and audit trail matter just as much as token lifespan. Without those layers, a workload can remain identifiable while still being difficult to control or investigate.

Q: What breaks when secret management is treated as storage only?

A: Storage-only thinking leaves replication, runtime delivery, and offboarding outside governance. Secrets can still be copied into pipelines, logs, and workloads even when a vault exists, so the real failure is lifecycle blind spots. Organisations need discovery, ownership, and revocation controls around every place a secret can be materialised or reused.

Q: Who should own zero-knowledge secrets governance in an enterprise?

A: The customer should own policy, lifecycle, and access accountability even when the provider cannot decrypt the material. That means security, IAM, and platform teams must define retrieval conditions, review access regularly, and preserve audit evidence for compliance and incident response.

Technical breakdown

How vaultless secrets delivery changes the control plane

Traditional secrets managers concentrate risk and operational work into a vault service that must be deployed, patched, replicated, and monitored. A vaultless model changes the control plane by making secrets available on demand through SaaS APIs rather than storing them in a customer-run backend. That can reduce infrastructure work, but it also means policy enforcement, availability, and auditability become inseparable from the provider's runtime model. For NHIs, this matters because the secret is no longer just a stored asset; it is part of a live access transaction.

Practical implication: map which access paths now depend on the SaaS control plane and test them as production identity dependencies.

Why zero-knowledge architecture matters for secrets custody

Zero-knowledge design means the platform never sees the secret material in a form it can decrypt. In this model, key fragments are split so no single system assembles the full secret, which reduces the custody problem but does not eliminate governance requirements. The important distinction is between possession and policy. A platform can avoid knowing the secret and still be responsible for enforcing who can retrieve it, when, and under what conditions. That distinction is central to modern NHI governance.

Practical implication: verify that zero-knowledge claims are matched by usable controls for access review, rotation, revocation, and audit.

Why short-lived secrets are more compatible with machine identities

Machine identities such as Kubernetes workloads, CI/CD pipelines, and AI agents do not fit well with long-lived credentials because their access patterns are dynamic and distributed. Just-in-time secrets reduce standing exposure by issuing credentials only for the task window, then expiring them automatically. The architectural benefit is not just smaller blast radius. It is that the identity system begins to treat secret use as a runtime event, which is closer to how NHIs actually operate in cloud environments.

Practical implication: replace persistent shared secrets in machine workflows with time-bound issuance tied to workload identity and policy.

NHI Mgmt Group analysis

Vaultless secrets management is best understood as lifecycle governance, not infrastructure outsourcing. Moving from self-managed vaults to SaaS removes one class of operational burden, but it does not remove the need to govern issuance, rotation, revocation, and audit. The control problem shifts from backend administration to identity lifecycle discipline across workloads, CI/CD, and AI systems. Practitioners should treat the platform as an access dependency, not a governance substitute.

The core risk is fragmentation, not just storage. When secrets live across multiple platforms, pipelines, and runtime contexts, the organisation loses a coherent view of who can retrieve what and for how long. That is the same failure mode seen in broader NHI sprawl: access outgrows the programme's ability to certify it. The practical conclusion is that central policy matters more than central vault branding.

Secretless AI agent support exposes a useful governance boundary. AI agents can retrieve secrets dynamically, but that does not make them inherently autonomous in the identity sense. If their tool use, timing, and access scopes are still policy-bounded, they remain NHI-governed systems. The implication is that teams should classify the actor correctly before deciding which lifecycle and approval controls apply.

Zero-knowledge architecture sharpens accountability questions rather than resolving them. If the provider cannot decrypt customer secrets, then the customer owns more of the policy burden, including scope definition, access review, and incident response. That is a healthier security posture only when the operating model is mature enough to handle it. Practitioners should validate governance maturity before treating zero-knowledge as a complete control answer.

From our research:

• The average estimated time to remediate a leaked secret is 27 days, despite 75% of organisations expressing strong confidence in their secrets management capabilities, according to The State of Secrets in AppSec.
• 54% of organisations are dissatisfied with their current secrets management solution because not all secrets are secured, and 43% cite lack of central management.
• For a broader control view, see Guide to the Secret Sprawl Challenge for how sprawl, hardcoded credentials, and runtime exposure interact.

What this signals

Secrets management programmes are moving from vault administration to identity lifecycle governance. The next maturity step is not simply more encryption or more integrations, but a tighter operating model for issuance, rotation, revocation, and audit across workloads, CI/CD, and AI-connected systems.

Vault sprawl debt: when secrets are scattered across tools and environments, the organisation inherits a governance burden that looks manageable until incident response begins. That means teams should measure not just how many secrets exist, but how many control planes can independently issue or expose them.

If your programme is already handling machine identity and workload access, the practical next step is to align secrets governance with broader identity policy and cloud control baselines such as the NIST Cybersecurity Framework 2.0 and the OWASP Non-Human Identity Top 10.

For practitioners

• Inventory every secret-bearing workflow Map CI/CD pipelines, Kubernetes workloads, AI agent integrations, and remote access paths to identify where static credentials still persist. Prioritise systems where a secret is reused across multiple environments or where ownership is unclear.
• Replace standing secrets with task-scoped access Use short-lived credentials for deploy, build, and runtime access wherever workload identity is available. Tie issuance to policy, time-to-live, and explicit workload context so credentials expire when the task completes.
• Test provider dependence as an identity dependency Validate what happens when the secrets platform is unavailable, delayed, or policy-restricted. Document fallback paths for production workloads so access continuity does not depend on undocumented operator workarounds.
• Separate secret custody from access governance Treat zero-knowledge or vaultless design as a storage model, not a lifecycle control. Retain ownership of approval workflows, rotation rules, revocation triggers, and audit evidence in the identity programme.

Key takeaways

• Secrets management is a lifecycle and governance problem, not only a storage problem.
• Fragmented control over credentials, keys, and certificates extends the time it takes to contain leaks and weakens auditability.
• Vaultless and zero-knowledge designs can reduce infrastructure burden, but only mature identity governance turns them into durable security.

Key terms

• Vaultless Architecture: A vaultless architecture delivers secrets through a managed service instead of a customer-operated vault server. The governance challenge does not disappear; it shifts to policy, identity, and runtime control over when secrets can be issued, retrieved, and revoked.
• Zero-knowledge encryption model: An encryption design where the provider cannot read the stored data because decryption keys are held by the user or derived locally. For identity programmes, this reduces provider visibility but does not remove the need to govern recovery paths, enrollment state, and administrative authority around access continuity.
• Just-in-Time Secrets Provisioning: Just-in-time secrets provisioning issues a credential only when a workload needs it and removes or expires it shortly after use. This reduces the time window for abuse and is most effective when paired with policy checks, workload identity, and automated revocation.
• Secretless Access: Secretless access is a pattern where workloads authenticate and receive access without relying on long-lived embedded credentials. It typically uses runtime identity verification, federation, and short-lived authorization decisions. The goal is to reduce exposure from hardcoded or reusable secrets while keeping machine-to-machine access functional.

What's in the full article

Akeyless's full post covers the operational detail this analysis intentionally leaves for the source:

• How its vaultless architecture is implemented across hybrid and multi-cloud environments.
• How Distributed Fragments Cryptography supports zero-knowledge custody in practice.
• How the platform handles certificate lifecycle management, secure remote access, and CI/CD injection.
• How its pricing and deployment model are positioned for organisations replacing legacy vault infrastructure.

👉 The full Akeyless post covers architecture details, use cases, and deployment considerations for secrets governance.

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 or NHI governance programme, it is worth exploring.