TL;DR: Machine identities now outnumber human identities by roughly 82 to 1, and CyberArk reports that 42 percent of them hold privileged access while 61 percent of organisations lack workload identity controls. Aembit frames workload IAM as the discipline that replaces static credentials with runtime identity checks, policy evaluation, and ephemeral access for workloads, containers, pipelines, and AI agents.
At a glance
What this is: This is an analysis of workload IAM and its key claim that workloads need the same identity-first controls as humans, but applied at runtime rather than through static secrets.
Why it matters: It matters because IAM, PAM and NHI programmes increasingly have to govern workloads, pipelines and AI agents that do not fit human authentication or review cycles.
By the numbers:
- For every human identity your IAM program governs, there are roughly 82 machine identities operating outside it.
- 42 percent of machine identities carry privileged access, according to CyberArk research cited by Aembit.
- 61 percent of organizations lack identity security controls for cloud workloads, according to CyberArk research cited by Aembit.
Context
Workload identity management is the discipline for governing non-human access at runtime, not just storing credentials. The article says traditional IAM assumes a person, while workloads spin up and down quickly, call APIs across boundaries and often rely on secrets that were issued once and never reviewed.
The governance gap is straightforward: human IAM tools answer who a person is and whether they can access something, but they do not model a workload that needs access only for a specific task, environment and time window. That is why the article frames workload IAM as a distinct category for cloud workloads, pipelines, services, containers and AI agents.
For IAM teams, the practical issue is not whether machine identities exist. It is whether those identities are authenticated, authorised and audited in a way that survives multicloud, SaaS and high-churn runtime behaviour.
Key questions
Q: What breaks when workloads still rely on static credentials for service-to-service access?
A: Static credentials break down when workloads are ephemeral, distributed across multiple environments, or expected to authenticate without preconfigured secrets. They are difficult to rotate safely, easy to expose in configuration or environment variables, and poorly matched to dynamic infrastructure. The result is brittle access control, weaker auditability, and a larger attack surface for compromise and lateral movement.
Q: Why do workload identities create a different risk profile from human accounts?
A: Workload identities authenticate without human presence, often use long-lived credentials, and are frequently delegated across teams and pipelines. That combination makes ownership drift, weak storage, and over-permissioning more likely. Human IAM controls alone do not cover these patterns, so workload identity governance needs its own inventory, credential, and offboarding discipline.
Q: How do you know workload identity controls are actually working?
A: You should be able to show that access is issued without static secrets, that every workload has a clear owner, and that audit logs reconstruct identity, policy, and destination for each transaction. If those three signals are missing, the control is reducing effort but not yet governing risk.
Q: What should security teams do when AI agents and workloads share the same environment?
A: Security teams should treat AI agents as part of the attack surface and apply the same visibility and containment discipline used for workloads and users. That means tracking their traffic, understanding what they can reach, and limiting access to only the connections they truly need. If agents are unmonitored, they can become silent paths for data exposure or lateral movement.
Technical breakdown
Runtime workload identity versus static secrets
Workload IAM replaces the old pattern of a developer embedding an API key or token in code, configuration or a vault and leaving it to age indefinitely. Instead, the workload presents an identity at runtime, the platform verifies attributes such as service account, namespace, cloud instance or execution role, and only then issues access. That model matters because the credential is no longer the source of trust. Trust moves to attestation and policy evaluation, which allows access to be scoped to the session, workload context and resource sensitivity rather than to a reusable secret.
Practical implication: stop treating stored secrets as the primary control and shift workload access decisions to runtime identity verification.
How conditional policy governs workload access
The article describes workload IAM as more than federation. After identity verification, policy engines decide whether access should be granted now, using context such as environment, time, posture and sensitivity. That is a zero-trust pattern applied to non-human actors, because identity alone is not enough to authorise access. The important architectural point is that policy becomes the enforcement layer for workloads that may be legitimate but not currently eligible, such as a compromised container or a pipeline outside its expected posture.
Practical implication: define workload policies that combine identity, environment and posture instead of relying on static role grants.
Ephemeral credential issuance and the end of secret reuse
Once a workload passes policy, WIAM brokers a short-lived credential instead of exposing a long-lived API key or certificate. This reduces the standing blast radius because the credential expires automatically and is scoped to the task. It also addresses the provisioning problem and the last-mile delivery problem that secrets managers leave behind. In practical terms, the control target is no longer just the vault. It is the entire lifecycle of access issuance, use and expiration across cloud, SaaS and third-party services.
Practical implication: replace reusable machine credentials with ephemeral, task-scoped tokens wherever workloads can support them.
Threat narrative
Attacker objective: The attacker aims to turn a single exposed or overprivileged machine credential into broad access across services, clouds or SaaS integrations.
- Entry begins when a workload authenticates with a static API key, OAuth token or certificate that was provisioned once and never reviewed.
- Credential access occurs because the same reusable secret can be copied, reused or inherited by anyone or anything that gets hold of it.
- Escalation follows when the credential carries broad or privileged access across cloud boundaries, APIs or third-party integrations.
- Impact is the compromise of sensitive data or systems through machine-to-machine access that was never constrained to the original task.
Breaches seen in the wild
- Dropbox Sign breach 2024: A compromised back-end service account gave attackers Dropbox Sign customer data, including API keys, OAuth tokens and MFA information.
- Microsoft Midnight Blizzard breach: Midnight Blizzard (APT29) exploited legacy test account without MFA to breach Microsoft.
Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Workload identity management is now a distinct governance discipline, not a feature of secrets management. The article draws a clear line between storing credentials and governing access at runtime. That distinction matters because a vault can secure storage while still leaving provisioning, delivery and eligibility unresolved. Practitioners should treat workload IAM as the control plane for non-human access, not as an add-on to secrets tooling.
Static credential trust debt is the core operating risk in machine identity programmes. A secret issued once and never reviewed creates a long tail of ungoverned access that human IAM controls would never tolerate. The article’s 82-to-1 identity ratio and CyberArk figures underline the scale, but the governance issue is structural: access persists beyond the lifecycle that created it. Practitioners should reframe the problem as accumulated trust debt in the workload estate.
Runtime attestation is the right security primitive for workloads because identity alone is insufficient. The article shows that a service account, instance role or token must still be judged in context before access is granted. That aligns with zero-trust thinking in NIST SP 800-207, where access is conditional, not assumed. Practitioners should design for proof of workload state, not just possession of a credential.
Workload identity controls should align with NHI governance standards, not human access processes. The article shows workloads, containers, CI/CD pipelines and AI agents behaving as non-human identities with their own lifecycle and exposure patterns. Human IAM review cadences, SSO flows and MFA prompts do not fit that behaviour. Practitioners should govern these actors with NHI-specific standards and lifecycle controls, then extend that model to agentic systems where runtime decisions compound the risk.
From our research library:
- NHIs outnumber human identities by 25x to 50x in modern enterprises, according to the Ultimate Guide to NHIs.
- 69% of organisations still authenticate machine identities with long-lived API keys, according to the 2026 State of AI Agent Identity Security Report.
- Read next: Guide to NHI Rotation Challenges
What this signals
Static credential trust debt: the longer a workload credential survives, the more it behaves like standing privilege rather than controlled access. That is why workload IAM has to move governance from issuance and storage into runtime eligibility, with revocation and expiration built into the access path.
The shift matters across human IAM, NHI and agentic systems because the same control gap appears in different forms. Human programmes assume interactive authentication; workloads require attestation, policy and ephemeral access, while AI agents add a runtime decision layer that makes stale credentials even harder to govern.
For practitioners
- Map every workload that still uses static credentials Inventory service accounts, API keys, OAuth tokens and certificates used by workloads, pipelines and integrations, then identify where access is still granted outside runtime policy.
- Replace reusable secrets with ephemeral access Use platform-managed identities, federation or brokered tokens so the workload receives short-lived credentials only when policy approves the request.
- Enforce context-aware workload policies Require identity plus environment, posture and resource sensitivity before access is issued, especially for cloud-to-cloud and SaaS-to-SaaS traffic.
- Extend governance to AI agents and pipelines Treat agent identities, CI/CD jobs and other runtime actors as governed workloads with inventory, ownership and revocation paths, not as application exceptions.
Key takeaways
- Workload IAM addresses a governance gap that traditional human IAM does not cover well, because workloads authenticate and consume access at runtime rather than through human sessions.
- The article ties the risk to scale, with machine identities far outnumbering human identities and many still using privileged or ungoverned access paths.
- The practical answer is to shift from stored secrets to runtime identity, contextual policy and short-lived credentials for workloads, pipelines and AI agents.
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 Zero Trust (SP 800-207), 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 centers on static machine credentials that persist beyond intended use. |
| NHI-05 — Overprivileged NHI | It cites privileged machine identities as a major workload governance risk. | |
| NHI-07 — Long-Lived Secrets | The article argues for short-lived credentials instead of credentials that remain valid indefinitely. | |
| Recommendation — Scan workload estates for exposed secrets and remove reusable credentials from runtime paths. Review workload entitlements and reduce every service account to task-scoped access. Replace long-lived workload secrets with ephemeral tokens wherever federation is available. | ||
| NIST Zero Trust (SP 800-207) | Section 2.1 — Policy decisions and access enforcement | Workload access is granted only after policy and context checks, not by identity alone. |
| Recommendation — Require contextual policy evaluation before any workload receives access. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | The article is fundamentally about governing which workloads can access which resources. |
| Recommendation — Align workload entitlements to PR.AA-05 and remove standing permissions that are not task-based. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Static credentials and token lifecycle management are central to the discussion. |
| Recommendation — Use IA-5 to govern issuance, rotation and revocation of workload authenticators. | ||
| MITRE ATT&CK | TA0006;TA0008 — Credential Access; Lateral Movement | The article’s breach examples show attackers abusing machine credentials to move across systems. |
| Recommendation — Map exposed machine credentials to TA0006 and TA0008 to prioritise the highest-blast-radius paths. | ||
Key terms
- Workload Identity Management: Workload Identity Management is the practice of creating, issuing, securing, rotating, and revoking identities used by software workloads. It covers how services, containers, functions, and agents prove who they are to other systems, usually through certificates, tokens, keys, or federated assertions, so access can be controlled and audited.
- Runtime Attestation: Runtime attestation is a control that cryptographically proves a request came from the expected system or workload. It adds evidence to machine-to-machine access decisions, which is especially valuable when bearer tokens alone cannot distinguish a real integration from an attacker replaying credentials.
- Ephemeral Credentials: Ephemeral credentials are short-lived access artefacts issued for a limited task or session. They reduce the window for abuse, but they only improve security when paired with strong scope limits, telemetry, and automatic revocation at task completion.
- Static Credential: A static credential is a long-lived secret such as an API key, password, token, or certificate that exists outside the moment of use. It creates persistent attack surface because it can be copied, stored, reused, and exposed across code, pipelines, configuration files, and third-party environments.
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 7, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org