TL;DR: As AI agents now authenticate to APIs, query databases and trigger workflows autonomously, the non-human identity surface is expanding faster than legacy IAM was built to govern, according to Aembit. The key issue is not just visibility but whether identity controls can enforce least privilege across workloads, service accounts and agent-driven workflows.
NHIMG editorial — based on content published by Aembit: non-human identity management, machine identity management and workload identity and access management
By the numbers:
- With non-human identities now outnumbering human ones by ratios commonly exceeding 100:1 in enterprise environments, getting the distinctions right matters.
- Only 5.7% of organisations have full visibility into their service accounts.
- 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools.
Questions worth separating out
A: Treat the three layers as related but separate controls.
Q: Why do non-human identities create more risk than human accounts in cloud environments?
A: Non-human identities often outnumber human users, persist longer, and are reused across systems without the same lifecycle discipline as employee accounts.
Q: What breaks when certificate trust is treated as the same thing as access control?
A: A machine can be authentic and still have excessive permissions.
Practitioner guidance
- Classify identities by control layer Separate service account governance, machine certificate trust and workload access enforcement into distinct ownership domains.
- Replace static secrets with policy-mediated access Use just-in-time or secretless access for workloads that move frequently or call multiple services.
- Map every downstream dependency before revocation Build a dependency map for service accounts, SaaS-to-SaaS connections and workload credentials so revocation decisions do not rely on guesswork.
What's in the full article
Aembit's full analysis covers the operational detail this post intentionally leaves for the source:
- A side-by-side breakdown of NHIM, MIM and WIAM implementation decisions across cloud and SaaS environments
- Examples of how policy-based workload access is applied in CI/CD and production runtime paths
- Operational distinctions between secretless access, just-in-time credentials and certificate-based trust
- The article's own framing of how AI agents change the identity control plane
👉 Read Aembit's analysis of non-human identity management, machine identity and WIAM →
Non-human identity, machine identity and WIAM: where teams get it wrong?
Explore further
Non-human identity management is a visibility layer, not an enforcement model. The source article is right to separate governance from trust, because finding a risky service account does not stop it from being used. This is where many identity programmes overstate maturity: discovery without policy enforcement leaves the same access path open. Practitioners should treat NHIM as a detection and inventory capability, not as a control that can absorb runtime risk.
A few things that frame the scale:
- 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface, according to the Ultimate Guide to NHIs.
- Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them.
A question worth separating out:
Q: Should organisations prioritise workload identity over secret rotation?
A: They should do both, but workload identity is usually the stronger architectural move when environments are dynamic. Rotation reduces the lifespan of exposed secrets, while workload identity reduces dependency on those secrets in the first place. If a workload can authenticate without a stored credential, the operational and security burden both fall.
👉 Read our full editorial: Non-human identity management, machine identity and WIAM explained