Non-human identity (NHI) credential lifecycle management is the discipline of treating every machine credential — service accounts, API keys, tokens, certificates, agent and MCP server credentials — as a managed asset with a beginning, a governed middle, and a guaranteed end. Most organizations run ten to fifty non-human identities for every human one, and the majority of those credentials were provisioned in minutes, scoped generously, rotated never, and decommissioned only by accident.

AI agents have turned this from hygiene debt into an active risk: agents are NHIs that act autonomously, delegate to other NHIs, and can be manipulated into misusing whatever credentials they hold. This post walks the five lifecycle stages and the operational discipline each requires. For the identity architecture underneath, see the complete identity and access guide for AI.

Why NHIs became the dominant identity problem

Human identity management matured because it had forcing functions: employees join, move, and leave through HR processes that trigger identity events. NHIs have no HR department. They are created by engineers under deadline, inherited by teams that did not create them, and referenced by systems nobody fully maps. The result is a population with three chronic properties:

  • Anonymity. Nobody can say what svc-integration-04 is for, who owns it, or what breaks if it is revoked — so it is never revoked.
  • Over-scope. Credentials get provisioned with broad permissions because narrow ones require understanding the exact need, and deadlines don't wait. The gap between held and needed permission grows from day one — the privilege-creep mechanism in its most common form.
  • Immortality. With no expiry and no owner, the default lifespan of an NHI credential is forever. Security reviews find five-year-old keys with production write access belonging to projects that shipped, pivoted, and died.

AI agents inherit all three problems and add autonomy: an agent doesn't just hold a credential, it decides when to use it, thousands of times a day, under reasoning that an attacker can influence. The distinctions between agent identity and other NHI classes are drawn precisely in machine vs workload vs agent identity.

Stage 1: Provision — identity before credential

The lifecycle's quality is set at creation. The rule: no credential without an identity record, and no identity record without three fields — an accountable human owner, a stated purpose, and an expected lifespan (or review date). This is minutes of friction that makes every later stage possible: rotation needs to know what the credential touches, monitoring needs to know what normal looks like, and decommissioning needs to know who to ask.

For AI agents specifically, provisioning means registration as a first-class principal — not the reuse of a team's service account. Per-agent identity is what makes attribution, scoping, and revocation surgical; the reasoning is laid out in why agents need their own credentials. The same applies to MCP servers: each registers with its own credential, never a shared integration key.

Stage 2: Scope — the credential encodes the minimum

Scoping turns identity into bounded capability. The credential (or the token exchanged for it) should carry the minimum permissions the stated purpose requires: resource types, operations, tenant boundaries, and — for agents — tool allow-lists per connection. Two patterns raise the ceiling on what scoping can do:

  • Short-lived tokens over standing credentials. The long-term credential (client secret, private key) lives in a secrets manager and is exchanged for short-lived, scoped access tokens at use time. A leaked token expires in minutes; the pattern and its trade-offs are covered in how to authenticate AI agents.
  • Audience binding. Tokens minted for one resource are rejected by every other — the RFC 8707 resource-indicator model the MCP authorization spec now mandates. It converts credential reuse and replay from an easy pivot into a dead end.

Stage 3: Rotate — automation or it doesn't happen

Manual rotation has a known failure mode: it is disruptive, so it gets deferred; deferred long enough, the credential's consumers multiply until rotation is dangerous, so it gets deferred permanently. The fixes are structural rather than motivational. Prefer credential types that rotate by design — short-lived tokens make rotation continuous and invisible. Where standing secrets are unavoidable, automate rotation through a secrets manager with dual-validity windows (old and new valid during transition), and alert on secrets past their rotation SLA. Store nothing in code, config files, or prompts — the retrieval path goes through the secrets manager, per secrets management for AI agents.

Rotation cadence should track exposure, not the calendar alone: a credential used by one internal batch job and a credential embedded in a customer-deployed integration have different leak surfaces and deserve different clocks.

Stage 4: Monitor — usage is the truth

The identity record says what the credential is for; usage logs say what it actually does. Monitoring closes the loop:

  • Attribution. Every use of every NHI credential lands in an audit trail tied to the specific identity — the precondition for everything else, and for agents, the substrate of behavioral baselining.
  • Anomaly detection. New source locations, new resources touched, volume spikes, and off-pattern hours are the classic signals of a leaked or misused NHI credential — machine identities are more baseline-able than humans because their legitimate behavior is regular.
  • Inactivity detection. A credential unused for ninety days is a decommissioning candidate; a permission unused for ninety days is a scoping-reduction candidate. Inactivity is the cheapest sprawl detector available and feeds access reviews automatically.

Stage 5: Decommission — the stage that defines your posture

Every credential's end state should be revoked-and-verified, not forgotten. Decommissioning discipline has three parts: triggers (project end, owner departure, agent retirement, inactivity threshold — each generating a review, with owner departure the most commonly missed), execution (revocation that propagates immediately across every surface the identity could touch, per the kill-switch propagation requirements), and verification (post-revocation authentication attempts should fail and be logged — the log entry proving both that the credential is dead and that something, somewhere, was still trying to use it, which is its own finding).

The decommissioning stage is where NHI programs succeed or fail, because it is the only stage working against entropy rather than with it. Organizations that measure one NHI metric should measure this: the count of credentials with no owner, no recent use, and no expiry. That number is your standing attack surface.

The lifecycle as a compliance artifact

Regulators and auditors increasingly ask NHI questions directly: SOC 2 access reviews extend to service accounts; the EU AI Act's logging and accountability obligations assume attributable agent identity; access-review evidence must cover non-human principals. A lifecycle run through a governance platform generates this evidence as a by-product — provisioning records, scope definitions, rotation timestamps, usage attribution, and decommissioning proofs, all queryable per the compliance checklist. A lifecycle run through tribal knowledge generates a spreadsheet-hunting exercise every audit cycle.

Common questions

What is a non-human identity (NHI)? Any identity that authenticates without a human at the keyboard: service accounts, API keys, OAuth clients, certificates, workload identities, AI agents, and MCP servers. NHIs typically outnumber human identities by an order of magnitude and, unlike humans, have no natural join/move/leave lifecycle forcing management.

What makes AI agents different from other NHIs? Autonomy and manipulability. A service account executes fixed code paths; an agent decides how to use its credentials under reasoning that adversarial content can influence, and it can delegate to other agents. That demands per-request verification, task-scoped delegation tokens, and instant revocation — stricter properties than traditional NHI classes require.

Where should a team start with NHI lifecycle management? Inventory with ownership: enumerate every NHI credential and attach an accountable owner and purpose to each. Anonymous credentials cannot be scoped, rotated, or safely revoked, so ownership is the gateway stage. Inactivity detection is the natural second step — it finds your decommissioning backlog for you.

How often should NHI credentials rotate? Short-lived tokens rotate continuously by design — prefer them wherever supported. For standing secrets, a common baseline is 30–90 days, adjusted by exposure: anything embedded beyond your infrastructure boundary or holding production write access sits at the aggressive end. A credential that cannot be rotated without an outage is itself a finding to fix.

Who should own NHI lifecycle management — security or platform engineering? The policy belongs to security; the paved road belongs to platform engineering. The programs that work make the governed path the easy path — identity issuance, scoping, rotation, and revocation available through the platform teams already use — so lifecycle compliance is a side effect of normal work rather than a parallel duty.