TL;DR: Akeyless research finds single-cloud vaults still fit Azure-native workloads, but multi-cloud estates push teams into fragmented policy, audit, and rotation models, according to cited market research. The durable answer is identity-based, short-lived access that reduces the value of a leaked secret and fits machine and AI-agent workflows.
At a glance
What this is: This analysis says Azure Key Vault remains a strong native fit, but multi-cloud estates expose the limits of single-cloud vaulting and push teams toward identity-based, short-lived access models.
Why it matters: IAM, PAM, and NHI teams should read this as a governance question, because secret sprawl, audit fragmentation, and static credentials become harder to control as environments expand beyond one cloud.
By the numbers:
- The global secrets management market is projected to roughly double from about $4.2B in 2025 to $8B or more by 2030.
👉 Read Akeyless's analysis of Azure Key Vault alternatives and multi-cloud governance
Context
Azure Key Vault is a cloud-native secrets store, key manager, and certificate service for Azure environments. The governance gap appears when an organisation runs AWS, GCP, Kubernetes, or on-prem alongside Azure and needs one policy model across all of them.
Single-cloud vaulting breaks down because every native service governs only its own provider. That creates separate audit trails, rotation schedules, and access models, which is why the issue is not vault quality but multi-cloud control-plane fragmentation.
Key questions
Q: What breaks when teams keep one vault per cloud?
A: Policy, audit, and rotation become siloed by provider, so security teams lose a single view of who accessed what and when. That fragmentation also creates inconsistent lifecycles, because one cloud’s rotation model rarely matches another’s. The result is a governance gap, not just operational duplication.
Q: Why do static secrets become more risky in multi-cloud estates?
A: Because static credentials stay valid long enough to be copied, cached, and reused across environments. When access is not bound to a short-lived identity session, one exposed secret can outlive the task that needed it and become reusable in places the original system never intended.
Q: How do teams know if their secrets programme is really unified?
A: Look for one consistent answer to four questions: who issued the credential, which policy approved it, where it was used, and when it expired. If each cloud or vault answers differently, governance is still fragmented even if the tools are connected by dashboards.
Q: How should teams govern AI agent access when downstream systems still require secrets?
A: Use the agent's attested identity as the trust anchor, then issue short-lived downstream credentials that are scoped to one resource and one task. The goal is to keep the secret disposable while preserving an audit trail that ties every access back to the workload that requested it. That reduces standing privilege without requiring every target system to support native workload identity.
Technical breakdown
Why native cloud vaults fragment multi-cloud governance
Native vaults are designed to govern their own cloud first. Azure Key Vault ties well into Entra ID and Azure resource access, AWS Secrets Manager aligns to AWS IAM, and GCP Secret Manager fits Google Cloud. The architecture works until secrets, certificates, and workloads span more than one provider. At that point, each vault becomes a separate policy domain with its own audit trail, rotation cadence, and access review process. The result is not one secrets programme but several parallel ones, which is why audit consistency becomes the real challenge.
Practical implication: map every provider-specific vault to a single governance owner and identify where policy, logging, and rotation diverge.
Why scheduled rotation is weaker than dynamic secrets
Scheduled rotation changes a secret on a timer, but it still leaves the secret as a reusable credential between rotations. Dynamic secrets work differently: access is minted on demand, tied to identity and context, and expires with the session or task. That reduces the value of a leaked credential because there is less time for reuse and less chance for long-lived credential reuse across pipelines, workloads, and agents. This is the key distinction between storage and issuance.
Practical implication: prefer issuance models that expire with the task, not timer-based rotation alone.
How AI-agent access changes the secrets problem
AI agents are not just another workload when they can act across tools and timing without human approval. If the secret is handed to the agent, the workflow inherits durable credential risk even if the vault is secure. A secretless or proxy pattern changes the trust boundary so the agent never holds the credential directly. That matters because the governance problem is no longer where the secret is stored, but whether the actor needs to possess it at all.
Practical implication: redesign agent workflows so the credential is brokered, not exposed to the agent runtime.
Threat narrative
Attacker objective: The attacker aims to turn one exposed secret into reusable access across multiple environments and services.
- Entry occurs when secrets spread across AWS, Azure, GCP, and on-prem, creating multiple governance surfaces instead of one. Credential exposure often comes later through config files, CI pipelines, or application runtime stores.
- Escalation follows when a leaked credential remains valid long enough to be reused because rotation is scheduled rather than task-bound. Standing privilege in a fragmented vault estate extends the window of abuse.
- Impact is broad credential reuse across environments, with one exposed secret potentially opening access beyond the cloud where it was originally created.
Breaches seen in the wild
- Millions of Misconfigured Git Servers Leaking Secrets: Nearly 5 million misconfigured Git servers expose sensitive secrets and credentials online.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 150+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Single-cloud vaulting is now a control boundary problem, not a product preference. Native vaults are architecturally correct inside one cloud, but they become governance fragments as soon as secrets span more than one provider. That shifts the real question from which vault to use to how to impose one policy and audit model across several. Practitioners should treat multi-cloud vault sprawl as an identity governance issue, not a tooling comparison.
Identity-based issuance is the more durable control model than secret storage. Static credentials can be rotated, but they still exist long enough to be copied, cached, and reused. Dynamic, short-lived access reduces the value of compromise because the credential is bound to identity, scope, and time rather than preserved as reusable material. For NHI governance, the decisive control is how access is issued, not how often a secret is swapped.
Secretless access is the right frame for AI-agent workflows. An agent that receives a durable secret inherits the same exposure pattern as a workload, but with more dynamic behaviour and less predictable runtime context. The better governance question is whether the agent should ever possess the secret in the first place. Practitioners should design around secret brokerage, not agent-held credentials.
Multi-vault estates need lifecycle governance, not just inventory. The article’s core point is that many teams end up running several vaults in parallel, each with its own rotation and audit model. That is a lifecycle failure as much as an architecture choice, because access outlives the control plane that issued it. The governance task is to unify issuance, audit, and offboarding across vaults, workloads, and agents.
Ephemeral credential trust debt is the hidden cost of scaling beyond one cloud. Every environment that keeps its own vault adds another place where a credential can persist longer than the business process that needed it. The longer the trust chain, the more likely teams are to accept static access as operationally normal. Practitioners should interpret multi-cloud vaulting as a prompt to reduce credential persistence, not just centralise it.
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.
- Read next: Ultimate Guide to NHIs — Static vs Dynamic Secrets
What this signals
Multi-cloud vault sprawl is a lifecycle problem disguised as a tooling choice. Once secrets live in several providers, the real challenge is not storage but governance continuity. The same identity policy has to follow the credential from issuance through review, expiry, and offboarding, or the programme ends up with parallel controls that do not reconcile.
Identity-based access will increasingly define secrets strategy. The practical direction is away from reusable static credentials and toward access that is issued for a task, then disappears. That shift matters most for workloads and AI agents, where long-lived secrets create trust debt that conventional rotation cannot eliminate.
For practitioners
- Map every vault boundary Inventory where Azure Key Vault, AWS Secrets Manager, GCP Secret Manager, and any self-hosted stores each own policy, audit, and rotation decisions.
- Replace scheduled rotation with short-lived issuance Use dynamic secrets for services that can authenticate at runtime so the credential lifetime matches the task lifetime instead of a fixed calendar interval.
- Unify audit trails across providers Define one access-review workflow that correlates who requested, issued, and used a secret across clouds and on-prem systems.
- Design secretless agent workflows Require proxy or brokered access for AI agents so the agent runtime never stores or reuses a durable secret.
- Classify which secrets still need storage Separate credentials that can be replaced by ephemeral identity from those that still require vault-backed retention, then reduce the latter over time.
Key takeaways
- Native cloud vaults remain effective inside one ecosystem, but they create fragmented governance when secrets spread across multiple clouds.
- The main risk is not just storage sprawl. It is the accumulation of separate audit, policy, and rotation models that are hard to reconcile.
- Practitioners should shift from static secret management to short-lived, identity-based access and secretless workflows where possible.
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 and MITRE ATT&CK address the attack and risk surface, while NIST SP 800-53 Rev 5 sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 — Secret Leakage | The article focuses on leaked and reusable secrets across cloud and agent workflows. |
| NHI-07 — Long-Lived Secrets | Scheduled rotation is weaker than short-lived issuance for this use case. | |
| NHI-10 — Human Use of NHI | Humans handling agent secrets is called out as a risk in the source article. | |
| Recommendation — Scan for secret leakage across repos, logs, and agent contexts, then revoke exposed credentials promptly. Replace long-lived secrets with task-scoped credentials wherever workloads permit. Eliminate manual copying of NHI secrets into scripts, pipelines, and agent workflows. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Credential lifecycle and rotation are central to the article's governance model. |
| Recommendation — Automate authenticator rotation and revocation across cloud vaults and workloads. | ||
| MITRE ATT&CK | TA0006;TA0008 — Credential Access; Lateral Movement | Exposed secrets can be reused for credential access and movement between clouds. |
| Recommendation — Treat exposed secrets as initial access paths and constrain their reuse across environments. | ||
Key terms
- Dynamic Secret: A secret generated on-demand for a specific task and automatically revoked after use or expiry. Dynamic secrets dramatically reduce the risk of credential exposure compared to static, long-lived secrets and are considered best practice.
- 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.
- Hybrid And Multi-Cloud Governance: Hybrid and multi-cloud governance is the discipline of applying consistent oversight across data, systems, and identities that span multiple hosting models and providers. The challenge is maintaining policy, visibility, and evidence when the control surface is distributed and operationally inconsistent.
- Vault Sprawl: Vault sprawl is the uncontrolled growth of secret stores, vault instances, and duplicate credential repositories across an organisation. It creates fragmented access control, unclear ownership, and inconsistent rotation practices, which makes it difficult to prove where a secret lives or whether the authoritative copy is still in use.
What's in the full article
Akeyless's full article covers the operational detail this post intentionally leaves for the source:
- Side-by-side comparison of Azure Key Vault alternatives by deployment model, including managed SaaS, self-hosted, and cloud-native options
- Pricing and operational trade-offs across per-operation, per-secret, and per-seat models
- Vendor-by-vendor fit notes for multi-cloud governance, developer workflows, and existing PAM programmes
- Practical guidance on secretless access patterns for AI agents and workload identity
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.
Published by the NHIMG editorial team on July 22, 2026.
Updated on October 7, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org