The Non-Human Identity Explosion

The 109:1 Ratio Nobody's Managing

Here's a number that should keep every CISO up at night. Palo Alto Networks' 2026 Identity Security Landscape, a survey of 2,930 security decision-makers, counted 109 machine identities for every human identity. The full report says 79 of those 109 are AI agent identities. A year earlier, CyberArk's 2025 edition put the ratio at 82 to 1 and attributed the growth to AI adoption and cloud-native development.

Non-human identities include service accounts, API keys, bot tokens, machine certificates, OAuth client credentials, CI/CD pipeline tokens, and now AI agent identities. They have quietly become the dominant identity type in every enterprise. Human identities get onboarded through HR, assigned to managers, and deactivated when people leave. Non-human identities are created casually, managed inconsistently, and forgotten routinely.

CyberArk's 2025 survey also expected AI to create more new identities with privileged and sensitive access than any other source that year. It found that 68% of organizations lacked identity security controls for AI.

Now add AI agents to the mix.

What Counts as a Non-Human Identity

Before we go further, let's map the landscape. Non-human identities aren't a single thing. They're a category that keeps expanding.

Non-Human Identity Taxonomy
============================

Service Accounts
  +-- Cloud IAM service accounts (AWS, GCP, Azure)
  +-- Database service accounts
  +-- Application service accounts (Active Directory)
  +-- Kubernetes service accounts

API Keys and Tokens
  +-- Developer API keys
  +-- Third-party integration tokens
  +-- Webhook signing secrets
  +-- CI/CD pipeline tokens
  +-- Container registry tokens

Machine Certificates
  +-- TLS/SSL certificates
  +-- mTLS client certificates
  +-- Code signing certificates
  +-- SSH keys

Bot and Automation Identities
  +-- RPA bot credentials
  +-- Chatbot service accounts
  +-- Monitoring agent credentials
  +-- Backup system credentials

AI Agent Identities  [THE NEW CATEGORY]
  +-- Coding assistant tokens
  +-- Autonomous agent credentials
  +-- Multi-agent system service accounts
  +-- Agent-to-agent delegation tokens
  +-- MCP server credentials

Each category has its own lifecycle, rotation requirements, and governance gaps. The newest category, AI agent identities, is growing fastest and is governed least.

Why This Matters More Than You Think

The scale of non-human identities isn't just an administrative headache. It's a fundamental security problem. Here's why.

The Attack Surface Math

Every non-human identity is a potential entry point. Human identities are protected by MFA, password policies, and security awareness training. Most non-human identities are protected by a string of characters stored somewhere.

Identity Type	Typical Protection	Typical Rotation	MFA Capable?
Human user	Password or passkey + MFA	On compromise, not on a timer (NIST SP 800-63B)	Yes
Service account	Static password	Rarely or never	No
API key	Key string	Varies widely	No
Bot token	OAuth token	At expiry	No
AI agent credential	Inherited or static	Rarely	No
Machine certificate	PKI certificate	Annually or less	N/A

The pattern is clear. Human identities get layered protections. Non-human identities get a secret and a prayer.

Leaked secrets also stay alive. GitGuardian's State of Secrets Sprawl 2026 retested credentials it had confirmed valid in 2022. More than 64% of them still worked in January 2026.

The Ownership Problem

When a developer creates a service account to connect an application to a database, who owns that identity? The developer? Their team? The application? The database team?

In practice, nobody owns it. The developer moves to another team or leaves the company. The service account keeps working. Nobody knows it exists until it breaks something or gets compromised.

This ownership vacuum is worse for AI agent identities. A platform team deploying an AI coding assistant creates service accounts, API tokens, and OAuth credentials for it, then shares them across the team. When the assistant is updated, old credentials may persist alongside new ones. When a team member leaves, the personal tokens they shared with the agent aren't revoked, because nobody knows the agent was using them.

The Traditional IAM Gap

Identity and access management systems were built for humans. That sounds obvious, but the implications are profound.

What IAM Was Designed For

Traditional IAM systems (Active Directory, Okta, Microsoft Entra ID, Ping Identity) were architected around assumptions that don't hold for non-human identities:

1. Identities map to people. Every identity has a name, an email, a department, a manager. Lifecycle events (hiring, transfer, termination) drive identity changes.

2. Authentication is interactive. Humans can type passwords, approve push notifications, use passkeys, and insert hardware keys.

