The New Frontier: Non-Human Identities and AI Agents

Here is a number that should change how you think about identity: for every human identity in a typical enterprise, there are 45 non-human identities. Service accounts, API keys, OAuth tokens, certificates, bot accounts, CI/CD pipeline credentials, cloud workload identities, and now - AI agents.

A Fortune 500 company with 50,000 employees might have over two million non-human identities. Most of them are invisible to the IAM team. Most have no owner. Many have standing privileges that were granted once and never reviewed. Some have admin access to production systems and have not been rotated in years.

This is not a theoretical risk. In breach after breach, attackers exploit non-human identities because they are the path of least resistance. Service account credentials do not require MFA. API keys do not trigger behavioral analytics. Bot accounts do not go through access certifications.

And now, with the rise of AI agents that autonomously make decisions, take actions, and access resources, the problem is about to get dramatically more complex.

---

The Non-Human Identity Landscape

Non-human identities (NHIs) come in many forms, each with different management challenges:

NHI Type	Typical Count	Rotation Frequency	Common Risk	Management Tool
Service accounts	Hundreds to thousands	Rarely	Standing admin privileges	PAM (CyberArk)
API keys	Thousands	Varies (often never)	Leaked in code repos	Secrets manager (Vault)
OAuth client credentials	Hundreds	Token expiry only	Over-scoped permissions	IdP
SSH keys	Thousands	Rarely	Unknown/orphaned keys	Key management
Certificates (TLS/mTLS)	Tens of thousands	Annual (manual)	Certificate expiry outages	Venafi, Keyfactor
Cloud IAM roles	Hundreds	Never (static)	Over-permissioned	CIEM tools
CI/CD pipeline tokens	Hundreds	Varies	Access to production	Pipeline-native
Database credentials	Dozens to hundreds	Rarely	Shared/embedded passwords	Secrets manager
Bot/automation accounts	Dozens to hundreds	Rarely	No MFA, no review	Often unmanaged
AI agent identities	Emerging	Unknown	Autonomous actions	No standard yet

THE NHI ICEBERG
================

What IAM teams typically manage:
┌─────────────────────────────────┐
│   Human Identities (1x)        │  <-- Visible
│   ┌──────────────────────┐     │
│   │ SSO, MFA, Lifecycle  │     │
│   └──────────────────────┘     │
├─────────────────────────────────┤  ── Waterline ──
│                                 │
│   Non-Human Identities (45x)   │  <-- Mostly invisible
│                                 │
│   Service accounts              │
│   API keys                      │
│   OAuth tokens                  │
│   Certificates                  │
│   Cloud IAM roles               │
│   CI/CD credentials             │
│   SSH keys                      │
│   Database passwords            │
│   Bot accounts                  │
│   Webhook secrets               │
│   AI agent tokens               │
│   ??? (unknown unknowns)        │
│                                 │
└─────────────────────────────────┘

---

Why NHIs Are a Security Nightmare

Non-human identities present challenges that traditional IAM processes were never designed to handle:

No MFA. You cannot ask a service account to approve a push notification on its phone. Machine authentication relies on secrets (passwords, keys, certificates) or protocol-level identity (mTLS, SPIFFE).

No access reviews. Most access certification campaigns only cover human users. Service accounts are excluded because "nobody knows what they do and we are afraid to break something."

No offboarding. When the developer who created a service account leaves, the account stays. Nobody knows what it does, nobody knows what depends on it, and nobody wants to be the person who disables it and causes an outage.

Over-privileged by default. Developers creating service accounts typically request (and receive) far more permissions than needed because "we might need it later." Admin-level service accounts are shockingly common.

Secrets in code. Despite decades of warnings, API keys and credentials are still embedded in source code, configuration files, environment variables, and CI/CD pipelines. GitHub's secret scanning detects millions of leaked credentials annually.

---

Managing NHIs - The Emerging Playbook

The NHI management space is maturing rapidly. Here is the framework that leading organizations are adopting:

Step 1: Discovery and Inventory

You cannot manage what you cannot see. The first step is comprehensive discovery of all NHIs across your environment.

Discovery sources:

• Cloud provider IAM (AWS IAM, Azure Service Principals, GCP Service Accounts)
• Secrets managers (HashiCorp Vault, AWS Secrets Manager)
• Certificate authorities and PKI systems
• CI/CD platforms (GitHub Actions, GitLab CI, Jenkins)
• Active Directory service accounts
• API gateway logs
• Source code scanning for embedded secrets

Step 2: Ownership Assignment

Every NHI needs an owner - a human who is accountable for its existence and access. This is the hardest step because it requires investigating thousands of NHIs, many of which were created years ago by people who no longer work at the organization.

Step 3: Lifecycle Management

Apply JML principles to NHIs:

• Joiner: Service accounts should be provisioned through a request-and-approval workflow, not created ad hoc by developers
• Mover: When a project transitions teams, its NHIs should transition ownership
• Leaver: When a project is decommissioned, its NHIs should be deprovisioned

Step 4: Credential Hygiene

