Non-human identity (NHI)

A non-human identity (NHI) is any AI agent, service, script, or workload that can call an API, treated as a first-class identity with its own credential, lifecycle, and governance rather than borrowing a shared static service account. The shift the term describes is not the existence of machine credentials, which predate agents by decades, but the decision to manage each as an identity with a joiner-mover-leaver record rather than as a config value.

Identity and access management has always covered machines. What changed is population and behavior. Zylos research published in July 2026 frames the problem as joiner-mover-leaver lifecycle management for machines and notes that the NHI population grew faster than the governance built for it. Security Boulevard's July 2026 analysis draws the operative contrast: a service account sits in one system, holds one credential, and does one job, while an AI agent acquires permissions dynamically at runtime and spawns sub-agents. Security Boulevard also reports that only 22% of security teams treat agents as independent identities. Cloud Security Alliance and Okta material argues the same, that agents should be identity principals rather than features of the app hosting them.

What counts as a non-human identity

The category is broader than agents. Service accounts, API keys, OAuth clients, CI/CD runners, database users, webhook consumers, and container workloads all qualify in the conventional sense. Each authenticates without a person present, and each has historically been governed loosely compared to employee accounts, often created during an integration and never reviewed again.

Agentic systems add principals that behave differently. The AI agent decides at runtime which tools to invoke, so its effective permission set is discovered rather than declared. A multi-agent system creates transient sub-agents whose lifetimes are measured in seconds. Every Model Context Protocol server attached to a deployment is itself a principal, usually holding its own credential to the system behind it. The population is therefore larger and less static than inventory tools built for service accounts assume.

Why AI agents break service-account assumptions

The service-account model rests on three assumptions, and agents violate all three. The first is that the account's job is fixed, so its scope can be set once and audited rarely. An agent's job is described in a prompt that changes with every release, and tool calling means new capabilities can be added without touching the credential at all.

The second is one principal, one system. A support agent authenticates to a CRM, a billing platform, an order service, and a knowledge base within a single conversation, which makes it a bridge between security domains rather than a resident of one. Compromise or confusion in that principal is lateral movement by default.

The third is that the account acts only when a scheduled job or an application calls it. Agents act on natural-language input, which means an external party influences what the credential does. That is what turns identity into a security problem rather than an inventory problem, and it is why the confused deputy problem reappears in agent deployments: a valid credential used for a request nobody authorized.

The lifecycle problem

Human identity governance is built around joiners, movers, and leavers: provisioning tied to a hiring record, permission changes tied to role changes, deprovisioning tied to a departure date. Machine identities have no equivalent triggers, and agent fleets expose that absence at scale.

Provisioning is the easy part and the point at which scope inflates, because the fastest path to a working prototype is a credential broad enough to cover anything the agent might need. Rotation is where practice diverges most sharply from policy: a long-lived key embedded in an agent's configuration is one nobody wants to touch, since rotating it risks breaking a production flow. Deprovisioning is the failure that accumulates: an experiment is abandoned, a team reorganizes, an integration is replaced, and the credential remains valid, owned by nobody. Adjacent to this is shadow AI, where agents stood up outside any platform process never enter the inventory at all.

What agent-specific identity requires

Delegation chains. A record of who or what an action was taken on behalf of, preserved across hops. When a router hands work to a specialist agent that calls an MCP server that queries a database, the database sees one principal, and attribution stops at the last hop.

Scoped, short-lived credentials. Tokens minted per session or per task, narrowed to the resources that task legitimately touches, expiring on their own. This replaces rotation as a problem with expiry as a default, and it also constrains a confused deputy, since authority the agent never holds cannot be misused.

Attribution and observability. Logs that identify the specific agent version and identity behind each call rather than a shared account name. This rests on AI observability spanning the agent and the systems it touches, and it is what makes an incident reconstructable and a control narrative defensible to an auditor.

An action-side check. Identity establishes who is calling; it does not establish that the call was wanted. AI intent validation and tool-call guardrails cover that separate question, and NHI programs that stop at inventory and rotation leave it open.

What this means for a support organization

Support is one of the places where agent fleets meet regulated data soonest. An agent resolving a billing dispute touches payment records, one processing a return touches order and refund systems, one verifying a caller touches whatever backs identity checks. Each is a credential, provisioned by whoever was unblocking the integration.

The practical work is unglamorous. Enumerate every credential the agent platform holds, including those held by tools and connectors rather than by agents. Assign each an owner and an expiry. Separate credentials per agent so retiring one version does not require reasoning about what else shares its key. Scope read access to what a given conversation type actually needs rather than to the union of all of them.

The payoff is not only breach prevention. Data handling commitments, such as zero data retention arrangements, are only as strong as the set of principals that can reach the data, and an accurate answer to which identities touched which records is what turns a policy statement into something verifiable.