Non-Human Identities (NHI): The Hidden Security Crisis Powering AI Agent Attacks in 2026

The identity crisis nobody saw coming

In 2024, a security team at a Fortune 500 bank audited their identity infrastructure expecting around 50,000 human user accounts. They found 4.2 million non-human identities instead: service accounts, API keys, OAuth tokens, certificates, bot credentials. Most were unmanaged. Many had excessive privileges. Thousands were completely abandoned.

This isn't an anomaly. It's what most large organizations look like when they actually check.

NHIs now outnumber human identities in enterprise environments 40:1 to 100:1, with some hyper-automated organizations hitting 500:1. AI agents are accelerating this faster than existing IAM tools were built to handle.

Gartner named "Identity and Access Management Adapts to AI Agents" one of its top six cybersecurity trends for 2026. The World Economic Forum called NHIs "agentic AI's new frontier of cybersecurity risk." Most organizations still manage them like it's 2019: spreadsheets, manual rotation schedules, shared API keys that nobody ever expires.

68% of IT security incidents now involve machine identities. Half of enterprises have already had a breach tied to unmanaged NHIs.

What a non-human identity actually is

A non-human identity is any credential, token, or secret that lets a software system, automated process, or AI agent authenticate and access resources, no human directly involved in the transaction.

AI agent identities are driving the 2026 problem. Every time you deploy an AI agent: a coding assistant, a support bot, an autonomous data pipeline: that agent needs credentials to hit APIs, databases, communication tools, cloud services. A single AI workflow can mint dozens of new NHIs in an afternoon. In most organizations, those credentials are created once, never rotated, and owned by nobody.

The 2026 NHI Reality Report puts the average enterprise at over 250,000 NHIs across cloud environments. 71% haven't been rotated within recommended timeframes. 97% carry more access than their function requires. Only 15% of organizations feel confident they can actually prevent NHI-based attacks.

Why attackers go after NHIs first

The main thing about compromised NHIs is that they don't tell anyone. A suspicious login from a human account might trigger a password reset or an IT ticket. An API key just keeps working. The average dwell time after an NHI breach is over 200 days: more than three times the average for compromised human accounts.

On top of that, they come pre-loaded with too much access. Developers grant broad permissions when creating service accounts because narrowing scope takes time they don't have. The OWASP NHI Top 10 lists excessive permissions as the most prevalent NHI risk. An API key with read/write access to cloud storage is a skeleton key, not a service credential.

The blast radius when one goes wrong can be enormous. In the 2025 Salesloft-Drift incident, attackers compromised OAuth tokens connecting multiple SaaS platforms and reached hundreds of downstream customer environments through a single credential: roughly 10x the impact of a typical human account breach, because that one NHI was trusted by many interconnected systems.

Most NHI breaches don't get caught from the inside. Only 21% of executives report complete visibility into agent permissions, tool usage, or data access patterns. Most incidents surface through external reports or accidents, not internal detection.

And NHIs don't expire on their own. API keys and service account passwords often survive employee departures, product pivots, and infrastructure migrations for years.

The five OWASP NHI risks worth acting on

OWASP published a Non-Human Identities Top 10 framework in 2025, recognizing that NHI security doesn't fit neatly into existing application security or human IAM processes. Here are the five that matter most.

1. Improper offboarding

When a service is deprecated, an employee leaves, or a vendor contract ends, the NHIs tied to those entities rarely get cleaned up. Zombie credentials keep their access long after they serve any purpose.

Attackers hunt for them by enumerating endpoints, scanning certificate transparency logs, and combing code repositories for abandoned keys.

What to do:

• Wire NHI deprovisioning into HR offboarding and vendor management as an automated step, not a task someone might remember
• Set hard expiry dates at creation time, no NHI should exist without one
• Run a monthly report on NHIs with no activity in 30 days
• Assign every NHI a named human owner; if that person leaves, the NHI gets flagged automatically

2. Secret leakage

Credentials hardcoded in source code, committed to version control, baked into container images, or sitting in CI/CD environment variables are consistently exploited. AI coding assistants have made this worse: they generate placeholder credentials that developers swap with real values, often without a scanning gate in place.

What to do:

• Run pre-commit secret scanning on every developer workstation and CI/CD pipeline; detect-secrets, Trufflehog, and GitGuardian can block credential commits before they hit the repository
• Rotate any credential that may have touched a repo, even a private one
• Don't store secrets in environment variables for production; use a vault
• Make secret scanning part of the code review checklist, not something optional

This .pre-commit-config.yaml gets you scanning in under five minutes:

# .pre-commit-config.yaml - add to repo root, then run: pre-commit install
repos:
 - repo: https://github.com/trufflesecurity/trufflehog
    rev: v3.88.0
    hooks:
     - id: trufflehog
        name: TruffleHog secret scan
        entry: trufflehog git file://. --since-commit HEAD --fail
        language: system
        pass_filenames: false
 - repo: https://github.com/Yelp/detect-secrets
    rev: v1.5.0
    hooks:
     - id: detect-secrets
        args: ['--baseline', '.secrets.baseline']

3. Excessive permissions

