Non-Human Identity for Agentic Systems

Every enterprise has an identity problem it hasn’t named

Your organization runs MFA on every human account. You have conditional access policies, identity governance reviews, automated provisioning. You spent years building that program.

Now count your service accounts. Your API keys. Your OAuth client credentials. Your workload identities. Your CI/CD tokens. Your agent credentials.

The ratio varies by industry, but the pattern is consistent: non-human identities outnumber human identities by an order of magnitude, and most organizations have no lifecycle management for them at all. No inventory. No ownership. No rotation policy. No deprovisioning process. Nothing.

Human IAM has MFA and behavior analytics. Machine IAM usually has a long-lived secret and a hope for the best.

This was already a serious problem before AI agents entered the picture. Now it is a critical one.

Non-human identity in the agentic context

A non-human identity is any identity used by software rather than a person to authenticate and access resources. Service accounts, API keys, OAuth client credentials, workload certificates, CI/CD tokens, bot accounts, machine-to-machine tokens. The OWASP Non-Human Identities Top 10 defines them as identities used to “identify, authenticate, and authorize different software entities to access secured resources.”¹

When an organization deploys an AI agent that reads email, queries databases, calls APIs, and takes actions on behalf of users, that agent needs credentials. It needs to authenticate. It needs authorization scopes. It has a lifecycle: provisioning, operation, rotation, deprovisioning. It is not a user. It is a non-human identity.

The problem is that most organizations treat agents as extensions of the human who deployed them, inheriting the human’s identity and permissions. This is the “service account running as admin” pattern from 2005, repackaged for 2026. It was wrong then. It is catastrophically wrong now, because agents operate autonomously, at machine speed, across multiple systems, and they make tool-call decisions without human review.

What counts as a non-human identity

The taxonomy is broader than most teams realize. Every one of these is an NHI, and every one of them needs lifecycle management.

graph TD
    A[Non-Human Identities] --> B[Service Accounts]
    A --> C[API Keys]
    A --> D[OAuth Client Credentials]
    A --> E[Workload Certificates]
    A --> F[CI/CD Tokens]
    A --> G[Bot Accounts]
    A --> H[AI Agent Identities]
    H --> I[Agent OAuth Tokens]
    H --> J[MCP Client Credentials]
    H --> K[Delegated User Tokens]
    H --> L[Tool-Call Scoped Tokens]
    H --> M[Inter-Agent Auth Chains]

AI agents are not a separate category from NHI. They are the newest, most complex, and least governed class within it. An agent credential has every property of a traditional NHI credential (it authenticates a non-human principal) plus additional properties that traditional NHI management was never designed for:

• Delegation chains. An agent acts on behalf of a human, who delegated authority. That delegation has scope, intent, and temporal bounds. Traditional service accounts don’t carry delegation metadata.
• Ephemeral lifecycles. Agents spin up, run a task, and terminate. Their credentials should do the same. Most NHI credentials are long-lived.
• Dynamic scoping. An agent’s required permissions change with each task. A static OAuth scope granted at provisioning time is either too broad (security risk) or too narrow (breaks the agent).
• Multi-system traversal. A single agent session may touch email, CRM, databases, code repositories, and external APIs. That is five different authorization boundaries crossed in one execution.

The identity governance gap

Here is the uncomfortable reality: most enterprises have mature human identity governance and no NHI governance at all.

The OWASP NHI Top 10 exists because the problem is severe enough to warrant its own risk framework, separate from the standard OWASP Top 10 and the LLM Top 10. The top three risks tell the story:¹

NHI1: Improper Offboarding. When an employee leaves, their human account gets deprovisioned. The service accounts they created, the API keys they generated, the OAuth applications they registered: those stay active. Nobody knows they exist. Nobody knows who owns them. The Okta breach in 2023 ran through exactly this pattern: a service account credential was saved to an employee’s personal Google account, the employee’s personal account was compromised, and 134 customer organizations were exposed.²

NHI2: Secret Leakage. Credentials end up in code repositories, configuration files, log outputs, chat messages, and documentation. GitGuardian reported finding over 12 million new secrets exposed in public GitHub repositories in a single year.

