Non-Human Identity for AI Agents

AI Agent Identity AI Agent Authentication Non-Human Identity (NHI) Machine Identity

AI Agent Identity: A Buyer’s Guide to Non-Human Identity

Every agent you deploy acts on something. This guide is the buyer’s view of what gives an agent an identity of its own instead of a borrowed one — how agents authenticate, how a pass is issued, scoped, expired, revoked and attested, and what has to be on the record for an auditor to reconstruct who acted.

By John Byron Hanby IV

CEO & Founder, Iternal Technologies • Published September 2026 • 20 min read

See How AgentAuth Issues Agent Credentials

What is AI agent identity?

AI agent identity is the distinct, machine-owned identity an AI agent authenticates with — its own principal, not a borrowed human login. It makes an agent’s actions attributable, scopeable and revocable on their own, and it is the control the non-human identity (NHI) problem turns on as agents outnumber employees.

The practical test: if an agent misbehaves at 2 a.m., can you name the agent, the person or system it was acting for, exactly what it was allowed to touch, and when that permission ended — from a record, without asking an engineer to reconstruct it? That question is what the rest of this guide answers.

The scale of the problem

109:1

Machine identities per human across enterprise environments (Palo Alto Networks, 2026)

+85%

Projected growth in AI agents over the next 12 months (Palo Alto Networks, 2026)

Non-human identity risks catalogued in the OWASP NHI Top 10 (2025)

40%+

Agentic AI projects Gartner expects to be canceled by end of 2027 (cost, unclear value or inadequate risk controls)

Machine-identity ratios and agent growth per the Palo Alto Networks 2026 Identity Security Landscape; risk taxonomy per the OWASP Non-Human Identities Top 10 (2025); project-cancellation forecast per Gartner.

On this page

What AI agent identity is
Identity vs. credential
Authentication vs. authorization
The credential lifecycle
The standards landscape
What to log for the auditor
Working with your identity systems
Questions to ask before you buy
How Iternal implements it
Frequently asked questions

What AI Agent Identity Is — and Why a Borrowed Login Is Not One

An AI agent is a non-human identity: a digital principal that authenticates and acts with nobody at the keyboard. Give it an identity of its own and every downstream control becomes possible — scope it, expire it, revoke it, review it, attribute its actions. Skip that step and the agent runs on something never designed to be delegated: a developer’s session, a shared service account, or an API key pasted into an environment variable two quarters ago.

Scale turns that design preference into a governance problem. Enterprises now run roughly 109 machine identities for every human across their environments, and agents are the fastest-growing class of them — Palo Alto Networks’ 2026 report projects 85% growth in AI agents over the following twelve months. Identity programs built for a workforce of thousands are being asked to govern a population that never logs in, never sees a second factor and never appears in an access review.

The three things that break when an agent uses a human’s login

Permissions stop matching the work

A human account is sized for a person’s whole job; an agent needs one verb on one resource for ten minutes. Reuse the account and the agent inherits everything the person could ever do — OWASP NHI5, Overprivileged NHI.

Attribution collapses

The log records the human or the shared account, so no query separates what the person did from what the agent did for them. OWASP calls this NHI10, Human Use of NHI; it turns an incident review into archaeology.

Offboarding misses it

Joiner-mover-leaver processes retire people. When the person leaves or the project ends, the agent that borrowed their credential keeps running — OWASP NHI1, Improper Offboarding, and why retired agents become quiet backdoors.

Those three failures compose into the classic confused deputy: a component with more authority than the request deserves, acting on instructions it cannot fully vet. If the instruction reaching your agent can come from a document, a web page or another agent, the only durable limit on the damage is what that agent’s identity was allowed to do in the first place. Gartner expects more than 40% of agentic AI projects to be canceled by the end of 2027, inadequate risk controls among the named causes (Source: Gartner).

The controls that follow — identity per agent, least privilege, short-lived credentials — sit inside a wider frame covering injection, tool scoping, runtime containment and audit. For that frame, see the AI Agent Security Checklist, section 6, which maps these identity controls to the OWASP NHI Top 10 alongside nine other domains. This guide goes deeper on one of them.

Identity vs. Credential: The Distinction That Decides the Architecture

Most agent-identity conversations go wrong in the first ten minutes because the two words get used interchangeably. They are not the same object and they do not share a lifetime; conflating them is what produces an API key that has been valid since the pilot. An identity is a registered principal. A credential is a short-lived proof that a request comes from it, issued fresh and thrown away.

