Why traditional IAM breaks down for non-human identities

At a glance

What this is: This is a guide to non-human identities and the article’s central finding is that machine credentials now create a larger identity attack surface than human users.

Why it matters: IAM and NHI teams need to treat service accounts, tokens, and agents as governed identities because the same controls used for employees do not manage their lifecycle, privilege, or detection needs.

By the numbers:

• 25-50x in modern enterprises.
• 68% of IT security incidents now involve machine identities.
• 68% of organisations do not know how to fully address NHI risks.

👉 Read Obsidian Security's complete guide to non-human identities and NHI security

Context

Non-human identities are the machine-side credentials that let applications, services, tokens, certificates, bots, and AI agents authenticate without a person present. In practice, they create an identity layer that traditional IAM often does not govern well, because the lifecycle is faster, the volume is larger, and the activity pattern does not look like a human user’s.

The article frames the core problem correctly: NHI risk is no longer a side issue hidden inside engineering workflows. For IAM practitioners, the issue is whether access governance, monitoring, and offboarding can keep pace with service accounts, OAuth grants, and autonomous agents that now behave like operational infrastructure.

This is a typical starting point for enterprise NHI maturity. Most organisations discover the problem through inventory gaps, privileged integrations, or a breach notification, not through proactive governance.

Key questions

Q: How should security teams govern non-human identities at scale?

A: Security teams should govern non-human identities with the same discipline used for human access, but with machine-specific controls. That means continuous discovery, ownership, rotation, least privilege, and automated revocation. The key difference is speed: NHIs are created and used far faster than manual IAM processes can review, so governance must be lifecycle-driven and event-driven, not quarterly and reactive.

Q: Why do service accounts and API keys create more risk than many human accounts?

A: Service accounts and API keys create more risk because they are often long-lived, overprivileged, and invisible to human-centric controls. They do not use MFA, they do not trigger employee lifecycle events, and they often persist after the original purpose ends. When compromised, attackers can reuse legitimate trust instead of breaking authentication, which makes detection harder and blast radius larger.

Q: What is the difference between inventorying NHIs and governing NHIs?

A: Inventorying NHIs tells you what exists, while governing NHIs tells you who owns them, what they can access, how long they are valid, and how abuse will be detected. A spreadsheet can help with discovery, but it cannot enforce rotation, offboarding, or runtime monitoring. Governance begins when the identity has a lifecycle, a policy, and a response path.

Q: When should organisations prioritise NHI security over other identity work?

A: Organisations should prioritise NHI security when machine credentials are already spreading across SaaS, cloud, and AI workflows faster than access reviews can follow. If third-party integrations or service accounts can reach sensitive data, the risk is immediate. In that situation, NHI security is not a future programme. It is a prerequisite for trustworthy IAM.

Technical breakdown

Why NHIs bypass traditional IAM assumptions

Traditional IAM was built around people, not machine credentials. Human access is usually tied to HR events, interactive authentication, and behaviour that can be baselined by time, device, and location. NHIs break those assumptions because a service account can exist for years, an OAuth token can renew access without reauthentication, and an API key can be copied across environments. The result is a hidden identity layer where access may be valid long after the original purpose has disappeared. In agentic environments, the problem deepens because the identity can also take actions, not just authenticate.

Practical implication: Inventory every machine identity as a governed subject, not a technical artifact.

OAuth tokens, service accounts, and the problem of inherited trust

OAuth and service-account models create trust chains, not just credentials. A token often carries delegated permissions from one system into another, while a service account may inherit broad backend access so workflows keep running. That makes compromise especially dangerous: attackers do not need to break authentication if they can reuse a trusted token. Once inside, lateral movement can follow the same paths automation uses every day. In SaaS environments, the risk expands because one compromised integration can expose many downstream tenants and tools through legitimate connections.

Practical implication: Map delegated access paths and revoke any token or service account that exceeds its real business need.

Why behavioral detection matters more than static inventory

Static NHI inventories answer who exists, but not how access is being used. That matters because compromise often looks normal at the credential level. A valid token may suddenly access new data, call APIs at unusual volume, or operate from a location that does not fit the integration’s pattern. Behavioural detection adds context by comparing activity against expected use, toxic combinations, and unusual privilege chains. In practice, this is the only scalable way to separate legitimate automation from misuse when machine identities multiply faster than manual review can keep up.

Practical implication: Pair identity discovery with continuous behavioural monitoring and alert on access pattern drift.

Threat narrative

Attacker objective: The attacker’s objective is to turn legitimate machine trust into persistent access across connected systems and downstream environments.

1. Entry occurs through a valid but unmanaged machine credential such as an OAuth token, API key, or service account that was never properly offboarded.
2. Escalation follows when the attacker reuses delegated trust to access connected SaaS tools or backend systems with broader permissions than the original workflow required.
3. Impact is achieved through lateral movement across trusted integrations, allowing data access, persistence, or supply-chain reach without triggering human-focused controls.

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

Machine identity is now the dominant identity governance problem, not a niche exposure. The scale matters because NHIs outnumber humans by orders of magnitude, and their lifecycle is managed by engineering processes rather than identity processes. That combination creates a governance gap that conventional IAM programs cannot close with quarterly reviews alone. Practitioners should treat machine identity growth as an architectural risk, not an inventory inconvenience.