3. Access patterns are predictable. Humans work business hours, from known locations, using a relatively stable set of applications.

4. Governance is periodic. Access reviews happen quarterly. Certifications happen annually. The pace of change is manageable.

None of these assumptions apply to machine identities. Service accounts don't have managers. API keys can't approve push notifications. AI agents work around the clock from cloud data centers. And they are created and changed far faster than any quarterly review cycle.

The Frankenstack That Results

Because traditional IAM handles non-human identities poorly, organizations end up with a patchwork of systems, each managing a different NHI type:

+---------------------------+
|    Human IAM (Okta,       |
|    Entra ID, etc.)        |
+---------------------------+
          |
          | (gap)
          |
+---------------------------+
|  Secrets Management       |
|  (Vault, AWS Secrets)     |  <-- Handles storage, not governance
+---------------------------+
          |
          | (gap)
          |
+---------------------------+
|  Cloud IAM                |
|  (AWS IAM, GCP IAM)       |  <-- Per-cloud, no unified view
+---------------------------+
          |
          | (gap)
          |
+---------------------------+
|  Certificate Management   |
|  (Venafi, cert-manager)   |  <-- Certificates only
+---------------------------+
          |
          | (gap: widest, but narrowing)
          |
+---------------------------+
|  AI Agent Identity        |
|  (Entra Agent ID, Okta    |  <-- New, rarely deployed
|   for AI Agents, others)  |
+---------------------------+

Each system handles a piece of the problem. None handles all of it. And the gaps between systems are where breaches happen.

The bottom layer is changing quickly. Microsoft Entra Agent ID is now generally available and registers agents as directory identities with sponsors and lifecycle governance. Okta, Auth0 and others have shipped agent identity products too. The AI Agent Security Map tracks which vendors publicly claim each agent identity building block. Products existing is not the same as products deployed, though. Most organizations still run agents on service accounts and personal tokens.

The AI Agent Identity Crisis

AI agents introduce identity challenges that are qualitatively different from traditional machine identities.

Agents Act on Behalf of Others

A service account runs a specific application. Its actions are predictable and attributable. An AI agent acts on behalf of a human, but with its own judgment about how to reach the human's goal. That creates a delegation problem most IAM deployments were not built to answer.

When an agent performs an action, you need to answer three questions:

• Who authorized this action? (the human who launched the agent)
• Who decided to take this specific approach? (the agent)
• Whose permissions should apply? (unclear)

Agents Compose Access

A traditional service account accesses one system with one credential. AI agents routinely chain across several systems in a single task. An agent asked to "deploy the latest build to staging" might need to:

1. Pull code from GitHub (Git credentials)
2. Build the application (CI/CD credentials)
3. Push a container image (registry credentials)
4. Update the Kubernetes deployment (cluster credentials)
5. Verify the deployment (monitoring credentials)
6. Update the ticket (project management credentials)

Each credential represents a different identity, system, and trust boundary. The agent isn't using one identity. It's composing six into a single workflow.

Agents Create Identities

Most concerning, AI agents can create new non-human identities as part of their work. An agent setting up a new microservice might create:

• A Kubernetes service account
• An AWS IAM role
• A database user
• An API key for inter-service communication
• A webhook token for notifications

These agent-created identities inherit no governance process. They exist because an AI decided they were needed. They have no owner, no expiration, and no review. They are shadow IT in the most literal sense, created in the shadows of autonomous agent activity.

The Governance Gap at a Glance

Here is how I assess the typical gap between human, machine and agent identity governance today. This is my judgment from working with security teams, not survey data.

Governance Capability	Human Identities	Non-Human Identities	AI Agent Identities
Complete inventory	Standard	Partial	Rare
Assigned owner	Standard	Partial	Rare
Regular access review	Standard	Rare	Almost never
Automated deprovisioning	Standard	Rare	Almost never
Anomaly detection	Common	Rare	Almost never
Compliance reporting	Standard	Rare	Almost never

Organizations have spent decades building governance processes for human identities. They've barely started for machine identities. For AI agent identities, most haven't started at all.

What's at Stake: The Breach Scenarios

Non-human identity compromise is already a leading attack path. The four scenarios below are illustrative, built from common failure patterns rather than specific incidents.

Scenario 1: The Forgotten Service Account

