NHI vs AI Agent Identity: What Changes for Agents

An AI agent authenticates with the same API keys, OAuth tokens and service accounts as any other workload, yet it chooses its own actions at run time, often on behalf of a person, so controls designed for predictable non-human identities stop being enough. Every AI agent identity is a non-human identity (NHI), but not every NHI is an agent. This guide sets out what stays the same, what changes when the workload reasons and acts, and how to decide which controls an identity needs. It compares the two as concepts, not products, and is for IAM teams, security architects and AI platform owners extending an NHI programme to agents. For the foundations see the Non-Human Identity (NHI) Guide and the Agentic AI Identity Guide.

Key takeaways

Agent identity is a subset of NHI, not a replacement. Inventory, ownership, short-lived credentials and decommissioning apply unchanged. Agents add requirements on top.
The change is non-determinism. A classic workload does what its code says. An agent decides which tool to call from model output, so its permissions describe what it could do, not what it will do.
Delegation becomes the norm. Agents often act for a user. That needs both identities in the token and the audit trail, not an agent impersonating a person or a person borrowing an agent's credentials.
Authorisation moves closer to the action. Static role grants are not enough; agents need per-task scopes, audience-bound tokens, approval steps for high-impact actions and a way to stop them quickly.
Use the test "does it choose its next action?". If yes, apply agent controls on top of NHI controls. If no, standard NHI governance is enough, even if a model is somewhere in the pipeline.

Definitions

Non-human identity (NHI): any identity used by software or a device rather than a person: service accounts, cloud roles and service principals, API keys, OAuth apps and tokens, certificates and workload identities. NIST's glossary describes a non-person entity as one with "a digital identity that acts in cyberspace, but is not a human actor". OWASP's Non-Human Identities Top 10 (2025) lists the main risks, from NHI1 Improper Offboarding to NHI10 Human Use of NHI. See Human vs Non-Human Identity.
AI agent identity: the identity, credentials and authorisation context of a software system that uses a model to plan and take actions through tools, APIs or other agents. OWASP's Top 10 for LLM Applications 2025 describes the risk as Excessive Agency (LLM06), whose root causes are excessive functionality, excessive permissions and excessive autonomy. OWASP's Top 10 for Agentic Applications (published December 2025) includes ASI03 Identity and Privilege Abuse.

The OpenID Foundation's October 2025 whitepaper, Identity Management for Agentic AI, makes the same point from the standards side: existing frameworks were not designed for recursive delegation chains, and agents should be treated as first-class identities in IAM infrastructure. NIST's National Cybersecurity Center of Excellence (NCCoE) has a project on software and AI agent identity and authorisation, with a concept paper open for comments as of November 2026.

Side-by-side comparison

Dimension	Classic NHI (service account, workload, integration)	AI agent identity
Behaviour	Deterministic: follows code and configuration	Non-deterministic: chooses tools and parameters from model output
Who it acts for	Itself (the application)	Itself, a user, or another agent; often a delegation chain
Permission model	Static role or scope sized to known calls	Needs per-task, time-bound and context-dependent scopes
Main threats	Leaked or long-lived secrets, over-privilege, orphaning, reuse	All of those, plus prompt injection steering actions, tool misuse, goal hijack, confused deputy through token passthrough
Behavioural baseline	Stable: same calls, same hosts, same volume	Variable: new tool sequences are normal, so anomaly detection needs task context
Lifecycle	Tied to the application release	Also changes when the model, prompt, tools or memory change
Audit question	Which workload made this call?	Which agent, acting for whom, on what instruction, made this call, and was a human approval required?
Kill switch	Disable or rotate the credential	Revoke credentials and tokens, pause the agent runtime, and stop downstream sub-agents
Ownership	Application or platform team	Agent owner plus the business owner of each delegated user's data

What stays the same

An agent programme should not start from scratch. These NHI controls apply to agents unchanged and are usually the fastest wins.