NHI3: Vulnerable Third-Party NHIs. The SolarWinds attack, the Codecov breach, the CircleCI incident, the tj-actions supply chain compromise: all of these ran through non-human identity credentials in third-party integrations.³

The next major breach pattern runs through NHI. Not because attackers got more sophisticated, but because defenders never built the governance layer.

What AI agents add to the NHI problem

Traditional NHI governance was already failing. AI agents make it worse in four specific ways.

NHI lifecycle management for agents

Every identity has a lifecycle: creation, use, maintenance, and retirement. Human identity lifecycle management is a solved problem with mature tooling. NHI lifecycle management is where most organizations have nothing.

graph LR
    A[Discovery] --> B[Provisioning]
    B --> C[Scoping]
    C --> D[Operation]
    D --> E[Monitoring]
    E --> F[Rotation]
    F --> G[Deprovisioning]
    G --> A
    E -->|Anomaly| H[Incident Response]

Discovery. You cannot govern what you cannot see. Most organizations do not have an inventory of their NHIs. The first step is discovery: scanning environments for service accounts, API keys, OAuth applications, workload identities, and agent credentials. If you do not know what you have, nothing else matters.

Provisioning. Every agent credential should be provisioned through a governed process with an identified owner, a defined scope, and an expiration date. “The developer created an API key and put it in the environment variable” is not a provisioning process. It is a future incident.

Scoping. Least privilege is not optional for agent credentials. An agent that needs to read email should not have a credential that can also delete email. Static OAuth scopes are a blunt instrument here. Rich Authorization Requests (RFC 9396) and transaction tokens that carry context through delegation chains are the direction the standards are moving.⁶

Operation and Monitoring. Agent credentials in use should generate telemetry: what was accessed, when, from where, and what action was taken. Behavioral baselines for NHI activity are the equivalent of UEBA for human identities. An API key that suddenly starts making calls it has never made before is the same signal as a human account logging in from an unusual location.

Rotation. Credentials expire. Secrets rotate. Certificates renew. This should be automatic and non-disruptive. SPIFFE and SPIRE provide exactly this for workload identities: short-lived, automatically rotated X.509 certificates with no stored secrets.⁷ The IETF WIMSE working group is formalizing this pattern for broader adoption.

Deprovisioning. When an agent is retired, its credentials must be revoked immediately. Not “marked inactive.” Revoked. Every OAuth token, every API key, every certificate, every delegated permission. The Okta breach happened because a service account was not deprovisioned when the employee who created it moved on. This is the most common NHI failure and the easiest to prevent.

A practical framework for NHI governance

This is not a maturity model. It is a checklist. If you cannot check every box, you have a governance gap that will eventually become an incident.

Pillar 1: Inventory

Maintain a complete, continuously updated inventory of all non-human identities. Every service account, API key, OAuth client, workload certificate, and agent credential has an entry. Each entry has an owner, a creation date, a last-used date, a purpose, and an expiration. If you cannot produce this inventory on demand, you are not ready for agentic AI.

Pillar 2: Ownership

Every NHI has exactly one human owner. Not a team. Not a department. A named person who is accountable for that credential’s lifecycle. When that person leaves the organization, ownership transfers explicitly. The OWASP NHI Top 10’s number one risk, improper offboarding, exists because ownership was never assigned in the first place.

Pillar 3: Least privilege and dynamic scoping

Agent credentials should be scoped to the minimum permissions required for each task, not for the agent’s entire range of possible tasks. Static broad scopes are the NHI equivalent of giving every employee admin access. Use short-lived, task-scoped tokens. Use Rich Authorization Requests to specify what the credential is permitted to do, not just which API it can call.

Pillar 4: Credential hygiene

No long-lived secrets. Period. Use certificates (SPIFFE/SPIRE), use managed identities, use workload identity federation. If you must use secrets, rotate them automatically on a schedule shorter than your mean time to detect a compromise. Secrets stored in code repositories, environment variables without encryption, or configuration files are breaches waiting to happen.

Pillar 5: Monitoring and anomaly detection

