By NHI Mgmt Group Editorial TeamBased on Token Security: “Why Non-Human Identities Break Traditional Cloud Security Models” (April 20, 2026)

TL;DR: Traditional cloud security models were built for interactive human users, but modern enterprises now rely on service accounts, API keys, bots, containers, and AI agents that operate at far greater scale and speed, according to Token Security. That mismatch creates a governance gap where identity, not perimeter, becomes the decisive control plane.


At a glance

What this is: This article explains why traditional cloud security breaks when non-human identities become the dominant actors, with scale, velocity, and ephemerality driving the failure.

Why it matters: IAM, PAM, and cloud security teams need to govern machine identities as a primary control plane because human-centric controls do not match how workloads and AI agents actually operate.

By the numbers:

  • Non-human identities now outnumber human identities by a ratio of at least 45 to 1 in large enterprises.

Context

Non-human identities are the service accounts, API keys, bots, serverless functions, and containers that run modern cloud environments. Traditional security models assumed identity meant a person, but cloud-native architecture has made that assumption incomplete and often wrong.

The governance problem is not simply that there are more machine identities. It is that they are created, used, and destroyed at IaC speed, while legacy IAM and IGA processes were designed for slower human lifecycles and interactive authentication. That mismatch leaves blind spots in inventory, review, and offboarding.

For AI agents, the issue becomes sharper because runtime behaviour can change while privileges remain static. The article treats that as a structural failure of cloud security assumptions, not just a tooling gap.


Key questions

Q: What breaks when cloud security models are applied to non-human identities?

A: Human-centric IAM breaks because machine identities do not have stable employment cycles, interactive logins, or manager-based approval paths. Service accounts and workloads can appear and disappear far faster than review processes can track them, which turns traditional governance into lagging paperwork instead of active control.

Q: Why do long-lived access keys increase risk in cloud environments?

A: Long-lived keys create standing access that is easy to reuse, hard to govern, and difficult to revoke at scale. If they are embedded in code or shared across teams, compromise can lead to broad access that persists until manually cleaned up. Temporary roles and federated identity reduce exposure and make access far easier to control.

Q: How can organisations tell whether NHI governance is actually working?

A: NHI governance is working when every machine identity has an owner, a purpose, a minimum-necessary entitlement, and evidence of rotation and review. If teams can produce that chain without manual reconstruction, the programme is mature enough to withstand audit pressure. If they cannot, the governance model is still fragmented.

Q: What should IAM teams prioritise when machines outnumber people?

A: They should prioritise inventory, ownership, and secret lifetime before they add more human review steps. When non-human identities dominate the environment, the key question is whether access is issued, observed, and revoked at the same speed as the workload that uses it.


Technical breakdown

Why human-centric IAM fails for machine lifecycles

Human IAM assumes stable roles, managers, and long-lived employment cycles. Machine identities do not follow that pattern. A workload can create hundreds of service accounts in minutes, operate across multiple cloud services, and disappear before a quarterly review ever sees it. That breaks joiner-mover-leaver logic, because the identity lifecycle is event-driven rather than personnel-driven. When teams bypass slow governance to keep delivery moving, they create shadow identities and lose authoritative inventory. Practical implication: govern machine identity creation and teardown at deployment speed, not at human HR cadence.

Practical implication: govern machine identity creation and teardown at deployment speed, not at human HR cadence.

Why static secrets and MFA assumptions collapse

Machine identities authenticate non-interactively, so controls built around human challenge-response flows do not apply. The article describes API keys and certificates as bearer tokens, meaning possession is enough to act. Once a secret is stolen, the attacker inherits uninterrupted access because there is no second factor to interrupt or confirm the session. That is why long-lived secrets become structural liabilities in cloud environments. The weakness is not just leakage; it is the persistence of trust after leakage. Practical implication: treat every long-lived machine secret as a standing access grant with a theft path attached.

Practical implication: treat every long-lived machine secret as a standing access grant with a theft path attached.

Why ephemerality defeats conventional logging and review

Ephemeral workloads can execute, touch data, and disappear before traditional agent-based tooling or periodic audits can observe them. That means the evidence trail often ends with the workload, not with the access event. In cloud environments, this makes post-incident reconstruction difficult and weakens review-based governance because the privilege may never exist long enough to be examined manually. The article also ties this to AI agents, where static policy is a poor fit for runtime decision-making. Practical implication: shift detection and governance closer to issuance and execution, where ephemeral access still leaves an observable control point.

Practical implication: shift detection and governance closer to issuance and execution, where ephemeral access still leaves an observable control point.


Threat narrative

Attacker objective: The attacker wants to turn unmanaged machine identity into durable cloud access that can be used for data theft, privilege expansion, or operational disruption.

  1. Entry occurs when attackers obtain a hardcoded API key, stolen token, or other forgotten machine credential that still grants access to cloud resources.
  2. Escalation follows when that credential belongs to a service account or workload with broad permissions, allowing the attacker to move beyond the original intended task.
  3. Impact appears as lateral movement through cloud APIs, data access, and configuration changes that blend into normal machine traffic and are hard to distinguish from legitimate activity.
  • Sisense breach 2024: A credential in Sisense's GitLab reportedly opened S3 buckets of customer tokens, passwords and certificates; CISA urged a full reset.
  • Internet Archive breach 2024: An exposed GitLab token opened Internet Archive code and 31 million user records; unrotated Zendesk tokens let the attacker back in weeks later.

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


NHI Mgmt Group analysis

