Why non-human identities are the fastest-growing AI security risk

At a glance

What this is: This analysis argues that non-human identities have become the dominant enterprise identity risk as automation and AI multiply machine accounts, tokens, and keys.

Why it matters: IAM and NHI teams need to shift from human-centric access reviews to machine-first discovery, lifecycle enforcement, and ephemeral authorization.

By the numbers:

• 45 to 1.

👉 Read Token Security's analysis of why non-human identities are the fastest-growing AI security risk

Context

Non-human identity sprawl is what happens when software, cloud services, and AI agents need credentials to operate at machine speed. In this article, Token Security argues that the real security gap is not just volume, but the fact that existing IAM processes were built around people, while NHI governance has to manage service accounts, API keys, OAuth tokens, and bot identities that never follow a human lifecycle.

That matters because the enterprise is now creating identities in code, CI/CD pipelines, and autonomous workflows faster than security teams can inventory them. The right comparison is not employee access review versus workload access review, but manual governance versus continuous control over machine-issued credentials and privileges.

Key questions

Q: How should security teams govern non-human identities in AI-driven environments?

A: Treat non-human identities as first-class assets with ownership, inventory, and lifecycle rules. Enforce least privilege, short-lived credentials, and automated revocation, then monitor for anomalous machine behavior. Human approval loops alone are too slow for autonomous workloads and AI agents that can create or consume access at software speed.

Q: What is the difference between human IAM and NHI governance?

A: Human IAM centers on people, managers, and periodic review. NHI governance centers on workloads, software ownership, continuous telemetry, and automated lifecycle controls. The key difference is that machine identities act at high volume and speed, so manual recertification and directory-centric models leave too much standing access in place.

Q: When does short-lived credentialing reduce risk but not solve it?

A: Short-lived credentials reduce replay time, but they do not fix over-permissioned access or weak trust boundaries. If a workload can still reach too many systems, a stolen token can be used quickly and effectively. Real risk reduction requires both expiration and narrow authorization scope.

Q: Why do AI agents create new identity governance problems?

A: AI agents can decide when to call tools, request permissions, and trigger downstream actions without a human in the loop. That means access can expand dynamically during execution, not just at provisioning time. Governance has to watch the agent's runtime behavior, not only the identity record attached to it.

Technical breakdown

Why AI agents turn identity sprawl into recursive identity creation

Agentic AI changes the pace and shape of identity creation. A human developer can provision a few accounts, but an autonomous agent can spin up services, request permissions, and trigger downstream identities without waiting for a ticket or review. That is why the article's idea of recursive identity creation matters: machine identities can now create other machine identities inside workflows that security teams did not explicitly design. Traditional IAM tools struggle here because they assume a bounded set of users and approvers, not self-propagating access in software loops. Practical implication: teams need discovery and policy controls that watch for machine-issued credentials emerging from automation, not just from identity administrators.

Practical implication: Treat agent-driven provisioning as a control point and require policy checks before any new machine identity can be created.

Why bearer tokens and static keys are a different risk class

Machine identities typically rely on bearer tokens, API keys, or other non-interactive secrets because they cannot use human MFA flows. That creates a sharp failure mode: if the credential is copied, the identity is effectively cloned. Unlike a password protected by a second factor, a stolen token often works immediately and can be replayed from outside the environment unless there are separate IP, audience, or workload-bound restrictions. This is why secret location matters as much as secret strength. Practical implication: reduce the number of long-lived machine secrets and bind what remains to narrow context.

Practical implication: Move from static credentials to short-lived, context-bound access wherever workloads can tolerate it.

How standing privilege turns one exposed identity into an enterprise breach

The article correctly links over-provisioning to blast radius. A machine identity that can read logs, query metadata, and reach upstream data stores gives an attacker multiple paths after initial compromise. Because these identities are often not recertified and do not map cleanly to human managers, privilege accumulates quietly. In practice, the danger is less the initial secret leak than the transitive trust that follows inside cloud and microservice environments. When one service account can enumerate other secrets or call privileged APIs, compromise expands fast. Practical implication: review every NHI for minimum permission and break trust chains between workloads.

Practical implication: Limit each NHI to a single job and eliminate permissions that let one compromised workload discover others.

Threat narrative

Attacker objective: The attacker wants durable authenticated access that can be used to move laterally and extract data while appearing legitimate.

1. Entry via exposed API keys or secrets found in source code, logs, or public repositories.
2. Escalation through over-provisioned service accounts that expose additional credentials, metadata, or cloud resources.
3. Impact through authenticated data extraction that looks like normal application traffic and evades simple DLP checks.

Breaches seen in the wild

• Moltbook AI agent keys breach — Moltbook breach exposed 1.5M AI agent keys.
• Dropbox Sign breach — compromised Dropbox Sign service account exposed API keys and OAuth tokens.

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

NHI Mgmt Group analysis

Non-human identity risk is now an architectural problem, not a tooling gap. The article is right to frame machine identities as the dominant actor in modern enterprise traffic. Once workloads, bots, and AI agents become the primary consumers of infrastructure, human-centric IAM processes stop being the control plane that matters. Practitioners should treat NHI governance as core architecture, not a side function of access administration.