Agent identity compared with agent credential, across seven dimensions
Dimension	Agent identity	Agent credential
What it answers	“Which agent is this, and who owns it?”	“May this request proceed, right now?”
Lifetime	Months to years — as long as the agent exists	Minutes to an hour — ideally one task
How many	One per agent	Thousands over the identity’s life
Created by	Registration: a named owner, a purpose, a review date	Issuance: an authenticated request against that identity
What changes	Ownership, purpose, tier of autonomy, status	Scope, audience and expiry — narrower on each hand-down
Revocation means	The agent is decommissioned; nothing new is issued	One pass stops working; the agent keeps operating
Failure mode	A shadow agent: no owner, no registry entry, no review	A standing secret: long-lived, over-scoped, widely copied

Read the last row twice, because it is where most programs sit today. A standing secret is a credential problem you can fix in a sprint. A shadow agent is an identity problem, and you cannot fix what you have no record of — which is why Microsoft’s Agent 365 gives ownerless agents a view of their own in the admin center, alongside an Agents-at-risk card that aggregates high-severity signals from Microsoft Entra and Defender.

The buyer’s consequence: a registry and an issuer are two different purchases, and you need both. The registry answers which agents exist, who owns each and when its authority is next reviewed. The issuer answers whether this request gets a pass, and how narrow. A tool that does only the first gives you an inventory of ungoverned agents; one that does only the second issues excellent credentials to principals nobody can account for.

Authentication vs. Authorization for AI Agents

Authentication establishes who is calling; authorization decides what that caller may do. Human systems blur the two because a person authenticates once in the morning and carries a session all day. Agents invert that. They authenticate constantly, machine to machine, with no browser and no second factor, and each authenticated moment should buy the smallest possible amount of authority.

Agent authentication compared with agent authorization
Dimension	Authentication (AuthN)	Authorization (AuthZ)
The question	Is this agent who it claims to be?	Is this agent allowed to do this, here, now?
Evaluated	Once per connection, then reauthenticated regularly	On every request, against the current context
Evidence used	A cryptographically verifiable credential bound to the agent	Scope claims, resource attributes, environment, human approval
Model to aim for	Short-lived, holder-bound credentials; no shared secrets	Attribute-based access control with capability-style scopes, not broad roles
Default posture	Fail closed — an unverifiable holder gets nothing	Default deny with explicit grants
What goes wrong	A stolen pass works for anyone who holds it	A verified agent does something nobody intended to permit

Acting on someone’s behalf: intersection, never union

Almost every useful agent acts for a person: it reads a calendar, files a ticket, moves an invoice. That makes delegation the hardest part of the model, because two permission sets are in play at once. The safe rule is that effective authority is the intersection of the two, never the union. An agent must never reach something its principal could not, and a person’s broad entitlements must never flow through an agent built to do one thing.

The rule carries down a chain. When an orchestrating agent hands work to a helper, the helper’s pass must do strictly less — fewer permissions, a shorter life, a narrower audience. Widening on hand-down is the most dangerous behaviour in an agent system, because it lets a compromised leaf agent acquire the authority of the root. Standards work is explicit about the shape: token exchange keeps the acting party and the party acted for as separate claims rather than collapsing them (Source: IETF RFC 8693, OAuth 2.0 Token Exchange), and NIST’s attribute-based guidance evaluates each request against attributes instead of granting a standing role (Source: NIST SP 800-162).

One asymmetry matters to a buyer: authentication failures are loud, and authorization failures are silent. The agent was who it claimed, the call succeeded, and the damage surfaces later — hence deny-by-default, out-of-band approval on irreversible actions, and the recorded decision trail in the logging section.

The Agent Credential Lifecycle: Issue, Scope, Expire, Revoke, Attest

An agent identity is durable; the passes it uses are not. These five stages are the whole model, and each one is a question to put to any platform you evaluate. NIST states the target for the middle three plainly: each service should present a short-lived, cryptographically verifiable identity credential, authenticated per connection and reauthenticated regularly (Source: NIST SP 800-207A, Zero Trust for Cloud-Native).

Issue

A credential is minted on demand, against a registered agent identity, for an already-authenticated request. Nothing is pre-provisioned and nothing sits in a file the agent reads at start-up. Just-in-time issuance is what makes zero standing privilege achievable rather than aspirational.

Control to demandJust-in-time issuance against a registered principal; no static keys in config, images or env vars

Maps toOWASP NHI7, Long-Lived Secrets

Scope

The pass carries the smallest set of verbs on the smallest set of resources that finishes the task, plus the audience it may be presented to. Scope is expressed as capabilities, not roles: a role is sized for a job description, and an agent task is far smaller than one.

Control to demandCapability-style verb-on-resource scopes, evaluated per request; hand-downs may only narrow, never widen

