Non-human identities outnumber users and outlast human controls

At a glance

What this is: This is an explanatory analysis of non-human identities and the core finding is that NHIs often outnumber human users while holding broader, longer-lived access.

Why it matters: It matters because IAM, PAM, and SaaS security programs built around human logins miss the credentials, token lifecycles, and inherited permissions that attackers increasingly abuse.

By the numbers:

• Non-human identities outnumber humans 10-50x in enterprise environments.
• Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them.
• 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools.
• 79% of organisations have experienced secrets leaks, with 77% of these incidents resulting in tangible damage.

👉 Read Obsidian Security's explanation of what non-human identities are and why they matter

Context

Non-human identity security is the problem of governing accounts, tokens, keys, certificates, bots, and AI agents that act without a person at the keyboard. The core gap is that these identities are created for machine-to-machine work, but most governance and monitoring practices still assume human login patterns and human offboarding workflows.

In SaaS-heavy environments, that mismatch produces invisible standing access, weak ownership, and weak visibility into third-party integrations. The article argues that this is normal in modern enterprises, not an edge case, which is why NHI governance now sits inside mainstream IAM and Zero Trust planning.

Key questions

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

A: Start with a complete inventory of service accounts, API keys, OAuth apps, tokens, and bots, then assign each one an owner, purpose, and expiry path. After that, recertify permissions against actual use, not historical convenience, and monitor post-authentication behaviour because machine credentials often look legitimate even when compromised.

Q: What is the difference between OAuth tokens and API keys from a security perspective?

A: OAuth tokens are delegated credentials tied to consented access, while API keys are static credentials that often provide broader, less granular access. In practice, both can create persistent non-human identity risk, but refresh tokens and long-lived API keys are especially dangerous when rotation and revocation are weak.

Q: Why do non-human identities create more risk than employee accounts in some environments?

A: NHIs often outnumber humans, hold broader permissions, and bypass controls built for interactive logins such as MFA and employee offboarding. They also operate continuously across systems, so one compromised credential can create durable access and a larger blast radius than a single human account would.

Q: When should organisations tighten controls around automation and AI agents?

A: They should tighten controls whenever an automation workflow or AI agent can reach multiple systems, handle sensitive data, or make dynamic decisions about tools. That is the point where least privilege becomes hard to prove and where task-scoped access, continuous review, and behavioral monitoring become necessary.

Technical breakdown

Why service accounts and API keys evade human IAM controls

Service accounts and API keys are built for automation, not interactive authentication. They often authenticate once and then continue operating through API calls, so controls such as MFA, password reset, and employee offboarding do not map cleanly to them. Because these credentials can be embedded in code, config, or pipelines, their true scope is often wider than the team that created them understands. In practice, the security issue is not just possession of the credential. It is the combination of long-lived authentication, broad permissions, and weak lifecycle ownership.

Practical implication: Inventory where machine credentials live and tie each one to an owner, purpose, and expiry path.

OAuth tokens and inherited permissions in SaaS supply chains

OAuth tokens create delegated access, which means one app can act through another with the permissions that were granted at consent time. Access tokens are usually short-lived, but refresh tokens can silently mint new access for months or years. That makes token theft especially dangerous in SaaS supply chains, where one compromised integration can become a trusted bridge into downstream systems. The architectural issue is not only token theft, but also the inheritance model that carries permissions across connected applications.

Practical implication: Review every third-party OAuth connection as a trust relationship, not a convenience feature.

Why AI agents increase identity blast radius

AI agents are more volatile than traditional automation because they make dynamic tool and access decisions based on instructions and context. That means the next API call, target system, or data source is not always known in advance, which makes least privilege harder to express and harder to prove. When an agent can chain actions across multiple platforms, the effective blast radius expands from a single identity to the full set of systems the agent can reach. Governance must therefore shift from static inventory to continuous policy enforcement.

Practical implication: Treat AI agents as privileged non-human identities and constrain their tools, scopes, and runtime access continuously.

Threat narrative

Attacker objective: The attacker wants durable, quiet access that survives human-centric controls and opens a path into multiple connected systems.

1. Entry occurs when an attacker steals a service account password, API key, or OAuth token from a repository, integration, or endpoint.
2. Escalation follows when the compromised non-human identity already has broad or inherited permissions across connected SaaS applications.
3. Impact occurs when the attacker uses persistent, MFA-free access to move laterally, exfiltrate data, or extend access into downstream tenants.

Breaches seen in the wild

• Moltbook AI agent keys breach — Moltbook breach exposed 1.5M AI agent keys.
• Sisense breach — unauthorized GitLab access led to exfiltration of access tokens, API keys and certificates.

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

NHI Mgmt Group analysis

NHI governance is now an enterprise identity discipline, not a niche secrets problem. The article’s core pattern is that machine identities hold persistent access where human controls do not apply cleanly. That changes the operating model for IAM teams because every integration, token, and service account becomes part of the access perimeter. Practitioners should treat NHI governance as a standing part of identity architecture, not a bolt-on audit exercise.