Identity does not equal person any longer: cloud governance was designed around humans, but the modern control problem is dominated by service accounts, API keys, containers, and bots. That shift changes the security unit of measure from users to executable identities. Programmes that still optimise around human-centric workflows will keep producing blind spots in inventory, review, and offboarding.

45 to 1 is a governance ratio, not just a scale statistic: when machine identities outnumber people by that margin, manual review models stop being security controls and become compliance theatre. The real problem is not volume alone, but the fact that scale erodes the ability to assign ownership, confirm purpose, and verify current need. Practitioners should treat machine identity sprawl as a control integrity issue, not an administrative inconvenience.

Ephemeral credential trust debt: the article exposes a specific failure mode where short-lived workloads are governed as if they behaved like stable human accounts. That assumption fails because access can be created, used, and discarded within one task, while periodic certification cycles operate much later. The implication is that governance must move to issuance time and runtime context, or the review model will certify nothing meaningful.

Static secrets create standing risk even inside cloud-native architectures: bearer-style credentials collapse the distinction between legitimate automation and attacker possession. Once a secret is copied, the environment has no inherent way to distinguish intended machine use from abuse. That is why secret lifetime, ownership, and rotation discipline sit at the center of machine identity governance.

AI agents expose the limit of static policy: the article correctly shows that autonomous behaviour breaks permission models written for predictable software paths. When the actor can change intent at runtime, least privilege is no longer just a provisioning question. Practitioners need to rethink what can be certified, what can be pre-authorised, and what must be constrained dynamically.

From our research library:

What this signals

Credential lifetime is the real control boundary: when machine access is non-interactive, the meaningful governance moment is issuance, not login. That is why teams need lifecycle controls for secrets and workload identities, not just monitoring after the fact.

Identity sprawl will keep outrunning human review: the article's 45 to 1 ratio shows why manual certification cannot be the primary defense for non-human identities. Security programmes should expect machines to expand faster than board-level or quarterly governance cycles can absorb.

Autonomous behaviour changes the governance question: once AI agents can act at runtime, access no longer behaves like a static entitlement. Programmes must decide which decisions are certifiable in advance and which ones require real-time control instead of post hoc review.


For practitioners

  • Map every machine identity to an accountable owner Create a current inventory of service accounts, API keys, bots, containers, and serverless identities, then assign business and technical ownership for each one.
  • Eliminate long-lived machine secrets where possible Replace static API keys and other durable bearer credentials with short-lived, task-scoped access so stolen secrets do not remain valid beyond their intended use.
  • Move governance to deployment and issuance time Build controls that validate workload identity, purpose, and scope when credentials are issued, rather than relying on later periodic access reviews that miss ephemeral activity.
  • Right-size permissions continuously Monitor unused privileges on service accounts and workloads, and remove rights that have not been exercised so machine identities do not accumulate standing admin access.
  • Instrument cloud identity visibility across platforms Correlate identity, code, and resource context across cloud and SaaS environments so security teams can see which workload deployed an identity and what it can reach.

Key takeaways

  • Traditional cloud security fails when machine identities become the dominant actors and the control model still assumes a human at the keyboard.
  • The article cites a 45 to 1 ratio of non-human to human identities in large enterprises, which shows why manual governance cannot keep pace.
  • Practitioners need ownership, short-lived access, and continuous visibility at the point of issuance if they want identity controls that match cloud reality.

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 sets the governance and control requirements practitioners need to meet.

FrameworkControl / ReferenceRelevance
OWASP Non-Human Identity Top 10NHI-05 — Overprivileged NHIThe article centers on machine identities accumulating broad rights in cloud environments.
NHI-07 — Long-Lived SecretsLong-lived API keys and certificates are identified as a central liability in the article.
NHI-10 — Human Use of NHIThe article warns against applying human-centric security patterns to machine identities.
Recommendation — Review and reduce machine permissions so workload identities do not retain standing broad access. Replace durable machine secrets with short-lived credentials and rotate any remaining keys aggressively. Separate human IAM workflows from machine identity governance and stop forcing MFA-based assumptions onto workloads.
NIST CSF 2.0PR.AA-05 — Access Permissions, Entitlements and AuthorizationsThe article is about governing who or what can access cloud resources and how those permissions persist.
Recommendation — Continuously validate permissions and entitlements for workloads so access remains aligned to current need.
MITRE ATT&CKTA0006;TA0008 — Credential Access; Lateral MovementThe threat pattern described is stolen machine credentials enabling movement through cloud services.
Recommendation — Map stolen-token scenarios to credential access and lateral movement detections in cloud telemetry.

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.
  • Identity Sprawl: Identity sprawl is the uncontrolled growth of identities, entitlements, and credentials across an environment. For NHIs, it usually appears when automation creates accounts faster than governance teams can inventory, review, and remove them. The result is hidden access, weak accountability, and a wider attack surface.
  • Bearer Token: A bearer token is a credential that grants access to whoever possesses it, without requiring strong proof that the holder is the intended client. In NHI environments, that makes theft and replay the main risk, especially when tokens are long-lived, broadly scoped, or stored in local files.
  • Ephemeral Cloud Workload: A workload that exists for a short time, often created and destroyed automatically as demand changes. Ephemeral systems are difficult for traditional security tools to track because they may appear, scale, and disappear before manual onboarding or agent deployment can keep pace.

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.
NHIMG Editorial Note
Published by the NHIMG editorial team on May 30, 2026.
Updated on October 6, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org