An AI agent is deployed for a three-week proof of concept. The POC ends and the team moves on, but the agent's service account keeps production database read access. Eighteen months later, the credentials appear in a data dump from a compromised third-party tool. An attacker uses them to exfiltrate customer records.

Scenario 2: The Over-Privileged Token

A developer creates a personal access token with broad permissions to use with an AI coding assistant. They share it with their team. The token has no expiration. Three team members leave over the next year. The token stays active, and people who have left still effectively hold access.

Scenario 3: The Agent-Created Backdoor

An AI operations agent setting up a new service creates an IAM role with admin permissions "for initial setup." It was supposed to reduce them afterwards, but the task timed out before that step. The admin role persists, undiscovered, until an attacker finds it.

Scenario 4: The Token Chain

An attacker compromises a low-privilege bot token used for Slack notifications. The bot can read channels where developers share debugging details, including temporary credentials and API endpoints. Those credentials lead to a CI/CD system that stores more tokens. The chain continues until the attacker reaches production, entirely through non-human identities.

The Compliance Blind Spot

Most compliance frameworks (SOC 2, ISO 27001, HIPAA) were written with human-centric identity management in mind. They require access reviews, role-based access control, and termination procedures. They don't spell out:

• How to run access reviews for machine identities that operate autonomously
• How to apply least privilege to agents that determine their access needs at runtime
• How to maintain audit trails when agents create other identities
• What a "termination procedure" means for an autonomous agent

That creates a blind spot. An organization can pass a SOC 2 audit while holding hundreds of unmanaged machine identities with excessive permissions. The auditor asks "do you have access reviews?" and the answer is "yes, for human users." The machine identities, which are the larger attack surface, go unreviewed.

Forward-thinking organizations extend their compliance controls to NHIs even when a framework doesn't explicitly require it. That means including service accounts in quarterly access reviews, documenting machine identity lifecycle procedures, and managing agent identities with the same rigor as human ones.

Building an NHI Management Strategy

Addressing the non-human identity explosion takes immediate tactical actions and longer-term strategic investment.

Immediate Actions (0-30 Days)

Inventory what you have. Use cloud provider tools (AWS IAM Access Analyzer, GCP Policy Analyzer, Microsoft Entra reports) to enumerate service accounts, API keys, and machine identities. Cross-reference with your secrets manager. Identify identities with no recent usage.

Find the high-risk NHIs. Prioritize identities that are over-privileged (admin access that isn't needed), dormant (unused for 90+ days), unowned (no identifiable human responsible), or externally usable (from outside your network).

Kill the obvious risks. Deactivate dormant identities. Rotate credentials that haven't been rotated in over a year. Remove admin permissions from service accounts that don't need them.

Short-Term Improvements (30-90 Days)

Establish ownership. Every non-human identity needs a human owner, responsible for its continued existence, its permissions, and its eventual decommissioning. Deactivate NHIs that still have no owner after 30 days.

Implement expiration policies. No non-human credential should be permanent. My starting benchmarks: API keys 90 days, service account passwords 60 days, agent tokens 24 hours or less. Tighten them as automation matures.

Deploy secrets detection. Use tools like Gitleaks, TruffleHog, or cloud-native secret scanning to find credentials that have leaked into repositories, chat systems, or documentation.

Strategic Investments (90+ Days)

Adopt workload identity federation. Replace long-lived credentials with short-lived, automatically rotated tokens wherever possible. GCP Workload Identity Federation, Azure managed identities, and AWS IAM roles (with IAM Roles Anywhere for workloads outside AWS) can eliminate whole classes of credential problems.

Build an NHI governance program. Govern non-human identities with the same rigor as human ones. Access reviews, certification, and compliance reporting should cover all identity types.

Plan for agent identity. The next chapter covers agent authentication in detail. Start now by defining how AI agent identities will be provisioned, scoped, monitored, and decommissioned in your environment.

The Bottom Line

The non-human identity explosion isn't a future problem. It's a current crisis that worsens as AI agents multiply. Organizations built identity management around humans and now face an environment where humans are the minority identity type. The minority is the only one being governed.

The answer isn't to stop deploying AI agents or machine identities. That ship has sailed. The answer is to extend governance, visibility, and control to every identity type, with particular urgency for the newest and fastest-growing one: autonomous AI agents.

Your identity infrastructure was built for a world of human workers. The world has changed. Your infrastructure needs to change with it.