Ephemeral access is not the same as low risk. A token or key may look temporary, but its effective exposure window can be long if refresh, rotation, and revocation are weak. That creates what we would call an identity blast radius problem, where the risk lies in how far one credential can travel across connected systems. The practical conclusion is that lifecycle control matters as much as initial issuance.

Shadow NHIs are the governance gap most teams still underestimate. Business users and automation platforms can create machine identities outside formal review, which means the security team may never see the trust relationship that was established. That is a structural weakness in SaaS-heavy environments, especially where third-party integrations are common. If you cannot enumerate the identity, you cannot govern the access.

Behavioral context must complement inventory. A static list of NHIs is necessary, but it does not tell you whether a credential is active, risky, or compromised. The article’s emphasis on normal-looking malicious activity reflects a broader NHI problem: the attack often appears legitimate after authentication. Teams need monitoring that understands expected machine behavior, not just login events.

Least privilege for NHIs must be measured by task scope, not by role habit. Many machine identities inherit permissions because they were easiest to configure, not because they were justified by the workflow. That is why overprivileged NHIs become durable footholds. Security leaders should use this as a trigger to recertify permissions by actual function and to retire standing access wherever possible.

From our research:

• 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface, according to Ultimate Guide to NHIs.
• 91.6% of secrets remain valid five days after the targeted organisation is notified, showing a critical gap in remediation procedures.
• Read 52 NHI Breaches Analysis for root-cause patterns across real incidents and remediation timelines.

What this signals

Ephemeral credential trust debt: organisations are accumulating short-lived machine credentials that behave like long-lived access when rotation and revocation are weak. The practical result is that NHI governance must move from one-time issuance review to continuous credential lifecycle management, especially in SaaS ecosystems where access paths multiply quickly.

With 96% of organisations storing secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools, the reader’s programme should assume that exposure is already distributed. That pushes teams toward detective controls, secrets discovery, and tighter developer workflow governance rather than relying on vault adoption alone.

The next governance step is to connect NHI controls to broader identity and AI risk programs, including the OWASP Agentic AI Top 10 and the NIST AI Risk Management Framework. For practitioners, that means treating AI agents, service accounts, and OAuth connections as one policy problem with different runtime forms.

For practitioners

• Inventory every non-human identity Map service accounts, API keys, OAuth apps, tokens, certificates, bots, and AI agents across SaaS, cloud, and CI/CD systems. Include shadow identities created outside IT so you can assign an owner and a business purpose.
• Classify trust relationships and blast radius Document which systems each NHI can reach, which permissions are inherited, and which downstream tenants are exposed through third-party integrations. Prioritise identities that bridge multiple SaaS platforms or hold admin-level scope.
• Enforce lifecycle controls on machine credentials Set expiry, rotation, and revocation workflows for API keys and refresh tokens. Tie those workflows to service ownership so dormant credentials do not survive project completion or employee departure.
• Monitor post-authentication behavior Look for unusual API volume, new data destinations, off-hours access, and changes in call sequence rather than relying only on login telemetry. Compromised NHIs often look valid at authentication time and abnormal only in what they do next.
• Limit AI agent scopes to task-scoped tools Give agents only the tools and data sources required for the job, then review those grants as the workflow changes. If an agent can chain actions across systems, constrain that chain before production use.

Key takeaways

• Non-human identities are not edge cases. They are the dominant identity surface in many modern environments and they require their own governance model.
• Persistent access, inherited permissions, and weak lifecycle controls are the main reasons NHIs create a larger practical attack surface than human accounts.
• The right response is continuous inventory, scoped access, rotation, revocation, and behavioral monitoring for every machine credential.

Key terms

• Non-Human Identity: A non-human identity is a credentialed entity that authenticates and acts without a person at the keyboard. It can be a service account, API key, OAuth token, certificate, bot, workload, or AI agent. The security challenge is that these identities often outlive the workflow they were created for and are hard to govern with human-centric controls.
• Service Account: A service account is a machine identity created to let software or jobs access systems automatically. It usually runs continuously, often with elevated permissions, and cannot use human authentication steps such as MFA. Because service accounts are frequently persistent and shared, they can become high-value targets when ownership and rotation are weak.
• OAuth Token: An OAuth token is a delegated credential that lets one application access another system on behalf of a user or organization. Access tokens are usually short-lived, but refresh tokens can extend access for months or years. Their risk comes from inherited trust, since stolen tokens can keep working even when passwords change.
• Shadow NHI: A shadow NHI is a machine identity created outside formal security governance, usually by a user approving an integration or automating a workflow without review. These identities are dangerous because they often remain invisible to security teams while still holding valid access to business systems and data.

Deepen your knowledge

NHI lifecycle control, secrets governance, and machine identity monitoring are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building controls for service accounts, tokens, and AI agents, it is worth exploring.

This post draws on content published by Obsidian Security: What Are Non-Human Identities? NHI Security Explained. Read the original.