• Rotate secrets on a defined schedule (90 days is a common target for high-risk credentials)
• Use short-lived tokens wherever possible instead of long-lived API keys
• Implement mTLS for service-to-service communication
• Adopt workload identity standards (SPIFFE/SPIRE) to eliminate static secrets entirely

Step 5: Continuous Monitoring

• Monitor NHI behavior for anomalies (unusual access patterns, geographic anomalies, privilege escalation)
• Alert on unused NHIs (if a service account has not authenticated in 90 days, investigate and possibly disable)
• Include NHIs in access certification campaigns

---

AI Agents - The Identity Problem Nobody Has Solved

AI agents represent a fundamentally new category of identity. Unlike traditional service accounts that execute predefined operations, AI agents make autonomous decisions about which resources to access, which APIs to call, and which actions to take.

This creates identity challenges that the industry has not yet solved:

The Authorization Problem

When a human user accesses a system, their permissions are predefined by their role. When an AI agent accesses a system, its actions are determined at runtime by its reasoning engine. The agent might decide it needs to read a database, call an external API, send an email, and modify a file - all as part of fulfilling a single user request.

How do you scope permissions for an entity whose actions are not predetermined?

TRADITIONAL vs. AI AGENT AUTHORIZATION
========================================

Traditional Service Account:
  Predefined actions:
  ├── Read from Database A      [ALLOWED - configured]
  ├── Write to Database A       [ALLOWED - configured]
  └── Call API endpoint /data   [ALLOWED - configured]

  Action space is known and fixed.


AI Agent:
  Runtime decisions:
  ├── Read from Database A      [? - agent decided this]
  ├── Read from Database B      [? - agent decided this]
  ├── Call external API          [? - agent decided this]
  ├── Send email to customer    [? - agent decided this]
  ├── Create file on shared     [? - agent decided this]
  │   drive
  └── ??? (next action depends  [? - unpredictable]
      on results of previous)

  Action space is dynamic and emergent.

The Delegation Problem

When a human asks an AI agent to "check my calendar and schedule a meeting with the finance team," the agent needs to act on behalf of the human. This is a delegation problem - the agent needs access to the human's calendar, the finance team's availability, and the meeting scheduling system.

But should the agent have the same permissions as the human? If the human has access to confidential financial data, should their AI agent also have access - even if the current task does not require it? The principle of least privilege says no, but implementing per-task permission scoping for an autonomous agent is an unsolved problem.

The MCP and Tool Identity Challenge

The Model Context Protocol (MCP) and similar frameworks allow AI agents to use tools - APIs, databases, file systems, and external services. Each tool interaction is an identity event. But MCP does not currently have a robust identity layer.

When an AI agent calls an MCP tool, several identity questions arise:

• Who is the AI agent acting on behalf of?
• Is the agent authorized to use this specific tool?
• What permissions should the tool grant to the agent?
• How do you audit the agent's tool usage?
• If the agent chains multiple tools together, how do you trace the authorization through the chain?

---

Career Opportunities in NHI and AI Agent Identity

This is a greenfield career space. Here is what makes it exceptional:

Demand is exploding. Every enterprise is waking up to the NHI problem simultaneously. The market for NHI management tools has grown from virtually nothing in 2022 to hundreds of millions in venture funding.

Expertise is rare. Very few IAM professionals have deep NHI experience because the tooling and practices have only recently matured enough to create dedicated roles. If you build this expertise now, you are in a pool of hundreds, not thousands.

The AI agent identity problem is unsolved. This is not a space where you learn existing best practices - this is a space where you help create them. If you have strong opinions on how AI agents should authenticate and be authorized, you can contribute to standards bodies, publish research, and build your reputation.

Vendor landscape is wide open. Companies like Astrix Security, Oasis Security, Clutch Security, and Natoma are building NHI management platforms. The space will likely consolidate (expect CyberArk, SailPoint, or a major cloud provider to acquire one or more of these), but right now there are opportunities at startups, enterprises, and consulting firms.

Skills to Build

Skill Area	How to Build It	Time to Competency
Cloud IAM (AWS, Azure, GCP)	Hands-on in cloud environments	3-6 months
Secrets management (Vault)	HashiCorp tutorials + home lab	2-3 months
PKI and certificate management	Build a CA, manage certs	3-6 months
SPIFFE/SPIRE	Open-source labs	2-3 months
AI agent frameworks	Build agents with tool access	1-3 months
API security and OAuth 2.0	Build and secure APIs	3-6 months

The Next Decade of Identity

The ratio of non-human to human identities is not going to decrease. As AI agents proliferate, as IoT devices multiply, and as microservices architectures create more service-to-service communication, the NHI ratio could move from 45:1 to 100:1 or higher within the next five years.

The IAM professionals who understand this shift - who can manage identity at machine scale, who can design authorization frameworks for autonomous agents, who can build governance processes for entities that do not fit the JML model - will define the next generation of identity architecture.

For a deeper exploration of how zero trust principles apply to AI agent systems, see Zero Trust in the Age of AI: Why the Classic Model Isn't Enough Anymore and Zero Trust Authorization for Multi-Agent Systems.

This is the frontier of identity. The map is still being drawn, and the people drawing it will define careers for decades.