Maps toNIST SP 800-162 (ABAC); OWASP NHI5, Overprivileged NHI

Expire

The credential dies on its own, on a timer measured in minutes, whether or not anyone noticed a problem. Expiry is the one control that works while your team is asleep, turning a leaked secret from an open door into a closing window.

Control to demandMinute-scale lifetimes with a hard ceiling; reauthentication on reconnection; no silent renewal beyond the ceiling

Maps toNIST SP 800-207A

Revoke

When something is wrong the pass must stop working now — and so must every pass handed down from it. Revocation that reaches only the parent leaves orphaned sub-credentials operating on borrowed authority.

Control to demandImmediate revocation that cascades to descendants; a decommissioned agent identity issues nothing further

Maps toOWASP NHI1, Improper Offboarding

Attest

Every issuance, hand-down, refusal and revocation is written at the moment it happens, into a store the system will not edit or delete afterwards. Attestation turns the previous four stages from claims into evidence an auditor can use.

Control to demandWrite-before-release event capture, tamper-evident storage, full parent-child lineage retained

Maps toEU AI Act Article 12 (record-keeping); Article 26(6) (six-month retention)

The last two stages are skipped most often and matter most under pressure. Revocation is often implemented at the parent only, so an incident response that looks complete leaves descendants alive; attestation is often implemented as application logging, so the record sits somewhere the compromised agent could write to. Ask for both to be demonstrated: revoke a parent pass and watch the children fail, then try to edit an event and watch the attempt be refused. The same instinct applies to scope — shrink-only hand-downs belong in the construction, not in a policy somebody has to configure correctly. Iternal builds all five stages into credential management for AI agents, so issuance, scope, expiry, revocation and attestation arrive as construction rather than configuration.

The Standards Landscape: OAuth, OIDC, Workload Identity and the Agent-Auth Drafts

No single specification defines agent identity end to end today. What exists is a set of mature building blocks designed for people and for workloads, plus active work aimed at the parts agents break. A buyer does not need to pick a winner — only to know which block each claim is standing on, and which parts are still moving.

The specifications in play for agent identity, and where each one fits
Specification	What it covers	Where it fits for agents	Status
OAuth 2.1 (with PKCE, RFC 7636)	Delegated authorization without sharing a password	The baseline most agent tooling already speaks; PKCE closes the interception gap for public clients	Established; OAuth 2.1 consolidation in progress
OpenID Connect	An identity layer over OAuth: who the authenticated party is, as verifiable claims	Supplies the assertion an agent platform exchanges for a narrower internal pass	Established
Token Exchange (RFC 8693)	Exchanging one token for another, acting party and subject kept as separate claims	The delegation primitive: an agent acting for a person, two identities intact	Established
SPIFFE / SPIRE	Workload identity: a short-lived, verifiable identity document per workload	An identity for the process an agent runs in, with no stored secret	Established in cloud-native estates
NIST SP 800-207A	Zero trust for cloud-native: per-connection authentication, short-lived credentials	The reference buyers cite for why minute-scale expiry is non-negotiable	Final
NIST SP 800-162 (ABAC)	Attribute-based access control: decisions from attributes, not standing roles	The authorization model that survives agents: scopes evaluated per request	Final
OWASP Non-Human Identities Top 10 (2025)	The ten most consequential machine-identity risks	The risk vocabulary to hold a design against; every lifecycle stage maps to one	Published 2025
Model Context Protocol authorization	How an MCP client and server authorize the transport between agent and tools	Where agent identity meets tool access, since tool calls are how agents act	Specified, evolving with the protocol
Agent-identity work at the OpenID Foundation and IETF	Open questions specific to agents: delegation chains, attestation, revocation at scale	Where the gaps in the established specifications are worked through in public	In progress — treat as direction, not as a requirement to conform to today

Read the table as two layers. The established rows solve authentication and delegation between systems, and are worth insisting on wherever an agent crosses a boundary you do not control. The in-progress row is where the agent-specific questions live: representing a delegation chain several agents deep, attesting an action whose actor is a model, propagating revocation across an elastic fleet. The posture that follows: adopt the mature specifications at your perimeters, and inside your own walls judge the properties rather than the acronym — a pass that expires in minutes, proves its holder, only ever narrows and lands on a record is defensible whichever specification eventually wins.

What to Log So an Auditor Can Reconstruct Who Acted

The question an auditor asks is narrow and unforgiving: who could touch what, when, and on whose authority? Answering it from a record is a decision made before the first agent ships; answering it from a reconstruction is what happens when logging was treated as telemetry. Seven fields per event is the difference.

