NHI Is Dead, Long Live Agentic Identity: Why Service-Account

Answer box

Non-human identity (NHI) was the right answer for service accounts, bots, and machine workloads. It is the wrong answer for autonomous AI agents. Agents need three properties that NHI doesn't offer cleanly: capability scoping at the action level, cryptographic delegation provenance through agent-to-agent chains, and continuous evaluation of whether each specific action is still authorized. Saviynt's 2026 CISO Risk Report finds 92% of organizations lack AI identity visibility. Okta's "AI Agents at Work 2026" and Strata's NHI playbooks both point to the same gap: NHI is the predecessor, agentic identity is the successor. This guide is the architectural blueprint.

What NHI got right, and where it stops

The non-human identity category emerged from a real problem: machine accounts now outnumber human accounts in most enterprises 100 to 1, sometimes 500 to 1. Service accounts, bots, robotic process automation jobs, CI/CD pipelines, microservices — each needed an identity, and treating them all like users created bloat and risk.

NHI got the basics right:

Distinct identity per workload, not shared.
Lifecycle management — provisioning, rotation, decommissioning.
Audit trails of machine activity.
Less-privileged access than the developer who created the workload.

NHI assumed three things that break for autonomous agents:

The workload's actions are bounded and predictable. A service account exists to do one thing. An autonomous agent reasons about novel situations and chooses actions dynamically.
The workload's authority is statically delegated. A bot's permissions are set at creation. An agent's useful authority shifts per task, per user it acts on behalf of, per agent it delegates to next.
The workload's identity is the right unit of audit. A microservice's logs are the audit unit. An agent's audit unit is the task, which spans multiple agents, tools, and identities — and the task is where humans, regulators, and incident responders need provenance.

When you operate autonomous agents against an NHI substrate, you discover these gaps experientially. Six months in, you've issued more identities than you can track, you can't tell which agent took which action under whose authority, and your kill switch revokes too much or too little. This is the universal complaint inside the Saviynt and Delinea CISO surveys.

The three forces creating a new tier

Force 1 — Capability scoping at the action level

A traditional NHI bot has a token that grants it "access to the customer database." An agent's task is "look up the customer's order history and offer a refund if and only if the previous return was incomplete." The bot-level grant is too broad: it lets the agent issue arbitrary refunds, query arbitrary customers, or write where it should only read.

The fix: tokens scoped to specific capabilities exercised in a specific task. Token = (read customer:1234 order history) AND (write refund:customer:1234 amount<200) AND (expire in 90 seconds). Each tool call gets its own token. Tokens are issued by a capability service, validated at the target system, and never reused.

This is sometimes called macaroon-style capabilities (from the original academic literature) or capability-scoped tokens in vendor marketing. The principle is the same: authorization is per action, not per identity.

Force 2 — Cryptographic delegation provenance

Real agentic workflows look like: user → planner → worker → tool → synthesizer → delivery. Six links. Each link delegates to the next. Some links are humans, some are agents, some are tools.

Without provenance, every system at every link sees only the immediate caller. Was this refund authorized by the user? Was the tool call requested by the planner or hijacked at the worker layer? Did the synthesizer receive its instruction from upstream or from a poisoned tool response?

The fix: each delegation step signs the chain it received. A receiving agent can cryptographically verify:

The original user request.
Every intervening agent that handled it.
The high-level goal at each step.
The specific tool calls each prior agent made.

This is the structural defense against goal hijack via handoff and inter-agent prompt injection. Without it, every link in the chain operates on faith.

Concretely: protocols like SPIFFE for workload identity, plus signed envelopes containing the request chain (see A2A Trust: Inter-Agent Prompt Injection), are the substrate emerging in 2026.

Force 3 — Continuous evaluation

NHI authenticates once and trusts thereafter. The bot has the token; the bot uses the token; the system checks the token; the system trusts the token.

Agents need authorization checked continuously. Has the user's session ended? Has the goal changed? Has the agent's risk score drifted? Has the tool being called become high-risk since the last check? Each action, not each session, needs to clear a policy gate.

This sounds expensive — and it is, naively implemented. In practice, the policy engine has to be optimized:

Cache authorization decisions per (user, agent, action class, scope) tuple with a TTL of seconds, not hours.
Pre-compute risk scores asynchronously and apply at decision time.
Inline policy evaluation at <10ms p99.

This is the operational difference between an NHI substrate (authenticate, trust) and an agentic identity substrate (authenticate, evaluate, act, log, repeat).

The three-tier agentic identity architecture

What this all adds up to is a three-tier identity model. Tier 1 you already have. Tier 2 is NHI. Tier 3 is the new layer.

Tier 1 — Human identity

Unchanged. Users authenticate via your IdP (Okta, Entra, custom OIDC). MFA. SSO. SCIM. Group membership drives base entitlements. This tier is mature.

Tier 2 — Workload identity (NHI)

Service accounts, bots, microservices, CI/CD jobs, automated workloads with static action sets. Identities issued via SPIFFE, vault-managed credentials, certificate-based mTLS. Lifecycle managed. This is what most "NHI platforms" cover today.

Tier 3 — Agentic identity

Each agent at runtime gets a distinct, ephemeral identity:

Workload identity (Tier 2) tied to the agent fleet — proves the agent runs the right code.
Task identity issued per task — represents the agent's purpose and scope for this specific job.
Delegation chain — signed envelope of every prior step in the agent's call chain.
Capability tokens — per-tool-call, scope-bounded, time-bounded. Issued just-in-time.
Continuous evaluation hooks — every consequential action re-validates against current policy.

A given autonomous agent will hold dozens of these identities in flight at any moment. They are issued and revoked at machine speed by a capability service operated by the AI control plane.

What needs to change in your IAM program

If you currently treat agents as Tier 2 NHIs, you have these specific gaps:

Shared agent identities. Multiple agents under one workload identity. Fix: per-agent identity. Fleet membership is metadata, not the auth unit.
Long-lived tokens. Agents holding API keys that last hours or days. Fix: short-lived, capability-scoped tokens issued per task.
Static permissions. Agent has the same permissions throughout its lifetime. Fix: dynamic, per-task capabilities.
No delegation provenance. Receiving systems can't prove the call chain back to the original user. Fix: signed envelopes with delegation history.
Session-level auth only. Authorization checked at the start of the agent's run and assumed valid throughout. Fix: per-action continuous evaluation.
Revocation that fails. Killing the agent's token leaves in-flight tool calls running. Fix: atomic kill across identity + token + bus + egress (see the 9-second delete piece).

Walk through each. The number you "yes" on is your current maturity score. Most enterprises score 1 or 2 of 6.

What this looks like in production

A worked example. An employee asks an internal AI assistant: "Process the Q2 refund batch."

Step 1 — User authenticates. Tier 1 identity. Token captures user, session, group, time.

Step 2 — Planning agent receives task. A new Tier 3 task identity is issued. Bound to the user's session token. Goal is signed: "process Q2 refund batch."

Step 3 — Planner delegates to worker agents. Each worker agent gets its own Tier 3 task identity, with a signed envelope: "original user X, goal Y, delegated by planner-task-Z, capability scope: refund processing."

Step 4 — Workers call backend systems. Each tool call gets a fresh capability token: "workload identity = worker-agent-fleet-v1, task identity = task-456, scope = read customer 1234 order history, expires in 90 seconds, signed by capability service."

Step 5 — Continuous evaluation. Before issuing the next capability token, the policy engine re-checks: user session still active? Agent risk score within bounds? Task goal still aligned with user intent?

Step 6 — Each step logged with full provenance. User ID, all task identities, all capability tokens issued, all tool calls, all responses. One searchable record per task.

Step 7 — Task complete. All task identities expire. All outstanding capability tokens are revoked. The audit record is sealed.

That is what "agentic identity in production" looks like. Most enterprises are years away from running it. The infrastructure to support it is starting to ship.

What vendors and standards are emerging

Selected signals from the first half of 2026:

NIST Center for AI Standards & Innovation is running an AI Agent Standards Initiative covering agent identity, authorization, and message integrity.
Okta's "AI Agents at Work 2026" explicitly proposes a tiered agent identity model.
Saviynt and Strata are extending their identity governance platforms to agent identity.
SPIFFE / SPIRE are being adopted as the workload-identity layer beneath agent-task identity.
CSA AI-CAIQ includes a section on agent identity that procurement teams are starting to enforce (see our 30-question RFP guide).
Anthropic's MCP has identity hooks; specific patterns (such as MCP "tunnels" in Claude Managed Agents, May 19, 2026) imply identity scoping at the connection level.
Microsoft Agent 365 + Entra ID extends Entra's identity model to Copilot Studio agents — a step toward Tier 3 inside the Microsoft stack.

Most of this is in flight. The standards aren't settled. The pragmatic move is to deploy the patterns above on your own infrastructure now, against whatever capability service your AI control plane provides, and migrate to the eventual standard when it lands.

Where AccuroAI fits

The Govern layer of AccuroAI implements all five components of Tier 3 agentic identity: per-agent workload identity issuance, task-identity issuance, signed delegation envelopes, capability-scoped tokens, and continuous evaluation hooks. The same policy engine that governs human prompts governs agent actions.

Customers running Tier 3 in production with AccuroAI report two things: (1) the audit story becomes dramatically simpler — one searchable record per task replaces a stitched view across IdP, agent framework, and backend logs; (2) the kill-switch story becomes operable — atomic revocation across identities + tokens + buses takes seconds, not hours.

If you want to evaluate where your current identity stack sits against the three-tier model, book a 30-minute architecture review and we will produce the gap map.

What to do this quarter

Inventory agent identities. Most enterprises have not. Use the MCP inventory playbook framework — agents follow the same pattern.
Score against the six gaps. Honest evaluation. Bring the score to your AI risk committee.
Stop shared agent identities. This is the lowest-friction fix and the highest-leverage. Each agent gets its own identity, even if the fleet is the new audit unit.
Pilot capability-scoped tokens on one high-blast-radius workflow.
Brief identity architects on Tier 3. Most enterprise IAM teams have not yet encountered the agentic identity concept. The conversation is shorter when they have the model already.
Reserve budget for an agentic identity capability — either through your AI control plane or through your identity governance vendor. The line item is appearing in 2027 budget cycles.

FAQ

Is "agentic identity" a real category or vendor marketing? A real category, still settling in vocabulary. The underlying primitives — capability-scoped tokens, signed delegation, continuous evaluation, per-agent identity — are established in academic and standards literature (capability-based security from the 1970s; ZTA and SPIFFE in the 2010s; ongoing NIST AI agent standards work). The combination as applied to autonomous AI agents is what's new.

Do I have to throw out my NHI platform? No. NHI is the foundation Tier 2 lives on. Tier 3 sits on top. Most NHI vendors are extending their platforms to cover agent identity; a few AI-native vendors are starting from the agent layer down. Either path can work.

What is SPIFFE and why does it matter for agents? SPIFFE (Secure Production Identity Framework for Everyone) is an open spec for issuing cryptographic workload identities. SPIRE is the reference implementation. Agents need workload identity at Tier 2 to attest what code is running; agentic identity at Tier 3 sits on top with task-level scope.

Is this what Gartner means by Guardian Agents? Adjacent. Guardian Agents is the broader category for AI that governs other AI; agentic identity is the IAM-specific layer within it. See our Guardian Agents explainer.

How does this map to EU AI Act and ISO 42001 requirements? EU AI Act Article 14 (human oversight) and Article 12 (record-keeping) both implicitly require per-action attribution — that's Tier 3. ISO 42001 A.5.10 and A.8.24 require traceability of AI processes — same. NIST AI RMF MAP-3 calls for resources and capabilities of AI systems to be tracked, which is the inventory side of Tier 3.

Sources: Saviynt CISO AI Risk Report 2026 · Okta — AI Agents at Work 2026 · Delinea Report — 90% of orgs pressure security to loosen identity controls · IANS — AI Agents Are Creating an Identity Security Crisis · TechTarget — Identity at RSAC 2026 · NIST Center for AI Standards & Innovation — AI Agent Standards Initiative.

NHI Is Dead, Long Live Agentic Identity: Why Service-Account Models Break for Autonomous Agents