Human IAM breaks at machine scale: why NHI needs new identity models

At a glance

What this is: Aembit argues that human IAM patterns do not scale to non-human identities, leaving machine access dependent on static secrets, manual rotation, and fragmented control planes.

Why it matters: IAM and PAM teams need to treat NHI access as a governance and architecture problem, because applying employee-era controls to workloads and AI agents creates operational drag and security exposure.

By the numbers:

• The amount of non-human identities continues growing to 45 to 1, then 100 to 1, then 200 to 1 in modern environments.

Context

Human IAM is built around people who authenticate interactively, but machine identities do not behave that way. Service accounts, CI/CD pipelines, SaaS apps, and AI agents need access patterns that are continuous, ephemeral, and policy driven, which makes employee-oriented identity controls a poor fit for non-human scale.

The governance gap is not limited to credential storage. When static secrets, manual rotation, and fragmented cloud controls become the default way to manage workload access, identity becomes an operational bottleneck as much as a security issue. That is why NHI programmes have to start with access architecture, not just secrets hygiene.

Key questions

Q: What breaks when machine identities are governed separately from human IAM?

A: Separate governance creates blind spots in entitlement review, revocation, and monitoring. A machine identity can retain broad access long after the business need changes, and teams may never see it inside the human access review cycle. That leaves runtime access outside normal oversight.

Q: Why do static credentials create so much risk for machine identities?

A: Static credentials are hard to track, easy to copy, and often survive long after the workload that used them has changed. That gives attackers or insiders a reusable access path with no natural expiry, which is why machine identity programmes need lifecycle controls as much as secret storage.

Q: How do security teams know whether NHI provisioning is actually governed?

A: Look for three signals: every identity has an owner, every secret lands in an approved storage path, and every new object appears immediately in inventory and lifecycle workflows. If any of those is missing, provisioning is still operating as a delivery process rather than a governance process.

Q: When should organisations separate human IAM from NHI governance?

A: Organisations should separate them whenever service accounts, API keys, tokens, or certificates are part of the access estate. Human identity controls are built around user behaviour and interactive authentication, while NHI governance must address secrets, standing privileges, rotation, and offboarding. Treating them as the same model leaves machine access under-governed.

Technical breakdown

Why static machine credentials fail at cloud scale

Machines cannot use MFA or step through human login flows, so they usually authenticate with API keys, passwords, or other static secrets. Those credentials are often embedded in code, stored in config, or distributed across tools, which makes rotation slow and leakage common. In a large cloud estate, the problem is structural: the number of identities grows faster than any manual process can govern. The result is not merely more work for security teams, but a broken identity model where issuance, rotation, and revocation lag the actual pace of system change.

Practical implication: treat static credentials as an architectural exception and reduce how many workloads depend on them.

Why secrets managers do not solve the secret zero problem

A secrets manager centralises storage, but it still requires a machine to prove who it is before it can retrieve anything. That bootstrap problem is often called secret zero: the first credential or trust signal needed to reach the vault in the first place. If that initial trust is still delivered through another static secret, the organisation has only moved the exposure point, not removed it. The real issue is access management for machines, not the storage location of secrets.

Practical implication: design the bootstrap path for machine identity before you assume a vault will fix credential sprawl.

How identity-first access creates short-lived machine trust

An identity-first model gives a workload a verifiable identity and issues a short-lived credential on demand, similar to SSO for humans but without the static password layer. This reduces the time window in which a credential can be stolen and reused, and it aligns access with runtime context such as code, environment, or purpose. For NHI governance, that is a shift from storing trust to issuing it only when needed. The control point moves from rotation after the fact to authorisation at issuance time.

Practical implication: anchor NHI controls in short-lived, policy-based credential issuance rather than post-issue cleanup.

Threat narrative

Attacker objective: The objective is to abuse machine access paths that outlive the business need for them, enabling reuse across systems and widening the blast radius of a single exposed credential.

1. Entry occurs through static API keys, passwords, or other long-lived machine credentials embedded in code, config, or toolchains. Those secrets create easy reuse paths when they leak or are copied across environments.
2. Escalation follows when a compromised workload credential can be reused across services, clouds, or SaaS boundaries because the access model was never designed for machine scale or consistent identity proofing.
3. Impact is operational and security-wide: attackers or internal misuse can move through workloads faster than human IAM processes can rotate or revoke access, while teams inherit audit drag and credential sprawl.

Breaches seen in the wild