The seven fields an agent identity event needs to be reconstructable
#	Field	Why the reconstruction fails without it
1	Timestamp and event type	Issuance, hand-down, refusal, revocation and use are different events; a record of successful use alone cannot show what was denied.
2	Acting agent principal	The registered identity, not the process ID or the host. Without it, every question about repeat behaviour becomes a correlation exercise.
3	On whose behalf	The person, team or system the agent acted for, kept as a separate claim so the two identities are never conflated.
4	Credential reference and expiry	Which pass was presented and when it was due to die — the proof that an action fell inside a valid window.
5	Parent credential lineage	Which pass this one descended from. With lineage a delegation chain reconstructs end to end; without it the trail stops at the first hand-off.
6	Requested resource and verb	What was asked for, at the granularity you authorize on, so scope decisions can be reviewed against real traffic.
7	Decision and reason	Allowed, denied or escalated for approval, with the rule that decided it. Refusals are the highest-signal records you keep.

Three properties the store itself needs

Written before the action completes. A record created afterwards can be missing exactly when it matters; issuance events should land before the pass reaches the requester. Outside the agent’s own authority. If a compromised agent can reach the store that records what it did, the record is a narrative rather than evidence — keep the audit path in a separate trust domain from the agent runtime.

Tamper-evident, not merely access-controlled. Regulation requires the records without prescribing how they resist editing: the EU AI Act requires high-risk systems to record events automatically across their lifetime, with deployers retaining those logs for at least six months (Source: EU AI Act, Article 12 and Article 26(6)). How the record proves it was not altered — hash chaining, append-only storage, write-once media — is your architecture decision, and it decides whether the evidence survives an incident.

Six months is a floor, not a target: match retention to how long a delegated action could stay undetected in your environment, and keep lineage as long as you keep the events. The risk vocabulary to hold the design against is the OWASP NHI Top 10; the wider control frame this sits inside is covered in the audit and traceability section of the AI Agent Security Checklist.

Working With the Identity Systems You Already Run

Nothing here argues for replacing your identity provider. The platforms you already run are the system of record for people, and the joiner-mover-leaver machinery around them took a decade to get right. Microsoft, Okta, Ping Identity and SailPoint are all extending that machinery toward agents — Entra Agent ID and the agent-identity capabilities the governance platforms have added through 2026 — so an enterprise standardized on one of them should expect its agent program to build on that investment.

What agents add is a population those systems were not built for: machine principals with no browser, no second factor and no access review, created and destroyed in minutes. The workable pattern is layered, not competitive. Your identity provider stays authoritative for people and the entitlements agents inherit from them; an agent layer registers the machine principals, issues their short-lived passes, enforces the narrowing rule and writes the record.

Settle one integration question early: which system is authoritative for what. If two systems both believe they own an agent’s entitlements, the effective permission set is whichever was evaluated last. Teams that want the pattern implemented against their existing stack can bring it into an AI agent development services engagement, where the identity model is designed alongside the agents rather than retrofitted after the pilot works.

Questions to Ask Before You Buy

Eight questions separate a platform that governs agents from one that stores their secrets more tidily. Ask for demonstrations rather than documentation on the middle four; those are the ones that behave differently under load and during an incident.

Can every agent be named, owned and reviewed from one record?

What good looks likeA registry entry per agent with an owner, a purpose and a review date — plus a way to find agents that have none.

What is the shortest credential lifetime the platform supports, and the longest it permits?

What good looks likeMinute-scale defaults with a hard ceiling. Ask what happens at the ceiling, and whether renewal is silent.

Is a stolen pass usable by whoever holds it?

What good looks likeHolder binding enforced by default and failing closed, not offered as an option to enable later.

Can a hand-down ever widen?

What good looks likeA structural guarantee that a child pass does strictly less than its parent, with widening refused automatically and recorded.

Does revocation reach the descendants?

What good looks likeA live demonstration: revoke a parent and watch the children fail, on your workload.

What exactly lands on the record, and can the runtime edit it?

What good looks likeThe seven fields above, written before the action completes, in a store the runtime has no authority over.

Where does the system run, and what leaves the perimeter?

What good looks likeDeployment on infrastructure you control, with a clear answer on outbound connections and key custody.

What does the first pilot look like, and how do we prove it ourselves?

What good looks likeOne real workflow, success criteria fixed before the start, and a revocation drill your own team runs.

How Iternal Implements This: AgentAuth

Iternal built AgentAuth on the model this guide describes, because the alternative — permanent keys handed to agents meant to act for minutes — is the pattern we kept finding in production estates. A pass is issued against a registered agent, narrowed to the task, timed to die on its own, and recorded before release. Four properties define it, each mapping to a stage of the lifecycle above.