97% of NHIs carry more access than they need. That's the default when permissions get set once and never revisited. Unlike human accounts, NHI permissions almost never appear in quarterly access reviews.

The fix is least privilege by design: every NHI should have access to the minimum set of resources for its actual function, based on usage data, not what a developer guessed it might need someday.

What to do:

• Pull 90-day usage logs for all NHIs, compare actual permissions used against what's granted, and revoke the rest
• Require explicit sign-off for any NHI with admin or wildcard scopes
• Include NHI permissions in your quarterly access review alongside human accounts
• Use cloud-provider tools (AWS Access Analyzer, Azure Access Reviews) to flag NHIs with unused permissions

AWS Access Analyzer makes it straightforward to generate a least-privilege policy from actual usage:

# Generate a report of services accessed by a role in the last 90 days
aws iam generate-service-last-accessed-details   --arn arn:aws:iam::123456789012:role/MyAgentRole

# List services that were NEVER used - safe to remove from the policy
aws iam get-service-last-accessed-details   --job-id <job-id>   --query "ServicesLastAccessed[?TotalAuthenticatedEntities==`0`].ServiceName"

Any service with zero authenticated entities in 90 days can be removed from the role's policy with no operational impact.

4. Third-party NHI risks

Every SaaS integration, vendor connection, and OAuth app you authorize creates NHIs you don't control. They run under your trust, with your data, governed by someone else's security program.

The February 2026 Moltbook breach illustrated this: attackers hit a third-party integration on an AI agent platform, then pivoted to client environments across the whole platform through the trusted NHIs that integration held.

What to do:

• Keep a complete inventory of all third-party NHIs and OAuth authorizations: that means auditing your SaaS catalog, not just your own infrastructure
• Narrow the scope of third-party OAuth grants; most are broader than the vendor actually needs
• Review all third-party NHI authorizations every 90 days and revoke what you can't justify
• Feed third-party NHI activity into your SIEM; unusual access patterns from vendor integrations often show up before the vendor admits anything is wrong

5. Insecure authentication methods

Most NHIs still authenticate with static, long-lived credentials: API keys that don't rotate, passwords in config files, certificates with multi-year lifetimes. Workload identity standards like OIDC, short-lived tokens, and certificate-bound access cut the attack surface considerably, but they take real effort to implement.

What to do:

• Start by eliminating static API keys in cloud environments; AWS, Azure, and GCP all support workload identity federation, which removes the need for long-lived keys entirely
• Set a credential lifetime policy: API keys expire in 90 days, service account passwords rotate every 30, certificates renew automatically
• Use JIT access for AI agents: issue credentials for a specific task and revoke them when it's done, rather than granting standing access
• Build break-glass procedures so a compromised agent's credentials can be revoked in minutes

JIT vs. standing access

Moving from standing access to just-in-time access is one of the highest-impact changes you can make for AI agent NHIs.

JIT access requires a vault that can issue dynamic credentials: HashiCorp Vault, AWS Secrets Manager with rotation, or Azure Key Vault all work. A compromised agent with JIT credentials can't do much once its task-scoped token expires. On Microsoft's stack, [Conditional Access for workload identities](/blog/conditional-access-for-workload-identities-entra-id) extends the same risk-based controls used for human sign-ins to these machine credentials.

NHI governance maturity model

Most organizations are at Level 1. Level 3 is where risk becomes manageable when you're deploying AI at scale.

Getting from Level 1 to Level 2 is the priority for most organizations. It needs three things: a complete NHI inventory, automated rotation, and NHI permissions added to your existing access review process.

Where to start

This week: get visibility

1. Run a discovery scan across cloud environments and CI/CD pipelines; Entro, Clutch, or your cloud provider's IAM analysis tools can help build the inventory
2. Flag every credential with no expiry date: those are your highest priority
3. List every AI agent deployment, document what credentials it uses, who created them, and whether there's a named owner

This month: shrink the exposure

1. Stand up a secrets management platform if you don't have one (HashiCorp Vault, AWS Secrets Manager, and Azure Key Vault are all workable starting points)
2. Get pre-commit secret scanning running across all developer repositories
3. Set an NHI ownership policy: every NHI needs a named human owner on record
4. Review and cut permissions on your 50 highest-privilege NHIs using actual 90-day usage data

This quarter: build the foundation

1. Automate credential rotation for all NHIs, starting with cloud service accounts and CI/CD credentials: those have the largest blast radius
2. Build behavioral baselines for AI agent identities and alert on anything anomalous
3. Wire NHI offboarding into HR and vendor management so credentials are revoked automatically when people leave or contracts end
4. Define a JIT access model for new AI agent deployments going forward

The governance gap

The habits that created shadow IT in the 2010s: move fast, create credentials for immediate needs, figure out lifecycle management later: are producing shadow NHIs at a scale that wasn't possible before. Every autonomous AI workflow, every new integration, every [MCP server connection](/blog/mcp-server-security-guide-2026) adds to the footprint. NHIs don't have offboarding interviews or IT-managed device wipes. They sit there until someone finds them.