Recursive identity creation is the new governance failure mode. The most consequential shift is not just more credentials, but credentials being created by systems that already hold authority. That breaks the old assumption that identity issuance is a linear, reviewable event. Security teams need controls that can evaluate machine-issued access in real time, because quarterly review cycles cannot keep pace with autonomous provisioning.

Ephemeral credential trust debt describes the hidden exposure created when organizations keep temporary access patterns but fail to make them truly temporary. Short-lived tokens reduce exposure windows only if expiration, revocation, and audience scoping are enforced consistently. If teams keep broad entitlements behind short-lived wrappers, they reduce dwell time but not privilege. Practitioners should pair ephemerality with least privilege, not treat it as a substitute.

Human IAM processes do not scale to machine populations. The article's critique of IGA is credible because human review workflows depend on managers, org charts, and infrequent recertification. Machine identities need ownership, telemetry, and automated lifecycle enforcement instead. That means security leaders should stop asking how to fit NHIs into employee review cycles and start asking how to govern software identities on their own terms.

Secret-less design is the direction of travel, but transition matters more than slogans. Eliminating long-lived secrets is the right endpoint, yet most enterprises will get there in stages through federation, workload identity, and scoped federation policies. The practical test is whether a stolen credential can still be replayed broadly. Practitioners should measure progress by how much exploitable standing access they remove, not by how many controls they announce.

From our research:

• 64% of valid secrets leaked in 2022 are still valid and exploitable today, proving that detection alone is not enough without automated revocation, according to The State of Secrets Sprawl 2026.
• AI-related credential leaks surged 81.5% year-over-year in 2025, with the surrounding AI infrastructure leaking 5x faster than core LLM providers.
• For lifecycle control context, Guide to the Secret Sprawl Challenge explains why discovery without rotation and revocation leaves exploitable exposure behind.

What this signals

With 28.65 million new hardcoded secrets detected in public GitHub commits in 2025, the operating assumption that secrets stay buried is no longer credible. For NHI programmes, that means discovery pipelines must be paired with revocation workflows and ownership mapping, otherwise every new leak simply increases the backlog of exploitable access.

Identity blast radius: this is the practical measure that matters when one NHI can unlock several downstream systems. As workload identity, API keys, and agent tool access multiply, programmes should reduce the number of identities that can pivot across services and verify that each credential is bounded to a single purpose.

The reader-level implication is straightforward. Security teams should prepare for more credential exposure outside code, more autonomous access decisions at runtime, and more pressure to prove that every machine identity has a current owner, a valid reason to exist, and a narrow path to impact.

For practitioners

• Implement continuous NHI discovery Inventory service accounts, API keys, OAuth tokens, certificates, and bot identities across cloud, code, and SaaS systems so newly created machine access is visible within hours, not quarters.
• Replace standing secrets with short-lived credentials Use workload identity federation and ephemeral tokens where possible, and tie each credential to audience, workload, and expiry limits that reduce replay risk.
• Automate offboarding for machine identities Revoke unused credentials after a defined inactivity window and destroy identities when the workload or project ends, instead of leaving orphaned access in place.
• Break privilege chains between workloads Remove permissions that let one service account enumerate other secrets, reach unrelated data stores, or create additional identities without a policy check.

Key takeaways

• Non-human identities have become the dominant operational identity class in AI-driven enterprises, which makes them a primary governance target.
• The biggest risk is not credential count alone, but the combination of standing privilege, weak lifecycle control, and machine speed.
• Practitioners should move toward continuous discovery, short-lived credentials, and automated revocation before exposure becomes routine.

Key terms

• Non-Human Identity: A non-human identity is any credentialed entity used by software, infrastructure, or an AI agent to authenticate and act. It includes service accounts, API keys, tokens, certificates, and bot identities. These identities can operate at machine speed and often exist outside human review cycles.
• Standing Privilege: Standing privilege is access that remains available continuously instead of being granted only when needed. For NHIs, it often appears as broad service account permissions or long-lived tokens that keep working long after the original task has changed, increasing the blast radius of compromise.
• Ephemeral Credential: An ephemeral credential is a short-lived secret or token issued for a narrow task and limited time window. In NHI governance, ephemerality lowers replay risk, but only if the credential is also scoped to the right workload, audience, and permissions.
• Recursive Identity Creation: Recursive identity creation happens when an automated system, script, or AI agent provisions additional identities as part of its own workflow. This creates governance pressure because access issuance can spread faster than manual review or traditional directory-based controls can track.

What's in the full article

Token Security's full blog covers the operational detail this post intentionally leaves for the source:

• The article expands the human-versus-machine identity table with a fuller risk profile across authentication, lifecycle, and privilege.
• It walks through the attack chain from secret discovery to data exfiltration, including how compromise can look like normal application traffic.
• It outlines a machine-first security strategy with discovery, lifecycle management, anomaly detection, and secret-less architectures.
• It gives the vendor's own framing for why AI-driven development accelerates NHI sprawl and why that changes programme priorities.

👉 Token Security's full post covers the attack chain, machine-first controls, and AI-driven identity sprawl

Deepen your knowledge

Non-human identity governance and lifecycle control are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If your environment is already dealing with AI agents, service accounts, and exposed secrets, it is worth exploring.