TL;DR: Secrets managers store and rotate credentials, but they do not decide whether a workload should have access, under what conditions, or for how long; Aembit’s analysis argues that workload IAM fills that governance gap by verifying nonhuman identity and issuing short-lived, scoped credentials. The broken assumption is that credential storage can substitute for runtime access control.
At a glance
What this is: This analysis argues that vault-centric secrets management stops at delivery, while workload IAM adds runtime identity verification, conditional access, and short-lived credentials for non-human identities.
Why it matters: IAM and security teams need to separate secret storage from access governance because service accounts, CI/CD tokens, and AI workloads need decisions made at request time, not only during rotation.
Context
A vault or secrets manager is a storage and delivery mechanism for credentials, not an access policy engine. In workload-heavy environments, that distinction matters because the system that hands out a secret does not decide whether the requester should be trusted at that moment.
For NHI governance, the real gap is runtime authorisation. Service accounts, tokens, and workload identities need controls that evaluate identity, posture, and context when access is requested, not after a secret has already been issued.
Aembit's position is that the common assumption is backwards: access control should govern the workload first, and secret handling should follow that decision. In environments with cloud, SaaS, CI/CD, and agentic systems, that is increasingly the typical problem, not an edge case.
Key questions
Q: What breaks when secrets are used as the default for workload access?
A: Static secrets become the easiest compromise path because they can leak into code, config files, build systems, and deployment logs. Once exposed, they often retain access longer than the workload needs, which increases standing privilege and widens the blast radius. The failure is not just exposure, but persistence after the business need has changed.
Q: Why do workload identities create new risk when used across clouds and APIs?
A: Because workload identities are transferable, their trust value can outlive the runtime conditions that made them safe. Across clouds and APIs, the credential may still be valid while the original process, container, or connection path has changed. That expands the blast radius of any exposed token and makes point-of-use enforcement more important than issuance alone.
Q: What are the signs that vault-centric NHI governance is failing?
A: Common signals include long rotation intervals, shared secrets between services, CI/CD tokens appearing in logs, and a growing number of bootstrap credentials outside the vault. Those patterns show that the organisation is managing secret custody but not controlling access conditions.
Q: When should teams move from secrets management to platform-native workload IAM?
A: Move when the organisation can already issue and audit access centrally, and when the main remaining problem is not storage but credential proliferation. At that point, continuing to expand secrets handling adds complexity without materially improving governance or reducing exposure.
Technical breakdown
Why vaults stop at secret delivery
Secrets managers centralise credentials, encrypt them, log access, and rotate them on a schedule, but their control boundary ends when the secret is handed to the requester. They do not evaluate whether the workload is in a trusted state, whether the request fits current policy, or whether the credential is being reused outside its intended context. That means a leaked token, cached secret, or replayed credential is still valid as long as the secret itself remains usable. In NHI terms, the vault manages the credential artefact, not the identity decision.
Practical implication: Treat vaults as storage and distribution controls, not as the decision point for workload access.
How workload IAM verifies non-human identity at runtime
Workload IAM shifts the trust anchor from possession of a static secret to cryptographic proof of workload identity. A workload presents platform-native signals such as service account context, instance identity, namespace, or runtime metadata, and the system verifies those signals before issuing access. The resulting credential is short-lived and scoped to the request, which reduces replay value and narrows blast radius. This model also removes secret zero from the access chain because the workload authenticates through its platform identity rather than a bootstrap credential stored elsewhere.
Practical implication: Use runtime identity verification where static credentials create a long-lived trust window.
Why cloud-native IAM does not replace cross-environment access governance
Cloud provider IAM systems are strong inside their own boundaries, but they do not create a unified policy layer across AWS, Azure, Google Cloud, SaaS, and on-premises systems. Once a workload needs access across those domains, teams often fall back to shared secrets, federation sprawl, or manual bridging controls. That fragments audit trails, complicates revocation, and weakens least privilege because the credential often has to work across multiple contexts. Workload IAM addresses the cross-domain gap by applying one access decision at the workload level, regardless of where the target resource lives.
Practical implication: Map cross-cloud and SaaS access paths separately from native cloud IAM and remove any shared-secret bridge you are using as a shortcut.
Threat narrative
Attacker objective: Use a stolen workload credential to reach services and data that should have required a fresh identity and policy decision.
- Entry occurs when a workload secret is exposed in code, a CI/CD log, a config file, or another repository outside the vault.
- Credential abuse follows because the leaked secret can be replayed by any party that obtains it, and the vault cannot distinguish the legitimate workload from the attacker.
- Impact occurs when the credential authorises access across services or clouds without runtime checks, allowing unauthorized access and lateral use of the workload path.
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.
- 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
Credential storage is not access governance: The industry still over-credits vaults for a problem they do not own. A secrets manager can protect a credential at rest, but it cannot decide whether a workload should be allowed to use that credential in the moment. Practitioners should stop treating secret storage as the centre of the access model and start treating it as one input into it.
Runtime trust is the missing control plane for NHIs: Workload identities need decisions made at request time, not only during provisioning or rotation. That is why conditional access, identity verification, and scoped issuance belong in the same control loop. The practical conclusion is that NHI governance must move from secret custody to access governance.
Static secrets create an identity blast radius that grows with every integration: Each additional service, pipeline, or AI workload adds another credential, another rotation dependency, and another compromise path. The more distributed the environment becomes, the less defensible it is to use a secret as the trust model. Teams should measure how much of their access architecture still depends on possession rather than proof.
Workload IAM names the broken premise behind vault-centric design: Least privilege was designed for access decisions that are explicit, contextual, and revocable. That assumption fails when a static secret can be replayed outside the runtime context that issued it. The implication is that governance models built around credential possession need to be reconsidered for non-human actors.
Identity-first access architecture is becoming the baseline for modern NHI programmes: Cloud, SaaS, CI/CD, and agentic systems now run through the same operational fabric. That makes per-request policy evaluation more important than any single vault implementation. The practitioner takeaway is to align NHI strategy around runtime identity and ephemeral credentials rather than around repository-style storage controls.
From our research library:
- 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools, according to the Ultimate Guide to NHIs.
- Read next: Guide to the Secret Sprawl Challenge
What this signals
Identity blast radius: Every static workload secret increases the number of places an attacker can pivot once one credential leaks, because possession becomes the only test that matters. That is why access models built around vault delivery need to be reworked around request-time identity and policy checks, not just better rotation.
Workload IAM does not replace secrets management so much as narrow its job description. The forward shift is toward runtime verification, ephemeral credential issuance, and context-aware policy enforcement, with the vault reduced to one component inside a broader control plane.
For practitioners
- Separate secret storage from access decisions Document where your current vault ends and where runtime authorisation begins, then remove any assumption that rotation alone enforces least privilege.
- Inventory bootstrap and secret zero dependencies Find every workload that still needs a stored bootstrap credential to reach a vault, then replace the dependency with platform identity where possible.
- Map cross-cloud access bridges Identify every AWS-to-Azure, cloud-to-SaaS, and on-premises access path that relies on shared secrets or manual federation and treat it as a governance gap.
- Shift policies to request-time evaluation Require current workload state, location, and posture checks before issuing short-lived credentials so access is granted by context, not by possession.
Key takeaways
- Vaults manage secret custody, but they do not make the access decision that workloads now need at runtime.
- The risk rises when shared credentials, secret zero dependencies, and cross-cloud bridges turn possession into the only trust signal.
- Modern NHI programmes need request-time identity verification and short-lived scoped credentials if they want least privilege to survive distributed environments.
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 CSF 2.0 and NIST SP 800-53 Rev 5 set 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 centres on leaked and misused workload secrets as the access path attackers exploit. |
| NHI-04 — Insecure Authentication | Workload identity verification replaces static secret possession as the trust signal. | |
| NHI-05 — Overprivileged NHI | The article argues that broad, reusable workload credentials violate least privilege. | |
| Recommendation — Eliminate exposed workload secrets and revoke any credential that can be replayed outside its intended context. Require cryptographic workload authentication before issuing access to NHIs. Scope NHI credentials to the minimum request and deny broad reuse across services. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | The core issue is whether workloads are authorised at request time under current conditions. |
| Recommendation — Apply PR.AA-05 to govern workload entitlements dynamically instead of relying on static secret possession. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Rotation, revocation, and lifecycle management of machine credentials are central to the article's risk model. |
| Recommendation — Use IA-5 to manage workload authenticators, including rotation, revocation, and expiry. | ||
| MITRE ATT&CK | TA0006;TA0008 — Credential Access; Lateral Movement | The article describes leaked workload secrets enabling credential abuse and spread across services. |
| Recommendation — Map exposed workload secrets to TA0006 and TA0008 to prioritise containment and detection. | ||
Key terms
- Workload IAM: Workload IAM is the practice of applying identity and access management controls to software workloads instead of relying on static secrets. It uses platform-native identity, policy, and short-lived credentials so access can be verified, scoped, and audited without embedding long-term secrets in applications.
- Secret Zero: Secret zero is the first credential needed to reach a secrets store, identity broker, or protected system. It is the root trust dependency that often survives even when everything else is rotated. If that initial credential is exposed, the rest of the secret model can collapse very quickly.
- Conditional Access: Conditional access is a policy model that decides whether an action should proceed based on context such as posture, resource sensitivity, timing, and scope. For AI agents, it must be evaluated at request time so a valid credential does not automatically equal permitted behaviour.
- Runtime Identity Verification: Runtime identity verification is the process of proving a workload's identity at the moment access is requested rather than trusting a pre-stored secret. It ties access decisions to the current workload instance, which is more suitable for ephemeral services and short-lived sessions.
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 June 6, 2026.
Updated on October 6, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org