Gartner projects that by 2027, organizations without formal NHI governance will see three times the identity-related breach rate of those that have it. For organizations running AI agents at scale, that's not an abstract risk.

The OWASP NHI Top 10, Gartner's IAM guidance, and a growing market of NHI management platforms give security teams a usable path. The practical starting point is the same as it is for most security problems: you need to know what you have before you can do anything about it.

Further Reading

The following reports and frameworks were used as the basis for this article:

• [Gartner: Top Cybersecurity Trends for 2026](https://www.gartner.com/en/newsroom/press-releases/2026-02-05-gartner-identifies-the-top-cybersecurity-trends-for-2026) - Gartner's official February 2026 press release naming IAM for AI agents as a top trend
• [OWASP Non-Human Identities Top 10](https://owasp.org/www-project-non-human-identities-top-10/) - The OWASP framework for NHI security risks
• [AI Agents Are Creating an Identity Security Crisis in 2026](https://www.iansresearch.com/resources/all-blogs/post/security-blog/2026/02/24/ai-agents-are-creating-an-identity-security-crisis-in-2026) - IANS Research analysis
• [Non-Human Identities: Agentic AI's New Frontier of Cybersecurity Risk](https://www.weforum.org/stories/2025/10/non-human-identities-ai-cybersecurity/) - World Economic Forum
• [AI Agents: The Next Wave Identity Dark Matter](https://thehackernews.com/2026/03/ai-agents-next-wave-identity-dark.html) - The Hacker News, March 2026
• [2026 NHI Reality Report](https://cyberstrategyinstitute.com/2026-nhi-reality-report/) - Cyber Strategy Institute
• [Why Non-Human Identities Are Your Biggest Security Blind Spot in 2026](https://www.csoonline.com/article/4125156/why-non-human-identities-are-your-biggest-security-blind-spot-in-2026.html) - CSO Online
• [The State of Non-Human Identity and AI Security](https://cloudsecurityalliance.org/artifacts/state-of-nhi-and-ai-security-survey-report) - Cloud Security Alliance

Frequently Asked Questions

What is a non-human identity (NHI) and how is it different from a human identity?

A non-human identity is any identity that authenticates to systems or services without a human actively logging in: service accounts, API keys, OAuth tokens, SSH keys, deployment pipeline credentials, and AI agent credentials. Unlike human identities that are tied to an employee and managed through HR-driven offboarding, NHIs are created programmatically, often by developers or automated systems, without a standard lifecycle management process. They frequently have no expiry date, no named owner, and persist long after the workload that created them is decommissioned. In large enterprises, NHIs outnumber human identities by 40 to 100 to one.

Why are AI agents creating a new NHI security crisis?

Each AI agent deployment mints its own set of credentials: API keys to call AI providers, OAuth tokens for the services the agent integrates with, and access keys for storage or databases it reads from. Unlike traditional service accounts that are created once for a specific integration, AI agents can be spawned dynamically, can create sub-agents with their own credentials, and often operate with broader permissions than required because scoping them correctly takes time developers do not budget for. The combination of rapid proliferation, broad permissions, and lack of governance tooling makes AI agent identities the fastest-growing NHI attack surface in 2026.

What is the OWASP NHI Top 10 and which risks are most commonly exploited?

The OWASP Non-Human Identities Top 10 is a community framework listing the most critical security risks for machine credentials and service identities. The risks most commonly exploited in incidents are: NHI-01 (improper offboarding: credentials that remain active after the workload is retired), NHI-02 (secret leakage in public repositories: API keys committed to GitHub), NHI-03 (overprivileged NHIs: service accounts with far more permissions than needed), and NHI-06 (third-party NHI exposure: credentials given to vendors or SaaS tools that retain them without your knowledge). The common thread is that NHIs lack the governance controls applied to human identities.

How do you build a NHI inventory when credentials are spread across multiple cloud accounts and tools?

Start with your secrets management platform if you have one: HashiCorp Vault, AWS Secrets Manager, or Azure Key Vault gives you a partial inventory. Supplement with IAM console exports from each cloud provider listing all service accounts, roles, and access keys. Run a secrets discovery scan across all developer repositories using tools like Trufflehog or GitHub's secret scanning to find credentials stored outside the secrets manager. Scan CI/CD pipeline variable stores. Specialized NHI management platforms (Entro, Clutch, Aembit) automate discovery across all these sources and build a unified inventory with ownership and last-used metadata. Plan for the inventory to be incomplete initially and improve it iteratively.

What is just-in-time access for NHIs and how does it reduce risk compared to long-lived credentials?

Just-in-time (JIT) access for NHIs means issuing short-lived, task-scoped credentials at the moment they are needed and automatically revoking them when the task completes, rather than providing a permanent API key or service account password. For example, a CI/CD pipeline using JIT access requests a short-lived IAM role token with deploy permissions when a deployment job starts, and the token expires automatically after 15 minutes. If that token is stolen from a log or environment variable, the attacker has a 15-minute window rather than an indefinite one. HashiCorp Vault's dynamic secrets, AWS IAM roles with short session durations, and Azure Managed Identity all support JIT access patterns for different use cases.