Expires in minutes

Five minutes by default, an hour at the ceiling. A leak becomes a closing window, not an open door.

Proves its holder

Bound to its agent, a pass is useless to a thief. Enforcement is on by default and fail-closed.

Only ever shrinks

A helper’s pass must do less than its parent’s. Escalation is not forbidden by policy; it is impossible by construction.

Logs everything

Every issuance, hand-down, refusal, and revocation lands on a permanent record before the pass is even released.

Two deployment facts matter as much as the properties. AgentAuth runs on infrastructure you already own — the issuing office, the records and the signing keys stay on your side of the perimeter. And it sits beside what you run rather than replacing it: the identity systems you already operate plug in, and their credentials are exchanged for narrow internal passes, so an agent program does not become an identity migration. Where this guide is the concept, the product page is the mechanism.

AgentAuth

Give every agent a pass instead of a key.

Expiring, holder-bound, shrink-only credentials with a tamper-evident record — on your own infrastructure. See how AgentAuth issues, narrows, expires and records every agent credential.

Explore AgentAuth

Where to Start

Start with the record, not the technology. List the agents in your environment, name an owner for each, and mark the ones running on a human account or a shared key — that list is your program. Then take the two moves that pay back fastest: give the highest-blast-radius agent an identity of its own, and cut its credential lifetime to the shortest window its work needs. After that the sequence is the lifecycle in order, and each step is independently useful.

Two companion reads: the AI Agent Security Checklist, section 6 places these identity controls next to the other nine agent control domains, and AI agent development services covers building the agents themselves with this identity model designed in from the first sprint.

Frequently Asked Questions

What is AI agent identity?

AI agent identity is the distinct identity an AI agent authenticates with in its own right — its own principal in your directory and your logs, rather than a human account or a shared service key it borrows. It is what makes an agent’s actions attributable to that agent, scopeable to one task, and revocable without disturbing anyone else.

Why can an AI agent not just use a service account or a human login?

Three things break. Permissions become excessive, because the account was sized for a person’s whole job rather than the agent’s one task. Attribution collapses, because the log shows the human or the shared account, not the agent — the risk OWASP catalogues as NHI10, Human Use of NHI. And offboarding misses it: when the person leaves or the ticket closes, the agent’s access quietly survives.

What is the difference between AI agent identity and AI agent authentication?

Identity is the durable answer to “who is this agent?” — a registered principal with an owner, a purpose and a lifecycle measured in months. Authentication is the momentary act of proving that identity on a single connection, and it is settled by a credential measured in minutes. One agent identity issues thousands of short-lived credentials over its life; losing one credential should never mean losing the identity.

How long should an AI agent credential live?

Minutes, not months. NIST SP 800-207A describes the target directly: each service presents a short-lived, cryptographically verifiable identity credential, authenticated per connection and reauthenticated regularly. The OWASP Non-Human Identities Top 10 (2025) ranks long-lived secrets as NHI7 for the same reason: expiry, not detection, is the control that limits the damage of a leak.

Can an AI agent delegate its access to a sub-agent?

It can, and the rule that keeps delegation safe is that a handed-down credential must be narrower than its parent — fewer permissions, a shorter life, a smaller audience. The effective authority of an agent acting for a person is the intersection of the two permission sets, never the union. Anything else re-creates the confused-deputy problem one layer down.

What does an auditor need to reconstruct who acted?

Seven fields per event: when it happened, which agent principal acted, which person or system it acted for, which credential was presented and when that credential expired, what was requested, what the decision was, and which parent credential the pass descended from. With the lineage recorded, a chain of delegated actions reconstructs; without it, the trail ends at the first hand-off.

Does agent identity replace the identity provider we already run?

No. Identity providers and governance platforms are the system of record for people and for the joiner-mover-leaver process built around them, and agent identity works alongside that machinery rather than instead of it. Microsoft, Okta, Ping Identity and SailPoint are all extending their platforms toward agent identity; the agent layer registers the machine principals, issues their short-lived credentials and records what they did.

About the Author

John Byron Hanby IV

CEO & Founder, Iternal Technologies

John Byron Hanby IV is the founder and CEO of Iternal Technologies, a leading AI platform and consulting firm. He is the author of The AI Strategy Blueprint and The AI Partner Blueprint, the definitive playbooks for enterprise AI transformation and channel go-to-market. He advises Fortune 500 executives, federal agencies, and the world's largest systems integrators on AI strategy, governance, and deployment.

G Grokipedia LinkedIn X Leadership Team