Inventory and ownership: every agent is registered with an owner, purpose and the credentials it uses. See the AI agent registry guide.
No long-lived secrets: use workload identity federation or a secrets manager with short-lived credentials, never keys in prompts, code or agent memory. See the AI Agent Credential Lifecycle and Rotation Guide.
Least privilege: the OWASP LLM06 mitigations (minimise extensions, minimise extension functionality and permissions, execute extensions in the user's context) are least privilege applied to tools.
One identity per agent: do not share an agent's credentials with other agents or people, which is OWASP NHI9 NHI Reuse and NHI10 Human Use of NHI in agent form.
Offboarding: when an agent is retired, revoke its tokens, OAuth consents and keys, not just the runtime.

What changes when workloads reason and act

Delegation instead of impersonation

RFC 8693 OAuth 2.0 Token Exchange distinguishes impersonation, where "A is B" within the rights of the token, from delegation, where "principal A still has its own identity separate from B". The act claim records the current actor and nested actors in a chain, and the may_act claim states who may act for the subject. For agents, delegation semantics preserve accountability: the resource sees both the user and the agent. See the OAuth Token Exchange and Delegation Guide and Delegation Chains and Attenuated Authority for AI Agents.

Audience-bound tokens at every hop

The Model Context Protocol (MCP) authorisation specification (version 2025-11-25) requires MCP clients to use RFC 8707 Resource Indicators, requires MCP servers to validate that access tokens were issued for them as the audience, and forbids token passthrough to downstream APIs because it creates a confused deputy. These rules are the agent equivalent of not reusing one NHI credential across services.

Authorisation at the moment of action

A classic NHI can be sized once. An agent's needed permissions vary per task, and a prompt injection can redirect it to any tool it holds. Effective patterns are per-task scopes issued just in time, policy checks on each tool call, spending and rate limits, and human approval for irreversible actions. See the AI Agent Authorisation Guide and the AI Agent Action Approvals and Spending Limits Guide.

Identity covers configuration, not just credentials

Changing an agent's model, system prompt, tool list or memory changes what it will do with the same credentials. Treat those as identity attributes: version them, record them in the registry, and re-review access when they change. See Agent Permission Drift.

Containment has to be fast and complete

Revoking one key does not stop an agent holding cached tokens or sub-agents with their own credentials. Plan a kill switch that pauses the runtime and revokes every credential in the delegation chain. See the AI Agent Kill Switch and Containment Guide.

When to apply NHI controls only, and when to add agent controls

Workload	Classification	Controls
Batch job that calls a model API to summarise documents, fixed code path	NHI	Standard NHI: owner, short-lived credentials, least privilege on the model API key
Chatbot that answers from a knowledge base with no tools	NHI	Standard NHI plus data access controls on the retrieval source
Assistant that can send email or create tickets for the signed-in user	AI agent	Delegated tokens with user and agent identity, narrow scopes, approval for external sends
Coding agent with repository write and CI access	AI agent	Per-task tokens, branch protections, sandboxed execution, human review before merge
Multi-agent workflow that spawns sub-agents	AI agent	Attenuated delegation at each hop, chain-aware audit, single kill switch
SaaS integration with an AI feature acting on your tenant's data	AI agent (third party)	Third-party NHI review, OAuth scope minimisation, token revocation plan

The deciding test is whether the workload chooses its next action. A model inside a fixed pipeline does not make the identity an agent; a tool-calling loop does.

Trade-offs and organisation size

Separate agent identity or extend NHI tooling: extending the existing NHI inventory and policies keeps one source of truth and one owner field. A separate agent platform can add tool-level policy and delegation awareness, but creates a second inventory to reconcile. Most organisations should extend first and add agent-specific enforcement where the NHI tooling cannot see tool calls.
Delegated access or agent service account: delegation keeps the user's permissions as the ceiling and records both identities, but depends on the target API supporting it. A dedicated agent service account works everywhere but can exceed any one user's rights. Use delegation for user-facing work and service accounts for back-office automation with narrow scopes.
Approval friction: approvals on every action make agents useless; approvals on none make them dangerous. Gate by impact: irreversible, external or high-value actions only.
Small organisations: start with the cloud or SaaS provider's built-in agent and workload identity features, a simple register of agents with owners, and a rule that agents never use personal tokens.
Large organisations: agents will appear in many business units and SaaS tools. Put agent registration into the same intake process as other NHIs, and set an organisation-wide policy on autonomy levels. See the AI Agent Autonomy Levels Framework.

Implementation approach

Extend the NHI inventory to agents. Add a type field for agent, and attributes for owner, model, tools, delegated users and autonomy level.
Remove static secrets from agents first. Move to federation or vault-issued short-lived credentials, and scan prompts, memory stores and logs for secrets.
Introduce delegation for user-facing agents. Use OAuth flows that keep the user and agent separate, such as token exchange with an actor claim, rather than shared service credentials.
Add tool-level authorisation and approvals. Start with irreversible or external actions (payments, deletes, outbound messages) and require approval in pilot.
Pilot with one agent in observe mode. Log every tool call with agent, user and task identifiers before enforcing policies. Tune, then enforce.
Test containment. Run an exercise that revokes the agent's credentials and pauses the runtime, and measure time to full stop.
Rollback: keep a policy toggle per agent to return to read-only or observe mode without redeploying, and keep the previous agent configuration version available.

Threat model, failure modes and a worked scenario for each option

Conventional NHI controls

Threat model. A service account or API key does the same thing every time, so the threat is theft and misuse of the credential, which OWASP catalogues as NHI7 Long-Lived Secrets, NHI5 Overprivileged NHI and NHI10 Human Use of NHI. Failure modes. Shared keys, no owner and no expiry. Controls. Inventory, least privilege, rotation and federated short-lived credentials. Decision criteria. These controls are sufficient when the workload's actions are fixed by code and reviewed before release.

AI agent identity controls

Threat model. An agent chooses its own actions at run time and can be steered by untrusted input, so a valid credential can be used for an unintended purpose without being stolen. This is the ground covered by LLM06 Excessive Agency and ASI03 Identity and Privilege Abuse. Failure modes. An agent forwarding the token it received to a downstream tool, so that one token unlocks every system in the chain. Controls. The Model Context Protocol authorisation specification shows what good looks like: clients must implement RFC 8707 resource indicators, servers must validate that tokens were issued specifically for them, and servers must not accept or transit other tokens. Pair that with RFC 8693 token exchange for delegation and per-action policy checks. Decision criteria. Add agent controls as soon as a workload decides which tools to call.

Worked scenario. A support agent reads tickets and can issue refunds through a payments tool. Under NHI controls alone it holds one broad API key. With agent controls, each tool server receives a token whose audience is that server only, refunds above a threshold require a human approval step, and a prompt injected through a ticket cannot reuse the ticketing token against the payments API, because the payments server rejects any token not issued for it.

Detection and measurement

Log per tool call: agent identity, delegated user, token audience and scopes, tool name, parameters (with sensitive values redacted), outcome and approval reference. The AI Agent Audit Log Schema Template gives a field list.
Alert on: tool calls outside the registered tool list, tokens presented to an unexpected audience, an agent credential used outside its runtime, bulk data reads by an agent, and approvals bypassed.

Metric	What it shows
Agents in the registry with a named owner and declared tools	Inventory coverage
Agents using static secrets	Credential hygiene; target zero
User-facing agents using delegation rather than shared credentials	Accountability in the audit trail
High-impact tool calls that passed an approval step	Control on irreversible actions
Time to fully contain an agent in exercises	Kill switch readiness

Common failure patterns

Agent runs on a developer's personal token: actions are attributed to a person, and the agent keeps working after that person leaves.
One integration token for many tenants: in the Salesloft Drift Breach 2025, OAuth tokens held by an AI chatbot integration were stolen from the vendor's environment and used to export data from many customers' Salesforce tenants. Customer-side lessons are scope minimisation, an inventory of connected apps and a tested revocation plan.
Token passthrough: an agent or MCP server forwards the user's token to downstream APIs, breaking audience binding and audit.
Broad standing scopes "in case the agent needs them": prompt injection then has the full scope to work with.
No re-review after configuration change: new tools are added to an agent without anyone re-approving its access.
Treating agents as human users: giving agents user accounts with MFA exemptions and interactive sign-in instead of workload identities.

Framework mapping

Framework	Reference	NHI	AI agent
OWASP NHI Top 10 2025	NHI5 Overprivileged NHI; NHI7 Long-Lived Secrets; NHI9 NHI Reuse	Core	Applies unchanged
OWASP Top 10 for LLM Applications 2025	LLM06 Excessive Agency	Not applicable	Core
OWASP Top 10 for Agentic Applications	ASI03 Identity and Privilege Abuse	Not applicable	Core
NIST SP 800-53 Rev. 5	IA-9 Service Identification and Authentication; AC-6 Least Privilege; AU-3 Content of Audit Records; AU-10 Non-repudiation	IA-9, AC-6	All four, with AU-3 and AU-10 covering who acted for whom
NIST CSF 2.0	PR.AA-01; PR.AA-05	Core	Core
MITRE ATLAS	AML.T0051 LLM Prompt Injection; AML.T0053 AI Agent Tool Invocation	Not applicable	Threats that turn agent permissions into actions
MITRE ATT&CK	T1528 Steal Application Access Token; T1550.001 Application Access Token	Core	Core

Practitioner checklist

Classify every AI workload with the test "does it choose its next action?".
Register agents in the NHI inventory with owner, model, tools and delegated users.
Remove static secrets from agents, prompts and agent memory.
Use delegation with both user and agent identity for user-facing agents; never impersonation by shared credentials.
Require audience-bound tokens and forbid token passthrough between agents, MCP servers and APIs.
Gate irreversible or external actions behind approval or policy checks.
Re-review agent access whenever its model, prompt, tools or memory change.
Log every tool call with agent, user and task identifiers.
Exercise the kill switch and measure time to full containment.

NHI vs AI Agent Identity: What Changes When Workloads Reason and Act