Ephemeral credential trust debt is the right concept for this category. Tokens, service accounts, and agent credentials often survive well beyond the task that created them, which means organisations accumulate hidden access obligations over time. The debt is not just stale credentials, but stale assumptions about what is still safe to trust. Teams should measure this debt explicitly and reduce it through lifecycle controls, not hope that visibility alone will fix it.

Behavioural trust must replace static trust for autonomous systems. When NHIs can authenticate continuously but also adapt their actions, the security question becomes whether behaviour still matches authorised purpose. That shifts the centre of gravity from initial authentication to runtime monitoring, privilege boundaries, and revocation speed. Practitioners should assume that validation at login is insufficient for machine identities that never stop operating.

Supply-chain exposure is now an identity issue as much as a software issue. Third-party integrations, vendor OAuth grants, and shared SaaS connections create an identity chain that can extend breach impact well beyond the first compromised system. The field needs to stop treating these as isolated credentials and start treating them as externally governed trust relationships. Practitioners should audit third-party NHIs with the same seriousness they apply to privileged internal accounts.

AI agents make the NHI problem visible, but not fundamentally new. Agentic systems increase urgency because they blend autonomy with execution authority, yet the underlying governance failures are familiar: excessive privilege, poor offboarding, and weak monitoring. The market will keep re-labelling the issue, but the control requirements remain grounded in least privilege, rotation, and continuous verification. Practitioners should build for autonomous behaviour now rather than waiting for a separate agent-specific program.

From our research:

• 68% of organisations do not know how to fully address NHI risks, according to Ultimate Guide to NHIs.
• Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them, which helps explain why machine trust lingers after business need ends.
• 52 NHI Breaches Analysis shows how weak lifecycle control repeatedly turns valid machine access into breach persistence.

What this signals

Ephemeral credential trust debt: the next governance problem is not just discovering machine identities, but reducing the amount of access that remains valid after the business reason has disappeared. When identities can be created and renewed faster than humans can review them, the programme needs lifecycle automation, not annual clean-up.

The operating model should shift toward continuous verification, with special scrutiny on delegated access through SaaS and AI workflows. That means pairing identity discovery with policy enforcement, behavioural signals, and rapid revocation paths so a compromised token does not become a standing bridge into production systems.

With 96% of organisations storing secrets outside secrets managers in vulnerable locations, per Ultimate Guide to NHIs, the problem is structural. Teams should expect the boundary between development, operations, and identity governance to keep blurring until machine identity control becomes a core security service.

For practitioners

• Implement continuous discovery for all non-human identities Build a current inventory of service accounts, tokens, certificates, and agent credentials across SaaS, cloud, CI/CD, and code repositories. Tie ownership to a named business or engineering team so stale identities do not remain anonymous.
• Shorten credential lifetime and enforce rotation by default Set rotation schedules for API keys, refresh tokens, and service credentials based on risk and use case, then remove exceptions that rely on manual renewal. Prioritise high-privilege and third-party identities first.
• Review delegated trust paths across SaaS integrations Identify which applications can reach customer data, admin functions, or downstream systems through OAuth grants and service accounts. Revoke unused scopes and isolate vendor access where inherited permissions create unnecessary blast radius.
• Add behavioural detection to identity monitoring Alert on unusual token use, new geographies, abnormal API volume, and access patterns that do not match the integration’s purpose. Static inventory is not enough when credentials are valid but misused.
• Apply offboarding to machine identities as a formal workflow When a project ends, a vendor is removed, or an application is retired, revoke the related secrets, tokens, certificates, and service accounts immediately. Treat machine offboarding as a control, not a cleanup task.

Key takeaways

• Non-human identities create a governance problem that traditional IAM was not designed to solve.
• The scale of machine identity exposure means stale credentials, delegated trust, and weak offboarding can become breach enablers quickly.
• Practitioners should move from static inventories to lifecycle control, behavioural detection, and rapid revocation for every machine credential.

Key terms

• Non-Human Identity: A non-human identity is a credentialed digital entity used by software, services, devices, or AI agents to authenticate and access systems without a person present. It can be a service account, API key, token, certificate, or workload identity. The governance challenge is that these identities are created and used at machine speed, often outside normal IAM workflows.
• OAuth Token: An OAuth token is a delegated access credential that allows one system to act on behalf of a user or application within defined permissions. In NHI security, tokens are risky because they can outlive the task that created them and can be reused if stolen, making them a common route for lateral movement and supply-chain abuse.
• Service Account: A service account is a non-human identity used by applications or backend processes to authenticate and perform tasks automatically. It often has no human owner in practice, which makes lifecycle control difficult. If permissions are broad or decommissioning is delayed, a service account can become a persistent access path for attackers.
• Behavioral Detection: Behavioral detection is the practice of identifying misuse by comparing a machine identity’s activity to its normal purpose, timing, volume, and access patterns. It is essential for NHI security because valid credentials can be abused without breaking authentication, so static inventory alone cannot tell the difference between legitimate automation and compromise.

Deepen your knowledge

Non-human identity lifecycle control is a core topic in our NHI Foundation Level course, the industry's only accredited NHI security programme. If your team is trying to bring service accounts, tokens, and agents under policy, this is a practical place to start.

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