• reviewdog Action compromise 2025: A stolen maintainer token poisoned reviewdog/action-setup, leaking CI secrets including the tj-actions bot token used in the next attack.
• CI/CD pipeline exploitation case study: Credentials in an exposed .git/config let a researcher edit a Bitbucket pipeline so it planted their SSH key on the server. No victim was named.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Human IAM assumptions break once the identity subject stops being a person. Access review cadences, MFA flows, and manual provisioning models were designed for human operators with stable accounts and observable login behaviour. Service accounts, CI/CD runners, SaaS integrations, and AI agents do not fit that model, so the programme failure is structural, not just procedural. The practitioner conclusion is that NHI governance needs its own identity assumptions, not a stretched version of employee IAM.

Secret zero is a bootstrap failure, not a storage failure. The article correctly shows that vaulting credentials does not answer the first trust question: how does a machine authenticate to the system that is supposed to authenticate it? That makes secrets managers necessary but insufficient, because they still depend on an initial credential path. The implication is that machine identity must be established before secret delivery becomes meaningful.

Ephemeral credential trust debt is the right concept for this problem. The longer an organisation depends on long-lived credentials, the more it accumulates hidden exposure across code, config, rotation queues, and audit processes. That debt increases operational friction and creates a standing attack surface that grows with every new workload. Practitioners should treat the elimination of static trust as a programme design objective, not a cleanup task.

Workload identity should be governed as access architecture, not as an add-on to secrets management. The strongest part of the article is its insistence that the core issue is access management for machines. That aligns with OWASP-NHI thinking on improper offboarding, long-lived secrets, and overprivileged identities. The practical conclusion is that NHI ownership belongs in the identity architecture conversation, where issuance, scope, and revocation can be designed together.

AI agents raise the same scale problem but with faster lifecycle turnover. The article's mention of agentic AI matters because it shows the machine identity problem is expanding into runtime systems that may request, use, and discard access dynamically. That does not make every AI workflow autonomous, but it does make static credential governance even less durable. The practitioner conclusion is to design for non-human identities whose access patterns change faster than review cycles.

From our research library:

• 69% of security leaders agree identity management must fundamentally shift to address agentic AI systems, according to the 2026 Infrastructure Identity Survey.
• 30.9% of organisations store long-term credentials directly in code, according to the Ultimate Guide to NHIs.
• Read next: Ultimate Guide to NHIs

What this signals

Human identity models do not scale cleanly into machine estates. Once workloads, SaaS connectors, and AI agents become the dominant identity population, access governance has to shift from interactive login assumptions to issued trust, bounded scope, and explicit offboarding. Ephemeral credential trust debt: the longer static secrets remain part of the operating model, the more unmanaged exposure accumulates across code, config, and pipelines.

Access reviews built for people cannot certify access that is created, used, and retired inside machine workflows. That is why NHI governance should move upstream to issuance time, where identity proofing, policy, and revocation can be linked to the workload lifecycle instead of an employee review cycle. The shift is now being reinforced by broader security leader sentiment: 69% of security leaders agree identity management must fundamentally shift to address agentic AI systems, according to the 2026 Infrastructure Identity Survey.

For practitioners

• Define a separate NHI access model Map service accounts, CI/CD runners, SaaS integrations, and AI agent access to a machine identity model instead of inheriting employee IAM patterns.
• Eliminate static secrets from build and runtime paths Inventory where API keys and passwords are embedded in code, configs, and pipelines, then replace those paths with short-lived credentials tied to workload identity.
• Design a bootstrap path for secret zero Document how a workload proves identity to reach the first trust point, and remove any dependency on another long-lived secret for vault access.
• Separate governance for human and non-human access Keep access reviews, entitlement scope, and revocation processes distinct for people and machines so lifecycle controls match the actor type being governed.

Key takeaways

• Human IAM patterns do not cover machine-scale identity because workloads, pipelines, SaaS apps, and AI agents depend on different trust and lifecycle assumptions.
• Static secrets and manual rotation create persistent operational drag and widen the blast radius of any exposed machine credential.
• The practical fix is to govern workload identity directly, with short-lived credentials, explicit bootstrap trust, and separate lifecycle controls for non-human access.

Key terms

• Non-Human Identity (NHI): A digital identity assigned to a non-human entity such as a software application, service account, API key, bot, machine, or AI agent that enables it to authenticate and interact with systems without direct human involvement. NHIs now outnumber human identities in most enterprises by 25 to 50 times.
• 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.
• Workload Identity: The identity assigned to a software workload, such as a containerised application, serverless function, or microservice, enabling it to authenticate to other services without storing static 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.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security 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.