Build behavioral baselines for NHI activity. Alert on deviations. An agent credential that starts accessing resources outside its normal pattern is the same signal as a compromised user account. The tooling gap here is real: most UEBA products are designed for human behavior patterns. NHI-specific monitoring is an emerging market, and the AI Defense Matrix catalogs what exists today.⁸

Pillar 6: Deprovisioning automation

When a project ends, when an employee leaves, when an agent is retired, all associated NHI credentials must be automatically revoked. Not manually. Not “next quarter during the access review.” Automatically, at the trigger event. Wire the deprovisioning to the event that requires it, or it will not happen.

Implications for Zero Trust

Zero trust architecture, as defined by NIST SP 800-207, is built on a simple principle: never trust, always verify. Verify the identity, verify the device, verify the context, verify continuously.⁹

The problem: the “verify the identity” step was designed for human identities. The device posture check assumes a device with an endpoint agent. The context check assumes a human session with location and behavior patterns. The continuous verification assumes a persistent session that can be re-evaluated.

AI agents break every one of these assumptions.

graph TD
    A[Zero Trust Policy Engine] --> B{Identity Verified?}
    B -->|Human| C[MFA + SSO + UEBA]
    B -->|Agent NHI| D[??? ]
    A --> E{Device Verified?}
    E -->|Human| F[EDR + Posture Check]
    E -->|Agent NHI| G[No device to check]
    A --> H{Context Verified?}
    H -->|Human| I[Location + Time + Risk Score]
    H -->|Agent NHI| J[No location. Ephemeral session.]
    A --> K{Continuous Verification?}
    K -->|Human| L[Session re-evaluation]
    K -->|Agent NHI| M[Token expires or it doesn't]

Zero trust fails at the workload layer because identity governance was not designed for ephemeral infrastructure. You cannot enforce least privilege continuously on a workload that spins up, executes, and disappears.

NIST SP 800-207A begins to address this by explicitly naming SPIFFE as a workload identity mechanism for cloud-native zero trust.¹⁰ The IETF AIMS draft proposes a composable agent identity stack: WIMSE/SPIFFE for workload identity at the transport layer, OAuth 2.0 for authorization at the application layer, and OpenID Shared Signals for cross-system event propagation.¹¹ These are the right building blocks. They are drafts, not deployed standards.

For practitioners building today, the practical path is:

1. Use SPIFFE/SPIRE for agent workload identity. Attestation-based, short-lived, automatically rotated. No stored secrets. The CNCF graduated project with production adoption at scale.

2. Use OAuth 2.0 with token exchange (RFC 8693) for delegation. When an agent acts on behalf of a user, the delegation is explicit, scoped, and auditable. The agent holds a derived token with narrower scope than the user’s original token.

3. Use DPoP (RFC 9449) for token binding. Sender-constrained tokens that are useless if stolen. The token is bound to a cryptographic key held by the agent, not just to a bearer string.

4. Build agent-specific verification policies. Do not reuse human conditional access policies for agent identities. Agent verification checks should include: credential age, scope alignment with declared intent, behavioral baseline deviation, and delegation chain integrity.

5. Treat agent identity as a first-class asset. The AI Defense Matrix includes “AI Agent Identities” as a dedicated asset row because defending agent identities requires AI-specific controls that generic security approaches do not cover.⁸

Start here

You do not need to solve the entire NHI governance problem in one sprint. But you do need to start, and the starting point is not a technology purchase.

The standards landscape in 2026

The NHI governance space is moving fast. For practitioners who need to track the standards and make informed architecture decisions, here is what exists today and where it is heading.

The convergence is clear: agent identity is being treated as a first-class problem by standards bodies, cloud providers, and the security research community simultaneously. The practitioners who build governance now, rather than waiting for the standards to finalize, will be years ahead of the organizations that wait.

The NHI governance gap is not new. It has been growing for a decade as microservices, APIs, CI/CD pipelines, and cloud-native architectures multiplied non-human credentials faster than governance could keep pace. AI agents are the forcing function. They make the gap visible because they are autonomous, they are powerful, and when they fail, they fail fast and at scale.

The organizations that govern their non-human identities the same way they govern their human ones will be prepared for agentic AI. The organizations that don’t will learn the lesson the hard way, through an incident report.

The control point for AI agent security is not the prompt. It is the identity.